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: Ramsey Gurley <email@hidden>
- Date: Tue, 9 Mar 2010 09:41:21 -0500
On Mar 9, 2010, at 4:59 AM, Johan Henselmans wrote:
Op 8 mrt 2010, om 17:58 heeft Ramsey Gurley het volgende geschreven:
Out of curiosity, what sort of data are you trying to restore with
PDsession?
It's basically information about the cashregister they are using. So
it contains information about how much money was in it when they
started, and links to all the stuff they have sold. This PDsession
can link any financial acitivity to a user, so you can find out who
did what when (provided they log in with their own password etc).
Have you looked at the ERCoreBusinessLogic framework? It sounds like
you could accomplish this with ERCore's audit trails pretty easily.
The only limitation I'm aware of in the current implementation are
many-to-many relationships. If nothing else, you may want to look at
it for inspiration.
Ramsey
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
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