Skip to content
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

[6.x] Implement new password rule and password confirmation #30214

Merged
merged 4 commits into from Oct 8, 2019

Conversation

@driesvints
Copy link
Member

commented Oct 8, 2019

These changes add a new password validation rule and the new password confirmation functionality.

The validation rule offers to validate a password input field and checks if the password matches the currently authed user's password. You can also pass a guard name as a parameter.

The password confirmation functionality behaves exactly like the Github confirmation screen, allowing you to set a password.confirm middleware on sensitive routes you want password protected. When a user enters a valid password, the time will be added to the session and its session will stay valid for a default of three hours (can be configured in the auth.php config file here: laravel/laravel#5129). Underneath the hood it makes use of the intended url to redirect the user to wherever they were going when the password confirmation was done.

Screen Shot 2019-10-08 at 13 24 35

Some remarks:

  • I went back and forth on some other naming like "reauthenticate" and "reconfirm password" but eventually settled for what was displayed in the UI (like Github)
  • The auth.password_timeout config option might need a better name but couldn't think of one
  • The "guest" method name of the Redirector class might need a rename because I noticed that this is actually a bad naming for what it actually does.

Feel free to provide feedback.

Kudos to @freekmurze, @mpociot, @christophrumpel and all the others that helped out with validating this idea. I first started working on this but later discovered this article below by @browner12 which inspired me a bit for this PR. Thanks!

laravel/ui PR: laravel/ui#34
laravel/laravel PR: laravel/laravel#5129

driesvints added 2 commits Oct 4, 2019
driesvints added 2 commits Oct 8, 2019
@taylorotwell taylorotwell merged commit 8b82aa3 into laravel:6.x Oct 8, 2019
1 of 2 checks passed
1 of 2 checks passed
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/styleci/pr The analysis has passed
Details
@driesvints driesvints deleted the driesvints:password-confirmation-rule branch Oct 8, 2019
@arcanedev-maroc

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2019

Thanks @driesvints 👍

@freekmurze

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

I very much like the functionality, but I find the name is a bit confusing.

If someone now says to you "I have a problem confirming a password", does that problem concern:

  • a problem with the second time you need to type your password when initially setting your password
  • a problem with this middlemare.

I think a name like Reauthorise would be better, Reconfirm could also be considered.

@browner12

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2019

Glad I could be an inspiration! Happy to see this in the core.

Couple of comments/questions:

  • 3 hours seems excessive for the default. Obviously this is a subjective value, but I would petition for more around the 1 hour mark.
  • Was the timer "reset" specifically left out or are you open to adding this functionality? The reset means whenever you visit an elevated security page, your timeout gets reset, so you don't need to keep re-authenticating.
  • Did you give any thought to allowing this to work on POST routes? One way I had considered doing this was adding all POST data as a hidden input on the re-authentication view. It's definitely a tricky question. If we don't want to support POST routes right away, we should add a disclaimer to the newly written docs.

My last point is a little more overarching. I think the way we handle injecting functionality into Controllers with built in features (auth, password resets, elevated security) is a little off. Having the Traits is great, but the methods of the Traits are too all inclusive and therefore (IMO) restrictive. A trait method should not encompass an entire route Controller method. I think it would be better if the methods were more "single responsibility", and then the programmer would use them to compose their own Controllers. This gives the programmer the freedom to make the flow of the Controller to work however they like, while also having the consistency of the methods in the Traits. This also prevents us from having to add a bunch of properties to customize every single use case. Maybe I'll bring this up elsewhere, because this is a concern I have with all of these features.

@driesvints

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2019

3 hours seems excessive for the default. Obviously this is a subjective value, but I would petition for more around the 1 hour mark.

Github also does "a few hours", hence the reason why I decided on this value.

Was the timer "reset" specifically left out or are you open to adding this functionality? The reset means whenever you visit an elevated security page, your timeout gets reset, so you don't need to keep re-authenticating.

Left out intentionally but I don't mind adding that either way. Not sure how @taylorotwell feels about that.

Did you give any thought to allowing this to work on POST routes? One way I had considered doing this was adding all POST data as a hidden input on the re-authentication view. It's definitely a tricky question. If we don't want to support POST routes right away, we should add a disclaimer to the newly written docs.

This is gonna be a bit tricky indeed. Not sure how to exactly solve this. In any case, the current middleware will still protect post routes, they'll just fail if people attempt to execute them manually.

I think the way we handle injecting functionality into Controllers with built in features (auth, password resets, elevated security) is a little off.

This is more of a discussion for the ideas repo.

@arcanedev-maroc

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2019

Hi @driesvints,

What if the user has an account without a password (Socialite) ?

What is the best approach ?

  • Resetting the password
  • Or skip the password confirm
@driesvints

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2019

@arcanedev-maroc this would only work with a password based flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.