[contrib.auth] Separating tightly coupled User model and auth processes implementations

dule depends on the `User.pk` attribute, "silently" supports `User.get_session_auth_hash()` method, uses the model reflection to serialize ids into the session object and forces the usage of AnonymousUser without an easy way out. It looks like the contrib.auth module does way more than

Re: Add autocomplete attribute to contrib.auth fields?

I wouldn't think such pentest tools are a major concern, as I'd guess not many users have to meet such requirements, and it would always be possible to subclass the forms and set autocomplete=off where appropriate. Also the referred mdn docs

Re: Add autocomplete attribute to contrib.auth fields?

I don’t have much to add other than it’s pretty common for pentests to flag autocomplete being enabled on sensitive fields (email/password) and recommend disabling it (autocomplete=off). While I’m not sure if I agree with that recommendation in some situations you have little choice but to follow i

Add autocomplete attribute to contrib.auth fields?

Browser support looks somewhat limited, so I wanted to ask if there are any concerns or drawbacks with adding autocomplete=username/email/current-password/new-password to contrib.auth's forms? Pull request: ​https://github.com/django/django/pull/9921 >From the ticket [https://code.djangopr

Re: Should contrib.auth include support for 2fa out of the box?

I would like to explain a potential solution I have been working on (See commit https://github.com/mlevental/django/commit/51dbaa6748076e06d91b361c2fa60ecf24f5c27e

Re: Should contrib.auth include support for 2fa out of the box?

I would like to explain a potential solution I have been working on (See commit https://github.com/mlevental/django/tree/ticket_25612). I think it's not complete but I don't have the time to continue working on it. *Overview:* - In order to check if a user is authenticated with one or two fa

Re: Should contrib.auth include support for 2fa out of the box?

Hello, FYI django-two-factor-auth builds upon django-otp; they aren't alternatives. This is an ambitious project. I suggest to start by getting a better understanding of what these libraries do, what the different scenarios for two factor authentication are, and writing a DEP to describe the A

Re: Should contrib.auth include support for 2fa out of the box?

I would like to work on this ticket. As for the implementation there doesn't seem to be much choice. The implementation with the most features is from Bouke . It supports U2F, TOTP, SMS and phone call (with Twilio by default). Beside that one onl

Re: Should contrib.auth include support for 2fa out of the box?

+1 This sounds like a great feature, depending on the implementation. On Monday, October 26, 2015 at 10:22:46 AM UTC-7, Tim Graham wrote: > > On Trac [1], Alex says, "Django did a tremendous service to its users by > making strong password hashing be the default. The world is pushing > forward,

Re: Should contrib.auth include support for 2fa out of the box?

On Tuesday, October 27, 2015 at 12:46:47 AM UTC+1, Joey Wilhelm wrote: > > Fwiw, 2fa is on my short list of things to implement into my current > project. It's a fairly important feature to me, as this is a financial > project. And that particular implementation is precisely what I was looking

Re: Should contrib.auth include support for 2fa out of the box?

Yes, I would like to see that in contrib.auth, which will require rewriting the backends and introduce a auth pipeline ala django-social-auth (has/had) -- I was planning to get some thoughts about that on DUTH. Also see this (short) twitter discussion: https://twitter.com/jacobian/status

Re: Should contrib.auth include support for 2fa out of the box?

Other then u2f and TOTP, I'll favour for email and sms (using external api like twilio) based OTP as well. Keeping different pluggable backends will be better in my opinion. On Tue, 27 Oct 2015 at 07:01 Russell Keith-Magee wrote: > > +1. Sounds like a great idea to me. > > Russ %-) > > On Tue, O

Re: Should contrib.auth include support for 2fa out of the box?

+1. Sounds like a great idea to me. Russ %-) On Tue, Oct 27, 2015 at 1:22 AM, Tim Graham wrote: > On Trac [1], Alex says, "Django did a tremendous service to its users by > making strong password hashing be the default. The world is pushing > forward, and now 2fa is the next standard that many

Re: Should contrib.auth include support for 2fa out of the box?

Fwiw, 2fa is on my short list of things to implement into my current project. It's a fairly important feature to me, as this is a financial project. And that particular implementation is precisely what I was looking to use. I would happily contribute money and/or time toward this implementation, es

Re: Should contrib.auth include support for 2fa out of the box?

Having pluggable 2fa backends is a great idea. Many sites that allow 2fa have it as an option per user. I would think Django would allow the same. Allow admins to force 2fa, or allow Users to choose if they'd like it enabled. There'd have to be ORM/Model support (presumably) for user choices. A

Re: Should contrib.auth include support for 2fa out of the box?

On 26 oct. 2015, at 18:22, Tim Graham wrote: > What do you think? I would very much like Django to have 2FA out of the box. Let’s bring django.contrib.auth kicking and screaming into the 2010’s ;-) I even considered crowdfunding it but that didn’t go much beyond idle thoughts. -- Aymeric. --

