Re: Porting _django_bash_completion to Windows Powershell

[Arthur Koziel]

On Mar 17, 2010, at 3:35 PM, guillermooo wrote:

> autocomplete() is executed always, regardless whether the user has
> requested completions or not. The only early exit point of
> autocomplete() is reached if DJANGO_AUTO_COMPLETE is false. Otherwise,
> sys.exit(1) returns to the console. How is this avoided when you do
> something like `manage.py sqlall`? Is the variable
> DJANGO_AUTO_COMPLETE implicitly unset after each execution of the
> completion bash script?

36 COMPREPLY=( $( COMP_WORDS="${COMP_WORDS[*]}" \
37COMP_CWORD=$COMP_CWORD \
38DJANGO_AUTO_COMPLETE=1 $1 ) )

The Python function is executed in a Bash subshell (that's what the outer round 
braces are for). COMP_WORDS/COMP_CWORD and DJANGO_AUTO_COMPLETE are local 
variables and available only within this subshell.

Arthur

-- 
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: Regarding httponly cookies

[Dennis Kaarsemaker]

On wo, 2010-03-17 at 11:10 -0700, Yuchen Zhou wrote:

> So does this ticket mean django now supports httponly cookies? And is
> it by default httponly?
> Or the application administrator has to turn it on?

The discussion on http://code.djangoproject.com/ticket/3304 indicates
that neither python nor django at the moment support it and that django
will need to implement its own cookie handling if it wants to continue
supporting python versions as old as 2.4.

There are patches attached to the issue, but none of those have been
applied to django yet.

-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
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: Regarding httponly cookies

[Yuchen Zhou]

Hi,

Thanks for your response!

So does this ticket mean django now supports httponly cookies? And is
it by default httponly?
Or the application administrator has to turn it on?

Best,

On Mar 17, 11:49 am, Tom Evans  wrote:
> On Wed, Mar 17, 2010 at 3:42 PM, Yuchen Zhou  wrote:
> > Hi,
>
> > I'm a security researcher at the University of Virginia I have been
> > looking into the use and adoption of http-only cookies. My advisor is
> > professor David Evans.
>
> > We were surprised to discover that Django does not explicitly supports
> > httponly cookie field. I have searched for some solution but they all
> > require patching to python or Django. I think if the client side JS
> > does not need to access cookie value, which is true at least for
> > authentication tokens, we should set that cookie httponly in order to
> > prevent cookie stealing against cross-site scripting attacks.
>
> > Is there any other good reason that django is not supporting this
> > feature? Are we missing something here?
>
> > Thank you very much.
>
> > Best,
>
> > --Yuchen
> > yz...@virginia.edu
> > Graduate student at Computer Science Dept.
> > University of Virginia
>
> Seehttp://code.djangoproject.com/ticket/3304
>
> Cheers
>
> Tom- Hide quoted text -
>
> - Show quoted text -

-- 
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: Regarding httponly cookies

[Tom Evans]

On Wed, Mar 17, 2010 at 3:42 PM, Yuchen Zhou  wrote:
> Hi,
>
> I'm a security researcher at the University of Virginia I have been
> looking into the use and adoption of http-only cookies. My advisor is
> professor David Evans.
>
> We were surprised to discover that Django does not explicitly supports
> httponly cookie field. I have searched for some solution but they all
> require patching to python or Django. I think if the client side JS
> does not need to access cookie value, which is true at least for
> authentication tokens, we should set that cookie httponly in order to
> prevent cookie stealing against cross-site scripting attacks.
>
> Is there any other good reason that django is not supporting this
> feature? Are we missing something here?
>
> Thank you very much.
>
> Best,
>
> --Yuchen
> yz...@virginia.edu
> Graduate student at Computer Science Dept.
> University of Virginia
>

See http://code.djangoproject.com/ticket/3304

Cheers

Tom

-- 
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.

Regarding httponly cookies

[Yuchen Zhou]

Hi,

I'm a security researcher at the University of Virginia I have been
looking into the use and adoption of http-only cookies. My advisor is
professor David Evans.

We were surprised to discover that Django does not explicitly supports
httponly cookie field. I have searched for some solution but they all
require patching to python or Django. I think if the client side JS
does not need to access cookie value, which is true at least for
authentication tokens, we should set that cookie httponly in order to
prevent cookie stealing against cross-site scripting attacks.

