Hi! > https://wiki.php.net/rfc/precise_session_management > https://github.com/php/php-src/pull/1734
I'm re-reading this RFC and I notice it does quite a lot of things: - Add five new INI values - Add two new functions - Changes behavior of two widely used functions - Changes four different defaults - Adds magic data to session This alone makes it very hard to figure out what is going on. It looks like "kitchen sink" RFC instead of targeted one. I appreciate very much your efforts to make sessions more secure, but it is very hard to review such big thing with so many things being changed at the same time. And it looks like not only myself think this way, judging by amount of feedback this is getting. Maybe I just don't understand bigger picture and all this is united by some common goal but then I'd like to have some description of this goal which will enhance my understanding. Going through RFC, here are the things that are not clear to me: 1. Why we need to change session_regenerate_id() ? It has session delete option already. You may argue it's not safe to not delete, but then you can opt to delete. I can even see adding option to expire session after a short period, but what is proposed looks a bit overcomplicated. 2. Why you need to keep session create and update time? IIRC we already have the time of last use (that's how GC) works, and we could have expiration timestamp for scenarios like session_regenerate_id() but I don't see why we need update TS in session, especially one that changes, and same for session.ttl_update. 3. Not sure what function NEW_SID serves? Why we need to know new ID in the old session? 4. Not sure how session.ttl would work. Would session expire in that time regardless of usage? Then it should be unset by default. I understand there is a use case for hard expiration, but that is separate functionality and I'm not even sure it should be in the same RFC. 5. Same for session.regenerate_id - that seems to be a piece of functionality not related to anything else. How it is connected to the rest of the RFC? In any case, I don't see why it should be enabled by default - RFC does not explain it. Same for session.num_sids and SIDS value - does not explain what is the use case for it and why it is necessary. 6. Changes like "Use strict mode by default (disallow stealing session forever). Use httponly cookie by default. Use SHA1 as hash (and use 5 bits for hashed value string for better compatibility)" are not described further and not clear how they are connected to the rest - is it necessary for the rest of the RFC to work? Why? Again, myself and I think others appreciate very much your efforts of making sessions better, but such big changes in a function that underlies almost every PHP application should be done very carefully and with full understanding of what is going on, and doing it in a huge package may be hard. I wonder maybe it'd be better to make RFC do one necessary thing - e.g. handle session regeneration - and then proceed to other things? Can we identify one problem we are trying to fix, define functionality that fixes it, agree on it, and then proceed to the next problem, etc.? Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
