Re: auth.User refactor: reboot

On Wed, Mar 21, 2012 at 12:48 AM, Russell Keith-Magee wrote: > > On 21/03/2012, at 12:23 PM, Clay McClure wrote: > >> 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 >>

Re: auth.User refactor: reboot

Hi On Fri, Mar 23, 2012 at 8:41 PM, Hanne Moa wrote: > On 21 March 2012 09:40, Ian Lewis wrote: > > To my mind it's the least important of the tenets of the design of > > newauth, but I personally would like to use it at least for admin > > users and

Re: auth.User refactor: reboot

On 21 March 2012 09:40, Ian Lewis wrote: > To my mind it's the least important of the tenets of the design of > newauth, but I personally would like to use it at least for admin > users and normal site users. The issue for me is that the > functionality required of users of

Re: auth.User refactor: reboot

Also, even if we decide to use django-primate's monkey patch to mount a user model on django.contrib.auth.models.User I think we should still consider breaking AbstractUser into orthogonal mixins. As it stands, AbstractUser is a monolithic model with an ad-hoc method for overriding fields. As a

Re: auth.User refactor: reboot

On Mar 22, 2012 10:55 PM, "Russell Keith-Magee" wrote: > * This solution still has the circular dependency, because any app with a ForeignKey(settings.USER_MODEL) needs to have a settings import in the models.py file Hmmm. I asked a question about that today and was

Re: auth.User refactor: reboot

On 23/03/2012, at 9:50 AM, Alex Ogier wrote: > I hope you don't mind, I added solution 2a. It's basically solution 2 minus > the monkey-patching and resultant circular dependency issues, and > correspondingly requires apps to opt-in to supporting pluggable Users. It > documents the reasoning

Re: auth.User refactor: reboot

On Thu, Mar 22, 2012 at 8:14 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote: > > > 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 >

Re: auth.User refactor: reboot

Hi, On Tue, Mar 20, 2012 at 10:37 PM, Russell Keith-Magee wrote: > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> User profiles solve the issue of app specific data in a better way >> than specifying additional fields on a a base user object, >> particularly as the

Re: auth.User refactor: reboot

Hi, On Tue, Mar 20, 2012 at 2:05 PM, Russell Keith-Magee wrote: > On 20/03/2012, at 8:00 AM, Ian Lewis wrote: >> Though we have had other times where there were multiple types of >> users in a single project. i.e. users that signed up via some >> affiliate program.

Re: auth.User refactor: reboot

On Wed, Mar 21, 2012 at 2:41 AM, Clay McClure wrote: > > 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

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 >

Re: auth.User refactor: reboot

On 21/03/2012, at 12:23 PM, Clay McClure wrote: > 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

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

Re: auth.User refactor: reboot

On 21/03/2012, at 4:57 AM, ptone wrote: > > > > The key point here is that we're not forcing every Django user to discover > > by accident that they need to run an ALTER TABLE statement in order for > > their projects to keep working. The opt-in nature of the change is key. > > > > > > I

Re: auth.User refactor: reboot

On 21/03/2012, at 2:00 AM, Tom Evans wrote: > On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft > wrote: >> What Alex said. If it was _just_ the username then you'd have a good >> argument for >> a setting like that. However there's username, email, some people want to >>

Re: auth.User refactor: reboot

On 20/03/2012, at 10:27 PM, Donald Stufft wrote: > > On Tuesday, March 20, 2012 at 10:08 AM, Tom Evans wrote: > >> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee >> wrote: >>> >>> The key point here is that we're not forcing every Django user to discover >>>

Re: auth.User refactor: reboot

