No Code Attached Yet bug
avatar bergwerkweb
bergwerkweb
26 Mar 2026

What happened?

When a guest user opens a direct link to a menu item with access level "Registered" in a new browser tab, Joomla stores the intended redirect target in the User State (Session) instead of passing it as a URL parameter.
This is done in SiteApplication::authorise():

$this->setUserState('users.login.form.data', ['return' => Uri::getInstance()->toString()]);
$url = Route::_('index.php?option=com_users&view=login', false);
$this->redirect($url);

The issue is triggered by SameSite=Strict cookie policy: when a user clicks a link from an external context (another tab on a different domain, an email client, or any cross-site navigation), the browser does not send the existing session cookie with the initial request. Joomla therefore creates a new session, stores the return value in it, but after the login-triggered session regeneration this value is lost. The issue does not occur when the URL is typed directly into the address bar, as browsers treat this as direct navigation and send the cookie even with SameSite=Strict.

The login URL generated by this redirect contains no return parameter. The navigation intent is stored exclusively in the session, which is shared across all browser tabs. This means:
If the user has multiple tabs open, a subsequent request in any other tab can overwrite users.login.form.data in the session
After successful login (which triggers a session regeneration for security reasons), the stored return value may be lost or mismatched
The user lands on their profile page or the home page instead of the originally requested page

Version

6.0

Expected result

After logging in, the user should be redirected to the originally requested page — the one that triggered the 303 redirect to the login page.

The redirect to the login page should include the return target as a URL parameter:
/index.php?option=com_users&view=login&return=BASE64(originally requested URL)
This approach is already used in other parts of Joomla and is tab-specific, session-independent, and stateless.

Actual result

After logging in, the user is redirected to their profile page or the home page instead of the originally requested page. This is particularly reproducible when:

  • Opening a protected link directly in a new browser tab
  • Having multiple tabs open simultaneously
  • The session was not yet established at the time of the initial request

System Information

Confirmed affected versions by reviewing SiteApplication::authorise() in:

5.4-dev
6.0-dev
7.0-dev

Additional Comments

The issue becomes most visible when the session is not yet established at the time of the initial request — for example when opening a direct link in a new browser tab with no prior session context.

The fix should ensure that SiteApplication::authorise() passes the return URL as a Base64-encoded return parameter in the login redirect URL, consistent with how other parts of Joomla already handle this:

$url = Route::_( 'index.php?option=com_users&view=login&return=' . base64_encode(Uri::getInstance()->toString()), false ); $this->redirect($url);

The setUserState call for users.login.form.data can either be removed entirely or kept as a fallback — but the URL parameter should take precedence, as it is tab-specific and survives session regeneration.

Security note: An open redirect concern is sometimes cited as the reason for using User State over a URL parameter. However, Joomla already validates the return parameter against the site's own domain before redirecting, which is sufficient to prevent open redirect attacks.

avatar bergwerkweb bergwerkweb - open - 26 Mar 2026
avatar joomla-cms-bot joomla-cms-bot - change - 26 Mar 2026
Labels Added: No Code Attached Yet bug
avatar joomla-cms-bot joomla-cms-bot - labeled - 26 Mar 2026
avatar bergwerkweb bergwerkweb - change - 26 Mar 2026
The description was changed
avatar bergwerkweb bergwerkweb - edited - 26 Mar 2026

Add a Comment

Login with GitHub to post a comment