Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69798 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22486 invoked from network); 23 Oct 2013 07:35:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Oct 2013 07:35:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=bof@bof.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bof@bof.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender) X-PHP-List-Original-Sender: bof@bof.de X-Host-Fingerprint: 80.242.145.70 mars.intermailgate.com Received: from [80.242.145.70] ([80.242.145.70:48805] helo=mars.intermailgate.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B6/66-10840-C3C77625 for ; Wed, 23 Oct 2013 03:35:25 -0400 Received: (qmail 20351 invoked by uid 1009); 23 Oct 2013 09:35:21 +0200 Received: from 209.85.212.44 by mars (envelope-from , uid 89) with qmail-scanner-1.25-st-qms (clamdscan: 0.96.2/17993. spamassassin: 3.3.1. perlscan: 1.25-st-qms. Clear:RC:1(209.85.212.44):. Processed in 0.186571 secs); 23 Oct 2013 07:35:21 -0000 X-Antivirus-MYDOMAIN-Mail-From: bof@bof.de via mars X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:1(209.85.212.44):. Processed in 0.186571 secs Process 20337) Received: from mail-vb0-f44.google.com (gmail@bof.de@209.85.212.44) by mars.intermailgate.com with RC4-SHA encrypted SMTP; 23 Oct 2013 09:35:21 +0200 Received: by mail-vb0-f44.google.com with SMTP id 11so222812vbe.3 for ; Wed, 23 Oct 2013 00:35:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q9fIU6ms+HiRxT5iTTK200H7K/pnEQZIQWvVxkgZkL8=; b=j8TXmB2S/Tl9qv28vEeIUdYFM5ElbYCCp83KXuBenBIjIUN6ddhS3O6iIK4gWfbHx1 n+d9uMABOeVcC6b/mEvcAGfMAgtsouqocs3i32uYq4uOUC6UJh7bUWW9mBTIPi2u5vu7 zMhKrf6gAHtCL//bRDUQxTl9tBqVQ61aKL2shv7COz+3UaLVpUZh9q7ktQVDxP+51s/u NXgyDCCfVblvqsjDlOBPfmkS1kvzb1lJ3e3FvLrj/POwqNlrp727G9t9tsBopl9C06v4 V/w3gGBuz+SQ15YljM3vETRlH9yJQDkMsDI6ZE1qB0qVRpIztrGVYPBzl2qaNGBhpUtH X81Q== MIME-Version: 1.0 X-Received: by 10.52.182.166 with SMTP id ef6mr29114vdc.105.1382513719935; Wed, 23 Oct 2013 00:35:19 -0700 (PDT) Received: by 10.52.185.102 with HTTP; Wed, 23 Oct 2013 00:35:19 -0700 (PDT) Received: by 10.52.185.102 with HTTP; Wed, 23 Oct 2013 00:35:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Oct 2013 09:35:19 +0200 Message-ID: To: Yasuo Ohgaki Cc: internals , Ferenc Kovacs Content-Type: multipart/alternative; boundary=bcaec548a7872c89b004e9638fc9 Subject: Re: [PHP-DEV] session_regenerate_id(true) by default From: bof@bof.de (Patrick Schaaf) --bcaec548a7872c89b004e9638fc9 Content-Type: text/plain; charset=ISO-8859-1 Hi Yasuo, Am 23.10.2013 02:56 schrieb "Yasuo Ohgaki" : > > On Tue, Oct 22, 2013 at 8:10 PM, Patrick Schaaf wrote: >> >> Working on the issue for our own application, I'm in the process of teaching our session wrapping class to regenerate ID often - but when doing so, first setting up the previous session ID with two pieces of information: a short timeout of 20 seconds or something like that, and a "forwarding ID" which references the new session ID. >> >> I want to do this because I want to regenerate IDs often (also based on a rather short timeout), and I'm concerned about parallel in-flight requests - a high probability reality with ajax getting more and more traction - still presenting the old session ID a second or two after a request determined to regenerate. > > Session save handlers lock session data to avoid mess, but your approach works without lock > in many cases. However, it may result in inconsistent session data (i.e. over written data), > so I would not recommend it as general usage. While true for us, that is a separate issue. The parallel in-flight requests meeting an invalidated session, will happen as well with fully locked sessions - for example they will wait on the lock for the old session ID while the regenerating script is still before the regeneration point. When the lock is lifted (with regenerate(true)) they will then see an empty session, potentially affecting their operation due to missing context. Regarding non-full session locking, going that way is a conscious decision for us. We find that most of the time the session data we use is readonly, i.e. a once set up set of contextual information is used but not modified by e.g. additional ajax requests. Full locking in these cases, coupled with the occasional longer running script, results in full serialization of request processing, which translates into much increased total latency for the end user. Thus, our general approach is to shortly open the session, capturing $_SESSION to class static storage, and closing the session again. Setter methods of our helper class then maintain a dirty flag, and at the end of the script run (or explicitly called), a "flush" method examines that dirty flag, and only when dirty, it opens the session again and replaces all session variables with the full set of variables modified by that script (so no modifications of several parallel scripts are mixed together - simple last-one-wins, which makes reasoning about correctness somewhat easier). > The main idea of this proposal is "Making PHP secure by default". > It does not worth to keep insecure default forever because of the initial implementation > had bug. IMHO. I'm fully agreed on changing the default! > BTW, I prefer not to raise errors for "false", since it has valid usage Exactly. best regards Patrick --bcaec548a7872c89b004e9638fc9--