Don't send session ID cookie until sessions are actually used

[tremby]

In Craft 2, is there any reason for the session to be started and the CraftSessionId cookie to be sent to the user before application code uses the session in any way or the user logs in?

CSRF, perhaps, but I noticed there's a separate cookie YII_CSRF_TOKEN for that, so I guess that can't be it.

The cookie is being set for any user visiting the site, even if they're not logged in. If that weren't the case, pages would be more cacheable for anonymous users, and the issue described in #1758 would be moot since I wouldn't have to have the caching proxy filter out this cookie on non-admin pages.

[narration-sd]

seems good thinking as an alternative approach to the original problem.

But doesn't the CSRF token change per session, so that it would have the same effect of cache breaking?

Maybe that also could be tamed to only show up if there is a form?

[tremby]

We block that one too. But that's not the point -- that one should also only be sent once needed, like when a form is rendered.

[narration-sd]

in fact, it looks like the csrf cookie could potentially be even worse as a problem, if perhaps not with Craft...see discussion here.

https://stackoverflow.com/questions/8655817/csrf-protection-do-we-have-to-generate-a-token-for-every-form

out of order with your comment, cross-posting.

And yes, to your comment, just not verified that's what Craft actually does pre response to this item....

[tremby]

Sure. The issue is with both. I care more about the session one, since our site doesn't use any Craft forms (except presumably in the admin panel), and it's the authentication status which is breaking things for us. But yes, ideally neither would be sent until necessary.

[angrybrad]

This has been a known issue in Craft 2 for ages that's just been impractical to fix. We kept it in mind developing Craft 3, though and after this fix it's working as expected again.