Re: [WebDNA] User sessions - cookies only or cookies and a
This WebDNA talk-list message is from 2016
It keeps the original formatting.
numero = 113107
interpreted = N
texte = 695 Sorry, the last post got sent by mistake before I was finished. Here's the correct post: > To build the browserID, we are using all the information > returned in the mime headers, like > > Accept text/html,application/xhtml > xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language > en-US,en;q=0.5 Accept-Encoding gzip, ... > > Any difference, including a single dot or an extra space , > would create a different browserID Question #1: Does the BrowserID use any other data from the browser, such as the ip address for example, or anything else OTHER THAN the data in the mime headers? Problem #1: You said you're using ALL the info returned in the mime headers, but this appears to be a mistake, here's why: One portion of the data returned in mime headers is cookies, so if there are any cookie changes from one page to the next, the BrowserID won't match any longer. This is a real problem for me because I reset the cookie expire date in my admin systems every time another page is requested. This brings up: Question #2: Does the BrowserID perhaps IGNORE use some of the data returned in the mime headers, rather than using all of it? If so, this would eliminate the problem of cookies changing on every page and theoretically offer a more reliable 'guess' about whether or not the current browser is the same as a previous browser. But this does NOT explain why Tom's test concluded that all three BrowserIDs were identical when in fact he used three different browsers. So here's the next question: Question #3: What happens when a mismatch occurs with the BrowserID values? Does WebDNA default to matching something else, such as the ip address? If so, this explains why all three of Tom's 'from' fields are different but the 'to' fields are the same: My guess here is that when the second and third browserIDs did not match, WebDNA moved on to "Plan B" -- it tried instead to match the ip addresses. And since they match it wrote the second and third "from" field values to match the first "from" field value. Is this why WebDNA thinks that all three of Tom's browsers are one and the same? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Administration --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list
. To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Associated Messages, from the most recent to the oldest:
695 Sorry, the last post got sent by mistake before I was finished. Here's the correct post: > To build the browserID, we are using all the information > returned in the mime headers, like > > Accept text/html,application/xhtml > xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language > en-US,en;q=0.5 Accept-Encoding gzip, ... > > Any difference, including a single dot or an extra space , > would create a different browserID Question #1: Does the BrowserID use any other data from the browser, such as the ip address for example, or anything else OTHER THAN the data in the mime headers? Problem #1: You said you're using ALL the info returned in the mime headers, but this appears to be a mistake, here's why: One portion of the data returned in mime headers is cookies, so if there are any cookie changes from one page to the next, the BrowserID won't match any longer. This is a real problem for me because I reset the cookie expire date in my admin systems every time another page is requested. This brings up: Question #2: Does the BrowserID perhaps IGNORE use some of the data returned in the mime headers, rather than using all of it? If so, this would eliminate the problem of cookies changing on every page and theoretically offer a more reliable 'guess' about whether or not the current browser is the same as a previous browser. But this does NOT explain why Tom's test concluded that all three BrowserIDs were identical when in fact he used three different browsers. So here's the next question: Question #3: What happens when a mismatch occurs with the BrowserID values? Does WebDNA default to matching something else, such as the ip address? If so, this explains why all three of Tom's 'from' fields are different but the 'to' fields are the same: My guess here is that when the second and third browserIDs did not match, WebDNA moved on to "Plan B" -- it tried instead to match the ip addresses. And since they match it wrote the second and third "from" field values to match the first "from" field value. Is this why WebDNA thinks that all three of Tom's browsers are one and the same? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Administration --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Kenneth Grome
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
[WebDNA] Need to convert unix date? (2009)
WebCatalog for guestbook ? (1997)
Emailer to include Human Name with email Address (2000)
[sendmail] on NT? (1997)
Sorting error (1997)
RE: combining strings (1997)
problems with 2 tags shakur (1997)
Spreadsheet App pref. [OT] (2001)
format problem on NT? (1997)
suffix mapping, use of cache, etc. (1997)
[WriteFile] problems (1997)
all records returned. (1997)
Newbie question (1998)
stopping/restarting service on NT? (1998)
Snake Bites (1997)
Email/Order to fax? (2003)
[OT] Test - THE ANSWER _ The winner is .... (2003)
WebCat2b13MacPlugin - [math][date][/math] problem (1997)
2.0 Info (1997)
changing order number (1998)