Re: logialogin_required does not check User.is_active

[Russell Keith-Magee]

On Thu, Apr 15, 2010 at 11:20 PM, subs...@gmail.com  wrote:
> Thanks for breaking it down.
>
> On Mar 17, 7:45 am, Russell Keith-Magee 
> wrote:
>
>>  1) Don't touch the code. It's an annoying edge case, but it can be
>> caught by shortening session timeouts and making more use of
>> permissions. However, we should document the edge case with
>> login_required, as it is certainly contrary to obvious usage.
>
> This isn't appropriate in situations where HR wants to do a hard cut-
> off of a user's access, in the event they are terminated.
>
>>  2) Add a specific "requires_active_user" decorator (and maybe a
>> decorator that combines the login_required and requires_active_user
>> check)
>
> Eh.
>
>>  3) Allow login_required to take an argument that customizes the
>> 'active' check. However, the default value for this argument would
>> need to be equivalent to the current behaviour; once you start down
>> this path, there really isn't much difference between a call to
>> login_required with an 'is_active' argument, and a call to
>> user_passes_test that does the authentication and active check.
>
> Seems strange: "I want a user to be authenticated to use this view,
> but I don't care if they're active." I'm not sure I agree that the
> default should be the current behavior. I think in most cases this is
> an oversight that most programmers simply don't account for in their
> code--and closing this hatch is a favor and not an incompatibility
> issue. Could be wrong.

As I indicated previously in this thread, there are two use cases that
need to be handled:

 1) Normal Django authentication, honoring the is_active flag. For
this use case, you are completely correct - the current behavior is
wrong.

 2) Custom authentication backends that *don't* honor the is_active
flag. This is entirely legal, and documented as such.

Unfortunately, the simple solution (add an is_active check to the
login_required decorator) is a completely valid and reasonable
solution for (1), but breaks (2). That's the sticking point.

>>  4) Work out if there is a way to refactor the login process so that
>> the decision of whether is_active is checked is deferred. I don't have
>> any great ideas how this could be done, though.
>
> Would it be too ugly or simplistic to have a callable
> Backend.is_active() which these backends could manipulate to their
> liking? Its flexible in the same way as get_profile(). Also, is it
> possible we're expecting too much perfection given that, as you say,
> there are legitimate proposals to refactor auth.User either way? (and
> present solutions are more or less trivial).

In principle, this sounds like the right approach. However, there are
a few implementation kinks:

 1) Backends aren't required to subclass a common base class, so we
have to assume that there will be custom backends out there that
*wont'* have an is_active check, even if we add one to ModelBackend.
This isn't a huge problem - we can work around it with a hasattr check
- but it's worth noting as something that will need to be addressed.

 2) How do you get access to the right authentication backend in the
login_required decorator? The only argument you are guaranteed to have
access to is user, and the user doesn't (currently) have a way to get
access to the backend on which they were authenticated.

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-develop...@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: High Level Discussion about the Future of Django

[skylar . saveland]

+1 I would love to join in with some liberal, even wild-eyed experimentation on 
github.  I have all sorts of cock-eyed ideas that I would like to play with.

I don't like patches; I don't like svn; I'm not a fan of trac.  I do however 
enjoy the fact that Django trunk leans toward being boring and stable.

Make a hostile fork.  If it turns out to be awesome and stable and tested and 
so on .. then awesome..

Not sure why it has to be "hostile".  But, depending on the project, I could 
definitely see advantages to giving up on some of the backward compatibility 
overhead.

Cheap branches with git I think could be a great way for community members like 
myself to get their feet wet without the overhead and constraints of the full 
contributing process.
sent from my baz foone

-Original Message-
From: "Tom X. Tobin" 
Date: Thu, 15 Apr 2010 14:38:01 
To: 
Subject: Re: High Level Discussion about the Future of Django

On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
 wrote:
> "You seem to be suggesting that a fork will somehow magically fix the
> speed of Django development. I ask you: who is going to work on this
> fork?"
>
> I think a hostile fork is almost a certain outcome if development
> continues as it has.  Not only is the resistance to make backwards
> incompatible changes in future releases a bad policy for the quality
> of the framework, but the behavior in trac has a negative effect on
> community contributions.
[...]
> Personally I believe my time might be better spent developing a fork,
> than arguing over clear flaws in architecture decisions that "can't be
> changed".

Django is BSD licensed; no one is going to stop someone from making a
fork if they want to.  That no one has done so is, IMHO, a good sign
that the Django codebase and development process is considered solid
by the community.

