On Sun, January 20, 2008 5:30 pm, jekillen wrote: > I am developing an application that uses php with Apache. > A user requests a script file from a web site and the server > takes such things as $_SERVER['REMOTE_ADDRESS'] You *DO* understand that large-scale ISP's users will change their IP address more often than most drummers change their underwear? For example, an AOL user could have dozens of IP addresses within a single login AOL session. Further, large corporations could have hundreds, nay thousands, of visitors behind a single firewall. For example, *EVERY* visitor to your site who works at IBM will appear (to you) to have the same IP address. So you CANNOT make any assumptions about users and $_SERVER['REMOTE_ADDRESS'] > and uses php's time() function to record the time in utc > code (which would be the server's system time) > and other bits of info and saves it in a php script file on > the server. That's fine, if you want to use it as a "guess" as to whether this is or isn't the same person and force them to re-authenticate to "too much" changes. But it's not going to work if you assume that any change at all means a different user. > The script is a login script. When the user successfully > logs in. Javascript is used to send the client time and > time zone offset. These are written to this file also. You do understand that you are relying on the user's computer clock to be set correctly, which is frequently simply not the case... And any user can write some JS to send you whatever they want for the date/time/tz. > To > track the user for statistical and authorization reasons > this file is used to authenticate each user request and > track usage. Don't do that; It won't work. Use the built-in sessions and require a login/password to authenticate. > What I do not understand perfectly at the moment, > and I have to learn somewhere sometime, is the > figures that are recorded. Well, you made them up... You should have a pretty good idea what they are. :-) > I know, I could use php's built in session handling but > I have special reasons for doing it this way. I suspect your special reasons aren't sufficiently well thought out... :-) > These are the values I am recording: (a sample php script file) > > $sid = '96f120f9dcf293e64e6dcbd16024491e'; // this is a session id > $da = '1200867964'; // this > is > the value generated by the time() function Number of seconds from midnight GMT JAN 1, 1970, the birth of disco. :-) > $hid = '2c9a46c1a5d89469481951065cc6a621';// another session id You should only have one, really... > $ctzo = '480'; // > This is time zone offset according to what javascript sends No idea, really, what this is... Number of minutes past/before GMT, I suppose, since some time-zones are offset not by an even number of hours, but by so many hours and 15 minutes. It's not my fault. > $ctzn = '1200868142247'; // This is > the client time according to javascript, which is supposed > > // to be in milliseconds I doubt that it is in milliseconds... But it would have to be milliseconds from a known start date to be useful. > The specific questions are > what does the offset '480' mean? (add or subtract from utc/GMT to get > local time?) > I am in Pacific Standard Time testing this script. The server is also > at the same location. But what time zone is the server set to? You could put a server in China and set its time zone to US/Chicago, if you wanted... > The javascript time value should be the original request time plus the > time it takes > for a successful login to be processed: This is extremely doubtful. For starters, depending on whether you do it onLoad or somewhere else, it could include the page rendering or not. And it's relying on the user's clock being set right, which is often not the case. > The user types in the info and clicks the form button > the client pre submission script is run > then the server receives and processes > $_POST values and decides if the user has sent a valid id. Ok. > Javascript time value is specified as milliseconds. > millisecond is 1/1000 of a second, right? > and dividing the value by 1000 would give seconds elapsed > from Jan 1 1970(?) Yes, but it's probably not in milliseconds from 1/1/1970... I suppose it might be, except that even if it's in seconds, we run out of time in March 2038... I'm unwilling to do the math to find out if milliseconds *COULD* be from 1/1/1970 and still be valid or when it would run out, but you can work it out if you want to. > thank you in advance; -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
