httpsession and cookie pb

[Stéphane Laurière <st...@hotmail.com>]

Hello,
I have the following problem when creating an HttpSession: the first time
the cookie is sent to the browser, the cookie value is in the url like the
following:
http://193.251.34.121:8000/wizemail/home.jsp;jsessionid=To1010mC130408654620
55928At
Then if I retry to logon (the cookie is set during the logon process)
everything works fine (the cookie is set and the client is redirected to the
correct page whereas in the first step, the redirection page is the one
containing the cookie value, which obviously doesn't exist).

Does any of you have had a similar pb?
Thanks if you can help,
regards
St

----- Original Message -----
From: "Thor Heinrichs-Wolpert" <th...@echidna.net>
To: <ge...@jakarta.apache.org>
Sent: Monday, July 31, 2000 6:30 PM
Subject: Re: http authentication


> res.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
> // set the authentication realm
> res.setHeader("WWW-Authenticate", "BASIC realm=\"" + _Realm + "\"");
>
> This is being sent to the browser, and the browser is replying with the
> correct un/pw.
> If you send it again, the browser will believe the un/pw is wrong and pop
up
> the auth panel for the user.
>
> The real trick is remembering you've killed this users session.
>
> This is NOT just for the webapp, but for the entire security realm (small
> point).
>
> Thor HW
>
>
> ----- Original Message -----
> From: Johan Peeters
> To: general@jakarta.apache.org
> Sent: Monday, July 31, 2000 3:54 AM
> Subject: Re: http authentication
>
>
> Thanks for the reply. I understand from what you write that the uid/pw are
> passed with each request that is subsequently made for pages within the
same
> webapp. What is not clear is whether there is a way to persuade the
browser
> to send uid/pw - I guess that boils down to persuade it *not* to supply
the
> Authorization header. Are you saying that there are 'correct headers'
which
> would effect this. Any clues on what they may be?
> I read up a little in the http and the http authentication rfcs - with
> digest authentication the 'stale' flag in the WWW-Authenticate header
> sounded promising, although, perversely, it would seem you have to set it
to
> FALSE to force the browser to prompt the user for uid/pw. However, I
> understand digest authentication is currently not supported on the apache
> servers. Are there any alternatives or should I go back to rolling my own
> authentication?
> Many thanks,
> Yo
> Thor Heinrichs-Wolpert wrote:
>   This is because the browser is maintaing the security context, rather
than
> in your previous version where you managed the context on the server.  The
> browser WILL ALWAYS send the un/pw for any page that wants it in the clear
> (if the challenge-response fails) and you are in a secure zone (or
configure
> it to not care). The only way to it, is to program it yourself (no free
> lunch here for ease or security) to invalidate what the browser believes
is
> the correct un/pw for the realm it now is associated it with, by sending a
> the correct headers back. Thor HW
> ----- Original Message -----
> From: Johan Peeters
> To: tomcat
> Sent: Sunday, July 30, 2000 9:08 PM
> Subject: http authentication
>  I think and I hope this is not so much an Apache-specific question as a
> general question about using http authentication in JSPs/servlets.
Apologies
> for being somewhat off-topic.
> I used a logon page previously where I provided the user with a form,
> retrieved the values (s)he put in and did the authentication against a
local
> database. Having authenticated the user, I put him into the session. For
> each subsequent access to a page belonging to the application, I would
check
> whether there is an authenticated user in the session. I now want to
change
> to using standard http authentication. The reasons for this are
> it is more secure since it can be configured to use a challenge-response.
> Whereas I could write that myself too, I prefer not to.
> it works across a WAP gateway - I couldn't get my home-grown
authentication
> to work in that configuration.
> So, I am able to do the authentication - the server (tomcat i.c.) checks
the
> password for me, without having to write extra code. My application knows
> who has logged in by calling session.getRemoteUser().
> But there are the following issues:
> my sessions used to timeout, forcing a new login. That appears not to be
the
> case anymore - at least, the user does not have to log in again as the
> authentication context seems to persist for the lifetime of the browser.
> logging off used to be easy: remove the user from the session or
invalidate
> the session altogether. However, I have not found a way of removing the
> remote user.
> Can anyone help? Any pointers to helpful material?
> Thanks,
> Yo
> --
> Johan Peeters mailto:johan.peeters@alcatel.be
> Software Architect - Net Commerce
> Alcatel - Gen. De Wittelaan 11 A bus 1 - 2800 Mechelen - Belgium
> Phone: +32 15 29 3427 Fax: +32 3 240 4800
>
>
> --
> Johan Peeters mailto:johan.peeters@alcatel.be
> Software Architect - Net Commerce
> Alcatel - Gen. De Wittelaan 11 A bus 1 - 2800 Mechelen - Belgium
> Phone: +32 15 29 3427 Fax: +32 3 240 4800
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>