Hi Scott, thx. Indeed, as I was reading RFC2616 after posting yesterday, I saw a whole bunch of issues: * How to construct the Request message (@URL seemed the only way) * dealing with memory usage. In fact this issue came up with a client who was uploading large files into the db, so SEARCH arguments can't be used. Apparently, he would get to the form, then go check the file and maybe make some changes. By the time he got around to hitting the submit button, he was timed out.
Actually, my re-direct approach is functionally similar to a TCF in that there is a single login.taf instance that does all authentication against the db. And the TCF does not solve the problem that the actual work being done ASSUMES that info is provided as ARGUMENTs. I think my basic programming model needs to change, so that the working code ALWAYS uses variables. We would need a code snippet at the top of each TAF that created variables with the same names as the arguments. [Ideally the app server would be optimized so variables created this way used a handle or pointer to the underlying argument data, rather than being copied]. >Hi Bill, > >> 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. > >Sounds more like a problem with how to record some data, then a problem >with Session >management. > > >> >> 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? >> > >Option c) provide Logon logic for all your pages, so you don't have to >redirect the user. > >If you have a common TCF, or Branch or Include at the top of all your TAF >files, then you >could also provide the code to do both: Logon in a user, and process a form. > >In your scenario, when the user finally posts a form, but their session >happened to expire - >then present a common logon form from an Include, for that TAF, as well at >the same time >provide code to capture any extra post arguments that happen to be >present. Something like: > ><form name="logon_form" method="post"> ><input type="hidden" name="x_log" value="on" /> ><input type="hidden" name="x_URL" value="<@appfilename><@ifempty ><@cgiparam http_search_args >encoding=none>><@else>?<@cgiparam http_search_args encoding=none></@if>"> ><input type="hidden" name="x_UserID" value="" /> ><input type="hidden" name="x_Password" value="" /> ><@assign local$x_Args value="<@argnames>"> ><@assign local$x_Args value="<@filter local$x_Args expr='#2 = post'>"> ><@if expr="<@numrows array=local$x_Args> >= 1"> ><@assign local$x_Args value="<@filter local$x_Args expr='#1 != "x_log"'>"> ><@assign local$x_Args value="<@filter local$x_Args expr='#1 != "x_URL"'>"> ><@assign local$x_Args value="<@filter local$x_Args expr='#1 != "x_UserID"'>"> ><@assign local$x_Args value="<@filter local$x_Args expr='#1 != >>"x_Password"'>" ></@if> ><@assign local$x_argCounter value="<@if expr='<@length str="<@cgiparam >http_search_args>"> > >1'>1<@else>0</@if>"> ><@! write the extra arguments> ><@rows array=local$x_Args> ><@assign local$x_argCounter value="<@calc expr='<@var local$x_argCounter> >>+ 1'"> ><input type="hidden" name="<@var local$x_Args[<@currow>,1]>" value="<@arg >name='<@var >local$x_Args[<@currow>,1]>'>" /> ></@rows> ></form> > >This way, when the user does their logon, arguments for both the Logon and >the form are sent >at the same time. Nothing is lost. > >Then, at the top of your TAF authenticate the User and then allow the User >to execute down >to where the form needs to be processed. All in one fill swoop. > >Attached is a picture of how the TAF might look. When you see the IF >Actions, you can see >the user will end up at the "Logon_form" position if their session has >expired (that's where >the above code goes). > >Then when they post, the TAF is requested again and the logon is >authenticated in >the "On_Create" method of the "Create_smasalsa" TCF at the top of the >file, then the >execution continues down to where it should go in the logic of the file. > >--- >The problem with trying to append the Post arguments to the redirect is >that your HTTP >header you assign in Witango is a Response header. Post arguments are only >valid in a >Request header. > >The best you could do is append your post arguments as search arguments to >the "Location" >address of the header. > >The success of such a thing is highly dependent on how big your post >argument values are. >There are limitations to how long a string of search arguments can be. And >that limit is >factored by brand of browser and webserver. > >Hope this helps. Cheers..... > >> 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 >________________________________________________________________________ >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
