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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
