tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: request.login() not persistent
Date Sat, 07 Apr 2012 16:38:17 GMT
2012/4/6 Jerry Malcolm <2ndgenfilms@gmail.com>:
>
> Questions:
>
> 1) The <meta... html tag simply tells the browser when it reads the page to
> 'try again' at the new URL.  In my mind that is no different from the user
> responding to something on a page and submitting a request for a new page.
> Why is the session logged-on state information somehow lost in that
> interaction when it is maintained if the user just hits a button and goes
> to another page?
>
> 2) I assume the response.sendRedirect( ) with the encoded URL sends one of
> the 301 or 303 or something response codes back, right?  In either case,
> <meta... or 30x response code, why is the session info lost in one and not
> the other?
>
> 3) The biggest concern I have is that it worked for several months on one
> machine with the <meta... tag coding.  If it worked, then it stopped, now
> it works again, and I don't know why, my assumption is that it's going to
> stop working again for me sometime in the future.  What could I have done
> that made it work at one time on one machine and then stop?
>

1. When the client accesses the webapp second time it has to provide
session id to Tomcat.  The session id can be provided via Cookie:
header in the request or via sessionid "path parameter" in the URL.

If none of provided values matches existing session, Tomcat creates a new one.

Your "refresh" meta tag does not include sessionid, so when refresh
happens the information can come only from a cookie  and apparently
the value is absent or not correct.

Chris already answered how to modify your HTML page.

2. When a user is authenticated, recent Tomcat versions change the
sessionid value. All data are migrated to the new session id, so
nothing is lost, but the new id has to be sent to the client.

The id is sent via "Set-Cookie" response header.  If the client does
not receive the header it might be that
a. setHeader() failed, because some response data has already been
sent to the client and thus no more headers can be added before the
response text,
b. The headers have been cleared before sending the response.
c. The client browser does not respect the Set-Cookie header (the
cookies are disabled in the browser),
d. Tomcat is behind a proxy (e.g. HTTPD) and the path in the
set-cookie header does not match the address that client requested.
(Misconfigured reverse proxy)
e. Several Set-Cookie headers are received.


3. The client can have several different "sessionid" cookies. That is
because a cookie is scoped to a "path" on the server. Each webapp has
its own path.  The "path" value is sent in Set-Cookie response header,
 but it is usually not included in the "Cookie" response header.

Thus Tomcat usually sees several session cookies and have to find the
applicable one between them.

Clearing the cookies for your server in the browser sometimes can
change behaviour. (I cannot clearly say why it could help, because
those cookies should not be persistent, but in some situations some
people said that it helped).



You need to use some tool to see those response and request headers.
E.g. for Firefox you can use Firebug plugin's Network tab or Live Http
Headers plugin.

https://addons.mozilla.org/en-US/firefox/addon/firebug/
https://addons.mozilla.org/ru/firefox/addon/live-http-headers/

It is also possible to capture and inspect network traffic with some
sniffing tools like Wireshark or Fiddler.  It is also possible to
configure Tomcat to print specific headers into its access log.


Best regards,
Konstantin Kolinko

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


Mime
View raw message