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
Alex Jacoby-2 wrote:
>
> Farhan, I figure we should take this back on-list. Messages in
> chronological order, with my last response at the bottom.
>
> > > On Apr 16, 2008, at 5:06 PM, [EMAIL PROTECTED] wrote:
> > > Alex,
> > >
> > > Wasn't sure how frequent are u in the forum, so thought to mail you
> > directly the reply...As below..
> > >
> > > Subclassing RequestCycle would give me control on begin/end of the
> > request, i wouldnt still have access to the Wicket Session (as the
> Wicket
> > Session isnt created at that time)....
> > >
> > > A plain servlet filter also gives me control in the beginning of
> the
> > request (if not at the end), except for the fact that i have am
> playing with
> > HttpRequest,HttpResponse, where as wicket RequestCycle gives me an
> > abstracted view of these classes, other than that i am just
> wondering what
> > is the real benefit of extending WebRequestCycle..I can still do
> all the
> > authentication stuff (check for authtoken/cookie etc) in a normal
> filter
> > too..isnt it?..unless am missing some benefits which extending
> RequestCycle
> > would provide
> > >
> > > Farhan.
>
>> On Wed, Apr 16, 2008 at 2:20 PM, Alex Jacoby <[EMAIL PROTECTED]>
>> wrote:
>> > Farhan,
>> >
>> > Good call emailing me - I only check the forum when I get to work
>> in the
>> > morning.
>> >
>> > Why use the (wicket) session for auth info at all? You can use a
>> custom
>> > request cycle just like you use a custom session. That way the
>> fact that
>> > the session doesn't exist at request time is irrelevant.
>> >
>> > Then in your pages you can use RequestCycle.get() instead of
>> Session.get()
>> > to extract auth info.
>> >
>> > My custom AuthenticatedWebSession's auth methods all delegate to
>> my custom
>> > request cycle methods.
>> >
>> > Does that make sense?
>> >
>> > I'm not sure if this will help in your case, but it sounds like
>> it might.
>> >
>> > Alex
>
> On Apr 16, 2008, at 5:42 PM, Farhan Sarwar wrote:
>> I kind of get you but to be sure, so u suggesting to store the auth
>> data within the request cycle itself and access it using
>> ((MyCustomRequestCycle)RequestCycle.get()).getAuthToken (offcourse
>> once i have set the same attributes onBeginRequest) as below..
>>
>> public class MyCustomRequestCycle extends WebRequestCycle
>> {
>> String authToken;
>> String cookieName;
>>
>> public String getAuthToken()
>> {
>> return authToken;
>> }
>>
>> public void setAuthToken(String authToken)
>> {
>> this.authToken = authToken;
>> }
>>
>> public String getCookieName()
>> {
>> return cookieName;
>> }
>>
>> public void setCookieName(String cookieName)
>> {
>> this.cookieName = cookieName;
>> }
>>
>> public VCertRetailRequestCycle(WebApplication application, Request
>> request,
>> Response response)
>> {
>> super(application, (WebRequest) request, response);
>> }
>>
>> protected void onBeginRequest()
>> {
>> // getToken from the url passed as a query string
>> setAuthToken(request.getParameter("authToken"));
>> }
>>
>> protected void onEndRequest()
>> {
>> authToken = null;
>> cookieName = null;
>> }
>> }
>>
>> Please comment if i am correctly understanding the approach u are
>> suggesting
>>
>> Now if that is the correct understanding, its just helping me
>> maintain the values submitted with each request, available to all
>> the pages in that particular request cycle...but i would want to
>> maintain that information across the whole session, so that i dont
>> have to append the authToken (passed to me in the url at the first
>> place by the authentication framework) in every url i have in my
>> wicket app (in the form links, forms etcs)...
>>
>> I understand that WebRequestCycle.onBeginRequest is acting like a
>> filter for me in a "wicket way" where before i allow the request
>> cycle to further continue i can redirect the un-authentication users
>> onBeginRequest to LoginPage or something...
>>
>> Thanks in advance and Regards,
>>
>> Farhan.
>
> 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.
>
> You don't need to worry about people logging out from outside your
> app, right?
>
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Re%3A-Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16696797p16747590.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
