search

w3c / webappsec-change-password-url

A Well-Known URL for Changing Passwords
https://w3c.github.io/webappsec-change-password-url/
Other
899 stars 27 forks source link

Add informative text clarifying that servers may use complex logic to determine where to redirect to #4

Open craigfrancis opened 5 years ago

craigfrancis commented 5 years ago

As this is to change a password for an existing account, and not for a forgotten password.

If the user is not currently logged on, I assume it's acceptable to redirect to the login page first, then on successful login, redirect to the change password form?

junderw commented 5 years ago

This is a pretty big problem... Having a unified link is useless if there's no direction on login pages and redirects.

I think the goal of this proposal is to make it easier for password managers to implement "auto-change-password" type features for all sites instead of having to implement on a site-by-site basis where it might change.

If so, some things are missing:

  1. If user is not logged in and they access the URL, what should the server reply with? This should be specific: what response code? What should the id elements of the username and password be? What should the id of the form for submission be?
  2. What should the id attributes of the old password, new password, and new password repeat boxes be? What should be the id of the form be?

This should allow the goal of automation for password managers to succeed.

leonklingele commented 5 years ago

Why not simply require /.well-known/change-password to redirect to the login page including a redirect query param if the user is not logged in? For example, /.well-known/change-password would redirect to /login?redirect_url=/user/change-password which will in turn redirect to the Change password page on successful login.

If I understood the proposal correctly there is no need for a special response code. Password managers check for the existence of that well-known URL endpoint and if it does exist, open it in a browser. Auto-filling in the credentials when being redirected to a login page could then be done just as usual.

hober commented 5 years ago

As with any other request a web server handles, the server is free to use whatever logic it wants to when determining where to redirect to. This spec doesn't need to make any additional normative statements for this; it's just inherent in how HTTP etc. work.

I'll add informative text clarifying this.

hober commented 5 years ago

Related Hacker News comments: