Re: auth.User refactor: reboot
On Wed, Mar 21, 2012 at 1:48 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: I agree - that's why my original proposal was to make the LazyForeignKey > explicit -- that makes the adoption process opt in. Yes, this means that > apps need to be modified and advertised to be "1.5 > swappable-User-compliant". However, to my mind, that's a good thing, > because you have an explicit marker that the author of the app expects the > app to work with an User model, or that they've documented any specific > requirements that the app needs to see in a swappable User object. > I appreciate the appeal of explicitly stating LFKs, I'm just concerned about the timeframe. Let's say we work through the design issues and have working LFK code available for 1.4.1. Based on your past experience, how long do you think it would take for, say, the 50 most common django apps (with FKs to User) to adapt? An unstated constraint that guided my pluggable auth apps design was the desire to ship something that makes email authentication possible in 1.4.1. I'm solution-agnostic, though, and if you think we could have LFKs ready and a healthy cross-section of apps ported by the 1.4.1 release, then I'm fully behind that idea. But if it will take longer than a year or so, then I am more inclined to look for an alternative solution that gets us there faster. This is also an area where test suites can help -- if an app has any > special expectations for User, the app author can write tests that > specifically check those integration requirements. > Agreed: apps should trust (that the developer read the requirements), but verify (with tests). I'm not sure I see why using a pluggable auth app instead of an auth model > changes anything. A third party app still needs to have foreign keys to a > model that might not meet contractual expectations. It could define > ModelForms that have clean methods or widget overrides for fields that > don't exist, or define redundant fields. You could define a model subclass > that has fields that clash with the base class. AFAICT, the problems that > exist are with being swappable in general, not with the requirements of > User (or auth) itself. > That's entirely true. The motivation for making several components of django.contrib.auth pluggable was, again, to do something backwards compatible that allows for at least some basic modification of the User model on a time scale that approaches "soon". > It would be folly to assume that every app with a User dependency will > seamlessly adapt to any swappable User model. Duck typing is useful, but it > isn't magical -- at some point, the responsibility needs to fall with the > app developers to document the species of duck they need, and for project > developers to check that they duck they have is appropriate for the task. > I agree, and noted in the previous thread that the burden for ensuring that the new User model works with third-party apps falls on the author of that User model. I assume, perhaps naively, that pluggable auth apps would be used sparingly, by advanced users with specific requirements that can't be met with the existing User model. I assume also that most changes would be relatively minor: dropping the username field, or "fixing" the email field (where the developer gets to define what that means), but not, say, removing all of the authorization attributes required by the admin. > [2] — Inheriting from a "swappable" model (auth.User isn't a very > realistic example here) > > ... > > Granted, I don't see many real-world use cases for this, but I suppose > somebody might want to have a pluggable model *and* subclasses thereof. > > I'm not sure I see any use cases either -- and even if I could, I'm not > sure this would be solved elegantly. At least for the first iteration, I'd > be inlined to punt the issue, and just say swappable models can't be base > classes, and enforce that at a class instantiation level. > That's a reasonable stipulation, I think. To be clear on the ModelForm issue, though, is it correct to say that any LFK proposal must also provide LMFs (Lazy ModelForms)? Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.User refactor: reboot
On Tuesday, March 20, 2012 8:38:36 AM UTC-4, Tom Evans wrote: I'm not -1 on pluggable auth models, I just think it is orthogonal to > the real issue. A 'fix' which doesn't allow longer email addresses by > default in d.c.a is not a fix as far as I am concerned. > We could debate what it means to "fix" the User model, but I don't think that simply increasing the length of the email field is sufficient. It is necessary, but for email authentication, we also need the email field to be indexed, unique, and required, which are changes that some on this list have rejected—e.g., there are existing installations that permit duplicate email addresses. Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/PQ0TAXye_d0J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.User refactor: reboot
On Saturday, March 17, 2012 8:52:01 PM UTC-4, Russell Keith-Magee wrote:
The only way I can see around this problem is to come up with a way for
> ForeignKey(User) to transparently become an effective
> LazyForeignKey('auth.User').
>
I explored this a bit and found that, since the binding of
ForeignKey('auth.User') is already deferred, it would be straightforward to
defer binding of a model declared as "swappable", as you've suggested. My
concern—and the reason I opted to go the pluggable auth app route—was that
a deferred binding approach might also be needed in ModelForm[1] and model
inheritance[2]. Even then, we would still have apps that expect to be able
to use the User model they find at django.contrib.auth.models.User. I agree
that lazy foreign keys would be a welcome addition to Django, but it seems
to me we have some other problems to solve before they can replace
auth.User in a backwards compatible way.
Cheers,
Clay
[1] — A ModelForm bound to auth.User:
class MyForm(ModelForm):
...
class Meta:
model = User
It's not hard to replace the forms that ship with django.contrib.auth and
django.contrib.admin, but I'm thinking of third-party apps that may contain
ModelForms bound to User and that don't allow developers to supply their
own forms.
One approach to dealing with this: the Form metaclass machinery could
register a callback to finish configuring MyForm after the binding of User
is known.
[2] — Inheriting from a "swappable" model (auth.User isn't a very realistic
example here)
class MyModel(SwappableModel):
# What to do if SwappableModel is defined
through run-time configuration?
Here again, the Model metaclass machinery could register a callback to
finish configuring and registering MyModel after the binding of
SwappableModel is known.
Granted, I don't see many real-world use cases for this, but I suppose
somebody might want to have a pluggable model *and* subclasses thereof.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/qT7oxf70yrMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Thu, Mar 15, 2012 at 2:48 PM, Daniel Sokolowski < daniel.sokolow...@klinsight.com> wrote: > The issue here is that django auth is limited, and restrictive and needs > hacks to make it use emails as usernames, we can agree on that yes? I agree with this point. > We can also agree that contrib.auth2 with LFK is a complex undertaking far > into the future? I agree that LFK isn't a simple undertaking, and doesn't solve all the auth.User problems, anyway. > Can we also agree that the 30 character limitation on the username ought > to be increased? I don't agree that changing the length of the username field is the general solution to the problem of email authentication. First, there's the issue of backwards compatibility: as Carl pointed out, you can't just change the size of the field without requiring a schema migration in every existing django installation, and that's very painful. Second, there's the issue that if you're storing emails in your username field, you've got a redundant email field floating around. With pluggable auth apps, you could make a User model with a longer username field, if you decide that's the best solution for your app, and if you're comfortable with the schema migration. I might elect to use a different User model that foregoes the username field altogether. With pluggable auth apps, the choice is mine—and yours. :) Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Thu, Mar 15, 2012 at 5:53 AM, Danny Adair wrote: Hi Danny, > I'm sorry I don't know if I like that. I hope I understand correctly > what you're doing, and that my criticism is seen as constructive. > Thanks for reviewing the code and providing feedback. > This sells itself as "pluggable auth" but really only provides the > originally requested auth by email, and I don't see how it could go > from there, i.e. what else would be possible (in regards to auth). > Pulling username and email out of (Base)User and then bringing one or > both of them - and the logic of which to check - back in, is not > really a pluggable auth. > It's "pluggable" in the sense that you could write a User model with whatever fields, methods, and attributes best suits your application. You aren't required to extend BaseUser—I only added that abstract class because I figure that most deviations from the stock User won't be that drastic, and it's convenient to be able to inherit from a model that has most of what you need already. It's the mixing of profile and information relevant to authentication > (and authorization - is_staff?) that's another problem of the existing > User model, and this is where this approach allows for dangerous > developments. > My dissatisfaction with the stock User model has less to do with the the fact that it combines authentication credentials and profile information in a single model, and more to do with the fact that it's hard to work around the stock User model if it doesn't meet your needs. The stock User model is the simplest thing that could possibly work—and indeed it does work, for most projects—but it's also one of the few components of Django that isn't configurable or replaceable. I can provide a custom ModelBackend easily enough, and a custom AuthenticationForm, but I'm always stuck with the auth.User model. We could debate for a long time (in fact, we have—the ticket was opened five years ago) what constitutes a proper User model, but may never reach a conclusion. Some will want to separate authentication from identity from profile, others will want to keep it simple. It's not clear to me that there's a "correct" User model, just as there's not a "correct" blogging application. So, rather than offer specific improvements to the stock User model, I aim to provide a means for developers to use their own User model, should they need to do that. > What about first_name and last_name? Why can't a pluggable auth dump > those from the User model? And certainly an "auth" should get to have > a say about "password". > Certainly, you could write a pluggable User model without first_name and last_name fields. Some have requested a User model with a simple "name" field. You could do that. It may not work in the admin, unless you define a first_name property, but your User model should work with a great many applications. The same is true for the password field: write a User model without it, if you'd like. That should work almost everywhere, even in the admin, so long as you provide your own UserCreationForm and UserChangeForm, and your own backend that handles authentication another way. And then... there's not much left anymore in that (Base)User model, > right... (GSoC: "reducing the user table to little more than an > identifying primary key") > Just to be clear, the BaseUser that I've proposed is there for convenience. It is not required. We could pare down BaseUser even more, but I suppose there will always be some disagreement about what should be the minimum set of fields and methods on a User model. I avoid that debate by saying that BaseUser isn't required—inherit from it, or don't, it's your choice. Some developers may want a User object that is just a primary key. They may have factored authentication and identity out in a way that is much more flexible (and much more complex) than the stock User model. That should be possible—and with pluggable auth apps, it is. Ok email auth problem solved. But now there's a simple way of > providing any User model I like, so first thing I'm going to do is to > bring in what I think the User should look like i.e. use the "auth" to > define what really is a "profile". And so will lots of projects. "The > User model needs a username for this app to work". "The User model > needs a timezone for this app to work". etc. > I'd like to see a later, "proper" auth.user that can undo that chaos. I don't know that I would call that "chaos". For many applications, it makes sense to have a simple User model with some profile data. I might not want to incur the extra JOIN or SELECT required to fetch a separate UserProfile object. Maybe it makes sense to store some profile attributes (display name, for instance) with the authentication credentials. Maybe it doesn't make sense to store email address there—what if I have several email addresses?—or timezone—what if I travel? There isn't a one-size-fits-all solution, but I think we can at least gi
Re: authentication by email
On Sun, Mar 11, 2012 at 4:39 AM, Clay McClure wrote: What you are really saying is this: being pragmatic means that we >> prioritise *your* immediate need above the need to keep the code and the >> docs maintainable, and above the need to maintain compatibility with >> existing installations. > > Luke, I'm sorry for being gruff and impatient in my previous reply. I'm anxious to see this problem fixed, but I don't want to sacrifice maintainability or compatibility to do it. I hope that the community can make some progress on this issue before the next release cycle. I'm willing to devote the time to it, whether it be tweaking my patch or working on a different solution altogether. Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Improving docs for User.is_authenticated()
On Thursday, February 23, 2012 10:41:36 AM UTC-5, Tom Evans wrote:
I don't like this function that much.
>
I share that sentiment. When it becomes possible to refactor auth.User, I
hope we'll be able to first deprecate and then remove
User.is_authenticated() and User.is_anonymous(). In addition to the point
you raised (that these methods don't actually test that the user has in
fact authenticated), there is also the possible source of confusion
stemming from the fact that in template language we write:
{% if user.is_authenticated %}
but in Python we write:
if user.is_authenticated():
You could easily get used to writing it the first way if you do a lot of
template development, and then accidentally write it that way when you
switch back to Python:
if user.is_authenticated:
which will happily and quietly always evaluate to True.
Perhaps the presence of a user object on the request object ought to be
enough to indicate that a user has authenticated. If so, maybe
AnonymousUser could be retired.
Cheers,
Clay
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/oqia2g66GLQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Sun, Mar 11, 2012 at 12:09 PM, Jacob Kaplan-Moss wrote: > I've written such a pluggable User app. By default, the User model works > as before. But I've also provided a User model (and forms, admin, backends, > etc) implementation that removes the limitations of the User model noted > above and allows for email authentication. It's still a bit rough around > the edges, but it works, insofar that `manage.py createsuperuser` doesn't > ask for a username, `manage.py changepassword` takes an email address, and > I can login to the admin interface with my email address. > > Can you please post this code somewhere? I'd love to see it. > Sure, here's a fork of 1.4rc1 that allows for pluggable auth apps: https://github.com/claymation/django/tree/pluggable-auth-apps The patch is rather large, but represents mostly the movement of files, and some refactoring of components to allow for greater reuse. For instance, the User model (and the forms, decorators, backends, and middleware that depend on it) has moved from django.contrib.auth to a new app, django.contrib.auth.default. This new app represents the default pluggable auth app, as reflected by the default value of the AUTH_APP setting (in a manner similar to the COMMENTS_APP setting). Backwards compatibility is maintained by continuing to honor the existing import contract, e.g., `from django.contrib.auth.models import User`. User is defined at run-time to be either the default (django.contrib.auth.default.models.User), or a user-provided model, based on the value of AUTH_APP. With the exception of having to add the new django.contrib.auth.default app to INSTALLED_APPS, existing django installations should be unaffected by this change. New django projects can elect to use an entirely different pluggable auth app, by setting AUTH_APP and adding such app to INSTALLED_APPS. Any library or bespoke code that imports User from django.contrib.auth.models will get the new model. The burden of ensuring that third-party and bespoke code is compatible with the new User model will fall on the author of that model. In other words, if I export a User model with no username field, I shouldn't expect that model to work in tandem with a blogging app that requires a username field. To simplify the process of writing new pluggable auth apps, I've factored out some common functionality from django.contrib.auth.default and put it in django.contrib.auth.base. These base models are intended to be an aid to reuse, but are not required, and have no special properties. As an example of a pluggable auth app, here's one I wrote that allows for email authentication: https://github.com/claymation/django_email_auth The pluggable-auth-apps fork is barely two days old, so it's still rough around the edges, and I've almost certainly missed some things. I haven't written any new tests for it yet, but the existing suite passes—at least the tests that aren't skipped. I've installed all the requirements listed in the testing docs—including selenium—but I get: -- Ran 4639 tests in 438.865s OK (skipped=72, expected failures=2) If this approach looks like something we might want to move forward with, I'll start working on some tests and docs. Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Fri, Mar 9, 2012 at 10:36 AM, Luke Plant wrote:
What you are really saying is this: being pragmatic means that we
> prioritise *your* immediate need above the need to keep the code and the
> docs maintainable, and above the need to maintain compatibility with
> existing installations.
>
Of course not. Firstly, this is not *my* need; it's a feature that many
have requested. Take a survey of the web applications that you use on a
weekly basis. How many of them allow you to sign in with an email address?
Compared to that, how many required you to invent a username? Of those, I
would wager that a good many are Django apps.
Secondly, I'm advocating for a backwards-compatible solution that won't
break existing installations. That point keeps getting missed, as you and
others keep assuming that we need schema migrations for this change—we
don't. People who are happy with the existing user model can keep using it,
as-is. But people who aren't happy with it should be able to provide their
own.
> There are a million-and-one hacks we would add if we took that approach,
> and Django would have a million-and-one more bugs, or possibly much
> worse - if you add just 10 boolean switches like the one you suggested
> in an earlier email, you've got over 1000 combinations to test and
> debug.
I was giving an example of a pragmatic solution: sometimes an `if`
statement is better than a far-reaching architectural change. I don't
advocate boolean flags for solving the auth.User problem, I'm merely trying
to encourage a shift in thinking from lofty aspiration to humble
accomplishment.
> I believe that all the problems you have can be solved already:
>
> - you can write your own authentication backend to authenticate
> by email
>
True.
> - you can write your own login and account creation views
>
True.
> - you can even override admin views by inserting items into
> urls.py
>
True.
But these things aren't the problem. It's the auth.User model that poses
the challenge. If you haven't implemented email-based authentication in
your own apps, let me suggest that you try it before you tell me how easy
it is. At some point, you will run into these limitations posed by the User
model:
- The username field can't be used to store emails (it's too short and
restrictive). No problem, let's use the email field;
- But the username field is required. OK, we can just fill it with a
random string;
- The email field does not have a unique constraint. But we can do a
reasonably good job applying the constraint in python;
- The email field is not indexed. We don't want full table scans whenever
someone logs in, so let's write a custom (and possibly non-portable) SQL
migration to add an index.
All this, and the email field is still too short to hold all valid email
addresses. On top of that, we've littered our database and admin interface
with random strings for usernames, and littered our application with the
code to generate them.
Yes, these are all more-or-less hacky. And they have problems. For
> instance, what if you have two accounts with the same email address? (I
> have that in some of my Django projects, BTW). The current code allows
> it, so we can't change anything that would make it impossible, at either
> the DB level or the Python level. This is the kind of issue that means
> you can't just use the existing models.
>
Of course, which is why we need to allow developers to supply their own
User model, while maintaining backwards compatibility for those who are
happy with the built-in model.
A full and correct solution that didn't introduce dozens of new bugs is
> quite hard - and I'm talking about just the code required to fix this
> one feature for you, without doing anything more generally useful.
>
Again, it's not just for me. And, yes, I appreciate that it's not a trivial
problem. It's hard, but all the problems worth solving are.
That is why we're not going to put hacks like this in core - we would
> have to support these hacks for at least 3 versions if we did. We are
> interested in *removing* existing hacks from our code base, and this is
> vital if Django is going to see increases in features and functionality.
> We are not interested in adding more hacks.
>
I can appreciate the appeal of a pristine, hack-free code base, but I've
never seen one. Eventually reality always trumps grand design. If my
example of the `if` statement above has led you to believe that I'm
proposing a mindless hack, then I apologize. I'm proposing something
between a mindless hack and grand design. Something pragmatic.
Some examples from a quick Google groups search for "auth User":
>
> http://goo.gl/swTpr
Some hand waving ("It's deceptively difficult"), with no examples, and no
mention of #3011.
http://goo.gl/fFlKh
This is someone with mediocre design skills trying to get paid to hack on
Django over the summer, but failing to convince anyone that he has a clue
about how to solve this problem. Save for some h
Re: authentication by email
On Fri, Mar 9, 2012 at 3:23 AM, Danny Adair wrote: > It's the "required" of username that's the problem if you don't want a > username at all when authenticating against email. > It would have to be not required and check required fields in clean() > where the backend could be asked what's really required. > That's one problem. Another problem is that the default User.email field is not unique, is not required, is not indexed, and may be too short. And there's Mr. Schema Migration again... > Who's talking about a migration? I'm asking for something that will work for *new* installations; existing installations can continue authenticating against usernames for all I care :) Moreover, I'm thoroughly frustrated by the fact that developers *do* bring working solutions to the table (in the form of patches in trac), but the core developers won't integrate them, either because it's not the right time (usually right before a release), because the patch isn't general enough, or because the patch doesn't meet some absurdly high bar of quality. I understand that they have a commitment to backwards compatibility and that accepting a mediocre patch could mean maintaining it for life, but I like to think that—with a framework that purports to be "pragmatic"—there are pragmatic solutions to these problems—and not, "sorry, it's not perfect, it can't go in." The GSoC page ( https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user) is a frustrating read. It goes on and on about how hard the problem is and how wrong your solution is, but doesn't provide any detail as to why it's hard or why it's wrong. Ticket #3011 was rejected without much of a reason. HM asked for an explanation both in the ticket itself and on django-dev; no explanation was ever given. The GSoC page also mentions migrations: "How can we roll out a new/modified User model without requiring almost every Django application on the planet to undergo a complex database modification?" But again, why do existing databases have to change? We're talking about leaving User as-is, by default, but providing a mechanism to use a different model if the developer chooses. Clearly this is a decision the developer would not take lightly: you're not going to change from username authentication to email authentication without a bit of thought. Projects that are using username authentication will continue to use username authentication, but at least new projects that want/need email authentication will be able to do that without monkey patching models. The GSoC page also mentions Lazy Foreign Keys, but no explanation is given there or in the linked django-dev thread as to why LFKs are required to implement a pluggable User model. LFK may be the panacea of code cleanliness and virtual awesomeness, but those of us with deadlines just need to authenticate against email addresses, like, five years ago. Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
"Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design"—unless you want to do something seemingly simple like using email addresses for authentication, in which case you need to monkey patch models and forms to get everything working right, which is neither rapid nor clean. What began as an innocuous feature request five years ago is now a high-level, general purpose, abstract, seemingly insurmountable design problem. The core developers are still perfectionists, but they seem to have forgotten their deadlines. Is there not a simple, pragmatic solution (optional and for new installations—we're not talking about backwards compatibility here) that could be implemented until the panacea of pluggable User models gets figured out? Something as simple (albeit ugly) as wrapping new models and forms in: if settings.AUTH_EMAIL_AUTHENTICATION: Should these things really take five years? What happened to pragmatic? Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/KebjFDOOBF4J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
