Peter Alfors wrote:
> Sorry to keep this post going on, and on, and on...
> But I am still pretty confused.
>
> I am attempting to disable the cookies on the server side by using the
> "noCookies" attribute in the RequestInterceptor as follows:
>
> <RequestInterceptor
> className="org.apache.tomcat.request.SessionInterceptor"
> noCookies="true"/>
>
> My simple web page:
>
> <HTML>
> <BODY>
> Session Id: <%= session.getId() %>
> </BODY>
> </HTML>
>
> I call this page directly in the address bar. So I should not have to worry
> about any url encoding before this page.
>
> On Windows NT:
> IE:
> - Works fine.
> Netscape 4.7:
> - the two browsers show the same session Id.
> Netscape 6:
> - I am unable to get more than one browser started without using
> file --> new
> - This causes the two browsers to have the same Id. (This I
> expected).
> On Linux:
> Netscape 6:
> - I am able to start two browser sessions with DIFFERENT Ids.
>
> If I disable cookies in Netscape (4.7 & 6), within the browser itself, they
> both work fine. However, this is not a valid option for us. We cannot
> ask/force the user to change the settings on his browser in order to safely
> use our product.
>
> Is this "NoCookies" attribute in Tomcat, somehow not effective in the
> Windows environment?
> Am I missing something?
>
The "no cookies" attribute tells Tomcat not to use cookies for session
management. However, you are facing a fundamental *client* restriction --
Netscape always runs all its windows as a single process on Windows platforms,
and there is absolutely nothing that the server can do about that.
If you are able to turn off cookies, you can cause Netscape windows to have
different sessions, but the user can still foil you if they right-click on a
hyperlink (with embedded session id) and select "open link in new window". You
are back in the same boat again.
The safe solution (and the only solution if you cannot control whether the user
uses cookies or not) is to program your app to deal with the "two windows / one
session" problem. One approach to this would be to embed a hidden variable in
each form that is essentially a "sub-session" identifier.
>
> Pete
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]