when you're done implementing persistent session, let me know ... ms
On Mar 8, 2010, at 11:13 AM, Johan Henselmans wrote: > I store a persistent PDsession EO (not related to WOSession): if a user is > timed out in a WOSessions, the next time the user logs in, the information > from the PDsession is restored unless they explicitely close it. > > The problem that occurs is that sometimes a user logs itself in twice, so the > information in the PDsession is updated from two browsers. > > So I have to prevent a user to log in twice. > > An option I thought of was: > -store a WOSessionID in thePDsession > -when the user logs in, check if that session is still available in the > applications WOSessionStore. > -if so, refuse login > > Problem is that (as far as I know) applications do not share the sessionID's > so if there would be another WOApplicatiion that has the same requirement, > the user would still be able to login. > > So I thought of changing the WOSessionStore to something persistent, instead > of residing it in memory, and let the applications that have to make use of > such a requirement (user can only login on specific application) to store > their sessions in a persistent place. > > In noticed that way is also mentioned in: > > http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/com/webobjects/appserver/WOSessionStore.html > > " > There is one subclass of WOSessionStore implemented for the developer's > convenience. A server WOSessionStore (the default) stores session state in > the server, in application memory. The serverSessionStore method returns this > WOSessionStore. > > You can create a custom session store by making a subclass of WOSessionStore. > The subclass should properly implement the saveSessionForContext > andrestoreSessionWithID methods and should have a public method that the > application object can use to obtain an instance. Some interesting session > stores could be: > > • A database session store that stores session data in a database as > blobs, with the session ID as the primary key. This kind of WOSessionStore > can be shared by many instances of the same WebObjects application, thus > distributing the load (requests) among the instances. > • An adaptive session store that stores session state either in cookies > or on the server, depending on what the client supports. > If you create your own WOSessionStore class that generates persistent > objects, you should implement an algorithm that cleans up session state after > the session is inactive for a long time. The server WOSessionStore provided > by WebObjects performs this clean-up properly, but the API is not yet public. > " > > I also noticed that in the Developer Examples There is the > WOSessionStoreExample Framework, that seems to implement something like this. > > Does anybody have any experience with this technique, does it solve the > problem I am trying to tackle or is there another approach more appropriate? > > > > Johan Henselmans > [email protected] > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
