-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add informative text clarifying that servers may use complex logic to determine where to redirect to #4
Comments
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:
This should allow the goal of automation for password managers to succeed. |
Why not simply require 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. |
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. |
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?
The text was updated successfully, but these errors were encountered: