Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92171 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26887 invoked from network); 8 Apr 2016 10:52:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Apr 2016 10:52:46 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:36346] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 10/A6-25122-C7D87075 for ; Fri, 08 Apr 2016 06:52:45 -0400 Received: (qmail 31532 invoked by uid 89); 8 Apr 2016 10:52:41 -0000 Received: by simscan 1.3.1 ppid: 31526, pid: 31529, t: 0.0731s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@86.178.189.242) by mail4.serversure.net with ESMTPA; 8 Apr 2016 10:52:41 -0000 To: internals@lists.php.net References: Message-ID: <57078D79.8020406@lsces.co.uk> Date: Fri, 8 Apr 2016 11:52:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC][Discussion] Add session_gc() From: lester@lsces.co.uk (Lester Caine) 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