user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Data too long for column (not really)
Probably OT, but, is there a simple fix for the problem when saving some text that contains special characters where the error misleadingly says the column is too long when it isn't (using mysql mysql-standard-5.0.18-osx10.4-i686): Next exception:SQL Warning:01004 -- error code: 0 -- msg: Data truncation: Data too long for column 'NAME' at row 1 at com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseContextInformationAdded(EODatabaseContext.java:4500) at com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabaseContext.java:6212) at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:376) at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3176) inserting some text like: L?kensgård What is my best plan of attach. I have done some googling and have ended up being very confused. Thanks John ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: user is only allowed to log in once
Out of curiosity, what sort of data are you trying to restore with PDsession? 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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/ramsey%40xeotech.com This email sent to ram...@xeotech.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
displayGroup keypath question
Greetings all, I have a component using Wonder's ExcelGenerator framework, which is based on another component which is also using batching display groups. I have a button which is supposed to generate an excel document version of the displayGroup. I also am adding a row at the bottom of the excel page which is supposed to give me a grand total of all the objects in the displayGroup, for that column. This all works, assuming the user did not set any queryMatch dictionary values on the preceding search page. My action to do this returns the following excelPage: WOComponent excelPage = pageWithName(MyExcelComponent.class.getName()); excelPage.takeValueForKey(displayGroup().filteredObjects(), arrayOfObjects); excelPage.takeValueForKey(minRefreshDate(), minRefreshDate); excelPage.takeValueForKey(displayGroup().allObjects().valueForKeyPath(@sum.myFieldValue), myFieldValueGrandTotal); ... Unfortunately, where the user did a search using values from the queryMatch dictionary, the @sum seems to give the total of all objects in the displayGroup and not just the ones that match the queryMatch. Apparently filteredObjects() is overridden to use allObjects() where the displayGroup is batching. Obviously, I don't need to batch the excel page, so I thought about setting the displayGroup isBatching = false; but there seems to be no such method. So I thought I'd post this as a question for the list. So in short (?) we have a search page, which qualifies the displayGroup based on some information the user has no control over (e.g. does this user have access to this data), and also has user entry fields which are used via queryMatch to further qualify the displayGroup. The results in the web page are properly totaled pages, which the proper number of batches. The excel page version is not supposed to batch (obviously), but rather display all the data in all batches in one excel file, with a total of all (subject to all the qualifiers and queryMatch values). The total seems to be the totals all in the displayGroup, without considering the queryMatch values. However, in the debugger, the displayGroup has the queryMatch values, and the qualifier has that as a limitation, yet does still return totals for all objects including those which do not match the query match. Any ideas? What am I missing/doing wrong? Andrew ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Data too long for column (not really)
John, I am guessing that somewhere along the line the byte count is being used to calculate the width rather than the UTF8 width. What does your jdbc connection URL look like? What does the 'SHOW CREATE TABLE tablename;' output for that table look like? Regards, Kieran On Mar 8, 2010, at 11:22 AM, John Pollard wrote: Probably OT, but, is there a simple fix for the problem when saving some text that contains special characters where the error misleadingly says the column is too long when it isn't (using mysql mysql-standard-5.0.18-osx10.4-i686): Next exception:SQL Warning:01004 -- error code: 0 -- msg: Data truncation: Data too long for column 'NAME' at row 1 at com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseContextInformationAdded(EODatabaseContext.java:4500) at com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabaseContext.java:6212) at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:376) at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3176) inserting some text like: L?kensgård What is my best plan of attach. I have done some googling and have ended up being very confused. Thanks John ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com This email sent to kieran_li...@mac.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net This email sent to a...@krank.net ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net This email sent to a...@krank.net ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription:
Re: user is only allowed to log in once
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 jo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net This email sent to a...@krank.net
Re: user is only allowed to log in once
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
Re: user is only allowed to log in once
Am 08.03.2010 um 21:46 schrieb Mike Schrag: 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. You'll *mostly* have to do this for every page component, not every component (unless it weirdly switches states and such). However, the huge cost of a persistent store is that you need to store after *every* request. In particular with postgres this will kill you... it would make more sense to put it in memcached or something. Cheers, Anjo ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
