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
6.0
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.
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:
Confirmed affected versions by reviewing SiteApplication::authorise() in:
5.4-dev
6.0-dev
7.0-dev
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.
| Labels |
Added:
No Code Attached Yet
bug
|
||