André Warnier wrote:
Pid wrote:
Tomcat Wiki?
However, in the upper left corner appears the legend Immutable page,
and I don't seem to find any button, link or whatever allowing me to
edit the page in question, add an item, whatever.
Am I using the wrong page ?
You are in the right
Bill Davidson wrote:
Bill Barker wrote:
This is correct. TC 3.2.4 never set the secure flag on that cookie,
and TC 3.3.2 would only set it if you enabled an option in server.xml.
This feature of TC is only on TC 4.0 and higher.
Thank you for confirming that.
I personally believe that this
André Warnier wrote:
Bill Davidson wrote:
Bill Barker wrote:
This is correct. TC 3.2.4 never set the secure flag on that cookie,
and TC 3.3.2 would only set it if you enabled an option in server.xml.
This feature of TC is only on TC 4.0 and higher.
Thank you for confirming that.
I
Pid wrote:
André Warnier wrote:
[...]
With everyone's permission, I would offer to write a draft, but I
wouldn't have a clue as to how or where to publish this.
Tomcat Wiki?
Well, I must be too dumb even for that.
On the page http://wiki.apache.org/tomcat/HowTo , the first item is
Date sent: Thu, 12 Jun 2008 13:23:20 +0200
From: André Warnier [EMAIL PROTECTED]
Subject:Re: Moving from a very old Tomcat to a new Tomcat.
To: Tomcat Users List users@tomcat.apache.org
Send reply to: Tomcat Users List
This has been a long thread, and somewhere along the line I must have
gotten lost.
There are two areas that puzzle me, and I would be grateful if someone
could enlighten me for future reference.
Feel free to blast me away if I ask any stupid questions below.
I am neither a Java nor a Tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
| From the thread (or two threads), I gather that :
| - originally, the problem was stated as losing the cookie/session,
| after moving to a more recent Tomcat version, without any other
| changes
Yes, but the OP didn't
[..]
| - how exactly does one override the Tomcat-generated JSESSIONID
| cookie? Just by overwriting it after Tomcat created it anyway ?
Yes.
| (And, as a secondary question, what does one exactly put in it then, so
| that it still matches the session key ? Or can you just put something
|
Christopher Schultz wrote:
[...]
| (And, as a secondary question, what does one exactly put in it then, so
| that it still matches the session key ? Or can you just put something
| arbitrary in it, and Tomcat will use whatever is there to identify the
| session data store ?)
The cookie must
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
| I'm possibly nitpicking, but still trying to get a full crash-proof
| explanation :
No problem. Sometimes it's fun to beat dead horses ;)
| A servlet context consists of a servlet (code), and a context descriptor
|
Christopher Schultz wrote:
Yes, but the OP didn't say whether no changes were made to the original
code (or configuration) when moving between Tomcat versions.
Until the change to the login servlet for the cookie, there were no changes
to the app's code. It's even still being compiled against
Christopher Schultz wrote:
[...] lots of smart things which I duly note but omit here
Tomcat knows that it uses the session to store authentication
information, so Tomcat itself will create the session and add the cookie
to the response at this point.
| The user authenticates, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
| Christopher Schultz wrote:
|
| [request.getSession(true)] has been called, just not by /your/ code
at this point.
|
| Aha ! So there can be hidden, I would even say occult, calls to
| HttpServletRequest.getSession(),
Hi Chris.
First I repeat my thanks for taking the time to educate this
Tomcat-amateur programmer.
Second, I do take your point about the ultimate need, for one who really
wants to understand the details, of reading the Servlet Specification.
I have tried before, and found many parts to be
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: Moving from a very old Tomcat to a new Tomcat.
The servlet now calls sess = request.getSession().
Better if the servlet were to call request.getSession(false) and check the
result for null. If not null, then either authentication
In general, yes, your application has to be able to handle dropped
sessions and session attributes. That's a consequence of the way the
web works. A user could bookmark any page and return to it weeks
later.
You can't control the timing or order of web page requests. If a
servlet finds some vital
Christopher Schultz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| - the behaviour of browsers versus secure/non-secure cookies is not new,
| and neither is the fact that Tomcat generates a secure JSESSIONID cookie
| when the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
| Regarding your questions about why I am concerned about knowing if the
| session-id that is supplied in the JSESSIONID cookie matches the
| session-id of the real current session :
|
| Imagine that a first browser
Bill Barker wrote:
This is correct. TC 3.2.4 never set the secure flag on that cookie,
and TC 3.3.2 would only set it if you enabled an option in server.xml.
This feature of TC is only on TC 4.0 and higher.
Thank you for confirming that.
On 9 Jun 2008 at 20:10, Bill Davidson wrote:
.
.
.
I didn't really do it as a filter though. The login servlet, after
verifying the
user's login and password, just creates and sets the cookie in the response
rather than letting Tomcat create the cookie.
I would make sure to do some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
Bill Davidson wrote:
| However today, I discovered door #3. Make the login servlet (which is
| https) create and set the cookie as a non-secure cookie instead of letting
| Tomcat create the JSESSIONID itself. This is a minor change to the
Christopher Schultz wrote:
Did you change Tomcat code, or your own code?
Our own code. We have an explicit login servlet that handles
checking the login/password against values stored in our Oracle
database.
Okay, so it sounds like you are using your own. Is there any particular
reason you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
Bill Davidson wrote:
| Christopher Schultz wrote:
| Is there any particular reason you are not using the built-in
| container-based security mechanism?
|
| I don't know. I didn't design it. Was that container based security
| available in
Christopher Schultz wrote:
Yep. It's part of the servlet specification. Maybe as you move forward,
you could look into using that and reduce the amount of code you have to
maintain. Note that TC container-managed authentication does not allow
drive-by logins (that is, logins that didn't result
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
Bill Davidson wrote:
| Martin wrote:
| if your client doesnt want to write cookies
| URL-rewrite is the answer
| http://tuckey.org/urlrewrite/
|
| Apache analog is mod_rewrite
|
| I don't understand.
That's because Martin's comment is neither
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
Bill Davidson wrote:
| One other thing I just noticed. The login servlet runs
| under https. After successful login, including creating a valid
| session, it calls
|
Christopher Schultz wrote:
Unfortunately, this is expected behavior. If the JSESSIONID cookie is
created for the first time during an HTTPS transaction, then the cookie
will me marked as secure, and the browser will not send it when
switching back to non-SSL HTTP.
You have two options, here:
Christopher Schultz wrote:
Are you using cookies or URL-rewriting (or both) for your application?
Can you use a tool like LiveHTTPHeaders to observe the headers being
exchanged during the interaction described above?
We are using cookies to track sessions. I don't think we're using URL
One other thing I just noticed. The login servlet runs
under https. After successful login, including creating a valid
session, it calls
HttpServletResponse.sendRedirect(http://myHost.myDomain.com/context/servlets/main;);
which is the one that ends up with no cookie.
Subject: Re: Moving from a very old Tomcat to a new Tomcat.
Bill Davidson wrote:
Christopher Schultz wrote:
Are you using cookies or URL-rewriting (or both) for your application?
Can you use a tool like LiveHTTPHeaders to observe the headers being
exchanged during the interaction described
So if I have this right, the sequence is:
1. Login to the unsecure http site
2. Click on a https secure link
3. You get a second login.
If that's the case, you should change things so people get moved to the
secure https page, login, and then taken back to the http unsecure
page. Sessions
David Smith wrote:
So if I have this right, the sequence is:
1. Login to the unsecure http site
2. Click on a https secure link
3. You get a second login.
If that's the case, you should change things so people get moved to
the secure https page, login, and then taken back to the http unsecure
32 matches
Mail list logo
