Re: [VOTE] RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy

From: Date: Fri, 14 Feb 2014 08:22:23 +0000
Subject: Re: [VOTE] RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-72584@lists.php.net to get a copy of this message
Hi! > When browser accesses to the personal page, application checks > authentication status and returns HTML page for it if user's session is > authenticated. Browser tries to load images which require authenticated > session. If session_regenerate_id() is called (timeout, etc) while > loading images, what happens? If old session data is deleted, other > images cannot be loaded because requests are done by old session ID. > This scenario valid since current browser uses multiple connections to > load resources of a web page. If anything was called that makes old session invalid, any further access to this session should result in failure. How the app does it, does not matter really. Doing otherwise would be a huge security problem - you removed the session, but you still can access it. Timing does not matter - milliseconds of unauthorized access may be enough to compromise an account. So I don't see any use in "delete, but only with delay" option - if the data still valid, no reason to delete, if not valid - should be deleted immediately. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

« previous php.internals (#72584) next »