Weird stuff with bolt_session cookies.

[bobdenotter]

A short while ago, I had an issue where Bolt would always set a bolt_session session cookie. Also on pages in the frontend, and also when you're not logged on.

I did not want this, because setting a cookie on "static" pages in the frontend will prevent Varnish or Cloudflare from doing their jobs: Every page requests/visitor gets their own cookie.

See here: #3309 / https://github.com/bolt/bolt/pull/3309/files

This code should prevent the bolt_session cookie from being set, but only in the frontend. Note:

• "Not setting a cookie" by removing the header that is about to set it, is not the same as removing a previously set cookie.
• This shouldn't interfere with other cookies being set.
• If you're not logged in, you don't need a bolt_session cookie by default.
• Setting it happens during initialisation of Application.php, in initSession(). (line 80)

For me, for the project i needed it to be gone, it works as it should. But, there's been more than one report of people seeing stupid shit happening, for it to be a coincidence. We should fix this. Somehow.

[GwendolenLynch]

[GwendolenLynch]

Related to #3413

[Pinpickle]

I had a good read through this recent discussion and it led me to the conclusion that using $app['session'] is not good for extensions and sessions in the front end, correct?

I was wondering if there are any docs on how an extension might have its own sessions for simple things such as form flashes. I looked through the Symfony docs and through your code for clientlogin, @GawainLynch, but I couldn't work it out. I think this would be a common usecase, and without docs warning against it, people will probably go immediately to $app['session'].

[GwendolenLynch]

Well, frontend sessions/cookies were broken for a short while and fixed in #3427. As it stands for the moment, default behaviour will be OK to use $app['session'] but you'd be right that it's questionable to rely on it. What is implemented in ClientLogin is simply a workaround for the behaviour introduced, but is no longer needed.

@CarsonF and I are looking at this for the Bolt responses in general in 2.3… watch this space 😉

[Pinpickle]

Sounds like 2.3 is going to make extensions very happy in lots of ways! I will eagerly watch all of the spaces.

[GwendolenLynch]

We're going to try… 2.2 has largely been about getting our testing infrastructure in-line so we can make these changes with a bit more insight.

[rossriley]

and if it all goes wrong there's a 🐨 lined up as the fall-guy.

[bobdenotter]

While this is certainly something we need to look into, this is currently not a showstopper anymore, right? We reverted the broken behaviour, and by default it works as before: You get a bolt_session cookie, unless explicitly disabled in your config.yml.

[GwendolenLynch]

That is my assumption. As I understand it the introduced bug was itself the broader problem, and with that reverted we're good.

Failing that 🐨 🔫

[bobdenotter]

Ok, with the setting for this, this is no longer "blocking release", but it's still something that ought to be fixed one way or another.

[GwendolenLynch]

This is now fixed in our upcoming controller refactoring branch.

For those that are curious, the problem is that accessing $app['session'] functions (e.g. getFlashBag() and friends) starts the Symfony/PHP session, which in turn sets the bolt_session cookie.

[bobdenotter]

Fixed by #3564