Hi Mike, On Mon, Dec 21, 2015 at 1:24 PM, Mike Willbanks <pen...@gmail.com> wrote: > > On Sun, Dec 20, 2015 at 7:01 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >> Hi all, >> >> On Sat, Dec 19, 2015 at 7:33 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> > I would like to restart better session management for PHP 7.1. >> > >> > https://wiki.php.net/rfc/precise_session_management >> > >> > Although this RFC targets PHP 7.1, new session management >> > could be applied to older releases also if majority of us agree. >> > Please comment. >> >> I would like to write patch for this next week. >> If you have comment, please comment this week. > > > This week is hard due to several holidays, I would recommend postponing > discussion until after.
Thanks. I'm working on this for years. I'm not in hurry. > > > However, I will comment on a few things that I dislike of the RFC: > > Exposing the internal state of the session via a key on the session > __SESSION_INTERNAL__ may be dangerous. How are you preventing writes to > this area? Is an exception or error thrown? I also do not feel that it is The session internal data structure (__SESSION_INTERNAL__) is removed when the data is unserialized. It is added back when session data is serialized. So user cannot see/touch private session data at all. If user add $_SESSION['__SESSION_INTERNAL__'] in user script, the module remove it and raise E_WARNING. > worth encoding this directly into the session value but would be of far > greater benefit to expose through functions and ensure it is not touched and > protected from user land. Anything that messes with the $_SESSION can cause > major issues (for instance upload progress did this and can cause session > corruption in certain cases as it manipulates the session state). Please file a bug report for this. As I wrote in previously, $_SESSION['__SESSION_INTERNAL__'] is completely hidden and untouchable from users > I fully agree that session_regenerate_id needs some additional work. > Although. I do not think that the implementation here seems like the correct > path as a general comment. >From user point of view, $_SESSION['__SESSION_INTERNAL__'] is a new reserved/ restricted session key. We had such restriction before "php_serialize" serialize option. e.g. $_SESSION['1'] , $_SESSION['1abc'], etc are invalid keys and raises confusing error messages. Key name must be valid as variable name for serialization method other than "php_serialize". I could choose to use completely new session serialization method like $__PSEUDO_SESSION_DATA__ = $SESSION_INTERNAL_DATA[] + $_SESSION[] where $SESSION_INTERNAL_DATA is $_SESSION['__SESSION_INTERNAL__'] and $_SESSION is the current session data array. No reserved key is required with this. However, this method breaks almost all 3rd party session data management libraries that access session data storage directly. Therefore, I chose to add and hide session internal data structure in $_SESSION. However, this could be vote option. Thank you for your comment! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
