Everybody is aware of that Python has a highly regarded Django framework. By default, the consumer mannequin there consists of an e mail, username, and password. However there are sometimes conditions the place it’s crucial to increase and substitute the default consumer mannequin.
For instance, there are conditions the place we don’t want a username, solely an e mail. Or we’d like a telephone quantity as a substitute of an e mail, and the e-mail isn’t vital. In some of these conditions, the default mannequin ought to be modified to a customized one which incorporates the related fields. So, the aim of the django-swap-user undertaking is to interchange an current mannequin with a customized one.
As well as, authorization by one-time code is now starting to realize recognition. So we accounted for this situation within the library as effectively. When a brand new consumer mannequin seems, it has just one discipline—e mail or telephone quantity—and a one-time passcode. There is no such thing as a password saved within the database, and a one-time passcode is shipped utilizing any supplier that you simply join. You get a one-time SMS, which you need to use to log in.
Why did we write a whole library for this? After we begin new initiatives, we frequently want a customized consumer mannequin. Beforehand, we copied every little thing from one undertaking to a different, however then we realized—why continually copy, when you possibly can write a library as soon as and that is it. We wished to discover a ready-made library, however all of the ready-made ones have been deserted or out-of-date. So our Python Teamlead, Artem Innokentiev, determined to write down this wrapper himself and open-source it.
So, in case you are bored with copying a customized consumer mannequin from one undertaking to different ones—use this bundle. It should do all of it for you!
pip set up django-swap-user
swap_user is cut up into a number of apps:
to_email– gives consumer with
e mailusername discipline
to_email_otp– gives consumer with
e mailusername discipline and OTP (One Time Password) authentication
to_phone– gives consumer with
to_phone_otp– gives consumer with
telephoneusername discipline and OTP (One Time Password) authentication
Why such an uncommon structure?
If we depart them in a single app, they are going to all create migrations and tables, resulting in redundant tables. They are going to be handled as three customized fashions inside the identical app, which causes confusion.
With this strategy (the place there’s a frequent app which incorporates inside apps), the consumer can select and join solely the precise consumer mannequin greatest suited to concrete enterprise logic.
We modeled this strategy after the Django REST Framework
authtoken utility, referenced right here.
Using a customized consumer mannequin in the beginning of a undertaking
If you end up beginning a undertaking from scratch, that is the perfect time to combine a customized consumer mannequin, because you haven’t had plenty of migrations or you possibly can simply regenerate them. Furthermore, Django’s official docs advocate that you simply use a customized consumer mannequin, even in case you are absolutely happy with the default one. Sooner or later, will probably be simpler to increase a customized mannequin to suit your use instances.
Incorporating a customized consumer mannequin in the midst of a undertaking
Including a customized consumer mannequin in the midst of a undertaking is a tougher approach of doing issues, however it’s nonetheless doable.
- Full all of the steps within the testing database and—ONLY IF all of them have been profitable—attempt to apply it within the manufacturing atmosphere
- Please be aware that these steps match most instances, however in some circumstances, you might have to adapt to the scenario
- Create a backup of your database
- Add steady tag into your repository or save a commit hash reference
- Pray 😀
- Take away your whole migrations in each app of the Django undertaking
- Take away all information from
django_migrationsdesk, for instance, with
SQL TRUNCATE django_migrations
- Now you may have a “clear” state, so you possibly can change the default mannequin
- Generate new migrations for your whole functions—
python handle.py makemigrations
- Now you must pretend migrate, as a result of you have already got all of the tables with information
- First, pretend the
authutility, since you are relying on this one:
python handle.py migrate --fake auth
- Set up the library, comply with the directions, and apply migrations
- Then, pretend the remainder of the migrations you may have—
python handle.py migrate --fake
- Run your utility!
Plans for the longer term
Sooner or later, we plan to write down higher documentation and add implementation to the undertaking. We are going to slowly add new authorization strategies, for instance, blended ones. There are instances the place you must do authorization both by e mail or by telephone, and we want to add this.
For the time being, everybody can use this undertaking, and we’d love to draw members of the neighborhood to contribute and assist with the event of the undertaking!
And, in fact, attain out to us by way of the shape under if you must develop an open-source answer or are in search of a group of pros to construct a undertaking from scratch!