Re: [PHP-DB] Index on email or ID?
Something I used was this: id | username | password | cookie_string $foo = the id was rot13'ed then base64-encoded $str = the cookie_string was an md5 hash generated at the time of registration then a cookie was set: setcookie(cookie_string,$foo.|.$str); When the user returns, we checked for the cookie, and if it existed, split on the |, de-crypted (haha) the ID, looked up the cookie_string in the DB and saw if it matched. If it did, it was pretty unlikely that it was hacked so we logged them in. Peter On Wed, 4 Dec 2002, Jim wrote: Always, always, always use a value that has no other significance other than being a unique ID. Email addresses change and so do passwords, so those are poor choices for linking data. They are fine and good choices for login, but that's about the only thing they should be used for. I understand what your saying, but if I just use the ID, then it makes it extremely easy to login as another user, simply change the ID in your cookie. Atleast if I have email/password aswell it takes someone with access to the network and a sniffer to get the values. If a user changes his email and/or password, then the cookie gets updated, simple. I can't see that its that much of an issue. If we were talking about a credit card number or something else critical then I'd agree. Jim. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Index on email or ID?
the id is definitely better. although creating an index on the email and potentially the password would help. I had a table that was indexed off of a random unique string and when i got to about 5+ rows updates were taking about 4 seconds. you can authenticate with the email and password, but then i would run all updates based on the ID, and if you need to be sure of authentication, store them in session variables and use them when you need them. if you want to keep it the way you have it, i'd just add indexes on those fields. i'm sure there are better ways but, . hth jeff Jim [EMAIL PROTECTED] To: [EMAIL PROTECTED] om cc: Subject: [PHP-DB] Index on email or ID? 12/04/2002 09:23 AM Hi, My website requires subscribed users to login with their email and password, the email is guaranteed to be unique, so this is one key, the other is the AUTO_INCREMENT ID assigned at registration time. In the cookie that I drop at logon time is the email/password combination (security isn't really a major issue)so I can then use the email as the unique key into the user table. Of course, I could also drop the AUTO_INCREMENT ID at logon time aswell, so instead of having: WHERE email = '[EMAIL PROTECTED]' AND password = 'userpass' I would use: WHERE id = 19 AND email = '[EMAIL PROTECTED]' AND password = 'userpass' Question is, is the index performance on a INT column much greater than that of a VARCHAR column? My guess would be yes. Also, if your thinking about saying well if ya got the ID, why bother with email and password, well I don't want to make it THAT easy to logon as another user. Just want to gather some opinions. Thanks, Jim. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Index on email or ID?
Always, always, always use a value that has no other significance other than being a unique ID. Email addresses change and so do passwords, so those are poor choices for linking data. They are fine and good choices for login, but that's about the only thing they should be used for. I've seen systems where the social security number was used as the unique ID. Sure it won't change, but it's also private information. Then there is the problem of human error on data entry. On Wednesday, December 4, 2002, at 09:23 AM, Jim wrote: My website requires subscribed users to login with their email and password, the email is guaranteed to be unique, so this is one key, the other is the AUTO_INCREMENT ID assigned at registration time. -- Brent Baisley Systems Architect Landover Associates, Inc. Search Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Index on email or ID?
Always, always, always use a value that has no other significance other than being a unique ID. Email addresses change and so do passwords, so those are poor choices for linking data. They are fine and good choices for login, but that's about the only thing they should be used for. I understand what your saying, but if I just use the ID, then it makes it extremely easy to login as another user, simply change the ID in your cookie. Atleast if I have email/password aswell it takes someone with access to the network and a sniffer to get the values. If a user changes his email and/or password, then the cookie gets updated, simple. I can't see that its that much of an issue. If we were talking about a credit card number or something else critical then I'd agree. Jim. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