Re: Should contrib.auth include support for 2fa out of the box?

I agree with Alex, no idea about that particular implementation though. It supports a lot of different implementations of two factor, though I suspect Django wouldn’t need all of those things. I think it would be reasonable to define something like auth_backends, but for 2fa and just ship u2f an

Should contrib.auth include support for 2fa out of the box?

On Trac [1], Alex says, "Django did a tremendous service to its users by making strong password hashing be the default. The world is pushing forward, and now 2fa is the next standard that many sites fail to meet. Django should include support for 2fa out of the box, ideally with support for b

Re: form validation in contrib.auth

1. I don't see much benefit to adding a max length for one form (AuthenticationForm) to give some sense of security as opposed to properly addressing the issue at the webserver level. As Paul said, "As documented in the deployment docs, it is your responsibility as the deployer to limit post bo

form validation in contrib.auth

The default auth.form.AuthenticationForm() did not set a max_length for the password field: https://github.com/django/django/blob/72f6513ebaa7a3fd43c26300e9a8c430dc07cdb5/django/contrib/auth/forms.py#L120-L126 Ok there is not really a max_length constraint. Because in the end the auth.models

Re: Draft branch: Swappable User models in contrib.auth

On Thu, Aug 23, 2012 at 10:16 PM, sergzach wrote: > The question about databases. > > Do I understand correctly that if we create a MyUser class (as in your > example) then extra fields (e.g. date_of_birth) will be stored in the same > table of a database with inherited fields (from AbstractBaseUs

Re: Draft branch: Swappable User models in contrib.auth

The question about databases. Do I understand correctly that if we create a MyUser class (as in your example) then extra fields (e.g. date_of_birth) will be stored in the same table of a database with inherited fields (from AbstractBaseUser)? > === > from django.db import models > > from dja

Re: Draft branch: Swappable User models in contrib.auth

Just felt compelled to say: "Thank you for the hard work". -Original Message- From: Russell Keith-Magee Sent: Monday, August 20, 2012 9:40 PM To: django-developers@googlegroups.com Subject: Re: Draft branch: Swappable User models in contrib.auth On Mon, Aug 20, 2012

Re: Draft branch: Swappable User models in contrib.auth

On Mon, Aug 20, 2012 at 7:11 AM, Russell Keith-Magee wrote: > On Sun, Aug 19, 2012 at 10:02 AM, Victor Hooi wrote: >> Hi, >> >> I'm just wondering, has there been any updates on the User model refactor? >> >> My understanding is that this is the official way of handling Users going >> forward. >>

Re: Draft branch: Swappable User models in contrib.auth

Ah, thanks Russ, I'd missed the final resolution to that. M On Monday, 20 August 2012 00:12:18 UTC+1, Russell Keith-Magee wrote: > > On Sun, Aug 19, 2012 at 5:23 PM, Marc Tamlyn > > > wrote: > > I believe changes to auth (and several other things) are waiting for > > contrib.migrations. It wi

Re: Draft branch: Swappable User models in contrib.auth

On Sun, Aug 19, 2012 at 5:23 PM, Marc Tamlyn wrote: > I believe changes to auth (and several other things) are waiting for > contrib.migrations. It will be some time... Incorrect. The strategy that was approved for trunk won't require migrations unless you want to change an existing project, whic

Re: Draft branch: Swappable User models in contrib.auth

On Sun, Aug 19, 2012 at 10:02 AM, Victor Hooi wrote: > Hi, > > I'm just wondering, has there been any updates on the User model refactor? > > My understanding is that this is the official way of handling Users going > forward. > > Is there any roadmap on when it might hit trunk? I didn't see any r

Re: Draft branch: Swappable User models in contrib.auth

I believe changes to auth (and several other things) are waiting for contrib.migrations. It will be some time... On Sunday, 19 August 2012 03:02:51 UTC+1, Victor Hooi wrote: > > Hi, > > I'm just wondering, has there been any updates on the User model refactor? > > My understanding is that this is

Re: Draft branch: Swappable User models in contrib.auth

Hi, I'm just wondering, has there been any updates on the User model refactor? My understanding is that this is the official way of handling Users going forward. Is there any roadmap on when it might hit trunk? I didn't see any reference to User models in the 1.5 release notes. Cheers, Victor

Re: Draft branch: Swappable User models in contrib.auth

On 10 kesä, 10:42, Russell Keith-Magee wrote: > I'm not sure I see why. This looks to me like *exactly* what apps are > designed to achieve. By way of implementation, it might make sense to > introduce this as a 'sub app' - i.e., contrib.auth.improveduser would > be an installable app in itself; t

Re: Draft branch: Swappable User models in contrib.auth

On Fri, Jun 8, 2012 at 7:50 PM, Anssi Kääriäinen wrote: > On 8 kesä, 13:43, Russell Keith-Magee wrote: >> That's certainly an interesting use case. However, I can think of at >> least 2 ways it could be mitigated. >> >> One way would be to treat this as part of the contract of a pluggble >> app.

Re: Draft branch: Swappable User models in contrib.auth

On 8 kesä, 13:43, Russell Keith-Magee wrote: > That's certainly an interesting use case. However, I can think of at > least 2 ways it could be mitigated. > > One way would be to treat this as part of the contract of a pluggble > app. We've always said that an app should do one thing, and one thing

Re: Draft branch: Swappable User models in contrib.auth

On Fri, Jun 8, 2012 at 8:53 AM, Anssi Kääriäinen wrote: > On 8 kesä, 02:43, Russell Keith-Magee wrote: >> >  - For documentation: It should be suggested that the example MyUser >> > should define class Meta: swappable = 'AUTH_USER_MODEL'. Otherwise it >> > will be synced to the database even if i

Re: Draft branch: Swappable User models in contrib.auth

On 8 kesä, 02:43, Russell Keith-Magee wrote: > Good idea. I haven't tried to see what it actually does; I'm guessing > you're going to get Table Does Not Exist errors. A nicer error > wouldn't hurt. Yes, that is what happens. > >  - For documentation: It should be suggested that the example MyUs

Re: Draft branch: Swappable User models in contrib.auth

On Thu, Jun 7, 2012 at 7:48 PM, Anssi Kääriäinen wrote: > On Jun 7, 11:57 am, Florian Apolloner wrote: >> Hi, >> >> On Wednesday, June 6, 2012 4:32:02 PM UTC+2, Anssi Kääriäinen wrote: >> >> > Still, yet another API idea: [snip] >> >> Then, Model.__new__ will replace the SwappableUser class with

Re: Draft branch: Swappable User models in contrib.auth

On Jun 7, 11:57 am, Florian Apolloner wrote: > Hi, > > On Wednesday, June 6, 2012 4:32:02 PM UTC+2, Anssi Kääriäinen wrote: > > > Still, yet another API idea: [snip] > > Then, Model.__new__ will replace the SwappableUser class with the > > > swapped in class. The 'swappable' in model.Meta tells wh

Re: Draft branch: Swappable User models in contrib.auth

Hi, On Wednesday, June 6, 2012 4:32:02 PM UTC+2, Anssi Kääriäinen wrote: > > Still, yet another API idea: [snip] > > Then, Model.__new__ will replace the SwappableUser class with the > swapped in class. The 'swappable' in model.Meta tells which concrete > model implementation to use. > I'd r

Re: Draft branch: Swappable User models in contrib.auth

On Jun 6, 9:20 am, Russell Keith-Magee wrote: > wrote: > > Understood & agreed (the "this model is dynamic made explicit" part > > seems really important specifically). > > > I am afraid of the hard-coding of meta.swappable must be 'SOME_VAR' > > which then references settings.SOME_VAR, and that

Re: Draft branch: Swappable User models in contrib.auth

On 4 June 2012 16:12, Russell Keith-Magee wrote: >  * The swapping mechanic is set up using a new Meta option on models > called 'swappable' that defines the setting where an alternate model > can be defined. Technically, the swappable option *could* be used for > any model; however, I'm not propo

Re: Draft branch: Swappable User models in contrib.auth

On Tue, Jun 5, 2012 at 9:00 PM, Anssi Kääriäinen wrote: > Understood & agreed (the "this model is dynamic made explicit" part > seems really important specifically). > > I am afraid of the hard-coding of meta.swappable must be 'SOME_VAR' > which then references settings.SOME_VAR, and that this is

Re: Draft branch: Swappable User models in contrib.auth

On Jun 5, 2:44 pm, Russell Keith-Magee wrote: > Two significant reasons: > > Firstly, if we use the Meta attribute approach, we can raise a > specific validation error when the user has an app with a model that > references auth.User directly, and User has been swapped out. This is > mostly useful

Re: Draft branch: Swappable User models in contrib.auth

On Tue, Jun 5, 2012 at 3:56 AM, Anssi Kääriäinen wrote: > On Jun 4, 6:12 pm, Russell Keith-Magee > wrote: >>  * The swapping mechanic is set up using a new Meta option on models >> called 'swappable' that defines the setting where an alternate model >> can be defined. Technically, the swappable o

Re: Draft branch: Swappable User models in contrib.auth

On Jun 4, 6:12 pm, Russell Keith-Magee wrote: >  * The swapping mechanic is set up using a new Meta option on models > called 'swappable' that defines the setting where an alternate model > can be defined. Technically, the swappable option *could* be used for > any model; however, I'm not proposin

Draft branch: Swappable User models in contrib.auth

Hi all, Following the BDFL pronouncement of a preferred option for customisable User models in contrib.auth [1], I've just pushed a branch to Github that contains a draft implementation [2]. It's not ready for trunk quite yet, but you can use this code to set up a custom User model, an

Re: [GSoC 2012] Enhanced contrib.auth

On Wed, 04 Apr 2012 19:25:26 +0300, Adrian Holovaty wrote: Hi Stratos, The core team is going to take the lead on the auth.User refactoring -- specifically, yours truly. :-) Given that the Summer of Code policy prohibits code contributions from non-students (right?), I don't think the User