Is there any other good reason that django is not supporting this
feature? Are we missing something here?

Thank you very much.

Best,

--Yuchen
yz...@virginia.edu
Graduate student at Computer Science Dept.
University of Virginia

-- 
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: Model validation outside of ModelForms.

[orokusaki]

Thanks James,

I'll focus on this here and see what I can come up with.


Michael

-- 
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

[mattd]

i need to think more about russell's points before responding in full,
but i did want to briefly mention the following:

1. simply shortening the length of sessions doesn't prevent a user
with revoked access from seeing new and potentially sensitive data
created after the user's deactivation. if deleting the user is not an
option (wasn't in my case), the only choice you have to force them out
(afaik) is to wipe the sessions table.
2. maybe this is just me, but if i'm *only* checking a binary "active"
flag, i'd rather not involve permissions/has_perm.

the path of least resistance would appear to be using
"user_passes_test", and perhaps packaging
"active_login_required" (named as you see fit) with django. this ties
usage directly to django's out-of-box auth (most likely used by the
majority of users), but if you're already using a custom auth backend,
it shouldn't be a deal breaker to write your own version.


thx,
matt

-- 
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: Porting _django_bash_completion to Windows Powershell

[guillermooo]

>Internally, the autocompletion is done using the
> ManagementUtility.autocomplete() method, line 264 of
> django/core/management/__init__.py.

I've taken a look the code, but there a few details that I don't
understand.

autocomplete() is executed always, regardless whether the user has
requested completions or not. The only early exit point of
autocomplete() is reached if DJANGO_AUTO_COMPLETE is false. Otherwise,
sys.exit(1) returns to the console. How is this avoided when you do
something like `manage.py sqlall`? Is the variable
DJANGO_AUTO_COMPLETE implicitly unset after each execution of the
completion bash script?

Cheers,
Guillermo

-- 
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

[Russell Keith-Magee]

On Wed, Mar 17, 2010 at 3:46 PM, Russell Keith-Magee
 wrote:
> On Wed, Mar 17, 2010 at 4:53 AM, Sean Brant  wrote:
>> A co-worker of mine noticed this bug today 
>> http://code.djangoproject.com/ticket/13125.
>> Should it be marked for 1.2 or punt it until after the release
>> candidate? It looks to be a bug so it could probably go in at anytime.
>> Let me know your thoughts.
>
> I've just marked the ticket accepted. It isn't 1.2 critical, since the
> currently behavior has existed since pretty much the beginning of
> time, but it does strike me as an edge case that is worth catching.
>
> The patch also requires some minor tweaks before it is trunk-ready;
> comments on the patch.

Looking at the problem a bit more, this isn't as simple as I first thought.

As the docs note, authentication backends aren't required to check
is_active. The background here is that authentication is separate from
granting permission. The authentication process validates that a
person are who they say they are. This is independent of determining
if that person is actually allowed to access the site. is_active is
the most basic way to check if a user is allowed to visit a site. The
role played by is_active could be completely replaced by a set of
permissions, for example.

Of course, the hiccough here is that Django's own authentication form
-- which probably represents the vast majority of auth.User installs
-- *does* validate is_active as part of the login process, which
causes the edge case failure where a logged in user is marked
inactive.

I suppose the root cause here is that login_required is badly named -
it's actually that the user requesting a view is authenticated, not
performing a login confirmation.

I'm no longer convinced that the solution is as simple as adding an
is_active check. This will break any login scheme that isn't using
is_active, which is specifically documented as an allowed use case.

Some possible (not necessarily mutually exclusive) solutions:

 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.

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

 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.

 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.

I'm open to any other suggestions.

There is also some crossover with #3011, the proposal to refactor
auth.User. If we're going to allow pluggable or configurable user
models, we'll need to come to some understanding of how the login
process is supposed to interact with is_active (as well as other User
flags).

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: logialogin_required does not check User.is_active

[Giuseppe Ciotta]

On Wed, Mar 17, 2010 at 8:54 AM, Russell Keith-Magee
 wrote:
