WordPress.org

Making WordPress.org

Opened 15 months ago

Closed 15 months ago

Last modified 15 months ago

#3794 closed defect (fixed)

Using the locale switcher on login.wordpress.org loses original redirect_to value

Reported by: garrett-eclipse Owned by:
Milestone: Priority: normal
Component: Login & Authentication Keywords:
Cc:

Description

Hello,

I keep hitting this when going to login from either core or meta trac. If you go to login and enter credentials and submit you're returned to your ticket or page on trac. However if you go to login, switch locale and then enter credentials you're sent to your profile instead of returning to the original page.

Inspecting I see the redirect_to hidden input containing the original URL but once you switch locale it updates to https://login.wordpress.org/

This seems to be identical to what was experienced with #3640 so maybe the code was reverted?

Thanks

Attachments (1)

WordPress Login Redirect.mp4 (3.3 MB) - added by garrett-eclipse 15 months ago.
Walkthrough of reproduction

Change History (16)

#1 @Otto42
15 months ago

I can't reproduce this. When I switch the locale, then the redirect_to is in the new URL, along with the new locale. The resulting form has the correct redirect_to hidden parameter in it.

@garrett-eclipse
15 months ago

Walkthrough of reproduction

#2 @garrett-eclipse
15 months ago

Hi @Otto42 I attached a walkthrough of the issue. And here's the steps to reproduce.

  1. Open this ticket in incognito or a clean (non-loggedin) browser.
  2. Click Login
  3. Inspect and note the redirect_to is currently correct and referencing the original core trac ticket
  4. Select a different locale than the current one.
  5. Inspect and note the redirect_to is now set to https://login.wordpress.org/ instead of the original core trac ticket
  6. Enter credentials and submit
  7. Note you end up on your profile page instead of the original core trac ticket.

Hope that helps

#3 @Otto42
15 months ago

Okay, so you have to do it from a Trac instance then? Because when I try it using, say, /plugins, then it works properly.

#4 @Otto42
15 months ago

  • Resolution set to fixed
  • Status changed from new to closed

Fixed by [7648].

#5 @garrett-eclipse
15 months ago

Yes, that appears to be the case. I just tried with /plugins and found that when you go to login the redirect_to is available as a param on the URL so is available to $_GET while in trac this param isn't supplied.
Login URL found on /plugins - https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fplugins%2F&locale=en_US

So maybe the trac instances need this $_GET param added to their URLs. or can check both the $_GET and $_POST to the changes made on #3640

Also to note, there's two redirect_to hidden inputs when you go from /plugins whereas the trac logins only have one as they don't have the $_GET on it.

#6 @garrett-eclipse
15 months ago

You fixed it faster than I could type ;)

Seems to have resolved. But with that it updated the first redirect_to as well as the second so I wonder even if the changeset introduced #3640 which added the second hidden input for redirect_to is even necessary any longer.

#7 follow-up: @joyously
15 months ago

Would this apply to the Handbook pages also?
If I'm in Gutenberg Handbook and then log in, it redirected to Frontenberg.
I was on https://wordpress.org/gutenberg/handbook/extensibility/theme-support/
and it took me to https://wordpress.org/gutenberg/

#8 @joyously
15 months ago

Actually, the logout also takes me to the profile page (after verifying I want to log out).

#9 in reply to: ↑ 7 @garrett-eclipse
15 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to joyously:

Would this apply to the Handbook pages also?
If I'm in Gutenberg Handbook and then log in, it redirected to Frontenberg.
I was on https://wordpress.org/gutenberg/handbook/extensibility/theme-support/
and it took me to https://wordpress.org/gutenberg/

Taking a quick looks it's slightly unrelated but still an issue so I've reopened this for @Otto42 to look at.

This issue is specific to the actual 'Log In' button on those sites as it's providing a redirect_to param on the URL that's truncated and doesn't hold the full URL.

For instance your example - https://wordpress.org/gutenberg/handbook/extensibility/theme-support/
The URL on the login for this page has - https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fgutenberg%2F&locale=en_US

Another example is - https://wordpress.org/about/
The URL on the login for this page has - https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2F&locale=en_US

As to your logout issue;

Actually, the logout also takes me to the profile page (after verifying I want to log out).

I can't seem to reproduce that, for me it just logs out without needing to verify and returns to the original page.

#10 @joyously
15 months ago

I see that your examples have the locale, it's just that the redirct_to has a hard-coded value instead of the current page.

I don't know about the logout. I've never done that before today, actually, because I was trying to test Otto's fix. Maybe it was because I had two windows open or something. I was logging out from the Trac page.

#11 @dd32
15 months ago

In 7689:

Login: SSO: Correct the login_url() function to properly handle the $redirect_to variable that's passed.

See #3794.

#12 @dd32
15 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

That seems to have fixed it, it was incorrectly using the per-site login url (https://wordpress.org/gutenberg/wp-login.php - but with the wp-login.php part stripped out) as the redirect location, instead of letting login.wordpress.org just redirect you back to the page you came from.

I'd already changed the code locally for another ticket, but I can't find which ticket.. @obenland do you recall which one that login_url() change was for?

#13 follow-up: @obenland
15 months ago

It was #3108

#14 in reply to: ↑ 13 @dd32
15 months ago

Replying to obenland:

It was #3108

Ahah! Thanks

#15 @garrett-eclipse
15 months ago

Thanks @dd32 and @obenland it's working nicely there. You guys rock

Note: See TracTickets for help on using tickets.