Hi Scott, Ah, but GROUPED BY userid alone, will not tell me how many distinct times that user logged in. That's why I was suggesting a compound key (userid/userreference) would do the trick in this case.
So, as long as we've hijacked this thread, I've found a little bug that I need some help with. When a user has timed out, the appfile stores the current request in a user variable: @@user$goodloginreturn == <@APPFILE>?<@CGIPARAM NAME=HTTP_SEARCH_ARGS aprefix="" asuffix="" rprefix="" rsuffix="" cprefix="" csuffix=""> Then we execute a 302 redirect to <@ASSIGN request$httpHeader "HTTP/1.1 302 Redirect<@crlf>Location: login.taf<@CRLF><@SETCOOKIES><@USERREFERENCECOOKIE><@CRLF><@CRLF>"> The user is authenticated (maybe requiring a login form) and upon success is redirected back to @@user$goodloginreturn This allows users to bookmark pages. The problem occurs when a user times out, and then submits a form with a POST argument. Because I'm not including the POST arguments in the goodloginreturn redirect, the form action fails. Typically, there's a missing field, and users say, justifiably, that everything is there. There are two answers: a) flag the requests that required re-authentication, and tell the user "Sorry, but you're session timed out. User the Back button and re-submit the form." b) construct a complete HTTP header and body to include the POST arguments. Can you tell me off the top of your head, how the POST arguments are appended to the header? thx >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 > 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