Re: [GSoC 2012] Enhanced contrib.auth

On Wed, Apr 4, 2012 at 10:16 AM, Stratos Moros wrote: > I'm apologizing for replying to my own post, but there are only two days > left before GSoC's submission deadline and my proposal has received very > little feedback. > > Since other proposals about contrib.auth a

Re: [GSoC 2012] Enhanced contrib.auth

Hello, I'm apologizing for replying to my own post, but there are only two days left before GSoC's submission deadline and my proposal has received very little feedback. Since other proposals about contrib.auth are being discussed, I was wondering if mine has any merit and whethe

Re: [GSoC 2012] Enhanced contrib.auth

On Fri, 30 Mar 2012 17:35:16 +0300, Tom Evans wrote: On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros wrote: You can read the proposal nicely formatted here: https://gist.github.com/8dd9fb27127b44d4e789 Hi Stratos It's a long proposal, so this is a brain dump of bits that I find interest

Re: [GSoC 2012] Enhanced contrib.auth

On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros wrote: > You can read the proposal nicely formatted here: > https://gist.github.com/8dd9fb27127b44d4e789 Hi Stratos It's a long proposal, so this is a brain dump of bits that I find interesting/worrisome. I'm sure you've followed the recent thread

[GSoC 2012] Enhanced contrib.auth

would like to participate in Google Summer of Code with Django, working on an enhanced contrib.auth. Goals - - Long term solution The proposed replacement doesn't aim at just improving some of the current limitations of contrib.auth (e.g. increasing the email field size)

[GSoC 2012] Questions regarding the contrib.auth project

Hi, I would like to participate in this years Google Summer of Code. As a project I would like to tackle Django's beloved auth.User model. The topic has been discussed quite extensively the last days so I won't repeat everything here again. My prefered solution would be "Solution 3" from the C

Re: Security - contrib.auth hashing

security-related pieces of Django ever undergone a security audit? I remember Simon W. asking for a code review of his signed-cookie implementation (https://groups.google.com/forum/#topic/django-developers/KX6LIgBvfzo), and I now see that Jacob didn't feel that a security audit was worthwhil

Re: Bug with testing framework when not using contrib.auth

Ok, I finally created a ticket for this: http://code.djangoproject.com/ticket/14632 On Nov 3, 5:26 pm, Russell Keith-Magee wrote: > On Thu, Nov 4, 2010 at 3:58 AM, Yo-Yo Ma wrote: > > Ok, thanks. I'm using CookieStorage for messages, so the issue may not > > reside only with legacy storage. Sho

Re: Bug with testing framework when not using contrib.auth

On Thu, Nov 4, 2010 at 3:58 AM, Yo-Yo Ma wrote: > Ok, thanks. I'm using CookieStorage for messages, so the issue may not > reside only with legacy storage. Should I create a ticket for this? If you'd be so kind. Yours, Russ Magee %-) -- You received this message because you are subscribed to t