On 21/03/2012, at 1:49 AM, Бачериков Вячеслав wrote: >> > There other way do do this. > For example tunning of User model can done by configuration, like that: > > EXTENDED_USERMODEL_SETTINGS = {'email': >{'uniq':True,'max_length':255, >

Re: auth.User refactor: reboot

> > > > On Tuesday, March 20, 2012 7:08:49 AM UTC-7, Tom Evans wrote: > >> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee >> wrote: >> > >> > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> >> >> > Personally, I'd be in favor of option (3), mostly because what the last >> 6 years has

Re: auth.User refactor: reboot

20.03.2012 20:40, william ratcliff ?: > To facilitate these different cases, can we have a pluggable > "Authentication Service" where the user provides a "credential" which > then returns a result of whether the credential is valid or not?We > could then implement a few "standard"

Re: auth.User refactor: reboot

A bit of an odd question-- What practices have other packages adopted? For example, I was playing with ASP.NET last weekend to help out a friend and found their decoupling of authentication from the database to be rather pleasant. Is it possible to add a layer of indirection. In some sense, I

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft wrote: > What Alex said. If it was _just_ the username then you'd have a good > argument for > a setting like that. However there's username, email, some people want to > add > fields, some want to get rid of, or combine

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 1:17 PM, Alex Ogier wrote: >> Would something like the following alleviate that problem? >> >> class User(models.Model): >>    if settings.USE_LONG_USER_FIELDS: >>        username = models.CharField(max_length=255, unique=True, ...) >>    else: >>    

Re: auth.User refactor: reboot

> On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote: >> >>> However not all databases have this same behavior when trying to >>> insert a string that is longer than >>> the field allows. This means that for a certain subset of Django >>> developers if they didn't read the >>> releases note, or

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 5:17 PM, Alex Ogier wrote: >> Would something like the following alleviate that problem? >> >> class User(models.Model): >>    if settings.USE_LONG_USER_FIELDS: >>        username = models.CharField(max_length=255, unique=True, ...) >>    else: >>    

Re: auth.User refactor: reboot

On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote: > > > However not all databases have this same behavior when trying to insert a > > string that is longer than > > the field allows. This means that for a certain subset of Django developers > > if they didn't read the > > releases note, or just

Re: auth.User refactor: reboot

> Would something like the following alleviate that problem? > > class User(models.Model): >if settings.USE_LONG_USER_FIELDS: >username = models.CharField(max_length=255, unique=True, ...) >else: >username = models.CharField(max_length=30, unique=True, ...) >... Maybe,

Re: auth.User refactor: reboot

> However not all databases have this same behavior when trying to insert a > string that is longer than > the field allows. This means that for a certain subset of Django developers > if they didn't read the > releases note, or just missed that section of it that Django would not > validate

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee wrote: > > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> >>>  * It's completely backwards compatible. >>> >>> If you've got an existing app with normal ForeignKeys to auth.User, >>> the app will continue to work,

Re: auth.User refactor: reboot

On 20/03/2012, at 8:38 PM, Tom Evans wrote: > >> * It's completely backwards compatible. >> >> If you've got an existing app with normal ForeignKeys to auth.User, >> the app will continue to work, without any migrations, as long as >> the rest of your project uses auth.User. It will also

Re: auth.User refactor: reboot

On Sat, Mar 17, 2012 at 5:59 AM, Russell Keith-Magee wrote: > 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

Re: auth.User refactor: reboot

Hi I have just been using Django for the last 4 months, and the application I developed needed an extensive UserProfile module. It needed things such as 1. Ability to log in via both email and username 2. Ability to link multiple social accounts with the same user account (the

Re: auth.User refactor: reboot

On 20/03/2012, at 8:00 AM, Ian Lewis wrote: >> * One very big new feature -- the ability to have multiple User models in >> the same project. >> >> This is the one controversial part of your proposal, from my perspective. In >> every situation I can think of, I can only see it being an

Re: auth.User refactor: reboot

Hi, On Mon, Mar 19, 2012 at 9:27 PM, Russell Keith-Magee wrote: > On 18/03/2012, at 12:19 PM, Ian Lewis wrote: >> 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. >

Re: auth.User refactor: reboot

Yes, it's not really a security bug! It's about to build a more secure account system. On Monday, 19 March 2012 19:25:24 UTC+8, Florian Apolloner wrote: > > Hi lepture, > > aside from the fact, that it's not really a security bug we do ask people > not to report security issues public but mail

Re: auth.User refactor: reboot

On 18/03/2012, at 12:19 PM, Ian Lewis wrote: >>> 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

Re: auth.User refactor: reboot

Hi lepture, aside from the fact, that it's not really a security bug we do ask people not to report security issues public but mail to security at djangoproject.com. Reporting them in the open does help neither you nor us. And please don't hijack threads like this -- this thread is about a

Re: auth.User refactor: reboot

Hello, Jacob. The current auth module has a very security bug, if the session cookie is stolen by others, you cannot do anything to stop them. You changed your password, but the session is still working. You signed out, the session is still working. You can do nothing, but waiting for the

Re: auth.User refactor: reboot

Hi, On Mon, Mar 19, 2012 at 1:00 AM, Joe Tennies wrote: > A feature I would love to see is the ability to support multiple forms of > authentication for a single user account. (One account to many credentials.) You can do this already with Django auth by specifying multiple

Re: auth.User refactor: reboot

A feature I would love to see is the ability to support multiple forms of authentication for a single user account. (One account to many credentials.) On Sat, Mar 17, 2012 at 11:19 PM, Ian Lewis wrote: > Hi, > > On Sun, Mar 18, 2012 at 9:41 AM, Russell Keith-Magee >

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

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

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

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

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

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

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

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

Re: auth.User refactor: reboot

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

Re: auth.User refactor: reboot

On Friday, March 16, 2012 at 11:51 PM, Henrique Bastos wrote: > Hello, > > I would like to share some early stage thoughts on this matter. > > On Fri, Mar 16, 2012 at 5:01 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > On Friday, March 16, 2012 at 3:59

Re: auth.User refactor: reboot

Hello, I would like to share some early stage thoughts on this matter. On Fri, Mar 16, 2012 at 5:01 PM, Donald Stufft wrote: > On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > > ... > Currently auth consists of multiple things: > * authentication > *

Re: auth.User refactor: reboot

Hello, I'm also interested in working on an enhanced auth.user as a GSoC project and I'm currently working on my proposal. My proposal is largely based on pluggable auth models. What I'm seeing is that most people are generally negative to the idea, including core developers and

Re: auth.User refactor: reboot

On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > Hi, > > sorry, if this was said before, I haven't read the latest user discussions. > > I'm in favor of enhancing the auth app step by step, as everything else > seems unlikely (haven't happend for a long time, why should it now). >

Re: auth.User refactor: reboot

Hi, sorry, if this was said before, I haven't read the latest user discussions. I'm in favor of enhancing the auth app step by step, as everything else seems unlikely (haven't happend for a long time, why should it now). What I dislike about the current auth app in general is that it solves

Re: auth.User refactor: reboot

Hi everyone, I'm a student at Brandeis University, and I'm actually interested in working on an 'enhanced auth.user' for GSOC 2012. I don't have a formal proposal yet, but I drafted up the main idea of what's I'm planning in a google doc:

Re: auth.User refactor: reboot

Yeah, a mechanism where you can subclass User **and use your subclass in lieu** is quite similar to what I suggested and, I agree, solves the problems I raise. A subclass is also going to be substantially cleaner than having a new special way to add fields. Then we just need a Django setting to

Re: auth.User refactor: reboot

On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: > Disclaimer: I was up really, really early this morning, so please bear with > me if I sound somewhat incoherent... > > On March 16, 2012, at 12:29 , Tom Evans wrote: > > > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss

Re: auth.User refactor: reboot

Disclaimer: I was up really, really early this morning, so please bear with me if I sound somewhat incoherent... On March 16, 2012, at 12:29 , Tom Evans wrote: > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss wrote: >> Hi folks -- >> […] > > I'm not in favour of

Re: auth.User refactor: reboot

On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote: > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote: > > Hi folks -- > > […] > > > > > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A

Re: auth.User refactor: reboot

On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote: > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A pluggable user model has to be set up by the project > developer, whilst the attributes an app may need are specified solely > by the app developer. >

Re: auth.User refactor: reboot

On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > […] I'm not in favour of pluggable user models, as for me, they solve the wrong problem. A pluggable user model has to be set up by the project developer, whilst the attributes an app may need are

Re: auth.User refactor: reboot

A big +1 to this. I'm willing to help where I can as well if you can find some use for me :) I think one of the big problems is the lack of being able to modify the user model in any appreciable way. Regardless of incremental improvements or not I think one possibly decent method is that