Re: Transitioning existing login portal to Django

On Tue, Dec 1, 2015 at 10:15 PM, Evan Palmer <evjpalmer@gmail.com> wrote:
> Hello,
>
> Does anyone have experience with transitioning an existing database
> including user login data to Django?
>
> I am about to begin work on a startup's hand-written web portal that
> consists of about 2000 lines of custom Python code (hashing passwords,
> managing user accounts, DB connections, etc.), some Mako templates, and a
> Postgresql database. A hand-written web framework makes me nervous for many
> reasons. I don't have access to the source code or the database yet, but my
> plan is to transition it to Django 1.8. I'd like to use inspectdb to help
> generate the models, but I doubt inspectdb will be smart enough to handle
> usernames and password hashes properly. How can I make sure this data gets
> transferred correctly?
>
> I'm looking for ideas about how to proceed and/or what to expect during the
> transition. Thanks.

inspectdb will do a pretty decent stab of things, although there is
always some rewriting necessary in order to give the model attributes
appropriate names (they don't have to match the table column name,
that is what the db_column attribute is for).
Django does not support composite primary keys; where this will
particularly bite is on M2M "through" or "link" tables; 3NF/BCNF would
have those tables with (foreign_key_to_table_a,
foreign_key_to_table_b) as the primary key, where as django will want
a separate "id" column as a primary key.

For passwords, Django provides a password hashing framework:

https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#how-django-stores-passwords

This allows you to define your own custom password hashing algorithm
to accommodate the existing passwords. Ideally, you will update the
stored passwords to the same format
("<algorithm>$<iterations>$<salt>$<hash>"), defining your own custom
name for the algorithm.

Adding your new custom password hasher class to the end of
settings.PASSWORD_HASHERS will then allow users to authenticate, and
then on login or password change - basically, any time the system
verifies a plaintext password - the password hash will be updated to
the preferred hasher (settings.PASSWORD_HASHERS[0]).

If your current hashing algorithm is not secure, eg unsalted md5, then
after a certain amount of time (business decision), you should email
all users who have not got an up-to-date hash that in X weeks you will
reset their passwords and they will have to reset their password.

Cheers

Tom

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFHbX1Lbru1PHcOsFQq0KSkOYMFvhnofUj9Bdjkv%3DduJwvTqFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.