Hi Bill, Thank you for the details.
I think in this case, you should query the "GROUPED BY" on the User's ID (or whatever you use), and not the USERREFERENCE key value. As long as the previous User had properly logged out of their session, it is permissiable that the same key could be re-used by another User. I don't see anything wrong with this. Remember, this same methodology for "session-cookie" keys is used by other Web application platforms, such as PHP, ASP, ColdFusion, blah, blah, etc... It is supported across the industry for good reason. Also consider the case of public computers at Internet cafes. Of course, "IF" the user did "NOT" logout properly - that's another story. And this was my point. --- I have a similar set of logic that records session information to the database, but it's purpose is to ensure that nobody other than the original owner of a UserRefernce key tries to logon, "IF" the original UserReference "session" is still considered active. To me, this is a potential security issue and I <@PURGE> the session, not expire the Witango_UserReference session-cookie. And of course, given the fact that both "sessions" carry the same USERREFERNCE key, they are both purged. Regardless of who the real owner of the session may be, I think it's best to error on the side of caution and purge both. Then let them try and get back in legitimately. This happens rarely, but still important enough to me to include it in my code. --- If I understand you correctly, it sounds like your system allows a User to extend access to your application during longer periods of inactivity - while at the same time not overloading memory management of the Server unnecessarily. Good idea, but if I also understand you correctly - you've also got a potential security risk because your extra cookie is overriding the purpose of the Witango_UserReference session-cookie. I don't think you have a problem with the fact the Witango_UserReference is still present. The problem is your extra cookie has too much control. I'm thinking in context of public computers mostly, but it's enough to give me pause. Please forgive me if I still don't understand your application. --- Hope I'm close to the mark, and this is of some help. Cheers..... Scott Cadillac, Witango.org - http://witango.org 403-281-6090 - [EMAIL PROTECTED] -- Information for the Witango Developer Community --------------------- XML-Extranet - http://xmlx.ca 403-281-6090 - [EMAIL PROTECTED] -- Well-formed Development (for hire) --------------------- -----Original Message----- From: Bill Conlon <[EMAIL PROTECTED]> To: "Witango-Talk" <[EMAIL PROTECTED]> Date: Thu, 4 Dec 2003 15:38:01 -0800 Subject: Re: Witango-Talk: Session issues > Scott, > > You do understand the framework posted on your site (thank you). But I > was just responding to the issue of why one might want to expire the > userreference session cookie. > > To review the framework, the userreference is maintained in a session > cookie. When someone logs out, their user authentication cookies are > expired. These cookies may be set as "session" (i.e., expire when > browser quits) or with some definite expiration -- it doesn't matter. > On > the other hand when that user times out, their user variables expire on > the server, but the authentication cookies remain. The authentication > cookies allow me to rapidly check (without hitting the db for each taf) > that users are authorized. If the user has timed out, they are used to > hit the db and re-establish user variables. > > My log entries have to do with info known to the server, so a > particular > user might have entries like. > user login logout method userreference IP > bill 12:00 12:05 prompt 123ABC > 192.168.181.13 > scott 12:01 00:00 prompt 456EFG > 192.168.181.14 > bill 12:19 12:32 cookie 123ABC > 192.168.181.13 > dan 12:33 12:35 prompt 123ABC > 192.168.181.13 > bill 13:02 00:00 prompt 789HIJ > 192.168.181.13 > > So, interpreting the log: > > * scott and bill are currently logged in (00:00 -- actuall its a 14 > digit > mysql timestamp) > * bill's session 123ABC had a total duration of 32 minutes, 18 of which > were active, where he actually used a witango userreference > * because the userreference cookie was NOT purged on logout, dan got > logged in with the same userrefence as bill. > > So If I wanted to run a report, GROUPED BY userreference, dan's session > time would get lumped with bill's, and I wouldn't even see that dan had > logged in. > > >Hi Bill, > > > >If I'm not mistaken, from what I understand about your particular > coding > >technique, > >your "cookie" is about "session information", not real > "session-cookies" - > >there is a > >distinction. > > > >Cookies that you assign with a long "expire" value are by definition > >regular cookies, > >regardless if they are about "sessions". These kind of cookies are > typical > >for auto-logons > >when revisiting a website, or for moving special data across more than > one > >website. > > > >And yes, it is important to maintain some management of them, as > required > >by your > >application. > > > >On the other hand, the Witango_UserReference is a "session-cookie" and > (by > >difinition) has > >no properties other than a value, and a single browser instance cannot > >contain more than one > >of these of the same name. "Session-cookies" are also automatically > purged > >when the browser > >instance closes. > > > >So if you're using regular cookies to maintain User IDs, it's a > different > >story. > > > >Granted, I've made some assumptions about how you are using your > cookies, > >but I'm sure we > >are on slightly different pages here. Correct me if I'm wrong. > > > >Cheers....... > > > >-----Original Message----- > >From: Bill Conlon <[EMAIL PROTECTED]> > >To: "Witango-Talk" <[EMAIL PROTECTED]> > >Date: Thu, 4 Dec 2003 14:02:47 -0800 > >Subject: Re: Witango-Talk: Session issues > > > >> I have automatic re-login via some session cookies in case the user > >> variables have timed out. I keep a user log (userid, IP, > >> userreference, > >> logintime, logouttime, loginmethod=prompt or cookie). I query this > >> log, > >> GROUPed BY userreference, to give me usage data that includes total > >> elapsed time as well as actual usage. > >> > >> This is a cose where purging the UserReference session cookie could > be > >> useful -- so two userids don't get combined. Though I could use a > key > >> consisting of userid+userrefernce to solve this. > >> > >> >I can't think of a single issue where it would be necessary to > >> >deliberately purge the > >> >Witango_UserReference session-cookie. > >> > >> > >> Bill Conlon > >> > >> To the Point > >> 345 California Avenue Suite 2 > >> Palo Alto, CA 94306 > >> > >> office: 650.327.2175 > >> fax: 650.329.8335 > >> mobile: 650.906.9929 > >> e-mail: mailto:[EMAIL PROTECTED] > >> web: http://www.tothept.com > >> > >> > >> > _______________________________________________________________________ > >> _ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > >______________________________________________________________________ > __ > >TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > > Bill Conlon > > To the Point > 345 California Avenue Suite 2 > Palo Alto, CA 94306 > > office: 650.327.2175 > fax: 650.329.8335 > mobile: 650.906.9929 > e-mail: mailto:[EMAIL PROTECTED] > web: http://www.tothept.com > > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
