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 On Fri, 16 Apr 2021 at 06:32, Shai Berger <s...@platonix.com> wrote: > 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. > > -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/20210415213200.72371c9f.shai%40platonix.com > . > -- -- ====================== Daryl Egarr, Director Kawhai Consultants Ltd Cell 021 521 353 da...@kawhai.net ====================== -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALzH9qvXE%2BoK3%2BM8uxNiJ4Sij4_yHT_aWvQhReAmZNSZjBd_GA%40mail.gmail.com.
