Strange behavior of Admin UI login #738
Comments
|
Database file from the test server: https://we.tl/t-sB4tAC4Dwd |
|
Compose and env files: |
|
I did a fresh install of 1.5 and upgraded to latest master. This seems to trigger the behavior at the same frequency as I'm seeing in production! Logs don't tell much: Basically I did: After waiting for things to settle, I tried login in. Couldn't login, even after 20x |
|
I could also reproduce this behavior, when I want to create an alias. I noticed it when testing #737 Normally there is (as you mentioned) a 302 redirect after successfully creating an alias: I could pass it with smashing the "Save" button very often. Also the behavior with the login page happens sometimes on my dev environment. |
|
Finally got screen recording to work 😆 . But I'm glad someone else can reproduce it. Almost started to worry it was the phase of the moon or something. |
|
I cannot reproduce the issue so I am mostly fishing. Not everything sounds consistent with it but it could be an issue with csrf checks. Could you try setting Also, you mention the redirection failing. But in the case of an alias creation for instance, does the alias get created or does the whole create-then-redirect fail? The former would eliminate my first hypothesis while the latter woule make wtform checks, especially csrf, very probable culprits. |
|
Could you check from the browser that all post requests, including the failing ones, contain a valid session cookie and the hidden csrf token as part of the submitted form? |
|
Also, I am assuming there is no significant delay between displaying the page that contains the form and posting the form itself (meaning << 1 hour). Is that assumption correct? |
|
So, one advancement. At one point login succeeded and I was not able to reproduce. After getting rid of the session cooky in my browser, this behavior came back. No new cookies are received at any point, even after a number of tried logins. Recap:
|
|
Small note, after changing |
|
Deleting the cookie again on my side continued the behavior. I'll continue with your suggestions now, |
|
csrf token is set in the form.
|
|
csrf is actually set twice to the same value: Setting |
As a matter of fact, we first cam across this problem in our psql branch. Because I though we did something wrong, I enable full verbosity on the database logs, allowing us to see what's happening. I'll cite my comment from the PR:
|
|
On my setup, the issue disappears if I set WEBROOT_REDIRECT=/admin |
@ofthesun9 You are sure its because of the env variable? Because for me the issue disappear for a while, when I just doing
The alias doesn't get created. Only after clicking the |
|
@hoellen
|
|
Now, the other way around :-)
|
|
@ofthesun9: Changing @kaiyou:
I don't believe we are managing the cookies directly in our app? I start to suspect flask-login to have a bug. I believe this was updated also in the admin refactor. |
muhlemmer
added
priority/p0
|
It seem to be CSRF tokens issues. We've modified the `/login' view: This is giving us the following logs: Sometimes a cookie gets passed back to the browser. (Usually the first time after restarting the container). The request that return the cookie looks like: So now the mis-match gave us a session cookie. Subsequently, we can now login: So now I logged out and deleted the cookie again. Browsing to the admin page (GET): No form errors, but also no cookie. |
|
@kaiyou: We have quite some injected code in https://github.com/usrpro/Mailu/tree/trouble. Maybe you want to reuse it. It includes the following:
We can see now, with setting of (4) a cookie is always send. Perfect. Put the cookie does not contain the CSRF token.... Somehow flask_wtf is not appending it to session. Not even when calling directly. There are quite some changes to the flask session and cookie interface, but I could find anything apparent there either, but maybe it broke something in flask_wtf, which has not been updated after the release of flask 1.0? |
The init script was pushing an application context, which maked flask.g global and persisted across requests. This was evaluated to have a minimal security impact. This explains/fixes Mailu#738: flask_wtf caches the csrf token in the application context to have a single token per request, and only sets the session attribute after the first generation.
Fixes #738 regarding application context
As discussed on Matrix. It seems that the login "failures" as noted in #670 are back.
In short
When doing a login on the admin UI, it happens from time to time that the login screen is presented once again. Looking in the logs, the
POSTis returned with a status200(success), instead of a302(redirect). This behavior is not consistent. Also, it seems that this behavior affects otherPOSTrequests, like creating a domain.It seems that the behavior exposes more in my production environment, 2 out 3
POSTrequest don't work. This environment is on Docker Swarm, with a replicated front and a single Admin.main.dbresides on a local file system. This might be due to the Docker env, network or the fact that the DB originated from a 1.5 installation.Reproduction
I was able to reproduce this on a test server with docker-compose setup. However, the behavior expresses less frequent. (Perhaps 1 out of 5). On this environment it seems that it did not expose using a database created with the latest master, only with an updated database.
Checkout a version from before the merge of #670. Build images, run mailu and setup the first user.
At this stage I verified that login behaved "normal". I logged out and proceeded to update.
Now, during log-in the behavior exposed as described above. Here are the admin container logs:
You can see that there are two POST requests that returned a 200. This where the ones where login did not work as supposed. All the other output are the succeeded attempts.
The text was updated successfully, but these errors were encountered: