tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Caron <ca...@unidata.ucar.edu>
Subject Re: How does one control what the path is on the JSESSIONID cookie?
Date Wed, 24 Jun 2009 19:05:24 GMT
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>
> On 6/23/2009 5:04 PM, John Caron wrote:
>   
>> Pid wrote:
>>     
>>> Filip Hanik - Dev Lists wrote:
>>>  
>>>       
>>>> John Caron wrote:
>>>>    
>>>>         
>>>>> Tomcat 6.0.18 automatically adds the session cookie like:
>>>>>
>>>>>  Set-Cookie: JSESSIONID=6D839FF3B960947CC6FD41B98CD02E0D; Path=/thredds
>>>>>
>>>>> How can I change the path part of the cookie?
>>>>>       
>>>>>           
>>>> the only thing you can do is set it to empty, by using emptySessionPath.
>>>>     
>>>>         
>>> Or you could change the name of your application.  That's unlikely to be
>>> helpful though.
>>>
>>> Why does it matter?
>>>
>>> p
>>>   
>>>       
>> The client may have more than one session, which must be distinguished
>> by the path, eg i need:
>>
>> Set-Cookie: JSESSIONID=6D839FF3B960947CC6FD41B98CD02E0D; Path=/thredds/p1
>>     
>
> Multiple cookies is not a problem. If Tomcat receives multiple
> JSESSIONID cookies with a request, it will try all of them until it gets
> a match for the webapp being used to serve the request.
>
> That said, having overlapping webapp URL spaces is asking for trouble.
>   
Sorry, I didnt explain much context. This isnt for browsers, its a 
specialized web service for specialized clients. I have control of both 
the client and the server code. The clients are accessing remote 
scientific datasets. In certain circumstances, establishing a session 
with them for each dataset that they open solves some hard problems.
>   
>> A previous post had this filter, which im guessing i can modify :
>>
>> /**
>> * This class will set the cookie maxAge to match the session timeout
>> value. That way, a user who closes their browser and
>> * re-enters the site will still have the same session if it has not
>> timed out on the server.
>> */
>>     
>
> This filter was written for a very different purpose.
>
>   
>>            HttpSession session = httpRequest.getSession();
>>     
>
> Note that this filter creates sessions when when one is not necessary.
>   
thanks for reminding me of that.
>   
>>                httpResponse.addCookie( sessionCookie ); //FIX! This
>> doesn't actually get rid of the other cookie, but it seems to work OK
>>     
>
> This comment is telling: yes, the old cookie is not removed, and it
> really should be. A better solution would be to write a Valve that wraps
> the response to intercepts addCookie calls and re-write the maxage when
> the cookie is added.

Im hoping to not use Valves since that makes my code Tomcat specific. I 
am delivering this webapp to some dozens of scientific institutions. 
Allowing them to run any servlet container is a big win.

I have rewritten this as follows:

public class CookieFilter implements Filter {

  public static final String JSESSIONID = "JSESSIONID";
  public static final String SESSION_PATH = "SESSION_PATH";

  public void init(FilterConfig config) throws ServletException {
  }

  public void doFilter(ServletRequest _request, ServletResponse 
_response, FilterChain chain) throws IOException, ServletException {
    chain.doFilter(_request, _response);

    // examine response after the request is processed
    if (_response instanceof HttpServletResponse) {
      HttpServletRequest httpRequest = (HttpServletRequest) _request;
      HttpServletResponse httpResponse = (HttpServletResponse) _response;

      HttpSession session = httpRequest.getSession(false);
      if ((session != null) && (session.getId() != null) && 
(session.getAttribute(SESSION_PATH) != null)) {
        Cookie sessionCookie = new Cookie(JSESSIONID, session.getId());
        sessionCookie.setPath((String) session.getAttribute(SESSION_PATH));
        httpResponse.addCookie(sessionCookie);
      }
    }
  }

  public void destroy() {
  }
}

However, it has no effect, the path stays equal the web context name. Im 
guessing there some code that rejects changing the session cookie ( I 
havent tracked it yet in the debugger). Is this a security thing or is 
there something in the Servlet spec that says what the path has to be?



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


Mime
View raw message