Opened 2 years ago

Closed 6 months ago

#6058 closed defect (bug) (fixed)

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

Reported by: bozzmedia's profile bozzmedia Owned by:
Milestone: Priority: normal
Component: Login & Authentication Keywords:


Many features on 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 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, I thought it may have been resolved but with the new header it seems to have returned. Thanks for the consideration.

Change History (10)

#1 @bozzmedia
2 years ago

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.

#2 @Otto42
2 years ago

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

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?

#3 @bozzmedia
2 years ago

Using the Firefox or Chrome browsers on Windows 10 without being logged in, visit a plugin support forum. Select the link for logging in "You must be logged in to create new topics.", log in successfully.

For me this lands me at and not the plugin forum I was trying to make a post to.

Last edited 2 years ago by bozzmedia (previous) (diff)

#4 @Otto42
2 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

#5 @bozzmedia
2 years ago

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:

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.

#6 @dd32
2 years ago

  • Component changed from General to Login & Authentication

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

I would like to add referrerpolicy="no-referrer-when-downgrade" to login links (per, 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 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.

#7 @dd32
2 years ago

In 11490:

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

See #6058.

#8 follow-up: @Otto42
2 years ago

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

See , which is directly referenced by

#9 in reply to: ↑ 8 @dd32
2 years ago

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.

#10 @dd32
6 months ago

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

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

Note: See TracTickets for help on using tickets.