Solid, of course, can sometimes be boring.  :-)  There's nothing wrong
with public experimentation; why not push a Django branch up on GitHub
with some features you find interesting?  You don't have to "fork" in
order to develop your own branch; we've been maintaining an internal
branch of Django at The Onion for a couple of years now, but we still
track upstream aggressively.  Sometimes I wonder if a long-running
experimental playground branch (or branches) on GitHub would be a
healthy way to direct some of the energy and interest in less
conservative changes; as pieces matured there, they could be
considered for the mainstream trunk, and trunk would in turn remain
nice and stable.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Django Newbie seeking for advice

[jmswen]

As has been mentioned, you should direct questions about using Django
to the django-users mailing list.  You can subscribe to django-users
at the top-right of this page: http://www.djangoproject.com/community/.

But, just to answer your question, this is a good place to start on
Django 1.0 (I know you wanted 1.1, but the two versions are very
similar).  http://www.djangobook.com/

The Django documentation (http://docs.djangoproject.com/en/1.1/) is
the source of truth on v1.1.1, and usually contains great examples.
Also, try out the tutorial at that link.

Try asking questions 2-5 on the django-users mailing list.

Cheers,
Jon

On Apr 12, 12:04 pm, Mister Yu  wrote:
> Hi experts,
>
> i m a newbie and i m self learning django and writing an web app as i
> go along. i learn django by following this great screencast tutorial
> from here:http://showmedo.com/videotutorials/series?name=PPN7NA155
> called Django From the Ground-up.
>
> it's a really great serious of tutorial. however it doesn't cover what
> i/everybody else' need. so i come here for some advice from you
> experts:
>
> 1. can you suggest an up-to-date(django 1.1) book which can guide a
> newbie to a higher level? ebook is ok, free is more than ok  :)
>
> best practice for the following things under django 1.1, (i tried
> google, but some of the material might not fit for 1.1 anymore), you
> can just name a library or which built-in module is best.
> 2. tags
> 3. open-id
> 4. user avatar
> 5. ajax form
>
> thanks very much in advance for any kind of advice.
>
> Cheers!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Pass Thru Image Proxy Patch Interest?

[SmileyChris]

Yes, I was thinking the other day that it would be a cool solution for
serve() to be able to use storage backends

On Apr 16, 7:09 am, Kevin Howerton  wrote:
> Why not just use the backend feature that already exists?
>
> I have an S3 backend that does this...
>
> It checks if it's on S3, if not it serves it locally.  If it's on S3
> it throws the url into memcache, and bob is your uncle.
>
> On Wed, Apr 14, 2010 at 9:27 AM, Russell Keith-Magee
>
>  wrote:
> > On Wed, Apr 14, 2010 at 8:58 PM, Ed Menendez  wrote:
> >> Agree on avoiding additional setting.
>
> >> Re: cache
> >> Basically if the file is not found locally then it goes out to the URL
> >> to get it. So a local file couldn't be overwritten as that's the first
> >> thing it checks. Cache is currently an option to the view too. Which
> >> should be documented so it can be turned off if disk space is limited
> >> locally.
>
> > Ok. We can work through details once we're in the new feature
> > discussion phase for 1.3.
>
> >> Re: 1.2
> >> No problem. Should I not even open a ticket with the patch until after
> >> or is it OK to do now?
>
> > Feel free to open a ticket now, just don't put it on the 1.2 milestone.
>
> > 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-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django

[Tom X. Tobin]

On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
 wrote:
> "You seem to be suggesting that a fork will somehow magically fix the
> speed of Django development. I ask you: who is going to work on this
> fork?"
>
> I think a hostile fork is almost a certain outcome if development
> continues as it has.  Not only is the resistance to make backwards
> incompatible changes in future releases a bad policy for the quality
> of the framework, but the behavior in trac has a negative effect on
> community contributions.
[...]
> Personally I believe my time might be better spent developing a fork,
> than arguing over clear flaws in architecture decisions that "can't be
> changed".

Django is BSD licensed; no one is going to stop someone from making a
fork if they want to.  That no one has done so is, IMHO, a good sign
that the Django codebase and development process is considered solid
by the community.

Solid, of course, can sometimes be boring.  :-)  There's nothing wrong
with public experimentation; why not push a Django branch up on GitHub
with some features you find interesting?  You don't have to "fork" in
order to develop your own branch; we've been maintaining an internal
branch of Django at The Onion for a couple of years now, but we still
track upstream aggressively.  Sometimes I wonder if a long-running
experimental playground branch (or branches) on GitHub would be a
healthy way to direct some of the energy and interest in less
conservative changes; as pieces matured there, they could be
considered for the mainstream trunk, and trunk would in turn remain
nice and stable.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django

