Right after I got onto my bike to ride home I realized the same thing
you did: it sounds like there's no need for the request cycle -- just
look for the token upon session creation (and maybe again if there's a
subsequent request for a not-yet-validated session).
But then there's the logout issue... If you do need to worry about
the user logging out in the other app too, it might be simplest to
just use a cookie to represent the fact that the user's logged in, and
check it (in the requestCycle) on each request. Assuming your two
apps are in the same domain, it works. There's some complication in
trying to make the cookie secure enough to avoid forgery, but it's
doable.
You mentioned the possibility of just invalidating the wicket session
from the other app -- if you can do that, go for it -- it sounds
simpler. In my case the other apps aren't java based, so that wasn't
an attractive option.
Good luck,
Alex
That is what I meant, but I wasn't sure if the token you were
referring to was in a cookie or in the URL. Since it's in the URL,
it
does complicate stuff.
Here's my proposal: use the custom request cycle to grab the initial
token and store that auth info in the request cycle. Then when you
create a new wicket session, check if the request cycle has a valid
auth token -- if so, you validate the session, save the auth token
there if necessary, and never worry about the request cycle (or URL
token) again.
Do i need to retain this in the RequestCycle at the first place ? I
mean i
can just fetch the token from the request object itself..in my
CustomSession constructor as follows :
public MyCustomSession(Request request)
{
super(request);
String authToken = request.getParameter("authToken");
if (authenticate(authToken) == "success")
{
setAuthToken(authToken);
}
}
I am not sure as to when exactly is the Session is created, but
given it
does before the request processing starts, in that case it is fair
enough
to have this logic in the Session constructor instead of
onBeginRequest(),
what do you think ?
You don't need to worry about people logging out from outside your
app, right?
Well we do, havent thought about it much, but the way i see it is
to have
invoke the InvalidateSessionPage (from this other interface/app),
in which
1) i invalid the wicket session
2) Have javascript to delete the cookie (jSessionId) from the
browser,
though i feel this wouldn't really be necessory if the first step is
performed..What do you think ?
What do you think? better approach, where the external app isnt
tightly
coupled with my app (where it needs to invoke the
InvalidateSessionPage)..
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
