Hi Andrey, On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev <n...@devilix.net> wrote: > Hi, > This gets a -1 from me as well. > > Much has been said already about why this is a bad idea, to the point where > I don't know why there's still discussion around it. But here's one more > reason ... > > It assumes, and thus also encourages, that users have an active session at > all times - this is bad. You're not supposed to start a session for a user > *until they have logged-in*.
You don't have to use it if don't need it or has other complement such as double submit cookie. > If you do, then unless you're not storing session data server-side (which > is hard to do properly and is not supported by ext/session), you're almost > certainly vulnerable to some form of DoS (e.g. inodes and/or memory/storage > being filled-up), exhaustion of free IDs, entropy available for new session > ID generation, pre-fetching of IDs to work around use_strict_mode > restrictions, etc. None of these arguments make sense... It does not consume much resources. Moreover, this RFC's CSRF protection requires less resources than most web frameworks' implementation that use session for CSRF protections. BTW, use_strict_mode is not a "restriction", but a mandatory requirement for proper session management. What current session manager is broken is other parts like inadequate session data lifetime management. > > Therefore, while the session store *after login* is suitable for token > storage, CSRF protection by default just doesn't belong in ext/session. Session task, by its definition, is to distinguish and manage state of requests. Session must distinguish requests, i.e. must keep authenticity. CSRF is obvious authenticity issue. Some of us see session manager as just a storage, but it's not a correct definition. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
