SOLUTION?: Session Question
SOLUTION?: Session Question
- Subject: SOLUTION?: Session Question
- From: Gerald Hanks <email@hidden>
- Date: Wed, 9 Feb 2005 15:00:04 -0700
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 :
<x-tad-bigger>public boolean </x-tad-bigger><x-tad-bigger>shouldRestoreSessionOnCleanEntry</x-tad-bigger><x-tad-bigger>(</x-tad-bigger><x-tad-bigger>WORequest</x-tad-bigger><x-tad-bigger> aRequest)
</x-tad-bigger>
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:
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
_______________________________________________
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