On Tue, 2009-06-30 at 16:32 +0200, André Warnier wrote:
> Daniel Henrique Alves Lima wrote:
> > 2. When user fills the form in your small login box,
> > - Send a JS XmlHttpRequest (AJAX) to a protected resource (for
> > instance protected_resource.jsp);
>
> It seems to me that you can skip the above step, no ?
> And do the following one immediately.
I don't know if Tomcat likes a directly call to login
page/j_security_check (i think i've just had troubles using this
approach).
I've did a similar thing to force an applet to authenticate the user
using Tomcat's declarative security in my webapp a long time ago.
>
> I think the problem is here (but probably solvable) :
> In return to a successful login by the XmlHttpRequest, the server sends
> back a page, along with a "set-cookie" header, or with embedded
> ";jsessionid=.." parameters.
I really don't know what is the exact moment when jsessionid is
created. I think that "set-cookie" will be handled by the browser as a
whole (just testing to be sure), but ';jsessionid=' could be a problem.
In previous applet example, i've used javascript (called from the
applet) to ask the value of JSESSIONID cookie, after a successfully
authentication.
> This response page is received by the
> XmlHttpRequest handler. This does not automatically (I think) mean that
> the browser (as a whole) knows about it, nor that any next outgoing
> request is going to magically include the jsessionid.
If you create an unauthenticated session before, will Tomcat "reuse"
sessionid after authentication ? If it does, you just need to do a
request.getSession(true) in the first (unprotected) resource of your
webapp.
--
"If there must be trouble, let it be in my day,
that my child may have peace."
Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...
