Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56739 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65721 invoked from network); 3 Dec 2011 20:31:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Dec 2011 20:31:10 -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 207.97.245.203 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.203 smtp203.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.203] ([207.97.245.203:45069] helo=smtp203.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/A7-25464-D078ADE4 for ; Sat, 03 Dec 2011 15:31:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp50.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 592A237018E; Sat, 3 Dec 2011 15:31:07 -0500 (EST) X-Virus-Scanned: OK Received: by smtp50.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D2ECA370174; Sat, 3 Dec 2011 15:31:06 -0500 (EST) Message-ID: <4EDA8709.3090407@sugarcrm.com> Date: Sat, 03 Dec 2011 12:31:05 -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> 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! > If user really want to set session ID, they can explicitly disable > use_strict_mode. > > For almost all application, setting static ID is bad code. There are > some applications that exploit adoptive session, but they can live > with new code also. I'm not sure I understand - why prohibiting the setting of the session ID is necessary? I understand the idea of the original patch - if somebody could set your session ID for you, without knowledge of either the user or the app, it is bad since third party knows this ID and thus can use it. However, I do not understand why it is bad for the app to set the session ID - after all, session ID comes from the app anyway, what's the problem here? Why we have to deny benefits of the protection that this patch claims to provide against injecting session by the third party to the applications that set the session from inside? I do not understand the link between one and the other, can you please explain? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227