Hey there… currently we noticed a lot of exceptions form invalid cookie names. I’m not really sure where this cookies came from, but I think flow shouldn’t throw an exception but instead simply ignore the invalid cookie.
At the moment, you can break every flow /neos site by simply executing this line in the js console:
document.cookie = 'torstens[fakecookie]=123'
Also I found no way to avoid this exception because every involved class has @flow\proxy(false) so AOP is not an option. Currently I’ve fixed this error by filtering $_SERVER['HTTP_COOKIE'] inside my Package.php file, but this should not be the way.
It’s a tough thing. There is a RFC, a standard for how cookies should look like, if you don’t stick to it, you do it wrong and the system should tell you, so from that perspective the exception is perfectly fine. Just ignoring the cookie will lead to people wondering where their cookie is gone, so we should at least log that incident IF we want to ignore it.
Personally in favor of not throwing exceptions in production context for this, but rather log the exception in that case. That’s done in other cases in Flow as well.
@christianm we use neos as some sort of hub that is the homepage of a lot of other systems (some flow, some wordpress) and all of those systems come with their own dependencies and own frontend (javascript) extensions. So this exception is not caused by us directly or by bad coding. Any js code can set a invalid cookie… and by that bring the whole system down.
An important thing to note is that this does not only happen between the frontend and flow. I had trouble once by communicating with a custom backend that used some none-standard cookies. We luckily could solve this by explaining the cookie-rfc to the vendor of that system but it was pure luck that it was that easy.
In total i think flow should be able to talk to partners who are lazy with cookies and at least not fail.