Re: combining cookies and user registration

Sounds like an okay idea. It might take some time and some work (and what website doesn't, right?), but you might have something going here. Now, the one thing that springs instantly into my mind is keeping track of data for non-registered users and registered users. Using a database, if you didn't want to have separate tables for registered and non-registered users, here's an idea I propose:

First, use a sessions table. The primary key would of course be a session ID (perhaps created with Digest::MD5 or some similar module). This table would also contain a 'user' field, saying who this session belongs to. The table also contains session-specific data (data that only has to last the duration of the session, if there is any).
Reserve a particular username pattern for non-registered users. This way, non-registered users can have the same sort of database entry as a registered user. Simply reserve names like 'anony_xxxxxx', where xxxxxx is a number. Set a blank password for these user's entries, so that a login isn't required. When a non-registered user comes along for the first time, create a new 'anony_xxxxxx' account and a new session, mapping that session id to that browser's cookie. Simply don't allow true logins to these special accounts. This might not make sense to you as I said it, it's hard to describe...
One problem I forsee here is users that may use multiple browsers on the same machine, or they might clear their cookies out once in a while. It would be frustrating to lose all your information because you decided to throw your cookies away.
I'm sorry to say this one (okay, only a little sorry): if somebody really wants to use your services and be capable of keeping information for a duration longer than the existence of a cookie, they will register on your site. May I even dare to say that if you lose people because you require them to register, then the people you lose weren't really into the site as much as you might have hoped. Besides, those people with these 'non-registered' accounts on their home computer probably won't be happy when they try to 'login' on a different computer, just to find out that they cannot access their previous session. :) I think it really depends on what content you provide on your site. For example, I cannot imagine perlmonks being a site with these 'temporary accounts'. What good would that do for a site like this? :)

If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, reply to this node or /msg me to tell me what is wrong with the post, so that I may update the node to the best of my ability. If you do not inform me as to why the post deserved a downvote, your vote does not have any significance and will be disregarded.

Comment on Re: combining cookies and user registration - strategies?

Replies are listed 'Best First'.
Re: Re: combining cookies and user registration - strategies? by Cabrion (Friar) on Feb 11, 2003 at 13:08 UTC
Ugh, please don't pack your data columns like "anon_xxxx". Use the DBMS. Create an anonymous column of type boolean. You really need to normalize this table heavily. See any good SQL intro on rationalization/normalization. Otherwise you are going to take a serious performance hit. Consider these two tables: Users ("anon_xxx" used in id) id, data vs. Users (boolean flag) id, anon, data In the first example, to retrieve a given username, your perl code has to retrieve EVERY row, split the id field on "-" and check for a match. In the other example you simply ask the database for the row(s) "where id = $userid and anon = false". The database will be much faster because it can use indexes to skip a great deal of the records and quickly zero in on the user id of your choice. Remeber, a good database (ala Postgres) will be written in C and is optimized for grinding through large amounts of data efficiently.	[reply]

Replies are listed 'Best First'.

Re: Re: combining cookies and user registration - strategies?
by Cabrion (Friar) on Feb 11, 2003 at 13:08 UTC

vs.

Users (boolean flag)
id, anon, data

In the first example, to retrieve a given username, your perl code has to retrieve EVERY row, split the id field on "-" and check for a match.

In the other example you simply ask the database for the row(s) "where id = $userid and anon = false". The database will be much faster because it can use indexes to skip a great deal of the records and quickly zero in on the user id of your choice. Remeber, a good database (ala Postgres) will be written in C and is optimized for grinding through large amounts of data efficiently.

[reply]