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.
>
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/Re%3A-Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16696797p16735396.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]