Re: Bug with testing framework when not using contrib.auth

Ok, thanks. I'm using CookieStorage for messages, so the issue may not reside only with legacy storage. Should I create a ticket for this? On Nov 3, 6:11 am, Russell Keith-Magee wrote: > On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma wrote: > > I've been using CookieStorage (for less DB usage). Us th

Re: Bug with testing framework when not using contrib.auth

On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma wrote: > I've been using CookieStorage (for less DB usage). Us that frowned > upon nowadays, in favor of the DB backend? There is no "db" backend for messages, there is only a "legacy" backend, which, as the name suggests, is for legacy applications -- app

Re: Bug with testing framework when not using contrib.auth

> > wrote: > > This is certainly an artifact of the fact that messages recent started > > supporting anonymous messages. Previously it depended on auth. > > > I suspect you just need to open a ticket for this. > > Yes - this is oversight, not intention. > > con

Re: Bug with testing framework when not using contrib.auth

sages recent started > > supporting anonymous messages. Previously it depended on auth. > > > I suspect you just need to open a ticket for this. > > Yes - this is oversight, not intention. > > contrib.messages depends on contrib.auth for reasons of backwards > compatib

Re: Bug with testing framework when not using contrib.auth

ot intention. contrib.messages depends on contrib.auth for reasons of backwards compatibility, but unless you're using the legacy fallback storage mechanism, that dependency doesn't exist in practice. You're the first person to report this dependency as a practical concern. I suspect we&#

Re: Bug with testing framework when not using contrib.auth

This is certainly an artifact of the fact that messages recent started supporting anonymous messages. Previously it depended on auth. I suspect you just need to open a ticket for this. On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma wrote: > I have a large application that doesn't user cont

Bug with testing framework when not using contrib.auth

I have a large application that doesn't user contrib.auth, and when I run `manage.py test` I get a slough of 35 errors, all of which are DatabaseError: no such table: auth_user (differing Tracebacks for each). I don't have any actual tests yet, just the SimpleTest that comes free i

contrib.auth tests depending on contrib.admin

Hi All! After installing django and creating a project runing "django-admin.py startproject", if I setup a sqlite3 database and try to run the tests (python manage.py test) it will fail. Seems that contrib.auth tests are missing 2 template files, making it dependent of contrib.admin

Re: Security - contrib.auth hashing

On Tue, Jul 20, 2010 at 12:09 PM, Jacob Kaplan-Moss wrote: > On Tue, Jul 20, 2010 at 8:41 AM, Craig Younkins > wrote: > > I'm very glad you don't have MD5 as the default. SHA-1 (currently > employed) > > is acceptable for now, but at this point there are theoretical attacks > that > > can find co

Re: Security - contrib.auth hashing

Hey Craig -- Thanks for the notes - this is good stuff! On Tue, Jul 20, 2010 at 8:41 AM, Craig Younkins wrote: > I'm very glad you don't have MD5 as the default. SHA-1 (currently employed) > is acceptable for now, but at this point there are theoretical attacks that > can find collisions in time

Security - contrib.auth hashing

Please note this email does not include or indicate a specific, immediately viable flaw. I'm doing a brief analysis of the contrib.auth system: http://www.pythonsecurity.org/wiki/django/#authentication . I have a couple of notes that I'd like to share with you. - I'm very glad

Re: contrib.Auth

ant to fix them. 2) No, seriously, we know about the limitations, and we want to fix them. 3) I wasn't kidding on the first two points. As has been said several times in this thread, the limitations with contrib.auth Users are well known, and they are something we want to address -- in the Djang

Re: contrib.Auth

It's not only about character restrictions on usernames. Some of developers want to use email as login (so we have to remove username and add unique option to email). Another example are english-only permissions. I would like to replace them with my own i18n permissions. Maybe someone needs somethi

Re: contrib.Auth

