Re: auth.User refactor: reboot
Hello, I wanted to support the idea of the pluggable User model, but Russell just sent an excellent argumentation, saving me the effort :) I agree very much with his proposal. Subclassing, or writing an API-compatible class (duck typing) is the canonical way to alter a built-in behavior in Python. Besides, I find project-wide "user profiles" impractical for most purposes. I prefer subclassing auth.User even if I just need a few extra fields, and add enough glue (middleware, auth backend, login and logout views) to hold the pieces together. So, what I always wanted is a configurable User model. This is the second most messy workaround in my current project (after datetime handling, which was the motivation behind my work on time zone support in 1.4), and I'm willing to work on improving the situation. As far as I can tell, app-refactor isn't very far from completion, and there's no opposition to the concept of LazyForeignKeys, only a simplistic implementation was rejected (the archives on this topic are sparse and sometimes confusing). Best regards, -- Aymeric. -- 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 Sat, Mar 17, 2012 at 20:38, Aymeric Augustin wrote: >[...] > Besides, I find project-wide "user profiles" impractical for most purposes. I > prefer subclassing auth.User even if I just need a few extra fields, and add > enough glue (middleware, auth backend, login and logout views) to hold the > pieces together. In my latest project there's a situation where neither is useful. We have a Person model (name, address, phone, FK company etc.), and that person may or may not (yet!) have a User account. Person gets a nullable FK from User and we have to listen to post_save() on both of them to synchronize first_name/last_name/email. Would be awesome if such a use case was covered. Cheers, Danny -- 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
Hi,
Eric Florenzano and I actually had a discussion about this at PyCon.
My company does Django development and simply doesn't use the Django
auth app because it tries to do authentication and authorization in
one app and the User models are just to inflexible. Many projects
didn't need or want usernames, email etc. and many required changing
the fields on the model. Using the get_profile() method in every view
and in every template was also a huge pain in the ass.
I have a concrete proposal and implementation that I wrote for our use
that solves a lot of the issues that have come up here. I have been
brushing up the api and documentation recently to release it but I'd
like to speed things up and release it publicly. The app is built on
some basic tenets in order of importance:
1. Django shouldn't decide what fields go on the user model. The app
provides an abstract base class which developers subclass to add the
appropriate fields they need.
2. Django shouldn't decide the type of the primary key. The app only
relies on the fact that the object has a pk. The id field can be named
anything you wish and can be any type (integer, char, uuid, etc.).
3. Third party apps don't rely on the user having any fields but
rather the base user class defines methods that are implemented by
subclasses. Methods like get_display_name() which provides a way for
third party apps to get something to display.
4. Rather than provide mixins or something, we should have conventions
for the field names like 'email' and third party apps should check if
the user has one using duck typing e.g. hasattr(user, 'email'). An
alternative could be to provide some kind of API for commonly used
actions like emailing users.
5. Basic username (or email)/password authentication can be provided.
The app has a base user class from which a basic abstract user with
username/password is defined. This can implement setting passwords
properly and provide forms etc.
6. Multiple user models can be defined (Like say for normal users and
affiliate users or admin users). If one wants to create a project
currently with a separate user model, none of the machinery in the
auth app can be used. With the above approach multiple user models can
be defined and used without any problems. It doesn't make much sense
to only allow one user model and only that model can use the auth API
and machinery. A default user model can be defined and imported via
the models module. Admin users can also be defined completely
separately from normal users.
You create users by creating your own app in your project and creating
a User there:
account/models.py
from django.db import models
from newauth.models import UserBase
class User(BaseUser):
full_name = models.CharField(u"Full Name", max_length=255)
email = models.EmailField('Email Address')
profile = models.TextField('Profile Bio', blank=True, null=True)
avatar = models.ImageField('Avatar', upload_to='profileimg/',
blank=True, null=True)
def get_display_name(self):
return self.full_name
class Meta:
db_table = 'my_user_table'
verbose_name = u"Djangonaut"
verbose_name_plural = u"Djangonaut"
There are even docs and tests.
Check the source out here: https://bitbucket.org/IanLewis/django-newauth/
See the docs here: http://ianlewis.bitbucket.org/django-newauth/
Having used this at my company for over a year, I can say it's
extremely nice and has worked well for us. I hope that the
implementation and docs can serve as a reference for any improvements
to Django auth.
Some other miscellaneous thoughts below:
On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
> 2. Complete improvement: recognize that the auth app is fundamentally flawed,
> and mercilessly refactor/replace/rewrite it, all in one go. The hypothetical
> results here would be better -- a modern auth system unencumbered by the
> decisions we made in 2005 -- but this would take far longer, and would block
> on things like the app refactor and schema migrations.
I'm in favor of this kind of solution personally but I think it will
really throw other projects for a loop. Especially projects like Pinax
which rely heavily on the auth.User models.
>> There's also a middle-ground proposal from Clay: make the auth app
>> swappable, thus making it possible for *users* to replace the auth app while
>> leaving time for us to make either incremental or complete change, as we see
>> fit.
I'm not really in favor of this for the reasons Jacob mentioned.
On Sat, Mar 17, 2012 at 2:59 PM, Russell Keith-Magee
wrote:
> * Add the concept of a LazyForeignKey.
>
> LazyForeignKey is a normal foreign key, with all the usual foreign key
> behaviors; the only difference is that the model it links to isn't specified
> in the model -- it's a configuration item drawn from an application
> configuration. So, ForeignKey('auth.User') creates a foreign key to
> django.contrib.auth.User; LazyForeignKey('auth.User') asks the
Tips required to run django tests configurazion for all databases
Hi, when I run the total django suite for all database there are times totally different, obvious sqllite is not possible compare with the others, oracle and postgresql have the similar performance during the tests, but mysql... there is some tricks to go faster the mysql suite test case? -- 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
суббота, 17 марта 2012 г. 0:15:39 UTC+6 пользователь dstufft написал: > > On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: > > Here's my hit list of perceived benefits: > 1. It regains the efficiency of a single table (which is minor, to be > sure, but since Jacob already brought it up...) > > This issue isn't as minor as one might think I don't believe. I've > recently started using the fetch_related thing (which would be the only way > to prevent N queries when trying to select a bunch of users + their > profiles) and on a table with 20k entries (this isn't User related) where > the entries are fairly large the processing time to fetch them all was very > significant. This effect would increase with Tom's per app profile issue. > If the Profile model has OneToOne relation to User (as suggested in django docs [1]) then prefetch_related is not necessary, select_related can be used to get all records using single JOIN query. And storing more data in a single table could reduce performance, not increase it, because this data will be fetched by default even if it is not necessary (+ database will have larger rows to search in) - this effect would increase if there are several user profiles :) Storing all data in a single table is database denormalization: sometimes it can be benifical but should not be default in my opinion. [1] https://docs.djangoproject.com/en/1.3/topics/auth/#storing-additional-information-about-users -- 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/-/1Bt6KG98h8wJ. 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.
list of function to django view
i learn django now, how i can To find a site or list with a function to django something like php.net to php or that: https://docs.djangoproject.com/en/dev/topics/http/shortcuts in that link have a function but i need more to do something i want https://docs.djangoproject.com/en/dev/topics/http/shortcuts -- 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: list of function to django view
Please ask questions about using Django on the django-users mailing list. The topic for this list is the development of Django itself. Karen -- 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.
GSOC 2012
Hello everyone, As some of you have already noticed, we've been accepted into GSOC 2012 and we're now starting to discuss ideas with students. The actual application period doesn't open until the 26th March, but we'd encourage you to start discussing applications on this mailing list before then so we can help you get them refined. Please try and put [GSOC] before any posts you make so we know what you're after, and so we can make sure to give you timely responses. Some key points to remember are: - We're looking for detailed proposals - we have an application template on the GSOC page at http://www.google-melange.com/gsoc/org/google/gsoc2012/django that details what you should be including. - While we'll happily look over a few drafts of your proposal (in fact, it's likely that you will have at least a couple), we won't put up with 10 or 20 revisions each with tiny changes. GSOC requires the ability to get things done by yourself, and it's best to start demonstrating that now. We'll also expect that you have previous experience working with Open Source projects or other related - The absolute deadline for proposals is 7pm UTC on April 6th, but by that point we'd expect that you've already discussed things with us. If you just submit an application without prior discussion with the django-developers list, it's not likely to get accepted. Our current ideas page is at https://code.djangoproject.com/wiki/SummerOfCode2012, but you're not limited to just the ideas on that page, so feel free to propose other ideas. Looking forward to seeing your applications! Andrew -- 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: Tips required to run django tests configurazion for all databases
On Sat, Mar 17, 2012 at 5:33 AM, Simone Federici wrote: > oracle and postgresql have the similar performance during the tests, > > but mysql... there is some tricks to go faster the mysql suite test case? > I recently encountered this as well; for me, it was because I was using MyISAM as the backend - switching to InnoDB saw about an 8x speedup, to become comparable to postgres (it took over four hours to run under MyISAM, for reference). Which backend are you using? -- 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 Saturday, March 17, 2012 at 1:59 AM, Russell Keith-Magee wrote:
>
> On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
>
> > Hi folks --
> >
> > This discussion of user authentication by email is getting pretty nasty;
> > can we start over? I know there's a lot of quite legitimate frustration
> > here, but we really need to drop the personal stuff and focus on the
> > problem at hand. I want to move this forward quickly, and I can commit to
> > spending some time on it in the coming weeks, but I'm going to lose
> > interest faster than than you can believe if the tone doesn't improve.
> > Please: keep it professional, and focus on the tech. I promise things'll go
> > smoothly if we all do.
> >
> > As I see it, there's two basic approaches we could take:
> >
> > 1. Incremental improvement: fix the most glaring issues with auth.User
> > (starting with email addresses for login, clearly), and generally improve
> > things a bit at a time. Once User's in a state where we're happy, move on
> > the rest of the auth app -- again, a bit at a time. This approach would see
> > the largest issues fixed more quickly, but would probably do so at the
> > expense of code quality (e.g. requiring a one-off solution to schema
> > migration of the User model) and would delay a more sweeping reform until
> > later.
> >
> > 2. Complete improvement: recognize that the auth app is fundamentally
> > flawed, and mercilessly refactor/replace/rewrite it, all in one go. The
> > hypothetical results here would be better -- a modern auth system
> > unencumbered by the decisions we made in 2005 -- but this would take far
> > longer, and would block on things like the app refactor and schema
> > migrations.
> >
> > There's also a middle-ground proposal from Clay: make the auth app
> > swappable, thus making it possible for *users* to replace the auth app
> > while leaving time for us to make either incremental or complete change, as
> > we see fit.
> >
> > I think we need to come together and agree on an approach before we move
> > forward, so I'd like to see some concrete proposals for each of these
> > approaches. Since all options have merits and since I think it's unlikely
> > we'll find consensus I'm prepared to make a BDFL ruling here. So if you
> > feel strongly about one approach or another, please write a concrete
> > proposal and post it here or on the wiki. I'll look these over -- and also
> > review Clay's branch -- and (again, baring consensus) make a ruling next
> > week.
> >
> > Just so my biases are clear: normally I'd lean more towards the
> > completionist stance, but in this case I haven't seen an actual proposal to
> > completely replace auth. Further, I think the fact that it's blocked on
> > *other* pretty hairy issues means it'd be unlikely to see that much action
> > that quickly. I'm also somewhat opposed to the "pluggable auth" idea since
> > I think it dilutes the utility of having built-in auth. In other words, if
> > we're going to make auth up to users, why not just get rid of the built-in
> > auth altogether? So I'm leaning towards an incremental improvement
> > approach, but only if I can see a concrete proposal that articulates what
> > to change, and deals with the backwards-compatibility issues in a
> > not-too-ugly way.
>
> Ok - I've been keeping quiet on this; partially due to the same tone issues
> that you've described, but also because I don't have a huge amount of spare
> time at the moment, and I don't want to be the person who makes a bunch of
> promises (expressed or implied) to work on something and then can't deliver
> on those promises.
>
> My biggest concern is that the middle-ground proposals that are on the table
> are implementing a workaround for a problem when the starting point of a
> long-term solution won't require that much more effort.
>
> IMHO, rather than implement a bunch of settings to introduce an
> auth.User-specific solution, we need to do two things:
>
> * Merge the app-refactor from GSoC 2010.
>
> This has a whole bunch of long-needed awaited benefits -- reliable hooks for
> app startup, configurable app labels, predictable module loading, amongst
> others -- but the one that matters for the purposes of auth.User is that it
> allows Apps to be treated as items that need to be configured as a runtime
> activity. In this case, we need to be able to specify, at a project level,
> which model is your "User" model in the auth app.
>
> * Add the concept of a LazyForeignKey.
>
> LazyForeignKey is a normal foreign key, with all the usual foreign key
> behaviors; the only difference is that the model it links to isn't specified
> in the model -- it's a configuration item drawn from an application
> configuration. So, ForeignKey('auth.User') creates a foreign key to
> django.contrib.auth.User; LazyForeignKey('auth.User') asks the auth app for
> the model that is being used as the 'User' model, and creates
Re: Tips required to run django tests configurazion for all databases
On Sat, Mar 17, 2012 at 15:03, Nate Bragg wrote:
> I recently encountered this as well; for me, it was because I was using
> MyISAM as the backend - switching to InnoDB saw about an 8x speedup, to
> become comparable to postgres (it took over four hours to run under MyISAM,
> for reference). Which backend are you using?
>
you're right :-)
'OPTIONS': {
'init_command': 'SET storage_engine=INNODB',
}
now is better, thanks
MYSQL Ran 657 tests in 54.382s
PGSQL Ran 657 tests in 44.537s
ORACLE Ran 657 tests in 66.953s
before with MyISAM was
Ran 657 tests in 1934.321s
--
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: Ticket 16317 https://code.djangoproject.com/ticket/16317
On Fri, Mar 16, 2012 at 15:00, Marcob wrote: > The ticket 16317 has a very nice 4 months old patch (it's has a two > lines fix, remainder are just test fixes). > It was marked for 1.3 version but now it's better to change it to 1.4 > version. > As I really hate to patch django I think my only solution is "to > lobby" this ticket here :-) > Is there anything else I can do? > Ciao. > Marco. > P.S. Someone said the putting your email in cc in a ticket isn't the > way to go. just to say that I did the patch 4 month ago, with test included, but the bug is not opened by me. https://code.djangoproject.com/ticket/16317 is related to a problem involved when try to dump the data (in natural key mode) of a model with a self relationship. but the resolution is one or two lines of code. -- 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.
GSoc Improved Error Reporting Project
Hi, My name is Melanie Rao, I am a student at the University of Edinburgh. In the final year of my Bachelors in Artificial Intelligence and Software Engineering, I was hoping to work on an open source project this summer, and would be very keep to join Django through the Google Summer of Code scheme. In particular, I am interested in the Error Report Project. I have checkout the code from the SVN, and will try to get familiar with it as much as possible in the next few days. Could you please tell me what would be good ideas to familiarise myself with the system? Thank you for your help, Melanie Rao -- 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 17/03/2012, at 4:16 PM, Ian Lewis wrote:
> Hi,
>
> Eric Florenzano and I actually had a discussion about this at PyCon.
> My company does Django development and simply doesn't use the Django
> auth app because it tries to do authentication and authorization in
> one app and the User models are just to inflexible. Many projects
> didn't need or want usernames, email etc. and many required changing
> the fields on the model. Using the get_profile() method in every view
> and in every template was also a huge pain in the ass.
>
> I have a concrete proposal and implementation that I wrote for our use
> that solves a lot of the issues that have come up here. I have been
> brushing up the api and documentation recently to release it but I'd
> like to speed things up and release it publicly. The app is built on
> some basic tenets in order of importance:
>
> 1. Django shouldn't decide what fields go on the user model. The app
> provides an abstract base class which developers subclass to add the
> appropriate fields they need.
+1
> 2. Django shouldn't decide the type of the primary key. The app only
> relies on the fact that the object has a pk. The id field can be named
> anything you wish and can be any type (integer, char, uuid, etc.).
+1
> 3. Third party apps don't rely on the user having any fields but
> rather the base user class defines methods that are implemented by
> subclasses. Methods like get_display_name() which provides a way for
> third party apps to get something to display.
> 4. Rather than provide mixins or something, we should have conventions
> for the field names like 'email' and third party apps should check if
> the user has one using duck typing e.g. hasattr(user, 'email'). An
> alternative could be to provide some kind of API for commonly used
> actions like emailing users.
This is essentially all I was proposing when I spoke of an "admin User
contract"; that we define some basic "identity" functions that every User
object is expected to provide -- short name, long name, and so on.
The admin case is a little more complicated because there is also a required
API for permissions and groups, but to my mind, these are different contracts,
and should be documented as such.
> 5. Basic username (or email)/password authentication can be provided.
> The app has a base user class from which a basic abstract user with
> username/password is defined. This can implement setting passwords
> properly and provide forms etc.
> 6. Multiple user models can be defined (Like say for normal users and
> affiliate users or admin users). If one wants to create a project
> currently with a separate user model, none of the machinery in the
> auth app can be used.
Sure you can -- you have a base User, and then subclasses to get AdminUser and
NormalUser -- both of which are effectively just another type of UserProfile.
> You create users by creating your own app in your project and creating
> a User there:
>
> account/models.py
>
> from django.db import models
>
> from newauth.models import UserBase
>
> class User(BaseUser):
>full_name = models.CharField(u"Full Name", max_length=255)
>email = models.EmailField('Email Address')
>profile = models.TextField('Profile Bio', blank=True, null=True)
>avatar = models.ImageField('Avatar', upload_to='profileimg/',
> blank=True, null=True)
>
>def get_display_name(self):
>return self.full_name
>
>class Meta:
>db_table = 'my_user_table'
>verbose_name = u"Djangonaut"
>verbose_name_plural = u"Djangonaut"
>
> There are even docs and tests.
How does this address the issue of reusable apps referencing User? Let's say I
write a comments app, and want an Author field. I need a ForeignKey to "User".
But I can't have a foreign key to BaseUser, because it's an abstract class. How
do I define my Comment model in such a way that it can reference a generic
"User"?
It seems to me that the solution you're proposing requires the LazyFK and
app-refactor infrastructure I've described in order to be useful in the general
case (not that I'm complaining, mind -- just pointing out that our two
proposals are complementary :-).
>> What are the benefits of this approach?
>>
>> * It solves the general problem, rather than just focussing on auth.User.
>>
>> The broad idea of defining behavior against an interface, rather than a
>> concrete model, is hardly new; auth.User is just the most obvious
>> manifestation in Django's problem space. It doesn't take much work to find
>> other examples: contrib.comments has an analogous "choose the comment model"
>> problem (solved in it's own bespoke way). It wouldn't take much of a survey
>> to find a whole lot of similar examples.
>
> I think the comments app doesn't do a terribly good job at solving the
> problem and won't make a good reference.
I'm not arguing that contrib.comments is a good reference -- quite the
opposite. I'm arguing that it has the same r
Re: auth.User refactor: reboot
On 17/03/2012, at 10:46 PM, Donald Stufft wrote:
> On Saturday, March 17, 2012 at 1:59 AM, Russell Keith-Magee wrote:
>>
>> * It solves the immediate problem ...
>>
>> As I see it, the immediate problem is that developers want to be able to
>> modify the base requirements of auth.User. There may well be people who want
>> to completely change contrib.auth, but for the moment, the 90% case can be
>> solved by modifying max_length or setting unique=True on the email field,
>> and/or removing the username field. The rest of auth.User is fine, at least
>> for now.
> It doesn't really solve the immediate problem though. It does technically but
> it also requires every single app that uses auth.User to update itself
> before you can use it which makes it less useful.
To my mind, this isn't any different to the situation with any other major
feature added in a Django release:
a) Existing apps continued to work as is.
b) Under certain conditions, existing apps will be able to use the new
features transparently
c) To be completely compatible, some modifications to the existing app are
required
Yes, this means that some apps will need to be labelled as "has been updated
for the 1.5 User model" -- but that's not without precedent.
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'). If we could manage this, then any existing
ForeignKey(User) would adapt to the new class, so the set of apps in class (c)
would be reduced to those that use features of User that aren't part of the new
User contract.
Personally, I like the idea of having an explicit "Lazy" reference; but we
might be able to address this in other ways. For example, if we mark a model
class as "swappable", references to that class would be resolved to the class
named in the app configuration. This might also provide the hook to prevent the
auth_user table from being created by syncdb (so we don't get empty auth_user
tables being created)
Yours,
Russ Magee %-)
--
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
Hi,
On Sun, Mar 18, 2012 at 9:41 AM, Russell Keith-Magee
wrote:
>> 1. Django shouldn't decide what fields go on the user model. The app
>> provides an abstract base class which developers subclass to add the
>> appropriate fields they need.
>
> +1
THX
>> 2. Django shouldn't decide the type of the primary key. The app only
>> relies on the fact that the object has a pk. The id field can be named
>> anything you wish and can be any type (integer, char, uuid, etc.).
>
> +1
THX again
>> 3. Third party apps don't rely on the user having any fields but
>> rather the base user class defines methods that are implemented by
>> subclasses. Methods like get_display_name() which provides a way for
>> third party apps to get something to display.
>> 4. Rather than provide mixins or something, we should have conventions
>> for the field names like 'email' and third party apps should check if
>> the user has one using duck typing e.g. hasattr(user, 'email'). An
>> alternative could be to provide some kind of API for commonly used
>> actions like emailing users.
>
> This is essentially all I was proposing when I spoke of an "admin User
> contract"; that we define some basic "identity" functions that every User
> object is expected to provide -- short name, long name, and so on.
>
> The admin case is a little more complicated because there is also a required
> API for permissions and groups, but to my mind, these are different
> contracts, and should be documented as such.
My solution is simply authentication, authorization would need to be
added on or in a separate app built on top of newauth.
>> 5. Basic username (or email)/password authentication can be provided.
>> The app has a base user class from which a basic abstract user with
>> username/password is defined. This can implement setting passwords
>> properly and provide forms etc.
>> 6. Multiple user models can be defined (Like say for normal users and
>> affiliate users or admin users). If one wants to create a project
>> currently with a separate user model, none of the machinery in the
>> auth app can be used.
>
> Sure you can -- you have a base User, and then subclasses to get AdminUser
> and NormalUser -- both of which are effectively just another type of
> UserProfile.
I meant one that was a completely separate concrete base model. The
current auth forces you to take along with you all the fields on the
User model.
>> You create users by creating your own app in your project and creating
>> a User there:
>>
>> account/models.py
>>
>> from django.db import models
>>
>> from newauth.models import UserBase
>>
>> class User(BaseUser):
>> full_name = models.CharField(u"Full Name", max_length=255)
>> email = models.EmailField('Email Address')
>> profile = models.TextField('Profile Bio', blank=True, null=True)
>> avatar = models.ImageField('Avatar', upload_to='profileimg/',
>> blank=True, null=True)
>>
>> def get_display_name(self):
>> return self.full_name
>>
>> class Meta:
>> db_table = 'my_user_table'
>> verbose_name = u"Djangonaut"
>> verbose_name_plural = u"Djangonaut"
>>
>> There are even docs and tests.
>
> How does this address the issue of reusable apps referencing User? Let's say
> I write a comments app, and want an Author field. I need a ForeignKey to
> "User". But I can't have a foreign key to BaseUser, because it's an abstract
> class. How do I define my Comment model in such a way that it can reference a
> generic "User"?
>
> It seems to me that the solution you're proposing requires the LazyFK and
> app-refactor infrastructure I've described in order to be useful in the
> general case (not that I'm complaining, mind -- just pointing out that our
> two proposals are complementary :-).
This is a bad example for showing how that works. I just wanted to
illustrate how you would make your own User model. In the case where
you want a foreign key to User you can import the default user model
from newauth.models as User much like you do with the current django
auth app.
See: http://ianlewis.bitbucket.org/django-newauth/third_party.html
>> This is going to be the biggest problem with my solution. There would
>> probably have to be some kind of compatibility layer added to make
>> existing apps work or to provide a simpler migration path.
>
> Isn't the compatibility layer just an implementation of the existing
> auth.User class that extends from BaseUser? We're going to have to ship this
> user class anyway, so that everything works out of the box; then if anyone
> wants to define their own User class, they can.
Perhaps. I think in reality it will be a bit more complicated though I
haven't really thought about it. I didn't really consider
authorization or backwards compatibility as a goal of the project when
first writing it.
>>> * It solves the immediate problem ...
>>>
>>> As I see it, the immediate problem is that developers want to be able to
>>> modify the base requirements of
