[Bug] Login broken after Shiro upgrade from 2.1.0 to 2.2.0 — session attributes lost on login

[sepe81]

Search before asking

• I had searched in the issues, including closed issues and found no similar issues.

Environment

• Apache Shiro upgraded from 2.1.0 → 2.2.0
• Native session management (DefaultSecurityManager)

Shiro version

2.2.0

What was the actual outcome?

Shiro 2.2.0 introduced session fixation protection: on Subject.login(), the pre-login session is stopped and a new session with a rotated ID is created.
Any session attributes written before subject.login() returns are written into the dead session and silently lost.

What was the expected outcome?

Session attributes written before subject.login() are accessible in the session after login completes.

How to reproduce

The following test added to DefaultSecurityManagerTest demonstrates the scenario — an attribute written before login must survive session rotation:

@Test
void sessionAttributesSurviveLoginSessionRotation() {
    Subject subject = SecurityUtils.getSubject();

    Session preLoginSession = subject.getSession(true);
    preLoginSession.setAttribute("tenantId", "ACME");
    Serializable preLoginSessionId = preLoginSession.getId();

    subject.login(new UsernamePasswordToken("guest", "guest"));
    assertTrue(subject.isAuthenticated());

    Session postLoginSession = subject.getSession(false);
    assertNotNull(postLoginSession);

    assertNotEquals(preLoginSessionId, postLoginSession.getId(),
            "session ID should change on login (session fixation protection)");
    assertEquals("ACME", postLoginSession.getAttribute("tenantId"),
            "session attributes set before login must survive session rotation");
}

Workaround

All session writes moved to after subject.login() returns.

The underlying cause should ideally be fixed in Shiro itself (attribute snapshot/restore in DefaultSecurityManager).
Once a Shiro release ships such a fix, the workaround introduced here can be reverted.

Reference

May be related to upstream #2704.

Debug logs

No response

[sepe81]

@lprimak Thank you for looking into this! Your PR #2711 would fix this bug — I tried it locally and it works as expected.