Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Cc: Mark Thomas <markt@apache.org>
Message-Id: <D2EA732A-F08F-485E-863A-5841C19F8ECA@headweb.com>
From: =?ISO-8859-1?Q?Johan_Str=F6m?= <johan@headweb.com>
To: "Tomcat Users List" <users@tomcat.apache.org>
In-Reply-To: <4AD43A80.4020609@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: PATCH: Session ID from URL; would like some input!
Date: Tue, 13 Oct 2009 13:01:22 +0200
References: <3D3C9FFA-0584-465A-A866-B1894B854191@headweb.com>
 <4AD43A80.4020609@apache.org>

Hi Mark,
thanks for your response!

On Oct 13, 2009, at 10:29 , Mark Thomas wrote:

> Johan Str=F6m wrote:
>> Hello list!
>> First of all, this maybe better suited for the dev list, but a quick
>> peek only showed svn log mails etc soo.. Sending here instead, let me
>> know if its wrong!
>
> It is 50/50. The patch is of more interest to the dev list but if the
> patch is rejected then the users list is the best place to get ideas
> about other ways of doing things. The mailing lists block most patches
> so an enhancement request in Bugzilla is the best place for your =20
> patch.


I see, it's available here if you'd like to take a quick look:

https://dev.headweb.com/johan/pub/Request.java.patch


>
> Without seeing the patch it is hard to comment but SRV.7.1 makes it
> clear that cookies override URL parameters. It doesn't make a =20
> comment on
> what if the cookie session is invalid and the URL one not. There might
> be some scope for flexibility here.

Correct, cookies override URL parameter, but as you said, not when the =20=

session in cookie is invalid. I guess one could make it configurable =20
but I have no idea how that would be done, haven't dug that deep into =20=

the tomcat source :)

>
>> We're having a problem related to Tomcat, in a pretty unusual =20
>> scenario.
>> Basicly the problem is with old expired sessions, and reading =20
>> session ID
>> from URL instead of cookie.
>> An example, in our case browser A is a main browser, and browser B =20=

>> is a
>> slave "browser" (actually only a webkit rendering engine) which we =20=

>> only
>> call with an URL to show a specific page, and we do not have control
>> over cookies in browser B.
>
> Any way to "close" "browser B"? That should delete the session cookie.

Unfortunately not, so not a solution.

>
>> So, browser B sends both the old session ID in the cookie (which is =20=

>> an
>> expired session), and the new sessionid on the URL. This confuses =20
>> tomcat.
>> In catalina/connector/Request.java and CoyoteAdaptor, we first =20
>> check for
>> a sessino ID on the URL, store it in Request, and then we check =20
>> for  a
>> cookie, and if we got one, we just overwrite the session ID from =20
>> the URL.
>>
>> My solution? The attached patch!
>> Now, what I'd like to know, can anyone of you developers see any =20
>> nasty
>> side effects that I might have missed about this?
>
> In principle, it sounds OK but I'd want to see the patch first. If it
> were implemented, then it would go into Tomcat 7 and may not be
> back-ported to earlier versions. It may also be made optional.

See URL above.

>
> Keep in mind that session handling is more configurable in the Servlet
> 3.0 spec (not that I think it helps with this issue) and that changing
> the session ID on authentication to protect against session fixation =20=

> is
> an open enhancement request that should also get included in Tomcat 7.

Me changing the session ID is not what I'm doing, its rather that the =20=

old session ID has timed out, and browser A is assigned a new session =20=

which i need to tell browser B to use too.

>
>> One thing that was concerned about was that it would introduce =20
>> session
>> hijacking risks, but the only difference is that the evildoer have to
>> erase his (already expired) cookie.. Normal tomcat accepts =20
>> jsessionid on
>> URL anyway, as long as there is no cookie, so that should not be a
>> security concern.
>
> Agreed.

Great :)

Johan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org