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: Mike Schrag <email@hidden>
- Date: Mon, 8 Mar 2010 15:46:17 -0500
for non-D2W you have to implement that interface for every single component you could ever use, though ... and deal with the fact that you could have pages with uncommitted EO's, etc. for D2W you might be able to do a rough impl, but you still can't general case it if people use custom components -- every component has to participate or be thrown away in mid-state.
i think you could probably do an admirable 75% job of it and the last 25% would be a big pain in the butt and would always have funky problems. the more i've thought about trying to solve this, the more i've wondered whether anyone actually even wants it ... do you really need full session failover with backtrack, or is it enough to get bounced out but just make sure your shopping cart stays around (i.e. just preserve the important state for your app, period, and don't try to play games attaching that to sessions).
this does suck, though, for people who are sitting on a form, filling it out, when your app bounces ...
ms
On Mar 8, 2010, at 3:34 PM, Anjo Krank wrote:
> It's way less complicated and can be solved on a case-by-case basis (AKA do I really need this stuff?). For one, you could almost trivially implement it in ERD2W.
>
> Cheers, Anjo
>
>
>
> Am 08.03.2010 um 21:24 schrieb Mike Schrag:
>
>> you say that like it's trivial :) if that was easy, we wouldn't need a sweet stateful web framework ....
>>
>> ms
>>
>> On Mar 8, 2010, at 3:09 PM, Anjo Krank wrote:
>>
>>> 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