Re: user is only allowed to log in once
Re: user is only allowed to log in once
- Subject: Re: user is only allowed to log in once
- From: Anjo Krank <email@hidden>
- Date: Mon, 8 Mar 2010 21:09:14 +0100
Bah. You don't really need to store the pages. You only need to store how they can be reconstructed...
Cheers, Anjo
Am 08.03.2010 um 18:07 schrieb Mike Schrag:
> Even within Apple, I would suspect that worked under VERY specific restrictions about what can be in your session at any point in time ... As soon as you start persisting the backtrack cache, it's going to get crazy complicated.
>
> On Mar 8, 2010, at 11:40 AM, Pascal Robert wrote:
>
>> So nobody outside Apple have been able to do this? :-(
>>
>>> 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@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
>>>
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
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