[Kevin Howerton]

"That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc."

1.1 and 1.2 are by definition not point releases.  Point releases
don't introduce new features.

On Thu, Apr 15, 2010 at 3:32 PM, Jacob Kaplan-Moss  wrote:
> On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
>  wrote:
>> The level of resistance I see to change or outsider code contribution
>> is an enormous de-motivator for people (like me) to want to make any
>> contributions in the first place.  Why should I contribute a patch to
>> your flawed architecture if I'm going to be talked down to, ridiculed,
>> then eventually have the patch rejected because it breaks code in some
>> edge-use-case?
>
> I'm sorry that you've felt ridiculed or talked down to. I can promise
> you that wasn't the intent. To satiate my own curiosity, and to help
> me not make similar mistakes, could you point me to where that's
> happened?
>
>> It's a good idea to avoid breaking backwards compatibility in point
>> releases, but as far as major releases go ... I whole heartedly
>> encourage it.
>
> That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc.
>
>> Personally I believe my time might be better spent developing a fork,
>> than arguing over clear flaws in architecture decisions that "can't be
>> changed".
>
> This is open source, and that's your prerogative. If you want to start
> a fork, do. I hope you'll consider contributing back to the trunk, but
> that's up to you.
>
> For better or worse, we've chosen a development policy that
> prioritizes stability, maturity, and longevity. If those aren't your
> priorities, then perhaps a fork is the right answer.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django

[Jacob Kaplan-Moss]

On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
 wrote:
> The level of resistance I see to change or outsider code contribution
> is an enormous de-motivator for people (like me) to want to make any
> contributions in the first place.  Why should I contribute a patch to
> your flawed architecture if I'm going to be talked down to, ridiculed,
> then eventually have the patch rejected because it breaks code in some
> edge-use-case?

I'm sorry that you've felt ridiculed or talked down to. I can promise
you that wasn't the intent. To satiate my own curiosity, and to help
me not make similar mistakes, could you point me to where that's
happened?

> It's a good idea to avoid breaking backwards compatibility in point
> releases, but as far as major releases go ... I whole heartedly
> encourage it.

That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc.

> Personally I believe my time might be better spent developing a fork,
> than arguing over clear flaws in architecture decisions that "can't be
> changed".

This is open source, and that's your prerogative. If you want to start
a fork, do. I hope you'll consider contributing back to the trunk, but
that's up to you.

For better or worse, we've chosen a development policy that
prioritizes stability, maturity, and longevity. If those aren't your
priorities, then perhaps a fork is the right answer.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Pass Thru Image Proxy Patch Interest?

[Kevin Howerton]

Why not just use the backend feature that already exists?

I have an S3 backend that does this...

It checks if it's on S3, if not it serves it locally.  If it's on S3
it throws the url into memcache, and bob is your uncle.

On Wed, Apr 14, 2010 at 9:27 AM, Russell Keith-Magee
 wrote:
> On Wed, Apr 14, 2010 at 8:58 PM, Ed Menendez  wrote:
>> Agree on avoiding additional setting.
>>
>> Re: cache
>> Basically if the file is not found locally then it goes out to the URL
>> to get it. So a local file couldn't be overwritten as that's the first
>> thing it checks. Cache is currently an option to the view too. Which
>> should be documented so it can be turned off if disk space is limited
>> locally.
>
> Ok. We can work through details once we're in the new feature
> discussion phase for 1.3.
>
>> Re: 1.2
>> No problem. Should I not even open a ticket with the patch until after
>> or is it OK to do now?
>
> Feel free to open a ticket now, just don't put it on the 1.2 milestone.
>
> 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-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django

[Kevin Howerton]

"You seem to be suggesting that a fork will somehow magically fix the
speed of Django development. I ask you: who is going to work on this
fork?"

I think a hostile fork is almost a certain outcome if development
continues as it has.  Not only is the resistance to make backwards
incompatible changes in future releases a bad policy for the quality
of the framework, but the behavior in trac has a negative effect on
community contributions.

The level of resistance I see to change or outsider code contribution
is an enormous de-motivator for people (like me) to want to make any
contributions in the first place.  Why should I contribute a patch to
your flawed architecture if I'm going to be talked down to, ridiculed,
then eventually have the patch rejected because it breaks code in some
edge-use-case?

Personally I believe my time might be better spent developing a fork,
than arguing over clear flaws in architecture decisions that "can't be
changed".