>
> In the interim, there are two other ways you could limit your exposure
> to this problem (other than the obvious "write your own
> login_required" check):
>
>  * Use a permissions check in addition to the login_required check --
> as noted it the docs, has_perm() will check the is_active status.
>
>  * Use a short-lived session (say, 24 hours). If a user has to log in
> every 24 hours, the is_active check will be re-evaluated every 24
> hours.

Also, a middleware which checks for user.is_active and calls
logout(request) looks fine in the short term, look at
http://www.djangosnippets.org/snippets/1105/

-- 
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: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

[Chris]

On Mar 15, 10:44 am, Yuri Baburov  wrote:
> Hello all,
>
> How do you like the following idea:
> startproject command puts a fixture for django.contrib.sites (and
> fixture for superuser probably) to the root folder or whatever, to be
> loaded with syncdb?
> That way also encourage users to get more familiar with fixtures.
> Of course it's too far for 1.2, so it can be implemented with 1.3 timeline.

This I like.

I also like the idea of sites prompting the user for a domain when
syncdb creates the contrib.sites tables.

Or maybe have the sites framework not add an 'example.com' entry on
creation by default and let the system raise an exception when it
tries to get the current site to remind the developer to add a site
object. Or maybe instead of raising an exception, have it try to get
SITE_URL from your settings.

I once accidentally had for a few days my sitemaps all pointing to
example.com because I forgot to change the url after a database purge.
Ouch.

Me honestly, I've never really liked the sites framework very much. I
don't *hate* it, but it's always been something that got in my way
more than it's granted me much convenience. The thing that bothers me
is how the overwhelming majority of sites (I'm assuming) have no use
for a sites framework, yet django kind of 'forces' you to use it for a
lot of functionality. For instance, the syndication framework,
sitemaps, the 'view on site' link in the admin interface, etc...

-- 
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

[Russell Keith-Magee]

On Wed, Mar 17, 2010 at 6:30 AM, mattd  wrote:
> interesting. i'm using the django-provided login form from 1.1,
> waiting for 1.2 to be released before using it.
>
> here's an example of my point: you run an internal tool for staff to
> discuss the topics of the day. a few staff are let go or otherwise
> deemed ineligible, and their access is revoked. so, you deactivate
> their accounts in the lovely django admin, but then find that they are
> still using the site. now, deactivating them doesn't log them out, and
> that's to be expected since contrib.sessions is wisely decoupled from
> contrib.auth. but, you thought you'd protected your views with
> "login_required", but it turns out "login_required" only makes sure
> that the user is currently logged in, riding on the assumption that
> their status would not change in the duration of their session.
>
> to me, it seems like an oversight. definitely interested in others'
> opinions.

Agreed that it is an oversight that should be fixed.

In the interim, there are two other ways you could limit your exposure
to this problem (other than the obvious "write your own
login_required" check):

 * Use a permissions check in addition to the login_required check --
as noted it the docs, has_perm() will check the is_active status.

 * Use a short-lived session (say, 24 hours). If a user has to log in
every 24 hours, the is_active check will be re-evaluated every 24
hours.

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: logialogin_required does not check User.is_active

[Russell Keith-Magee]

On Wed, Mar 17, 2010 at 4:53 AM, Sean Brant  wrote:
> A co-worker of mine noticed this bug today 
> http://code.djangoproject.com/ticket/13125.
> Should it be marked for 1.2 or punt it until after the release
> candidate? It looks to be a bug so it could probably go in at anytime.
> Let me know your thoughts.

I've just marked the ticket accepted. It isn't 1.2 critical, since the
currently behavior has existed since pretty much the beginning of
time, but it does strike me as an edge case that is worth catching.

The patch also requires some minor tweaks before it is trunk-ready;
comments on the patch.

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: Model validation outside of ModelForms.

[James Bennett]

On Thu, Jan 21, 2010 at 1:28 PM, Gerry  wrote:
> without using ModelForms? I really like the new Model validation but I
> don't
> like (nor think its very DRY) to override the save method for all of
> my models
> to just call full_clean(). It would be nice if there was someway I
> could enable
> validation by default.

The problem with this is that it can't really be generalized. One of
the reasons why ModelForm has the implementation it does is that often
you have a form which doesn't contain all the fields from the model,
or a view which uses the form for initial validation, then does
further work before finally saving a complete, valid object.

Similarly, being at the stage of calling save() doesn't necessarily
mean that the object is complete and valid; one common example is
default values, which won't yet be filled in when your custom save()
method tries to validate the object, resulting in a validation failure
even though the object *would* be valid by the time it hit the
database.

Developing an "automatic" validation option which is both simple
enough to actually be useful and robust enough to handle all the edge
cases is -- if it's even possible -- far more than can be accomplished
on the 1.2 timeframe. Hence, for now, Django doesn't have any such
thing, and won't have it in 1.2. If you think you can make it work for
1.3, your best bet is to work up a proposal, including at least some
sample code, along with an explanation of how you'll keep it both
simple and robust.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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: Model validation outside of ModelForms.

[James Bennett]

On Wed, Mar 17, 2010 at 1:00 AM, orokusaki  wrote:
> Actually I'm not lying. Russell hasn't given me any feedback regarding
> my idea or patch. I didn't simply reopen tickets. Russell changed my
> ticket to a documentation ticket, so I opened a new ticket to discuss
> that which he avoided in his discussion.

As you've been told now, multiple times:

Discussion of feature design and other high-level work does not take
place in Trac. Trac is good at organizing bugs and keeping tabs on
patches and status, but absolutely terrible at that sort of high-level
discussion. Thus, such discussion takes place here, on a mailing list
well-suited to the task. This is not "ego-driven closed mindedness",
this is simple practicality; it's the way things have to work in order
for them to work at all. And it's incredibly easy to do; in the time
you've spent opening and reclassifying tickets to try to get what you
want, you could've accomplished your stated goal -- getting discussion
and feedback on your proposal -- a dozen times over. Instead all
you've done is waste developer time and annoy people.

And just by way of official warning: if you decide to ignore this and
just continue on as you have been, you may leave the dev team with no
choice but to show you the door. We're short enough on developer time
already, and we can't afford to stop and go over basic things like
this multiple times (let alone doing so while you sit back and sling
insults at us).


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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: Model validation outside of ModelForms.

[orokusaki]

On Mar 16, 10:16 am, Harro  wrote:
> Just my brainfart when looking at this: Can't you simply add a pre
> save signal to call the full clean method?
>
> Dunno if that will work or not, just the first thing I would try.
>
> On Mar 16, 5:12 pm, James Bennett  wrote:
>

Hey James, I've not used signals yet so I don't know where they fit in
the control flow. My first guess is to say no it wouldn't work because
I couldn't imagine that pre_save would be called while ModelForm was
listening for ValidationErrors. This would be hackish IMHO also, but
I'll give it a try though when I get back to my comp (on phone).

-- 
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: Model validation outside of ModelForms.

[orokusaki]

On Mar 16, 10:12 am, James Bennett  wrote:
> On Tue, Mar 16, 2010 at 10:36 AM, orokusaki  wrote:
> > It doesn't seem that the core team is interested in working on Model
> > validation at the moment:http://code.djangoproject.com/ticket/13121
> > (my failed ticket)
>
> Stop right there and actually go back and *read* all the feedback
> you've gotten, because right now you're just flat-out lying. Russell
> has, on multiple occasions, asked you, begged you, and pleaded with
> you to get proper discussion going on the things you've proposed.
> You've refused and instead adopted a method of opening duplicate
> tickets and screwing around with the metadata on existing ones,
> apparently out of a desire to annoy as many people as possible rather
> than get anything useful done.
>
> If you'll actually pay attention to what others say and actually put
> in the time to learn how the Django development process works, you may
> be a lot happier with the results. If instead you just continue what
> you've been doing, well, I for one will be happy to direct you to some
> other framework that's willing to put up with such antics.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."


Actually I'm not lying. Russell hasn't given me any feedback regarding
my idea or patch. I didn't simply reopen tickets. Russell changed my
ticket to a documentation ticket, so I opened a new ticket to discuss
that which he avoided in his discussion. This kind of ego-driven
closed mindedness is probably why Django has a low rated community for
being such a popular framework. If one person could give me a good
(non-formality related) reason for Russell to dismiss my ticket in
aprox 2.5 minutes, I would stop complaining about it. It isn't because
of OCD that I want this bug fixed. It is because it won't break
compatibility, it takes about 5 minutes, and it adds so much value
(with respect to its simplicity).

-- 
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.