Hi Lester, On Sun, Aug 14, 2016 at 5:35 PM, Lester Caine <les...@lsces.co.uk> wrote: > On 14/08/16 01:56, Yasuo Ohgaki wrote: >> IMO. PHP should be easiest, yet secure, Web application programming language. >> I don't see any benefits, but only drawbacks, forcing users "to know session >> management details to write secure code" while it is very easy to implement >> tham in Session module. > > Sessions are something I rely on, but have thrown numerous problems over > the years. In my systems they should exist for the duration of a client > being logged into the system and so any problems either end have to be > handled. For that reason I store them in the database so when a client > has to log in again we can clear their last activity and start a new > one. The clients can be carrying out interviews for an hour or more, so > previous 'improvements' that try to clear 'inactive sessions' often lost > MY sort of sessions. Clients are only allowed to log on once so I need > to pick up if they try and start a second session, but I don't believe I > NEED all the complexity of cryptography secure id's? Just ones where I > CAN actually identify the client ... or should I be handling that > separate from the actual session_id ?
Concept of Session is simple just like transaction. Concept of transaction is simple but implementation requires complexity to do the job right. You wouldn't say 'Transaction could be inconsistent under rare unfortunate situations' probably. Anyway, session module generates collision free session ID by default. Why not for API generates new ID? Collision check for new session ID is cheap because it does not happen for every request, but only when session ID is regenerated. In addition, user needs a lot of work and details of session, including session save handler knowledge to generate collision free session ID. If anyone would really like to remove collision check overhead, they should do it by themselves. Unlike collision free session ID generation, it's very easy. Users can do ini_set('session.use_strict_mode', 0); session_id('my_session_id'); session_start(); with their own responsibility and risk. Regards, P.S. The next step having session_create_id() is session_regenerate_id() change. For example, having user ID prefixed session would be just session_regenerate_id(session_create_id($userid)); Warning: To do things like this safely, user MUST enable use_strict_mode!! -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php