Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL to 'auth.EmailUser', and done".
It'd be nice if 'swappable' could accomplish this for us. Something along the lines of for any set of swappable models which are swappable for the same settings value, only load the one that is named by the settings value. I am taking some time to read the source surrounding this setting and model loading to even figure out if this is a possible modification. Russel, curious about your thoughts on if this approach would be something you would sign off on. This seems like a good compromise over adding infrastructure for not installing certain models. This would instead create infrastructure to declare a certain 'type' of model must be present, but that you may decide which one based on a settings value. This approach feels cleaner to me because we don't want to 'turn off' a model, but rather only load a single 'User' model from some set of 'User' models. In the case of 'User', we need at least one 'User' model to be loaded, and this enforces that, where as the ability to turn off certain models could introduce situations in which someone turns off a model without replacing it. Aaron Merriam On Wednesday, September 18, 2013 1:39:16 PM UTC-6, Luke Sneeringer wrote: > > I added the authtools approach to the wiki for completion, although I > believe it to be an inferior approach. > > One thing I dislike is having a separate app (e.g. d.c.auth_email) that > has to be installed separately. That feels pretty impure to me. I'm doing a > thought exercise about potential solutions, though, and not exactly coming > up aces. > > The best solution I can currently think of is to have User and EmailUser > which are both models that live in django.contrib.auth. Then, we would have > to add code to our model detection that says that *if* a model is a > subclass of AbstractBaseUser, include it if and only if it is the > AUTH_USER_MODEL. > > I can't decide if that solution is better or worse than the disease. It > makes for a much more attractive set of steps to follow for people who want > to use it, though -- basically, just set AUTH_USER_MODEL to > 'auth.EmailUser', and done. > > Thoughts? > > Best Regards, > Luke Sneeringer > > On September 18, 2013 at 7:17:53 AM, Timothy Anderegg ( > timothy....@gmail.com <javascript:>) wrote: > > Hi all - I updated Russ's new wiki page to include the work I've done so > far: https://code.djangoproject.com/wiki/ContribEmailAuth Again, the > patch I've been working on is here: > https://github.com/tanderegg/django/tree/ticket_20824_master Please let > me know if you have any feedback. > > The only real other option (that I can see) would be to do something more > extensive like django-authtools ( > https://django-authtools.readthedocs.org/en/latest/). I can write up a > description of this approach as well if that would be useful, although I > did write up a description of the difference between my code and the two > other existing django apps in a post earlier in this thread. > > Thanks, > > Tim > > > On Wed, Sep 18, 2013 at 1:42 AM, Russell Keith-Magee < > rus...@keith-magee.com <javascript:>> wrote: > >> >> On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer >> <lu...@sneeringer.com<javascript:> >> > wrote: >> >>> Russell, >>> I would *love* to do the work for the email-login analogue you >>> describe. I actually proposed just such a thing a few months ago but was >>> rebuffed. >>> >> >> I'm sorry to hear this. Out of interest, did a member of the core team >> actually say "no", or was it just a matter of proposing something and not >> getting traction? >> >> If it was the latter, it's important to remember that the core team are >> all volunteers, and sometimes the spare time of the core team doesn't >> necessarily match up with the spare time of volunteers in the wider >> community. As a result, well intentioned and desired work sometimes gets >> ignored. It's not (necessarily) being ignored because it was bad -- often >> it's just "we don't have enough cycles *right now*. >> >> >>> However, I think this would be extremely useful. Also, I am, in fact, >>> looking to get involved with Django development, as I haven't quite >>> navigated the hurdles successfully. >>> >>> I do have one request, though. Is there a core developer that would be >>> willing to "mentor" my work on this, so I can make sure I am writing >>> something worthy of acceptance? >>> >> >> Well, I'm willing to mentor the effort. >> >> Like I've indicated, the first step isn't to write code at all - it's to >> get a good summary of the state of play of existing implementations. >> Multiple people have already taken a swing at an implementation; before we >> commit to one particular codebase, we need to understand what has already >> been offered by the community. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Django developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/django-developers/rb7v9kVAK3I/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to >> django-d...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/django-developers. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-develop...@googlegroups.com <javascript:>. > To post to this group, send email to django-d...@googlegroups.com<javascript:> > . > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
