Transitioning existing login portal to Django

[Evan Palmer]

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.

-EP

[Alan Hicks]

Hi,

I treat them as a straightforward migration (not Django's btw). Create the models and functionality to replicate existing then write sql if necessary to convert to the new schema.  Depending on the complexity, the migration should not try to change much until it's in a (Django) form you are comfortable with, as the Django framework handles changes well.

There are all sorts of errors that could surface, by keeping the data/functionality as close to the original you minimise any impact.  By scripting everything, it's easy to test and repeat until it goes live.

Usernames and passwords are just fields in a database so I would either replicate the credentials to Django's if possible or create a User model that replicates existing followed by a transition phase to Django if required.

Django's great for running different templates (I use Django's and Jinja2's) so you could use the existing ones until you have translated them into your preferred format.

Regards,
Alan

--
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...@googlegroups.com.
To post to this group, send email to django...@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/5fc8e870-68ef-4012-91e5-2467c7d0394f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Persistent Objects Ltd
128 Lilleshall Road
London SM4 6DR

Lifting brand value by using all means at my disposal
including technological, motivational and best practice.

Proud sponsor of TEDx Wandsworth 2015

Registered in England and Wales 03538717

+44/0 79 3030 5004
+44/0 20 8544 5292
http://p-o.co.uk
https://plus.google.com/+AlanHicksLondon

[Tom Evans]

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