How about fixing http://code.djangoproject.com/ticket/5786 "Relax character restrictions on auth usernames" Jacob already said back in December '07: "we just need to relax the current restrictions" The ticket has a patch, and tests... On Feb 11, 11:44 am, James Bennett wrote: > Once again: > >

Re: contrib.Auth

Once again: This is really not the time to be discussing this; anything in this thread's going to be long forgotten by the time 1.2's out and 1.3 feature discussions are going on. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message bec

Re: contrib.Auth

On 10 February 2010 23:33, Sayane wrote: > I think that an easy way to define your own user model is better idea. Auth > app should be more generic. It should define a protocol for user, group and > permission objects /../ Why should permissions and groups be in the same app as the user? Less reu

Re: contrib.Auth

I think that an easy way to define your own user model is better idea. Auth app should be more generic. It should define a protocol for user, group and permission objects (and of course there should be back compatible implementation of this protocols used by default). There is a ticket about extend

Re: contrib.Auth

Good suggestions, I think removing username and email from the user might be a good idea. Right now I authenticate with the email address stored on the profile and the username is a random hash :) As for breaking data and migrations; it shouldn't be that hard to write a management command that doe

Re: contrib.Auth

Vitaly Babiy On Tue, Feb 9, 2010 at 3:16 AM, James Bennett wrote: > On Tue, Feb 9, 2010 at 2:09 AM, Harro wrote: > > - Make email unique and username non-required on the model. That would > > make implementing something that authenticated by email a lot > > easier :) > > 1. It's *extremely* un

Re: contrib.Auth

On Tue, Feb 9, 2010 at 2:09 AM, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) 1. It's *extremely* unlikely that changes will be considered which require every Django install on the

Re: contrib.Auth

I recently tried to use the recommended approach for custom user profiles: http://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles and all the brick walls I hit were admin related. Whether these are better fixed in contrib.auth or contrib.admin is hard to say: 1. I can show profile

Re: contrib.Auth

On 9 February 2010 08:09, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) > For reference there are some good points here[1] on this topic started by Hanne Moa. I think ideally the

Re: contrib.Auth

On 9 February 2010 09:09, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) Pff, move emails out entirely. Email-addresses may change. Usernames shouldn't change. One may have more than

Re: contrib.Auth

rred to as "sobering up" > :-) > > To address Vitaly's original point - contrib.auth is on my list of > things I want to address in 1.3. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups &quo

Re: contrib.Auth

ost-release bliss. I believe the post-release period is typically referred to as "sobering up" :-) To address Vitaly's original point - contrib.auth is on my list of things I want to address in 1.3. Yours, Russ Magee %-) -- You received this message because you are subscrib

Re: contrib.Auth

To add another point, this doesn't mean that the day 1.2 hits release that everyone is gung-ho on 1.3. If past releases are any indication, there is usually a refactory period of a few weeks when everyone is basking in post-release bliss. -justin On Mon, Feb 8, 2010 at 6:46 PM, Karen Tracey wro

Re: contrib.Auth

Thanks, for the pointer. I think even if this gets people think about the problem its a good start, I will raise this question again after 1.2 release. Vitaly Babiy On Mon, Feb 8, 2010 at 6:46 PM, Karen Tracey wrote: > On Mon, Feb 8, 2010 at 6:39 PM, Vitaly Babiy wrote: > >> Hey Guys, >> So 1.

Re: contrib.Auth

On Mon, Feb 8, 2010 at 6:39 PM, Vitaly Babiy wrote: > Hey Guys, > So 1.2 is almost out the door so I wanted to raise an issue that I would > love to start working to fix for 1.3. > Not to discourage you, but be aware the focus of most attention until 1.2 actually goes out is still 1.2. Feature f

contrib.Auth

