Hi Michael, First upon successful login we set a random secure cookie value, but the trick is I also make sure the cookie *key* is unique by using a suffix on the key I can increment if necessary. Both key and value are stored in the session, so we can compare later, and the cookie needs a reasonable timeout (unrelated to session timeout) so that old keys disappear from the user's browser least within a day or two. This setup keeps cookies from different sessions from stepping on each other, which is important for our customers, who regularly have multiple tasks going on in separate windows.
Then in our subclass of ERXComponent I override checkAccess() to check that the in-memory key and value matches what’s in the request’s cookies. You have to override checkAccess() further down the chain for specific pages that shouldn’t ever deny access, like the home or login page, or your main checkAccess() can consult some list of "always allowed" pages, or some similar mechanism. Also, as I recall there was some timing issue with the very first request if you’re setting the cookie after login and immediately going to some protected page. For that I think I set a one-time flag on the session that basically says, “this is the request-response loop in which the user has successfully logged in”, so checkAccess() can ignore the missing cookie. Of course somewhere at the end of that loop, the flag needs to be reset. I think that’s the main part of what we do that relates to your question. Hope this helps! Take care, Mark > On Jan 12, 2017, at 11:44 AM, Michael Hast <mh...@desertsky.com> wrote: > > Hi Mark: > > Your combination approach sounds like a good idea. Which classes did you > overwrite in order to achieve this? > > Michael > > On 1/12/17 10:12 AM, Morris, Mark wrote: >> Hi, >> >> We use a combination of the session ID in the URL plus a secure cookie that >> we manage ourselves to verify that the session hasn’t been hijacked. Don’t >> know if this is a viable option in your case, but it does allow multiple >> sessions. >> >> Regards, >> Mark >> >>> On Jan 12, 2017, at 10:34 AM, Samuel Pelletier <sam...@samkar.com> wrote: >>> >>> Hi, >>> >>> Cookies are shared per browser instance so it is not possible to have >>> distinct sessions inside a single browser. You can uses different browser >>> and they will have their own sessions so if you need 2 simultaneous >>> sessions, you can use a window in FireFox and Chrome for example. >>> >>> WOComponent actions are not working well with multiple tabs or windows in >>> the same session, the "You backtracked to far" will always come. I usually >>> set the page cache very low like 2 so the user does not think it is >>> supposed to works and get the error very early. >>> >>> Samuel >>> >>>> Le 11 janv. 2017 à 21:42, Michael Hast <mh...@desertsky.com> a écrit : >>>> >>>> Hello: >>>> >>>> We recently switch our applications to store the session ID in cookies. >>>> With the session ID in the URL we were able to open the same application >>>> in multiple browser tabs each working with their own session. Is that >>>> possible with cookies? We are not experiencing "You backtracked to far" >>>> every once in a while because each browser tab works with the same session. >>>> >>>> Michael >>>> _______________________________________________ >>>> 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: >>>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >>>> >>>> This email sent to sam...@samkar.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: >>> https://lists.apple.com/mailman/options/webobjects-dev/mark.morris%40experian.com >>> >>> This email sent to mark.mor...@experian.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
