Servlet engines provide a method to hold a user session so that you're able to build complex applications on top of the usually stateless HTTP-Protocol. You can access this session from the HttpServletRequest with
getSession()
and are able to store any Object associated with that session.
A Session is represented by a unique string which allows the servlet engine to look up the session object. This string has to be carried back and forth with each request of the client to be able to identify the client belonging to the session. There are currently two methods, servlet engines use to accomplish this task:
Cookies are name/value pairs stored at the Client (the browser) which can be requested by the server. Thus using cookies is an ideal method to track sessions.
- using cookies
- with URL-rewriting
Unfortunalety, not all browsers support cookies and many people switch off the cookie support because of security concerns (that is a long story). In that case, the servlet engine has to pass the sessionid as parameter with every form action or URL. In order to pass the SessionID in servlet generated URLs, the
HttpServletResponse
has a methodencodeURL()
which does that (the generated URL looks e.g.http://www.foo.bar/servlet/SessionApp?sessionid=819ab810
)For further information see the servlet documentation or the chapter about Session Tracking in the Java Tutorial.
Embedding servlets in SSI-files (*.jthml) allows you to seperate program logic from static layout. However, if you use sessions and the client doesn't support cookies you're (or better: the session is) lost if the user chooses to follow a link in the static part of the jhtml-file: it doesn't contain the parameter with the session so the next time you come over one of your application servlets there is no session ...
One solution to this problem would be to append a servlet call to each URL in the SSI-page in order to dump out the sessionid. Ugly. Error prone. Slow.
The
ParameterPropagatingSSI
Servlet distributed with this Apache JSSI is able to rewrite<A HREF=..
URLs automatically. It appends GET-parameters to any URL if the parameter passed to the page is not null. You've just to specify which parameter name(s) you want to have propagated. In our example it would be thesessionid
parameter which has to be propagated; Apache JServ uses the special parameterJServSessionId
to hold the session. So you've to find out what name your servlet engine uses if you want to track the session.BTW: URLs in
<AREA>
and<FRAME>
tags are rewritten as well.Since you can propagate any parameter you can implement your own session handling passing your own parameter(s) you need to track your users session.
Installation is quite easy. TheParameterPropagatingSSI
is a servlet which implements the normal <SERVLET>-SSI features (as well as the traditional SSI) so it can replace the usual SSI. So install it like the normal SSI servlet.You propably may choose to use a simple SSI to treat your *.jhtml-files and the
ParameterPropagatingSSI
for some other files e.g. *.pjhtml or something like that.You've to give the parameters to be propagated in the init-argument named
PropagateParameters
as semicolon separated list.If you use Apache JServ as servlet engine, you've to give the init argument in your zone.properties file:
PropagateParameters=JServSessionId;myvariable
servlet.org.apache.servlet.ssi.ParameterPropagatingSSI.initArgs=PropagateParameters=JServSessionId;myvariable
Copyright (c) 1997-99 The
Java Apache Project.
All rights reserved.