Take the 2-minute tour ×

I currently have a news website setup in PHP/MYSQL that's a bit old and I'm in the process of migrating it to a new django site that uses Postgresql 8.4 and Psycopg2.

Django's admin models contain a auth_user table and I suspect this is the table I will need to insert all my user rows into.

Q#1: I should just rely on this already made table from when I syncdb with the admin, right?

It seems to be using sha1 encrypted passwords, the superadmin's password is 51 chars long and the password field is a VARCHAR(128).

Q#2: Do I have no choice but to force the user to create a new password from their stored email address? It's better to just keep the password column as is, since SHA1 is probably more secure than MD5 anyway.

Q#3: If I go about adding custom columns to this auth_user table for things such as aim_username, and other various user specific columns then would this messup the admin somehow? Would I need to override the default admin model somewhere?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

I'm not sure what you're asking with question 1.

For question 2, if you want to make the transition seamless to the user, what you could do is maintain a listing of the user's original passwords. When someone tries to login, you look up their e-mail in the original listing and check the md5 of the password they logged in with against the record you have in the database. If you have a match, remove the record from the original table and update the password record in the auth_user table by hashing the password you have from the form.

For question 3, Django allows you the ability to specify a user profile model that can contain any extra information you want. Have a look at: http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users.

share|improve this answer
My first question was kind of obvious but I just wanted to make sure - it's common for most people to just rely on the already-made table instead of create their own, right? –  meder Mar 7 '10 at 7:01
Ah, so what you're saying is that using the user profile model per #3 I just define the current md5 password column which will be temporary until the md5 matches then from then on use the regular password column.. –  meder Mar 7 '10 at 7:03
Yeah, using the built-in auth system (e.g. user_auth) is the normal path for most people. Yes, you maintain the original md5 password until the user logs in for the first time (so that you can verify and hash it to the new system). By doing this, the user is never aware that you've moved to a new password style. –  Adam Mar 7 '10 at 7:26
add comment

Your Answer


