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]
