Closed ndarville closed 12 years ago
django-twostepauth
has not been updated since its initial commit, so it is time to roll it back, before django-registration
is updated.
The relevant commits are 758c58bd91, 23c885b429, and 86a18f5b04dec.
Links:
urls.py
:
After three-and-a-half years,
django-registration
has been upgraded, involving a complete rewrite of the codebase. Instructions for migrating can be found here.Impetus
The main impetus to upgrade
django-registration
is that the current version,0.7
, uses SHA1 password-hashing, which has been deprecated by Django 1.4 and poses a security threat.The Problem
However,
django-twostepauth
has not been upgraded in light of the revision, so I assume that it will be incompatible withdjango-registration 0.8
.Ameliorations
A temporary fix would apply a newer password-hashing function to the deprecated, insecure SHA1-hashed passwords as some kind of post hook.
For now, better to look into whether
django-twostepauth
is in fact incompatible with the new version ofdjango-registration
.django-registration 0.8
upgrade guideMigration Instructions
python -Wall manage.py runserver
registration.urls
toregistration.backends.default.urls
django-registration 1.0
; in0.8
it raises aPendingDeprecationWarning
(which is ignored by default in Python), in 0.9 it will raiseDeprecationWarning
(which will begin printing warning messages on import) and in1.0
it will be removed entirely.profile_callback
argument of theregister()
view has been removed.activate()
view now issues a redirect upon successful activation; in the default backend this is to the URL pattern namedregistration_activation_complete
; in the default setup, this will redirect to a view which renders the templateregistration/activation_complete.html
, and so this template should be present when using the default backend and default configuration.save()
method which would create the new user account. This is no longer the case; creating the account is handled by the backend, and so any custom logic should be moved into a custom backend, or by connecting listeners to the [signals sent during the registration process]().RegistrationProfile
model:create_inactive_user()
method ofRegistrationManager
now has an additional required argument:site
.user_registered
signal is no longer sent bycreate_inactive_user()
, and theuser_activated
signal is no longer sent byactivate_user()
; these signals are now sent by the backend after these methods have been called. Note that these signals were added after the django-registration 0.7 release but before the refactoring which introduced the backend API, so only installations which were tracking the in-development codebase will have made use of them.create_inactive_user()
, and now exists as the methodsend_activation_email()
on instances ofRegistrationProfile
.Afterwards
Look into expansive password security measures: