Scott, I don't mind keeping this in the public light, it's good for all.
First note: domains.ini isn't a possible solution as I need to handle this affect across all my sites (hundreds). Second of all, you are partially correct... When a new user arrives at a site (and we can consider a user who is attempting to use a USR that has timed out as new) the USR is calculated as the MD5 hash of several bits of information. In my case, it's the Server IP and Port, the result from <@DOMAIN> result from <@CURRENTTIMESTAMP> and I think perhaps a random number. Phil can explain that in detail. The point is that the domain is considered in the creation of a USR. However, once a USR is created (and used, vars assigned, passed back to user, etc.) an incoming request does a simple match on the USR to determine if it's valid (in memory) and loads the USR vars for that request. Since the USR is a MD5 hash, it is inherently one-way, and therefore the DOMAIN at which it belongs can not be determined. Nor is the associated domain saved in the USR space. I should further explain that the first 12 characters of a multi-server setup is the server IP and port is stored as a hex value. This is read back out by the load-balancer to determine which server to send the request. The rest of the USR is an MD5 hash. Therefore, as long as the proper server gets a USR which is still memory-resident, the DOMAIN at which is arrives is irrelevant. This MUST work because many sites tend to log someone in at www.site.com, but might want to move the user to secure.site.com to check out their shopping cart. Granted domains.ini can help in this manner, but it's not and shouldn't be necessary. My only question is that in the past I've relied on the USR in the search arg as being the first checked (or most likely used from what Phil explained). Now it seems that the cookie has precedence. This is a slight problem for me as it's much easier for me to control the content of the USR in search args than the content of the USR in a cookie (especially if changing DOMAIN because I'm not currently executing code at the new domain therefore can't purge the old USR from the user's cookie. "Is this a bug?" is big question. It's true that a developer might be in the habit of <@ASSIGN user$login_ok 1> for all of his sites. If true then two sites on the same server could allow a user to login to one and be logged into both. Granted the user would need to do some footwork, but it's possible. I'm in the habit of always making my user vars unique with a prefix, ie. <@ASSING user$siteprefix_login_ok 1> Therefore there can't be a run-over even if the user switches domains. Let's see what Phil has to say on the matter. Robert Shubert Tronics -----Original Message----- From: Scott Cadillac [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 4:44 PM To: [EMAIL PROTECTED] Subject: RE: Witango-Talk: Loss of Session State Issues. Good questions Robert, I'm also interested in Phil's run down on this behavior, because it is also related to the Session Hijacking issue. In the meantime I'll give you my interpretation of what I understand, based on what I think you are describing. In one of my previous posts I said "One Witango session-cookie per Window instance", but I should have expanded on that. It should say: "One Witango session-cookie per Window instance, per Domain". Session-cookies, UserReference keys and User Variables are specific to a single Domain address - regardless if they are the same Server or not. Or at least that's the way they should be. If I understand you correctly, you're trying to re-use an existing set of User Variables from one Domain in another Domain on the same Server. Are you saying you have a page link or FORM posting from one site to another, something like: ~~~~~ TAF on www.siteB.com ~~~~ <a href="http://www.siteA.com/some.taf?<@USERREFERENCEARGUMENT>">Jump to siteA</a> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The UserReference value from www.siteB.com should be invalidated for www.siteA.com - if previous versions of Witango/Tango was allowing this, then I think Phil just fixed a major bug. (Another reason I'm glad I don't use <@USERREFERENCEARGUMENT>) If you need to share Variables across domains, then I would investigate the domain.ini file or look at Custom Scope. If all you're doing is trying to preserve your UserReference key for when you come back to www.siteB.com - then this is not how to do it. Either the "Back" action of your browser will return you to a URL with the appropriate <@USERREFERENCEARGUMENT>, or the Session-cookie will send the appropriate key automatically. Session-cookies are Domain specific. The browser handles the fact that all page requests to www.siteA.com gets "KeyA" and all page requests to www.siteB.com gets "KeyB" - no coding involved here. --- Maybe I'm totally misunderstanding what you're doing. If I am, please forgive me. I know you want Phil to answer, but you posted the question publicly - so I responded :-) Hope this helps. Cheers.... > -----Original Message----- > From: Robert Shubert [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 2:56 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Loss of Session State Issues. > > > Phil, > > Could you verify the server's response in this situation: > > Step 1. visit website A (get USR assigned in cookie) > Step 2. visit website B (get another USR assigned in cookie) > > Note that both sites are on the same W5 server. Both sites also use > <@USERREFERENCEARGUMENT> > > Step 3. wait an appropriate amount of time, so that your USR on site A > has timed out and cleared, but you are still active on site B. > > Step 4. Jump from site B to site A with > <@USERREFERENCEARGUMENT> to keep > your user variables. > > > Now I think that the W5 server will get an invalid USR from > the cookie, > but a valid USR in the search args. What will the server do? > In my case, > I need the server to realize that there is a valid USR in the search > args, and use it, rather that creating a new USR based on the > fact that > the USR from the cookie has timed out. > > I am seeing a small change in how my servers handle some > functions from > pre 058, since I also understood T2K to prefer USR in > POST/SEARCH/COOKIE > order. > > Thanks, > > Robert > Tronics > > -----Original Message----- > From: Phil Wade [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 1:43 AM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Loss of Session State Issues. > > I should note here that post args were not searched in T2K or > Witango 5 > prior to the 058 build when the server was trying to locate the user > reference so the T2K server would only look in the cookies and > searchargs. > > The 5.0.1.058 server and above looks for a user reference in the > following > order: > > 1. user reference cookie > 2. user reference search arg > 3. user reference post arg > > Once a user reference is found, the server will no longer continue to > search > for a user reference in the remaining contexts so now the server will > use > the first user reference found and not the last. > > Search arguments can only be up to 255 chars long so if the server > receives > concatenated search arg data from the Browser it just uses > it. For this > reason if you are not using user reference cookies and are relying on > the > user reference search arg it is important to put the user reference at > the > beginning of the search args, not at the end. > > These changes should not have any affect on existing code, except to > make > the delete of the search builders work with browsers that have cookies > disabled (see code below). The delete action passed the user > reference > via > a postarg and always created a new user session in this > instance. This > was > not a big issue as the search builder did not rely on any > user variables > until it was extended by a user. > > Phil > > On 20/8/03 2:31 PM, "Robert Garcia" <[EMAIL PROTECTED]> wrote: > > > The interesting thing about this, is I have a bunch of simple web > admin > > apps with the witango default code, and I haven't had the problem > > before. I think it started around v058 or so. > > > > If I use this code: > > > > <form method=post action="<@appfile>" name=deleteMe> > > <input type=hidden name="_userreference" value="<@userreference>"> > > <input type=hidden name="CommonlabSchedule_uid1" value="<@COLUMN > > "Common.epxLessonSched.rowid">"> > > <input type=hidden name="_function" value="delete"> > > <INPUT TYPE=SUBMIT VALUE="Delete Record"> > > </form> > > > > It seems to work reliably, So I will have to make a lot of minor > > changes. > > > > Robert. > > > > On Tuesday, August 19, 2003, at 08:50 PM, Scott Cadillac wrote: > > > >> Hi Robert, > >> > >> When METHOD=GET is used in an HTML form, like in your > first example, > >> all the > >> FORM element names and values (such as your hidden fields) are > >> automatically > >> concatenated to the value of the ACTION attribute. This > then appears > >> in the > >> address bar of your browser. > >> > >> BUT....if the ACTION attribute already contains other search > arguments > >> (such > >> as <@USERREFERENCEARGUMENT>), then they are sometimes > replaced by the > >> concatenated FORM elements. This is a classic > pain-in-the-*** issue. > >> > >> Your <@USERREFERENCEARGUMENT> is being removed which can > cause you to > >> loose > >> Session state. In the first FORM example, just replace METHOD=GET > with > >> METHOD=POST and it should work. > >> > >> But of course, that doesn't explain your second or third > example, or > >> why > >> your Session-cookie didn't pickup the slack. > >> > >> Are Session-cookies disabled deliberately in your browser? If so, > then > >> checking things like <@USERREFERENCEARGUMENT> for all your > links will > >> be > >> necessary. This includes the TAF files before your actual delete > >> request. > >> > >> Also, checking the value of your USERKEY setting in > witango.ini could > >> be > >> important too. > >> > >> If Session-cookies are supposed to be working, then > something strange > >> is > >> certainly happening. > >> > >> Have you tried seeing what's being passed back and forth > with an HTTP > >> Sniffer of some kind? This will show you exactly the > values are being > >> sent > >> to the Server (both session-cookies and GET and POST arguments). I > >> recommend > >> www.httpsniffer.com > >> > >> Hope this helps. Cheers.... > >> > >> Scott Cadillac, > >> Witango.org - http://witango.org > >> 403-281-6090 - [EMAIL PROTECTED] > >> -- > >> Information for the Witango Developer Community > >> --------------------- > >> > >> XML-Extranet - http://xml-extra.net > >> 403-281-6090 - [EMAIL PROTECTED] > >> -- > >> Well-formed Development (for hire) > >> --------------------- > >> > >> -----Original Message----- > >> From: Robert Garcia [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, August 19, 2003 9:23 PM > >> To: [EMAIL PROTECTED] > >> Subject: Witango-Talk: Loss of Session State Issues. > >> > >> > >> I have been having some problems for a while with some admin pages > that > >> require a login, so session state is paramount. > >> > >> If I use the standard code Witango uses for deleting a record, most > of > >> the > >> time, state is lost: > >> > >> <FORM METHOD=GET ACTION="<@APPFILE>?<@userreferenceargument>"> > >> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" VALUE="<@COLUMN > >> "Common.epxLessonSched.rowid">"> > >> <INPUT TYPE=SUBMIT VALUE="Delete"> > >> </FORM> > >> > >> I have also tried these variations: > >> > >> <FORM METHOD=GET ACTION="<@APPFILE>"> > >> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" VALUE="<@COLUMN > >> "Common.epxLessonSched.rowid">"> > >> <INPUT TYPE=HIDDEN NAME="_userReference" VALUE="<@UserReference>"> > >> <INPUT TYPE=SUBMIT VALUE="Delete"> > >> </FORM> > >> > >> <FORM METHOD=POST ACTION="<@APPFILE>"> > >> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" VALUE="<@COLUMN > >> "Common.epxLessonSched.rowid">"> > >> <INPUT TYPE=HIDDEN NAME="_userReference" VALUE="<@UserReference>"> > >> <INPUT TYPE=SUBMIT VALUE="Delete"> > >> </FORM> > >> > >> > >> However, if I use this code, I never lose state: > >> > >> <p><a > href="<@appfile>?_function=delete&CommonlabSchedule_uid1=<@COLUMN > >> > "Common.epxLessonSched.rowid">&<@userreferenceargument>">Delete this > >> Record</p> > >> > >> Anyone else having these issues, or have any ideas? > >> > >> -- > >> > >> Robert Garcia > >> President - BigHead Technology > >> CTO - eventpix.com > >> 2781 N Carlmont Pl > >> Simi Valley, Ca 93065 > >> ph: 805.522.8577 - cell: 805.501.1390 > >> [EMAIL PROTECTED] - [EMAIL PROTECTED] > >> http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/ > >> > >> > ______________________________________________________________ > _________ > >> _ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >> > >> > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
