Conversation
nightpool
requested changes
Sep 24, 2019
nightpool
approved these changes
Sep 24, 2019
Regression from #11831
hiyuki2578
pushed a commit
to ProjectMyosotis/mastodon
that referenced
this pull request
Oct 2, 2019
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Regression from #11831
Thankfully a master-only, unreleased bug.
It is my mistake but the Devise and Warden code around that functionality is very misleading: The
sign_incall in theDevise::SessionsControlleris a lie, becausewarden.authenticate!the controller calls earlier already sets the session. Not only that, if you remove thewarden.authenticate!call from the controller altogether, there is still another part of Devise that will callwarden.authenticatewhich will succeed when the correct username/password are in the request params and also set the session. To add insult to injury,:database_authenticatablealso has a side-effect, by setting the rememberable token in a cookie. So as it turns out there was no way to keep the code DRY and run configured strategies without any side effects just to find the correct user record to check for 2FA setting.Instead we have to duplicate the functionality to perform the 2FA setting check, i.e. finding the user from LDAP, PAM or database depending on configuration in our own sessions controller. It is also important that all the Warden strategies fail for users who have 2FA enabled, so that the aforementioned fuckery does not get in the way.