Logging in to wp.org does not direct you back to the context you were in upon successful login

[bozzmedia]

Many features on wp.org require a user to login before they can do something. Often you are looking at a support forum, or ready to leave a review and you are prompted to login.

The user selects login, logs in successfully and is simply redirected to the wp.org front page. The context that was important for the login procedure is lost. Using the browser back button can bring you back, but doesn't recognize your login state so you must refresh.

I have noticed this issue is previous instances of wp.org, I thought it may have been resolved but with the new header it seems to have returned. Thanks for the consideration.

[bozzmedia]

Another issue I just noticed: if you're already logged in, but a forum post doesn't notice you are logged in already, if you select "You must be logged in to reply to this topic." it simply dumps you to the front page without context.

[Otto42]

You will need to provide an exact procedure for duplicating this, because when you are viewing a page, then go to the login screen from that page, and login, you *are* redirected back to where you started properly. This has worked ever since we unified the login system.

So, how can I reproduce your results?

[bozzmedia]

Using the Firefox browser on Windows 10 without being logged in, visit a plugin support forum. Select the link for logging in ​https://login.wordpress.org/?locale=en_US, log in successfully.

For me this lands me at ​https://wordpress.org/ and not the plugin forum I was trying to make a post to.

[Otto42]

@bozzmedia Okay, thanks. I can reproduce this on plugin support pages. It works from other pages though, so might be something specific to those.

[bozzmedia]

I appreciate you looking into it, sorry I was short on details earlier.

I noticed on the plugin reviews page the similar log in to leave a review link looks more like this:

​https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Fplugin%2Fclassic-editor%2Freviews%2F%23new-post&locale=en_US

I also wonder about the header login link, I feel that would be another place to add the contextual redirection. I could have sworn it did at one point, but I'm relying on my memory at this point.

[dd32]

This is potentially due to some browser changes around referrers, specifically, that I'm not certain login.wordpress.org is the same origin as all the other dotorg things where you see the login links.

​https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default

I would like to add referrerpolicy="no-referrer-when-downgrade" to login links (per ​https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy), but might as well just ensure that all login links include the redirect_to, rather than relying upon the referrer, if we're going to go through an update/check all login link locations.

~7 years ago <meta name="referrer" content="always"> was added to the WordPress.org header, which may have worked for a short time to resolve some of this, but was recently removed during the header migration as always is not a valid value for the field (There were login issue reports like this before then) and browsers were flagging it as invalid/using-default-instead.
Restoring that with unsafe-url instead would have the original intended effect, but I'd prefer to a) Use the HTTP Header instead, and b) use origin-when-cross-origin instead.

[dd32]

In 11490:

SSO: Always include the current URL as the redirect_to (unless specified differently) on login URLs.

See #6058.

[Otto42]

Meta referrer = always was a valid header at the time it was added.

See ​https://wiki.whatwg.org/wiki/Meta_referrer , which is directly referenced by ​https://developers.google.com/search/blog/2012/03/upcoming-changes-in-googles-http

[dd32]

Replying to Otto42:

Meta referrer = always was a valid header at the time it was added.

Yeah, I'm not questioning that (although I did when I removed it, because no current documentation seemed to acknowledge it, or referred to earlier drafts of the standard, if we can call it a standard) - just pointing out that it wasn't operating as expected in recent times.

[dd32]

I'm marking this fixed with [11490], I don't think I've seen reports of this for a while.