Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56750 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27151 invoked from network); 4 Dec 2011 09:59:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Dec 2011 09:59:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:47771] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B7/A2-13454-2844BDE4 for ; Sun, 04 Dec 2011 04:59:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3DE803A054C; Sun, 4 Dec 2011 04:59:28 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id F27683A0539; Sun, 4 Dec 2011 04:59:27 -0500 (EST) Message-ID: <4EDB447F.4000500@sugarcrm.com> Date: Sun, 04 Dec 2011 01:59:27 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <4EBDC283.3040700@yahoo.co.jp> <4ED727FB.7030001@uw.no> <4ED76013.50601@lerdorf.com> <4ED85560.6040101@uw.no> <4ED8805B.7070308@uw.no> <4EDA8709.3090407@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Strict session? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > For example, it is easy to find cases with google code search, that > users are setting ID while they really should do is > session_regenerate_id(). These kind of mistakes would be better to be > prevented under strict mode, IMHO. I'm not sure how that would help in this case - so the set would be rejected, then the users will turn the strict mode off to make their code work and thus lose the protection it provides. How that improves anything? Setting session ID and protection against adoption are two different things, why you need to turn off the latter to get the former working? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227