It's a good idea to avoid breaking backwards compatibility in point
releases, but as far as major releases go ... I whole heartedly
encourage it.  If keeping backwards compatibility was a good idea, my
macbook pro would have a 5.12" floppy drive, a 3.25" drive, a jazz
drive, it would accept serial and adb plugs and maybe have a
display mode to emulate those green crt monitors of yore.

Good software is about removing flaws, improving the architecture, and
learning from past mistakes.  If this comes at a price, then pay.

-k

On Wed, Apr 14, 2010 at 9:25 AM, Russell Keith-Magee
 wrote:
> On Wed, Apr 14, 2010 at 8:34 PM, veena  wrote:
>
>> I know there's django deprecation policy nicely documented
>> http://docs.djangoproject.com/en/1.1/internals/release-process/#internal-release-deprecation-policy
>>
>> But what I don't know is how you discover it. Is it described
>> somewhere in the text or the video from conference? What were the
>> reasons to have this deprecation policy? Was there any user research?
>> Research of when the django users upgrade, what are the main problems
>> of upgrades and how they imagine upgrading should work?
>
> The policy was arrived at after a debate between the core team, based
> on how the core team believe a well-behaved project should behave. For
> the record, it wasn't much of a debate, either - we were all pretty
> much in agreement on the core points from the beginning.
>
> In the opinion of the core, well-behaved projects don't require
> massive rewrites (or worse - subtle bug chasing efforts) every time a
> new release is made. Developers using a library should have the
> confidence to know that when they write code, it will continue to work
> for a long time, not just until the core developers have a change of
> heart.
>
> I would suggest to you that one of the reasons for Django's success
> has been it's policy on backwards compatibility.
>
>> What I try to say is that I'm little bit afraid that it seems like
>> improvements of django will take years instead of months.
> ...
>> I think this could lead to fork the django by some devs
>> and rapid development of this fork
>
> You seem to be suggesting that a fork will somehow magically fix the
> speed of Django development. I ask you: who is going to work on this
> fork?
>
> Progress on Django may be slower than many would like, but it's not
> slow because we're hampered by backwards compatibility. It's because
> the core team all have full time jobs, families and friends, and we
> contribute to Django in our spare time. If you want to fix the speed
> of development, pitch in.
>
> 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-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: logialogin_required does not check User.is_active

[Andy McCurdy]

On Thu, Apr 15, 2010 at 9:50 AM, Harro  wrote:

> I think the problem isn't the login_required, but it simply does what
> it says it does: Check if the user is logged in.
>
> For me a user with is_active set to false shouldn't be allowed to
> login, they either just created an account and still need to verify it
> or they indicated that they wanted their account "removed", in which
> case it's marked inactive so it doesn't cascade delete all their
> related items too.
>

Or the third case, when a staff user de-activates the user for some reason.
 In this scenario, the user is still logged in, and simply using
@login_required will continue to allow the user to access resources that are
meant to be restricted.

To correct this behavior, we've subclassed the Authentication middleware and
the LazyUser object it sets on the request.  Our LazyUser ensures the user
is active, otherwise it creates an AnonymousUser instance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: logialogin_required does not check User.is_active

[Harro]

I think the problem isn't the login_required, but it simply does what
it says it does: Check if the user is logged in.

For me a user with is_active set to false shouldn't be allowed to
login, they either just created an account and still need to verify it
or they indicated that they wanted their account "removed", in which
case it's marked inactive so it doesn't cascade delete all their
related items too.

As the login view and the authentication middleware both use the
backend to get the user, this is is the place to implement the check
or not.

Which isn't that hard, the quick fix is to simply point out that the
is_active doesn't check this and if people want this they should
simply extend the ModelBackend's authenticate and get_user functions
and add the checks there.




