GSOC Proposal : A new AUTH library.

155 views
Skip to first unread message

NIKHIL MUDDAMSETTY

unread,
Apr 9, 2021, 9:12:22 AM4/9/21
to Django developers (Contributions to Django itself)
Hello,
I am Nikhil Muddamsetty and I want to add a new AUTH library with the following features.

1 > Custom user model to support phone-number or email or username or a combination of any of these three.

2 > Traditional Account signup and login 

3 > Email verification for traditional signup.

4 > 2-factor authentication using OTP sent to email.

4 > Oauth signup and login support (Google, Github & Twitter for now). 

5 > Authenticator app login support.

6 > Single user model for any kind of signup type (traditional or Oauth).

7 > Multiple social accounts linking to the same Django user instance.

please provide me feedback, if this will be a good proposal. Can this proposal be considered valid under the third category (Work on libraries that supplement or add new features to Django to ease development) and what features should be added (or removed)

Regrads
Nikhil Muddamsetty

Curtis Maloney

unread,
Apr 14, 2021, 9:26:16 PM4/14/21
to 'Mike Hansen' via Django developers (Contributions to Django itself)
Just throwing another idea into the pile whilst we're here.

For a long time I've felt we could more easily support a lot more use cases if we separated Authentication from Authorization.

The simplest path for this would be to separate credentials (username, password) from the User record.

This would mean then we normalise the idea of separating credentials, and having multiple sets for a single user; Each auth backend would know to check its own set, be it (username, password), or Twitter oauth token, or whatever.

--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

Shai Berger

unread,
Apr 15, 2021, 2:32:18 PM4/15/21
to django-d...@googlegroups.com
Hi Nikhil,

I am not calling the shots here, just a member of the community.
However, if you are suggesting this as a work on a 3rd-party library, I
think your suggestion should be either for something completely new, or
a significant improvement over existing 3rd-party libraries. Libraries
which support registration, OAuth, and 2FA, all exist -- in fact, more
than one for each of the above. I suggest that you research them a
little, and reformulate your suggestion to show how you'd make a
significant contribution beyond what they already offer.

Cheers,
Shai.

Daryl

unread,
Apr 15, 2021, 4:11:08 PM4/15/21
to django-d...@googlegroups.com
I'd add this to the direction Shai's comment is going (if i've interpreted Shai's commments correctly);

Some Django components (such as how static files are served) often change during the production life of a project; the way you auth users almost never changes, or if it does, it changes once. 
This leads to the conclusion that an auth library that provides more than one type of auth is counter productive - if your auth library provides auth mechanisms A, B, C and D, and D has a bug that needs fixing, all users who only use A B or C need to also upgrade your library (or at least need to review the changes to determine they actually *dont* need to upgrade). 
The gains from being able to switch from D to [A B or C] and still use the same library are almost non-existent. Even if switching doesn't require "pip install [alternative auth library], it *will* require a code review because of how different each auth mechanism is.
So even if you were to come up with a significantly better A, B, C or D library than the current options, your chances of getting it accepted into regular community use are much better if they are separate libraries.
This doesn't mean its not a worthwhile project or GSOC proposal, its just a fact of software design and planning.

D




--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.


--
-- 
======================
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell       021 521 353
da...@kawhai.net
======================
Reply all
Reply to author
Forward
0 new messages