priority of session cookie and url rewriting

[Da...@swisscom.com]

We have two web applications: one (A) is using session cookies the other
(B) is using url rewriting. The first access to the B is always done via
A (request by HttpClient). 
For an upload form the architects (unfortunately?) switched from this
approach to a direct call to B. In this case we have a session cookie
from A AND a rewritten URL (form action).
In org.apache.catalina.connector.CoyoteAdapter  I found the following
code:

   protected void parseSessionCookiesId(org.apache.coyote.Request req,
Request request) {

        // Parse session id from cookies
        Cookies serverCookies = req.getCookies();
        int count = serverCookies.getCookieCount();
        if (count <= 0)
            return;

        for (int i = 0; i < count; i++) {
            ServerCookie scookie = serverCookies.getCookie(i);
            if (scookie.getName().equals(Globals.SESSION_COOKIE_NAME)) {
                // Override anything requested in the URL
                if (!request.isRequestedSessionIdFromCookie()) {
                    // Accept only the first session id cookie
                    convertMB(scookie.getValue());
                    request.setRequestedSessionId
                        (scookie.getValue().toString());
                    request.setRequestedSessionCookie(true);
                    request.setRequestedSessionURL(false);
                    if (log.isDebugEnabled())
                        log.debug(" Requested cookie session id is " +
                            request.getRequestedSessionId());
                } else {
                    if (!request.isRequestedSessionIdValid()) {
                        // Replace the session id until one is valid
                        convertMB(scookie.getValue());
                        request.setRequestedSessionId
                            (scookie.getValue().toString());
                    }
                }
            }
        }

This codes leads to a higher priority of session cookies regardless of
the settings in jboss-web.xml or context.xml.

I had to patch this class in order to enable the correct behaviour:

                // Patch: if JSESSIONID AND URL rewriting, decide
according to the context.xml settings
                if (request.getContext().getCookies() &&
!request.isRequestedSessionIdFromCookie()) {

This allows to disable completely session cookies putting a context.xml
in the /WEB-INF of the war file (we use jboss):

<Context path="/medialbum" cookies="false" override="true" />

Is there another solution to this problem?

Cheers

Daniele

RE: priority of session cookie and url rewriting

[Da...@swisscom.com]

Thank you Mark for the hint with the bug database; I think next time I
will check it before I loose too much time...

I'd prefer to have the patch like

        // Parse session Id from cookies if context allows it
        if (request.getContext().getCookies())
       	    parseSessionCookiesId(req, request); 

and if getCookies() would be called isCookiesEnabled() the code would be
better readable...

However, this is a question of style only, it works, and that's all what
counts ;-)

Daniele

-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org] 
Sent: Sunday, January 20, 2008 6:33 PM
To: Tomcat Developers List
Subject: Re: priority of session cookie and url rewriting

Daniele.Ulrich@swisscom.com wrote:
> Is there another solution to this problem?

The fix for bug 43839 should have fixed this.

Mark

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


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

Re: priority of session cookie and url rewriting

[Mark Thomas <ma...@apache.org>]

Daniele.Ulrich@swisscom.com wrote:
> Is there another solution to this problem?

The fix for bug 43839 should have fixed this.

Mark

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