Allow to change the environment, kernel.debug and HttpCache by cookie

[mpdude]

Q	A
License	MIT
Doc issue/PR	TODO

I would like to propose the possibility to use cookies to change the Kernel environment, debug mode and enabling the HttpCache.

This is helpful if you want to

• find out why things work in your dev environment, but fail with production settings
• benchmark some requests with kernel.debug disabled or with the HttpCache
• control the environment during high-level integration or acceptance tests

This solution is convenient because it can easily be used from a browser. Cookies will persist for subsequent requests and will not otherwise "pollute" the URL. JavaScript/Bookmarklets can be used to easily set, change or revert settings. Also, the cookies can easily be added in tools like curl, ab or a Behat/Mink session.

The alternative of editing .env files and/or the index.php file is not easily available in automated test setups. Also, you cannot have two browser instances/windows in parallel that work with different settings at the same time.

Of course, this should only be possible under very special conditions, namely your development environment. So, a SYMFONY_ALLOW_OVERRIDE environment variable must have been set in the webserver to allow it.

[ghost]

Pull request passes validation.

[nicolas-grekas]

This looks very dangerous to me. People will enable this on prod for sure. This file is yours so if you want to do this, fine, but I wouldn't make this available by default to everyone, even under an opt-in env var.

[mpdude]

I can accept your 👎s if the reason is just to prevent people from harming themselves. May I assume that if there were better or established ways of doing this, you would have mentioned it?

In particular, I think about running full-scale integration tests (over HTTP) on my local machine, without the need of duplicating the index.php and/or changing back and forth the APP_ENV in .env.local.

[Nyholm]

As discussed on Slack:
This is a great way to easily debug applications using ESI with Symfony Cache. However, it is not used by 80% of the applications and (as Nicolas says) it makes it really easy to accidentally write insecure applications.

May I assume that if there were better or established ways of doing this, you would have mentioned it?

Im not aware of a workaround that does the same thing but is less secure. :/

---

Im going to close this PR. But I encourage you to post this solution on a blog or a gist.