WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 weeks ago

#16482 new defect (bug)

Visibility: password-protected breaks with redirected domains

Reported by: monkeyhouse Owned by:
Milestone: Future Release Priority: normal
Severity: minor Version: 3.0.4
Component: Login and Registration Keywords: has-patch 2nd-opinion
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).

  1. password protect a page
  2. visit domain.com/protected (which redirects to www.domain.com/protected)
  3. enter password
  4. 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:

  1. password protect a page
  2. visit www.domain.com/protected (requiring no subdomain redirect)
  3. enter password
  4. successful log-in

Attachments (1)

16482._wp_http_referer.diff (811 bytes) - added by duck_ 3 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 solarissmoke3 years ago

  • Keywords reporter-feedback added; visibility password removed

Tried the procedure you describe and it works fine for me. Are you using server rewrite rules to do the non-www -> www redirect?

comment:2 dd323 years ago

  • Keywords needs-patch added; reporter-feedback removed
Last edited 3 years ago by dd32 (previous) (diff)

comment:3 follow-up: dd323 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);

comment:4 in reply to: ↑ 3 ; follow-up: duck_3 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.

comment:5 dd323 years ago

makes a bit more sense there.

Also related, and I'll probably fix at the same time: #16483

comment:6 MikeHansenMe20 months 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.

comment:7 nacin3 months ago

#23412 was marked as a duplicate.

comment:8 nacin3 months ago

  • Component changed from General to Template
  • Milestone changed from Awaiting Review to 3.9

comment:9 in reply to: ↑ 4 nacin3 months 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.

comment:10 nacin3 weeks 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.

Note: See TracTickets for help on using tickets.