feat(http)!: regenerate the session identifier on authentication

[osbre]

The session identifier used to survive authentication, so an identifier an attacker planted before login stayed valid afterwards and granted them the authenticated session.

SessionRegenerator assigns a new identifier to the current session and destroys the session it replaces. SessionAuthenticator calls it when authenticating and deauthenticating.

This is what OWASP ASVS 5.0 requires under 7.2.4 at level 1, including the termination of the previous token, and what both Laravel and Symfony do by default.

Breaking changes

• SessionManager gains a regenerate() method, which custom resolvers must implement.
• SessionIdResolver gains a new issueNewId() method, which custom resolvers must implement
• Deauthenticating now discards the session data instead of carrying it over to the new identifier, matching Laravel and Symfony. Authenticating still preserves it, so flash data and the intended URL survive a login.

[github-actions]

Benchmark Results

Comparison of feat/session-regeneration against 3.x (0f478fb487e12a5891738a15a1663fa44c47295b).

Open to see the benchmark results

Benchmark	Set	Mem. Peak	Time	Variability
ViewRenderBench(benchPlainHtml)	-	22.036mb 0.00%	490.051μs +7.40%	±1.61% -27.92%

_{Generated by phpbench against commit 52b4d64}

[brendt]

Why not add the regenerate logic in the manager class?

[osbre]

Since SessionManager is an interface, adding it there would lead to duplication as all regenerate does is:

1. deleting the old session
2. swapping the ID via the resolver
3. saving the new one

It doesn't seem to be storage-specific, so all three managers would end up repeating the same code. It would also mean injecting the SessionIdResolver into every implementation.

[innocenzi]

I agree with @osbre regarding the responsibility of SessionManager.

I cleaned the API a bit by renaming methods to better names, and removing preserveData in favor of a dedicated method.

One thing I don't like but don't have a solution for is replaceId. It makes no sense for userland to ever reach it, but there isn't anyplace else to put it either. We can't just update Session in the container because it could be stale in other dependencies.

If you have any idea, I'll take it; otherwise we can just keep it as @internal, but it's not ideal.

[brendt]

It doesn't seem to be storage-specific, so all three managers would end up repeating the same code. It would also mean injecting the SessionIdResolver into every implementation.

I understand, but then I still think it can be better designed. I really don't like replacing SessionManager as a dependency. If anything, regeneration is a side effect of the manager doing something, not the entrypoint.

A couple of suggestions:

• Inject the regenerator in the managers. Yes, every manager implementation has to call it then. I don't mind all that much, as long as the regeneration logic itself is contained
• Handle regeneration with events as a side-effect of calling deauthenticate() and authenticate()
• Directly call regenerate from the authenticator, but also keep the manager calls there. So essentially inject both the manager and regenerator

I think the third option is the best, but am open for suggestions

[osbre]

Pushed option 3: the authenticator now takes both, with regeneration as a side effect. Let me know if this matches your vision.

OWASP also recommends regenerating on other privilege changes, like password changes, 2FA, impersonation, and role escalation, so users may need to call SessionRegenerator directly. I've updated the auth docs to cover this.

[osbre]

Thanks! Assuming it's for 3.20. Followed the same convention as 3.14 - included three fixtures: plain implementations, aliased-import implementations, and implementations that already have the methods.