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: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

>> One idea to mitigating this in Django core that I've considered would be >> introducing a '@csrf_defered' decorator > Practically speaking, I think this might be ok and would cover the > majority of real cases. But at the very least it means that this > decorator should live in

Re: Composite Key at Europython

On Fri, Mar 16, 2012 at 10:42, polo wrote: > Your project is stable ? that's the right question! no it isn't. As the docs said it is in a alpha release, I think is a good moment to create a first stable release but I'm waiting to release it as 1.0 when django 1.4 will be

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: Class based views: A standard hook for http-method-independent code

> I don't really see what difference another function makes. > Sayhttps://gist.github.com/1957251is implemented, what makes: > > def prepare_view(self, request, *args, **kwargs): >     # the thing I want to do >     super(ClassName, self).prepare_view(request, *args, **kwargs) > > preferable

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: Composite Key at Europython

Hi, Your project is stable ? Le 15/03/2012 13:02, Simone Federici a écrit : I'd like speak at europython about a project on composite primary and foreign key for Django. https://github.com/simone/django-compositekey This solution that I'm using on a very small realty. I've developed using

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: authentication by email

On Fri, Mar 16, 2012 at 10:05 AM, Carl Meyer wrote: [...] > I am not sure whether this should happen as a separate step or not. In > an ideal world, we would have a longer username field. In the real > world, we have to balance the benefit against the cost, and requiring a >

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

auth.User refactor: reboot

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

Sporadic proxy deletion failures on mysql

Hello all, When running regressiontests.delete_regress.tests.ProxyDeleteTest and regressiontests.delete_regress.tests.ProxyOfProxyDeleteTest on mysql, sporadic IntegrityErrors would occur. This was caused by the proxy model's base model not having the proxy model as a dependency, and the sporadic

Ticket 16317 https://code.djangoproject.com/ticket/16317

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

Re: Composite Key at Europython

On Fri, Mar 16, 2012 at 13:54, Michal Petrucha wrote: > Unfortunately, currently I'm busy until Thursday; afterwards I'll try to > find out whether it would be possible for me to attend. If you need my > assistance before Sunday, unfortunately, I'm afraid I'll be of little

Re: Composite Key at Europython

On Fri, Mar 16, 2012 at 13:59, Jacob Kaplan-Moss wrote: > The DSF has some funds set aside for precisely this purpose (getting > developers in rooms together). If getting you to europython to hack with > Simone helps make CPKs happen, I think you're a perfect candidate for a

Re: authentication by email

On Thu, Mar 15, 2012 at 4:49 PM, Carl Meyer wrote: > Hi Daniel, > > On 03/15/2012 09:24 AM, Daniel Sokolowski wrote: >> Why can we not just increase the length limit on the username field?, >> Why can't we just throw a validation error if data entered is to long >> and the

Re: Composite Key at Europython

On Friday, March 16, 2012 at 7:54 AM, Michal Petrucha wrote: > I'll consider attending, there's a possibility I might get some > support from my university; in that case I'm in, otherwise I'll have > to explore other options. > > The DSF has some funds set aside for precisely this purpose

Re: Composite Key at Europython

On Thu, Mar 15, 2012 at 01:02:24PM +0100, Simone Federici wrote: > I'd like speak at europython about a project on composite primary and > foreign key for Django. > > https://github.com/simone/django-compositekey > > This solution that I'm using on a very small realty. I've developed using >