Opened 9 years ago
Last modified 5 years ago
#34697 new defect (bug)
Password (re)set form fails when addressed as /wp-login.php/
Reported by: | friedcell | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.3.1 |
Component: | Login and Registration | Keywords: | bulk-reopened needs-patch |
Focuses: | administration | Cc: |
Description
setcookie
in resetpass uses $rp_path
to set the path for the cookie, but does not use the same $rp_path
when setting up the form action in HTML. This means that the cookie can be set to a path where it will not be submitted by the browser on post and thus the form will fail.
Easily reproducable by adding changing the reset password link from /wp-login.php?...
to /wp-login.php/?...
For some reason Firefox works (submits cookie), but Chrome and IE fail (don't submit cookie).
Attachments (1)
Change History (7)
#2
@
8 years ago
I'm also thinking about if this is a valid case, what other cases could happen so we can prevent them all.
I'm almost leaning towards wontfix
because as far as I know, any url that has this in it was tampered with somewhere.
#3
@
8 years ago
The proper fix would likely be to make sure that the cookie is set so that the path that matches the form action.
I'd go for getting the "resetpass" url and using the path part of it to set the cookie path - that way custom reset password URLs would still work and cookie is set to the proper path.
#4
@
8 years ago
Code at https://github.com/WordPress/WordPress/blob/master/wp-login.php#L338 should have the same way of generating the URL as the cookie setting code at https://github.com/WordPress/WordPress/blob/master/wp-login.php#L576
IIRC the problem was a plugin that set a custom "forgot password" email...
34697.diff simply rtrims off any additional slash so the cookie is set correctly in this situation. However, as I'm thinking about it, what other case would this even happen besides someone copy/pasting a url and editing it? Is there a plugin doing it wrong or something?