Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16103 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96305 invoked by uid 1010); 26 Apr 2005 20:24:39 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 96270 invoked from network); 26 Apr 2005 20:24:38 -0000 Received: from unknown (HELO velum.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2005 20:24:38 -0000 X-Host-Fingerprint: 69.17.117.29 mail27.sea5.speakeasy.net Linux 2.5 (sometimes 2.4) (4) Received: from ([69.17.117.29:45835] helo=mail27.sea5.speakeasy.net) by pb1.pair.com (ecelerity 1.2.12rc1 r(5476:5477)) with SMTP id 68/6C-59279-583AE624 for ; Tue, 26 Apr 2005 16:24:37 -0400 Received: (qmail 29878 invoked from network); 26 Apr 2005 20:24:32 -0000 Received: from out.appliedsec.com (HELO [127.0.0.1]) (hlellelid@[69.17.56.162]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 26 Apr 2005 20:24:32 -0000 Message-ID: <426EA37F.9060707@velum.net> Date: Tue, 26 Apr 2005 16:24:31 -0400 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Kalowsky CC: Stefan Esser , internals@lists.php.net References: <4266894D.1070702@cain.sh> <42668AC0.1010607@caedmon.net> <4269D32C.1080706@cain.sh> <426E6F87.5020908@velum.net> <426E7441.5010101@php.net> <426E7798.4020208@velum.net> <426E79DF.2080900@php.net> <426E7DBB.1050406@velum.net> <20050426131625.P90708@secret.deadmime.org> In-Reply-To: <20050426131625.P90708@secret.deadmime.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PATCH] Modifications for ext/session/ From: hans@velum.net (Hans Lellelid) Dan Kalowsky wrote: > On Tue, 26 Apr 2005, Hans Lellelid wrote: > >> I see your point, but I would still argue that being able to create an >> arbitrary, non-server-supplied session id is far more powerful -- >> primarly because it is not susceptible to session garbage collection >> on the server (i.e. the valid session id I get from the site will be >> invalid in gc_maxlifetime). > > > So what you want are cookies? > Well, no that doesn't address the problem, although certainly setting cookies_only makes it practically a bit harder (can't just paste in a simple URL with fixated session for someone to click). But the real problem (IMO) is the idea of a client making its own decision about what a session id should be. -- and of course sending an invalid session_id as a cookie is trivial. -H