Hi! > I have > https://wiki.php.net/rfc/dbc2
This doesn't seem to do anything with security. It's just a way of doing asserts, which we already have. > https://wiki.php.net/rfc/secure_serialization This may be a viable extension of somebody really is going to use it. I would suggest making a PECL extension. > https://wiki.php.net/rfc/introduce-type-affinity This also has nothing to do with security, and also looks unfinished, not clear what is sought and what is the benefit. > https://wiki.php.net/rfc/script_only_include This one we already discussed at length, and the vote result is clear. > Three RFCs for session is just too much for me already... Maybe we should concentrate on doing one specific thing, bring it to conclusion and then get to the next one? > Anyway, we may be better to talk about how it should be. > For this thread, how session management should be. > It's just not good enough currently. Besides exploiting > PHP session is too easy, random lost sessions is not I am sorry, but I still see no base to this claim. You seem to be under impression that stealing cookies from HTTPS connection is trivial, but I do not see how it is. Moreover, since virtually all secure communication over the web relies on this, if it were trivial, no secure communication would be possible, and I don't see this happening. If, however, HTTPS/cookies are secure, then I don't see how exploiting PHP session in current state is easy. There may be some browser bugs that make some scenarios not work sometimes, but so far I don't see any problem that were bigger than light annoyance. > acceptable. Weak defaults are not acceptable also. Let's There are a lot of different use cases for PHP and session, and the same requirements do not apply to all of them. So in my opinion, the defaults should cover the most common cases, and avoid breaking applications as much as possible. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
