Re: Can only locate or create session in the context of a request cycle.
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]
Re: Can only locate or create session in the context of a request cycle.
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
Re: Can only locate or create session in the context of a request cycle.
Would subclassing your wicket RequestCycle work? That's where I'm doing similar authentication stuff right now and it seems to be working well. It seems like Session is harder to integrate with external apps since actions can happen that it's unaware of. If you use RequestCycle you can check cookies, tokens, etc, on each request, which is really where you want to do it since you have no idea if the user did something (like logout) in the external app. Alex On Apr 15, 2008, at 1:22 PM, mfs wrote: Yeah i need to..i.e. the very authentication token so that for subsequent request i cant avoid the authentication call.. Well i can opt for HttpSession but then i will be using the same wherever in my pages i need it (there are a couple of scenarios where i need to pass the info back), and hence compromising the abstraction wicket provides.. Johan Compagner wrote: if there is no session do you already want to store something? On Tue, Apr 15, 2008 at 3:10 AM, mfs [EMAIL PROTECTED] wrote: Guys, Please comment.. I have a non-wicket AuthenticationFilter which is intercepting all request to my wicket-app and checking if the request is coming in from a valid user. Basically in the url am passed over an authenticationToken (by another application where the user has signed in already). Now in my AuthenticationFilter i check if that is a valid token and if yes i want to set some attribute (isAuthenticated etc) in wicket-session, . The problem is that the wicket session has yet not been created (because this is the first request to the wicket app, intercepted by the filter), and hence i get this error you can only locate or create sessions in the context of a request cycle, when i try do a Session.get(). I am already using WicketSessionFilter which would expose my wicket session to my non-wicket filter. The problem is just for the first request, where a wicket session yet doesnt exist. I am thinking of using HttpSession directly in my filter and store all the session data there, but before i do so, i thought to check if anyone has a better work around, ideally i would want to avoid using it. Thanks in advance Farhan -- View this message in context: http://www.nabble.com/Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16693084p16693084.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] -- View this message in context: http://www.nabble.com/Re%3A-Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16696797p16703394.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can only locate or create session in the context of a request cycle.
Subclassing RequestCycle would give me control on begin/end of the request, i wouldnt still have access to the Wicket Session...right..i am not sure if a wicket session is initiated at that time? If not, a plain servlet filter also gives me control in the beginning of the request, except for the fact that i have am playing with HttpRequest,response, where as wicket requestcycle gives me an abstracted view of these classes, other than i am just wondering as to what i would be able to achieve... I can still do all the authentication stuff (check for authtoken/cookie) in a normal filter too..isnt it?..unless am missing something.. Farhan. Alex Jacoby-2 wrote: Would subclassing your wicket RequestCycle work? That's where I'm doing similar authentication stuff right now and it seems to be working well. It seems like Session is harder to integrate with external apps since actions can happen that it's unaware of. If you use RequestCycle you can check cookies, tokens, etc, on each request, which is really where you want to do it since you have no idea if the user did something (like logout) in the external app. Alex On Apr 15, 2008, at 1:22 PM, mfs wrote: Yeah i need to..i.e. the very authentication token so that for subsequent request i cant avoid the authentication call.. Well i can opt for HttpSession but then i will be using the same wherever in my pages i need it (there are a couple of scenarios where i need to pass the info back), and hence compromising the abstraction wicket provides.. Johan Compagner wrote: if there is no session do you already want to store something? On Tue, Apr 15, 2008 at 3:10 AM, mfs [EMAIL PROTECTED] wrote: Guys, Please comment.. I have a non-wicket AuthenticationFilter which is intercepting all request to my wicket-app and checking if the request is coming in from a valid user. Basically in the url am passed over an authenticationToken (by another application where the user has signed in already). Now in my AuthenticationFilter i check if that is a valid token and if yes i want to set some attribute (isAuthenticated etc) in wicket-session, . The problem is that the wicket session has yet not been created (because this is the first request to the wicket app, intercepted by the filter), and hence i get this error you can only locate or create sessions in the context of a request cycle, when i try do a Session.get(). I am already using WicketSessionFilter which would expose my wicket session to my non-wicket filter. The problem is just for the first request, where a wicket session yet doesnt exist. I am thinking of using HttpSession directly in my filter and store all the session data there, but before i do so, i thought to check if anyone has a better work around, ideally i would want to avoid using it. Thanks in advance Farhan -- View this message in context: http://www.nabble.com/Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16693084p16693084.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] -- View this message in context: http://www.nabble.com/Re%3A-Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16696797p16703394.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] - 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.-tp16696797p16727266.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]
Re: Can only locate or create session in the context of a request cycle.
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]
Re: Can only locate or create session in the context of a request cycle.
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(),
Re: Can only locate or create session in the context of a request cycle.
if there is no session do you already want to store something? On Tue, Apr 15, 2008 at 3:10 AM, mfs [EMAIL PROTECTED] wrote: Guys, Please comment.. I have a non-wicket AuthenticationFilter which is intercepting all request to my wicket-app and checking if the request is coming in from a valid user. Basically in the url am passed over an authenticationToken (by another application where the user has signed in already). Now in my AuthenticationFilter i check if that is a valid token and if yes i want to set some attribute (isAuthenticated etc) in wicket-session, . The problem is that the wicket session has yet not been created (because this is the first request to the wicket app, intercepted by the filter), and hence i get this error you can only locate or create sessions in the context of a request cycle, when i try do a Session.get(). I am already using WicketSessionFilter which would expose my wicket session to my non-wicket filter. The problem is just for the first request, where a wicket session yet doesnt exist. I am thinking of using HttpSession directly in my filter and store all the session data there, but before i do so, i thought to check if anyone has a better work around, ideally i would want to avoid using it. Thanks in advance Farhan -- View this message in context: http://www.nabble.com/Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16693084p16693084.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]
Re: Can only locate or create session in the context of a request cycle.
Yeah i need to..i.e. the very authentication token so that for subsequent request i cant avoid the authentication call.. Well i can opt for HttpSession but then i will be using the same wherever in my pages i need it (there are a couple of scenarios where i need to pass the info back), and hence compromising the abstraction wicket provides.. Johan Compagner wrote: if there is no session do you already want to store something? On Tue, Apr 15, 2008 at 3:10 AM, mfs [EMAIL PROTECTED] wrote: Guys, Please comment.. I have a non-wicket AuthenticationFilter which is intercepting all request to my wicket-app and checking if the request is coming in from a valid user. Basically in the url am passed over an authenticationToken (by another application where the user has signed in already). Now in my AuthenticationFilter i check if that is a valid token and if yes i want to set some attribute (isAuthenticated etc) in wicket-session, . The problem is that the wicket session has yet not been created (because this is the first request to the wicket app, intercepted by the filter), and hence i get this error you can only locate or create sessions in the context of a request cycle, when i try do a Session.get(). I am already using WicketSessionFilter which would expose my wicket session to my non-wicket filter. The problem is just for the first request, where a wicket session yet doesnt exist. I am thinking of using HttpSession directly in my filter and store all the session data there, but before i do so, i thought to check if anyone has a better work around, ideally i would want to avoid using it. Thanks in advance Farhan -- View this message in context: http://www.nabble.com/Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16693084p16693084.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] -- View this message in context: http://www.nabble.com/Re%3A-Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16696797p16703394.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]
