Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:15701 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50870 invoked by uid 1010); 31 Mar 2005 17:13:27 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 50853 invoked from network); 31 Mar 2005 17:13:26 -0000 Received: from unknown (HELO php.net) (127.0.0.1) by localhost with SMTP; 31 Mar 2005 17:13:26 -0000 X-Host-Fingerprint: 64.151.81.46 www.brainbulb.com Linux 2.4/2.6 Received: from ([64.151.81.46:38267] helo=mail.brainbulb.com) by pb1.pair.com (ecelerity HEAD r(5268)) with SMTP id B6/8E-22409-5BF2C424 for ; Thu, 31 Mar 2005 12:13:26 -0500 Received: from [192.168.26.2] (host.239.172.mtl.residential.vdn.ca [64.254.239.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.brainbulb.com (Postfix) with ESMTP id 08D62346786; Thu, 31 Mar 2005 09:13:22 -0800 (PST) Message-ID: <424C2FB2.2070808@php.net> Date: Thu, 31 Mar 2005 12:13:22 -0500 User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Sokolewicz" Cc: internals@lists.php.net References: <424994B1.3000600@velum.net> <90e24d4e0503291116a5bde6a@mail.gmail.com> <4249ADAC.8000900@velum.net> <20050329193848.64327.qmail@lists.php.net> In-Reply-To: <20050329193848.64327.qmail@lists.php.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] why does PHP accept [new] session ids from client? From: shiflett@php.net (Chris Shiflett) M. Sokolewicz wrote: > "why is it this way" should also be posted to the general newsgroup, it > barely has anything to do with internals The behavior of the session extension has everything to do with internals. I'm not sure why everyone is sending him to php-general. No one there is going to be able to change this behavior. They can only suggest userland code to try to work around it. The problem is that PHP uses any user-supplied session identifier when creating a new session. This increases the risk of session fixation. If this behavior were changed, it would not completely protect developers from session fixation, but it would be a step in the right direction. I think the original poster was making this suggestion. Chris