-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to built-in 2FA #3215
Comments
This is caused by an incompatibility between Given 2FA is now in the core of all auth we should migrate to it, see https://docs.allauth.org/en/latest/mfa/django-allauth-2fa.html |
This view is currently broken See #3215
This view is currently broken See #3215
There is not a lot of documentation yet, but having taken a look at the codebase, it should all work out of the box, except for requiring 2FA for staff users. There is an issue for this feature request already. Should we wait until this is added, or should we migrate anyway and write our own middleware to enforce 2FA for staff users (we can use |
If you want to go down this route make a fork of |
That sound nice. I'll give it a try. |
I made a PR to allauth a while ago to add middleware to force MFA for certain users, but it sounds as though it will not make it into allauth. Should I go ahead and migrate and add our own version of this middleware? |
Okay, we tried at least, shame as it seems a common use case. From the comments:
Is is clear to you how that would be done? |
No, I have not had a look at how the login stages work exactly. If we have to implement our own version, I'd stick to the middleware to be honest. |
I think that we should at least investigate it given they know the framework the best. It looks like we would need to adapt this in our account adapters: And then add an authentication stage: or I don't know if there would be any complications from ordering of the different stages. I definitely think that it is worth trying out this solution first and then selecting the most promising. |
Ok, I will investigate |
Ok, I think this works well. The only downside is that it is only triggered when someone logs in, not when they are already logged in like with the middleware, but I think this is fine, certainly for our use case. |
Cool! Yes I think that it is okay, people must log in every two weeks anyway. |
Ah testing this when integrated into our app (and not just in a test), it turns out that it doesn't work how I thought it would. If I add the MFA-Setup stage in the same way as the authenticate stage (no matter whether before or after since only one of the two gets hit anyway), you end up in an infinite loop because the MFA set-up requires reauthentication. |
Okay! Good feedback for the PR review. |
Looks like it won't be easy to get this to work with login stages. Thinking about other alternatives to middleware, we could add this to the |
If I understand this correctly at that point I think that they would be authenticated, so could navigate away from the configuration page and remain logged in? |
Ah yes, you're absolutely right. Sorry, Friday afternoon brain. |
Taking a closer look at the stages code, it's actually not clear to me why we end up in this infinite loop. We pass the reauthentication check and should get redirected to the activate view. I will continue looking into this on Monday. |
Ok, looking at this again with a fresh mind, we do indeed end up in an infinite loop because the user is not authenticated yet when hitting the I don't think that we want to change that prerequisite for the activate view, and I don't think there is a way to finish authentication first if we're using the stages approach. I can continue looking for an alternative implementation, or we go with he middleware approach, which we know works since we've been using it for a while. If we implement middleware, I will take another close look at which urls to allow. |
To summarise the discussion in the RSE meeting: we will go for middleware in GC for now, then see if a way of doing this appears in allauth afterall. |
https://grand-challenge.sentry.io/issues/4606002971/?project=303639&query=%21logger%3Acsp+is%3Aunresolved&referrer=issue-stream&statsPeriod=30d&stream_index=0
The text was updated successfully, but these errors were encountered: