|
Re: Implementing Cookies
by mitd (Curate) on Nov 20, 2001 at 01:17 UTC
|
This is a pretty broad subject, so I suggest a little reading might help. Here is an old Lincoln Stein TPJ article to get you started. Note that although Lincoln uses mod_perl for implementation, the techniques he discribes can easily be applied other ways.
Once you have good understanding of technique checkout Apache::Session.
mitd-Made in the Dark
'Interactive! Paper tape is interactive!
If you don't believe me I can show
you my paper cut scars!'
Edited by footpad, ~Tue Nov 20 05:44:12 2001 UTC: Fixed broken HTML
| [reply] |
|
|
And despite the name, Apache::Session doesn't require that you be using the Apache web server!
Impossible Robot
| [reply] |
Re: Implementing Cookies
by tune (Curate) on Nov 20, 2001 at 01:15 UTC
|
I used to generate a session ID for my users, and store them in a database table. Also send this ID to the cookie.
And the database table can contain any type of information, with the ID, the client's IP address, the timestamp. In this way I can track if the session is expired, or still active, and e.g. show a list of active users, for the user community.
--
tune | [reply] |
Re: Implementing Cookies
by Nomis52 (Friar) on Nov 20, 2001 at 03:14 UTC
|
I wouldn't use IP addresses for tracking users ( or session ids based on them for that matter) as they can change between visits for returning users (for those of us on dial up accounts).
Apparently they even change between page requests for aol users due to proxys.Also with the use of proxys many users could be seen to originate from the 1 IP address.
I'd generate as session ID , fairly long and random , and store it as the key to a DB and in the cookie.
Then when the user visits lookup the key in the DB and get/set any info that you need to. | [reply] |
|
|
Yes, this is the way I solved a similar problem, I used
Apache::Session::Generate::MD5 to get random enough data,
but I guess "there's more then one way to do it".
Just keep in mind that Cookies have a limit of chars they
can hold in the value field which is AFAIK 255, so creating
too long random data might not be what you want.
| [reply] |
Re: Implementing Cookies
by cfreak (Chaplain) on Nov 20, 2001 at 01:16 UTC
|
As far as tracking them (disclaimer I've never actually used this before) I don't think you would need to compare people's individual cookies to any sort of data (logs, dbs etc) but as you stated you would probably want to use a DB for keep a log of people
Just for tracking you could set a date in the cookie to see when they last visited. You can use $ENV variables to get the page their on, their IP address and tons of other information.
| [reply] |
Re: Implementing Cookies
by JPaul (Hermit) on Nov 20, 2001 at 19:50 UTC
|
Given, whenever I do session handling, users have an account with the service - but;
I will take their service username and combine it with a random string (Normally the MD5 of my /etc/passwd, just as a little joke), from that I produce another MD5 checksum and store it in the cookie like so:
filmo:3d42e7ab7cd3f127cda36ed2512eb4c6
The MD5 checksum allows me to verify (in a relatively secure manner) that the username stored in the cookie is the one I assigned to that cookie in the first place.
I keep track of "users browsing" by keeping a DB table with a username and datestamp, and each time they hit any of the CGIs (the sites I deal with are generally entirely generated from perl CGIs anyway), I update the datestamp, thus keeping track of who's on and who's not. I run a cronjob every half-hour to remove idlers.
Someone has already mentioned that IPs aren't a particularly affective way of tracking user sessions. I would agree with this, multiple cache proxies are often implemented at large ISPs, and this will make your IP address often times rather redundant.
JP,
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off -- | [reply] |
|
|
Good idea with the MD5 checksum.Although the IP address can shift intra-session at the large ISPs, I was thinking that I could use cookies and IPs to track static pages as well. Thus for example, if someone comes to the main page, a cookie is set and the IP address and cookie are stored in a DB table. When the user jumps to another page, if the IP changes (ala AOL), the cookie remains the same and that IP is also recorded along with the cookie. Thus. I could write a log analysising program that would let me track how long a user spent on a particular page as well as the path they took since I would now have a way to link users across IPs. Obviously, it wouldn't work perfectly for all entries in the log, but probably well enough. Additionally, if the user is registered to a cookie and IP and then views a static .html page, I could still capture that path and time spent before moving off to the next request. This must be similar to how those large web analysising companies are able to aggregate data about how much time is spent on a particular page and the pathes that users took.
--
Filmo the Klown
| [reply] |
Re: Implementing Cookies
by fenonn (Chaplain) on Nov 20, 2001 at 20:53 UTC
|
You should definitely read merlyn's article on branding a browser with a cookie. Should be article 61 or so. You can find all his articles located here. | [reply] |