On Apr 15, 5:20 pm, "subs...@gmail.com"  wrote:
> Thanks for breaking it down.
>
> On Mar 17, 7:45 am, Russell Keith-Magee 
> wrote:
>
> >  1) Don't touch the code. It's an annoying edge case, but it can be
> > caught by shortening session timeouts and making more use of
> > permissions. However, we should document the edge case with
> > login_required, as it is certainly contrary to obvious usage.
>
> This isn't appropriate in situations where HR wants to do a hard cut-
> off of a user's access, in the event they are terminated.
>
> >  2) Add a specific "requires_active_user" decorator (and maybe a
> > decorator that combines the login_required and requires_active_user
> > check)
>
> Eh.
>
> >  3) Allow login_required to take an argument that customizes the
> > 'active' check. However, the default value for this argument would
> > need to be equivalent to the current behaviour; once you start down
> > this path, there really isn't much difference between a call to
> > login_required with an 'is_active' argument, and a call to
> > user_passes_test that does the authentication and active check.
>
> Seems strange: "I want a user to be authenticated to use this view,
> but I don't care if they're active." I'm not sure I agree that the
> default should be the current behavior. I think in most cases this is
> an oversight that most programmers simply don't account for in their
> code--and closing this hatch is a favor and not an incompatibility
> issue. Could be wrong.
>
> >  4) Work out if there is a way to refactor the login process so that
> > the decision of whether is_active is checked is deferred. I don't have
> > any great ideas how this could be done, though.
>
> Would it be too ugly or simplistic to have a callable
> Backend.is_active() which these backends could manipulate to their
> liking? Its flexible in the same way as get_profile(). Also, is it
> possible we're expecting too much perfection given that, as you say,
> there are legitimate proposals to refactor auth.User either way? (and
> present solutions are more or less trivial).
>
> -Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: logialogin_required does not check User.is_active

[subs...@gmail.com]

Thanks for breaking it down.

On Mar 17, 7:45 am, Russell Keith-Magee 
wrote:

>  1) Don't touch the code. It's an annoying edge case, but it can be
> caught by shortening session timeouts and making more use of
> permissions. However, we should document the edge case with
> login_required, as it is certainly contrary to obvious usage.

This isn't appropriate in situations where HR wants to do a hard cut-
off of a user's access, in the event they are terminated.

>  2) Add a specific "requires_active_user" decorator (and maybe a
> decorator that combines the login_required and requires_active_user
> check)

Eh.

>  3) Allow login_required to take an argument that customizes the
> 'active' check. However, the default value for this argument would
> need to be equivalent to the current behaviour; once you start down
> this path, there really isn't much difference between a call to
> login_required with an 'is_active' argument, and a call to
> user_passes_test that does the authentication and active check.

Seems strange: "I want a user to be authenticated to use this view,
but I don't care if they're active." I'm not sure I agree that the
default should be the current behavior. I think in most cases this is
an oversight that most programmers simply don't account for in their
code--and closing this hatch is a favor and not an incompatibility
issue. Could be wrong.

>  4) Work out if there is a way to refactor the login process so that
> the decision of whether is_active is checked is deferred. I don't have
> any great ideas how this could be done, though.

Would it be too ugly or simplistic to have a callable
Backend.is_active() which these backends could manipulate to their
liking? Its flexible in the same way as get_profile(). Also, is it
possible we're expecting too much perfection given that, as you say,
there are legitimate proposals to refactor auth.User either way? (and
present solutions are more or less trivial).

-Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Security hole with authenticated sessions

[Russell Keith-Magee]

On Thu, Apr 15, 2010 at 10:51 PM, subs...@gmail.com  wrote:
> Please note I've already consulted secur...@djangoproject.com about
> this and Jacob told me to post it here if I wanted to.
>
> One problem with authenticated sessions is that, upon de-activation of
> a user's account, any sessions that user has remain live until they
> logout.
>
> I think it would be a good idea to add a middleware to auth which
> checked is_active and, if it was found to be False, redirected the
> user to the logout url. Indeed it may look something like this:
> http://dpaste.com/184192/

This came up about a month ago (search django dev for the subject
"logialogin_required does not check User.is_active"). It resulted in
ticket #13125.

Yours,
Russ Magee %-)

> -Steve
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Security hole with authenticated sessions

[subs...@gmail.com]

Oh, and I apologize for the racy subject line =)

On Apr 15, 10:51 am, "subs...@gmail.com"  wrote:
> Please note I've already consulted secur...@djangoproject.com about
> this and Jacob told me to post it here if I wanted to.
>
> One problem with authenticated sessions is that, upon de-activation of
> a user's account, any sessions that user has remain live until they
> logout.
>
> I think it would be a good idea to add a middleware to auth which
> checked is_active and, if it was found to be False, redirected the
> user to the logout url. Indeed it may look something like 
> this:http://dpaste.com/184192/
>
> -Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Security hole with authenticated sessions

[subs...@gmail.com]

Please note I've already consulted secur...@djangoproject.com about
this and Jacob told me to post it here if I wanted to.

One problem with authenticated sessions is that, upon de-activation of
a user's account, any sessions that user has remain live until they
logout.

I think it would be a good idea to add a middleware to auth which
checked is_active and, if it was found to be False, redirected the
user to the logout url. Indeed it may look something like this:
http://dpaste.com/184192/

-Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.