Opened 14 years ago
Last modified 6 years ago
#16482 new defect (bug)
Visibility: password-protected breaks with redirected domains
Reported by: | monkeyhouse | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0.4 |
Component: | Login and Registration | Keywords: | has-patch dev-feedback |
Focuses: | Cc: |
Description
Pre-requisite to reproduce: domain.com must redirect to www.domain.com (haven't tested with other subdomains than www, but I'm sure it would be the same).
- password protect a page
- visit domain.com/protected (which redirects to www.domain.com/protected)
- enter password
- something about the redirect OR the way the password is stored/checked is broken; you are redirected to the wp-admin (WordPress login) page.
Sanity check:
- password protect a page
- visit www.domain.com/protected (requiring no subdomain redirect)
- enter password
- successful log-in
Attachments (3)
Change History (14)
#2
@
14 years ago
- Keywords needs-patch added; reporter-feedback removed
Confirmed.
- Visited http://127.0.0.1/wordpress/password-protected-post/
- Entered password, Form submitted to http://localhost/wordpress/password-protected-post/
- Redirected to http://localhost/wordpress/wp-admin/
#3
follow-up:
↓ 4
@
14 years ago
This is caused by wp-post.php using wp_safe_redirect(wp_get_referer());
for the redirection.
Since the referer is set to http://127... instead of http://localhost.. and i'm logged in, it'll redirect me to the WordPress admin.
Ideally, the best way to do this would be to POST the post_id along to wp-pass.php as well, and redirect to get_permalink($post_id);
#4
in reply to:
↑ 3
;
follow-up:
↓ 9
@
14 years ago
- Keywords has-patch added; needs-patch removed
Replying to dd32:
Ideally, the best way to do this would be to POST the post_id along to wp-pass.php as well, and redirect to
get_permalink($post_id);
Taken a slightly different approach by forcing _wp_http_referer to be the permalink. Was unable to quickly reproduce the problem for testing, but this should work.
#5
@
14 years ago
makes a bit more sense there.
Also related, and I'll probably fix at the same time: #16483
#6
@
12 years ago
- Keywords 2nd-opinion added
I was able to recreate the problem with version 3.5-alpha-21751 and installed the patch.
The patch corrected the redirect for me. I am unsure if there may be a better way to handle this but it works.
#8
@
11 years ago
- Component changed from General to Template
- Milestone changed from Awaiting Review to 3.9
#9
in reply to:
↑ 4
@
11 years ago
- Component changed from Template to Login and Registration
Replying to duck_:
Replying to dd32:
Ideally, the best way to do this would be to POST the post_id along to wp-pass.php as well, and redirect to
get_permalink($post_id);
Taken a slightly different approach by forcing _wp_http_referer to be the permalink. Was unable to quickly reproduce the problem for testing, but this should work.
#10
@
11 years ago
- Milestone changed from 3.9 to Future Release
After nearly committing this patch (changing esc_attr() to esc_url()), I noticed that it would cause a redirect back to the post, not to the screen they are on (such as an archive page). Let's at least make sure we are OK with that first.
#11
@
9 years ago
- Keywords dev-feedback added; 2nd-opinion removed
- Severity changed from minor to normal
Looks good patch wise. I think it's fine to send them back to the post, because they're logging in because they want to access that post. It'd be better if it went back to the same screen if possible
Tried the procedure you describe and it works fine for me. Are you using server rewrite rules to do the non-www -> www redirect?