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 plac
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
Send reply to: Tomcat Users List
>
>
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
quot
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 per
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 t
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.
-
-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 reques
"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
> | w
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
> 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 authe
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 dry
-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(), t
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 authenticat
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
-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
| (we
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
[..]
| - 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
-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'
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 spec
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 fr
-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 T
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 a
-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 cod
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 t
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:
-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
|
HttpServletResponse.sendRedirect("http://myHost.myDomain.com/context/servlet
-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 nei
:56 PM
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 desc
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.
---
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 above?
We are using cookies to track sessions. I don't think
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
rewritin
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
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 cre
I am trying to move an old Tomcat application to a new one. I am
new to Tomcat administration. This application has been around for
a long time but due to resources, it hasn't been keeping up with
Tomcat releases. However, it's becoming clear that it's time to get
more up to date to take advant
34 matches
Mail list logo
