Bit of a puzzle: how to associate data with a user once they register?

[ppc_michael]

Backstory: I'm writing a thing in PHP/PostgreSQL/XHTML for a website that's basically a mini Facebook. Specifically, it's to help alumni of a university student group reconnect with each other. So they can register there, and once they log in, they have a little profile where they can talk about what they're doing now, there's a "community wall" where they can write stuff, and they can upload old photos and things like that.

The problem: Well! There's also an "Events" feature I'm writing, which is what I'm having the problem with. We're having a reunion coming up and we'll be using the Events feature to display all the information and allow people to RSVP, just like how Facebook does.

To invite someone, you just specify the name and e-mail address, then they're sent an e-mail inviting them, with the link to the Event page where they can RSVP.

I'd like for anyone to be able to RSVP without having to be registered with the rest of the site, but if they do end up registering, I'd like that information to be linked to their account without them having to RVSP again when they're logged in, you know?

Any ideas how to do this? The one method I was toying with was, when they RSVP anonymously, save their e-mail address as a cookie, then if they ever go to register on the site, make their e-mail address "hard coded" so they can't change it, so the backend knows it's the same person and can consolidate the information. But that's bad for security reasons, especially if this occurs on a public computer. Also for "usability" because the e-mail address we invite them with may not be the one they prefer to use.

So as you can imagine this is a bit of a pickle. Any help would be greatly appreciated!

(I don't need code snippets, I'm looking more for "conceptual" advice, thanks! )

 

[ChrisA]

email address do make for good user IDs. But I think you have to just accept that emails and people are not one to one. People can have more then one address. Design your dbms so that you have a table with one row per email where you have the email and user ID in each row.

The security issue I asume is that it may not be nice to store emails in cookies because later some one might harvast these and spam your users. So, what you could store in the cookie is the MD5 hash of the email. Then in the above table you keep another column for the hashes

 

[ppc_michael]

Okay here's my scenario for how I think I'll work it, how does it sound?

* Inviting someone creates a blank account in the database with a user id, as well as name and e-mail provided by inviter

* When invitee follows e-mail link, the predetermined user id is stored in a cookie.

* When they RSVP, they are treated as the user with the uid just as a logged-in person, but they cannot log in or leave the event page.

* When they go to register, the script checks for a cookie with UID, and embeds that as a hidden form element.

* Registering is then inserted into existing uid info, and the cookie is deleted.