On 08/04/16 09:38, Yasuo Ohgaki wrote: >> If you want to explicitly document something as a best practice, it IS your >> > problem when users shoot their feet with it > Lack of proper API for required task is our problem. Misuse is not ours. IMHO. > > The best way to perform GC would be cron task. Low traffic sites can > make sure obsolete session is deleted. High traffic site can avoid > occasional slow down by GC. I suppose almost all high traffic sites > uses memcached or like that does not require PHP's session GC at all, > though.
Changes to 'defaults' on session handling, and other processes 'improving security' in that area have been a source of problems on many of my sites, so establishing a proper practice would be nice. Many of my sites involve people starting a session at the start of an interview process and the session holds that interview point locked until finished and for complex interviews this can be a couple of hours. Some staff will forget to 'log out' and then the next person kicks them off with a message, or the unfinished sessions get wiped over night. But ideally the interview times get logged accurately, something that becomes a problem when something else terminates the session early. Am I doing anything wrong using sessions in this way and expecting it to work? I have also been 'caught out' by time-outs which seem to be too short on other internet services. They tend to get a complaint when I've spent time putting data together only to find the session has been terminated - and all the data entred is lost! Handling this type of problem is another area where forcing defaults for a mistaken security improvement needs to be handled while looking at the wider context? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