Hey Guys, So 1.2 is almost out the door so I wanted to raise an issue that I would love to start working to fix for 1.3. As we all have used the contrib.Auth application we know there are some short comings in the application. Here is a couple of issue that I have noticed since using it. - If

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 11, 2009 at 8:14 AM, Russell Keith-Magee wrote: > On Wed, Dec 9, 2009 at 11:36 PM, Jacob Kaplan-Moss wrote: >> On Tue, Dec 8, 2009 at 5:15 PM, Russell Keith-Magee >> wrote: >>> There's overlap, but it isn't necessarily a perfect match. >> >> Good points -- you've clearly thought this

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Wed, Dec 9, 2009 at 11:36 PM, Jacob Kaplan-Moss wrote: > On Tue, Dec 8, 2009 at 5:15 PM, Russell Keith-Magee > wrote: >> There's overlap, but it isn't necessarily a perfect match. > > Good points -- you've clearly thought this through farther than me. > Consider the wrench withdrawn :) You mi

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Tue, Dec 8, 2009 at 5:15 PM, Russell Keith-Magee wrote: > There's overlap, but it isn't necessarily a perfect match. Good points -- you've clearly thought this through farther than me. Consider the wrench withdrawn :) If you need another set of eyes on the code, I'm happy to give it a review

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Wed, Dec 9, 2009 at 12:55 AM, Jacob Kaplan-Moss wrote: > Hi Russ -- > > This is looking pretty great; I'm a big fan of this approach. I've > looked through the places I've needed to work around this problem with > serializers, and your fix would work in every case, so I think you > nailed it. >

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

Hi Russ -- This is looking pretty great; I'm a big fan of this approach. I've looked through the places I've needed to work around this problem with serializers, and your fix would work in every case, so I think you nailed it. I do, however, have one wrench to throw into the works: As it stands,

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 4, 2009 at 7:38 AM, Russell Keith-Magee wrote: > On Fri, Dec 4, 2009 at 7:03 AM, Luke Plant wrote: >> On Thursday 03 December 2009 15:33:44 Russell Keith-Magee wrote: >> >> How easy would it be to fix this? If you used a list of string values, >> instead of a single string, wouldn't a

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

ed a query into the serialization language, I've taken a >> >> step back and looked at the problem a different way. >> >> >> If there is some mechanism that can be used to look up instances of a >> >> model, then by definition, it must be a surrogate key of

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

look up instances of a > >> model, then by definition, it must be a surrogate key of some kind. > >> Completely independent of serialization, it would be nifty to be able > >> to perform lookups based on this surrogate key. > > >> So, lets add a convention f

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

anguage, I've taken a >> step back and looked at the problem a different way. >> >> If there is some mechanism that can be used to look up instances of a >> model, then by definition, it must be a surrogate key of some kind. >> Completely independent of serialization, it

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

f a > model, then by definition, it must be a surrogate key of some kind. > Completely independent of serialization, it would be nifty to be able > to perform lookups based on this surrogate key. > > So, lets add a convention for these methods. As an example, consider > contrib.

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 4, 2009 at 7:03 AM, Luke Plant wrote: > On Thursday 03 December 2009 15:33:44 Russell Keith-Magee wrote: > >> So, I've taken a different approach with this new patch. The new >> approach is much simpler and more explicit than the last. Rather >>  than trying to embed a query into the s

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Thursday 03 December 2009 15:33:44 Russell Keith-Magee wrote: > So, I've taken a different approach with this new patch. The new > approach is much simpler and more explicit than the last. Rather > than trying to embed a query into the serialization language, I've > taken a step back and look

#7052 - Fixing serialization for contrib.contenttypes and contrib.auth

lookups based on this surrogate key. So, lets add a convention for these methods. As an example, consider contrib.auth Permissions (models have been slightly simplified for demo purposes). class PermissionManager(models.Manager): def get_by_surrogate(self, key): codename, ct_key = key.s

Re: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass

Not intending to derail the test-skip angle (which sounds generally useful), but in this case, wouldn't a better fix be to eliminate the dependency on admin, by providing the needed templates in the auth test suite itself? PasswordResetTest could also duplicate the setup/ teardown methods used by

Re: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass

On Sep 7, 6:32 am, sciyoshi <[EMAIL PROTECTED]> wrote: > On Jul 19, 2:15 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > Not sure if this should be considered a related issue - theauthtests > use a different urlconf that only include theauthurls, so if you > provide custom registration

Re: Proposal: Decouple messages from contrib.auth

On Oct 29, 5:50 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote: > From the looks of it, the patch onhttp://code.djangoproject.com/ticket/4604 > is heading this direction > re: backwards compatible and part of contrib.sessions. > > Maybe SmileyChris can speak to both of these points and if it could be

Re: Proposal: Decouple messages from contrib.auth

On 10/28/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <[EMAIL PROTECTED]> wrote: > > I think decoupling messages from contrib.auth is a worthy step to > > making auth a little bit more reusable. > > Agreed

  1   2   >