Re: SOLUTION?: Session Question
Re: SOLUTION?: Session Question
- Subject: Re: SOLUTION?: Session Question
- From: Chuck Hill <email@hidden>
- Date: Mon, 14 Feb 2005 15:12:42 -0800
That makes me feel a lot better than the previous solution did. :-)
Calling restoreSessionWithID could possibly cause problems with other
implementations (but should be fine with the standard one). From the
WOSessionStore API I would prefer to use checkOut/checkIn for this, but
looking at the WOContext.session() API docs (you need to create a
context to check in the session) I think that doing this would lead to
problems, like infinite recursion. I would be really nice if the
WOSessionStore API had a hasSessionWithSessionID method on it. I've
often wanted one.
Chuck
On Feb 9, 2005, at 2:00 PM, Gerald Hanks wrote:
OK, using this information from Stephane I have come up with the
following solution. I have added the following code to the
Application class:
public boolean shouldRestoreSessionOnCleanEntry(WORequest aRequest) {
WOSessionStore aSessionStore = this.sessionStore();
Session aSession =
(Session)aSessionStore.restoreSessionWithID(aRequest.sessionID(),
aRequest);
// If the session is not null then its still in the SessionStore and
can be restored.
if(aSession != null) {
return true;
}
//If the session no longer exists, return false so that the user
will get a
//new session instead of the session timed out error page
return false;
}
Remember this code is only called when the application is accessed
using the default request handler or what Apple is calling the front
door. (This would be the application url up to and including the
.woa). This code simply allows the application to decide whether or
not to drop the exiting session id cookies based on whether or not the
session associated with those id's is still in the sessionStore.
Anybody ready to trash on this code? During what little testing I
have done so far today this worked pretty well. It is a much better
solution than the one the I had before. Any comments, suggestions,
thrashings are appreciated.
--gerald
On Feb 9, 2005, at 1:21 AM, Stephane Guyot wrote:
Gerald,
the trouble with cookies is that you are dependant of the user-agent
( IE, firefox, Safari .... )
But have a look on the following API :
WOApplication :
public boolean shouldRestoreSessionOnCleanEntry(WORequest aRequest)
Stephane
Le 9 févr. 05, à 00:54, Gerald Hanks a écrit :
The return is by using /www.mydomain.com/cgi-bin/WebObjects/Test.woa
including the "woa". I have verified that the cookie is set with
the path of /cgi-bin/WebObjects/Test.woa so this should work.
However it does not.
--gerald
On Feb 8, 2005, at 4:14 PM, Chuck Hill wrote:
Do you return by using
/www.mydomain.com/cgi-bin/WebObjects/Test.woa or
/www.mydomain.com/cgi-bin/WebObjects/Test (note the missing .woa).
The wosid cookie is set with a path of
"/cgi-bin/WebObjects/Test.woa" and will not be sent for the regular
"front door" URL. Override public String domain() in Session to
return "/"; to avoid this. Unless, that is, you are running
multiple, cookied WOApps on the same domain. If which case you
will have to find some way to differentiate them.
Chuck
On Feb 8, 2005, at 1:26 PM, Gerald Hanks wrote:
I have an application called Test that I am developing. I can
access the app at
http://www.mydomain.com/cgi-bin/WebObjects/Test.woa I have the
application set to store session ids in cookies. I can start a
session and everything works well until I leave the site and
return. If I return by back tracking my session is still active.
If I return using a direct action such as
http://www.mydomain.com/cgi-bin/WebObjects/Test.woa/wa/default
then my session is still active. If I return using the
application url
http://www.mydomain.com/cgi-bin/WebObjects/Test.woa then a new
session is created and I lose all my session information.
Is this the way things are supposed to happen or am I doing
something wrong? How can I allow users to leave my webobjects
application and return without losing their sessions? My
understanding was all I had to do was to store the session ids in
cookies.
--gerald
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects
developers who want to increase their overall knowledge of
WebObjects, or those who are trying to solve specific application
development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden