Re: QuerySet filtering weirdness for dates with 3-digit years

[Evan Carmi]

We created a ticket in Trac: https://code.djangoproject.com/ticket/18176
>
>
I guess the decision regarding whether this is a docs clarification or a 
code patch will be made there. Although if someone would like to 
help expedite that process we would love to do the work for the fix in 
either direction.

Cheers,
Evan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/dk9Jdd7YShoJ.
To post to this group, send email to django-developers@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 File-based session doesn't expire

[Paul McMillan]

Hi,

This is explained in the docs about sessions:
https://docs.djangoproject.com/en/dev/topics/http/sessions/#clearing-the-session-table

We provide a job you can periodically run to remove expired sessions.
However, looking at the code, it appears that this only works for the
database backed sessions, and does not work for file-backed sessions.
In the usual case, the cookie expires out of the user's browser and so
they have no access to the session on disk, even if it is still
present, but this leaves you with an ever-growing directory of old
files on the disk.

As a practical matter, file-based sessions are extremely slow compared
to the other session backends, so they are not very common in
production environments.

If you'd like to open a ticket (or even write a patch), that would be
great. I would suggest two improvements (probably as separate
tickets). The first is to switch to using the new signing framework
for file-based sessions, which provides the option for stronger
datetime based integrity checking. The second would be to improve the
cleanup command so that it clears out file-based sessions in addition
to the database backed ones.

-Paul

On Thu, Apr 19, 2012 at 11:44 AM, ej  wrote:
> Anyone?
>
>
> On Tuesday, April 17, 2012 4:11:28 PM UTC-7, ej wrote:
>>
>> File-based session backend doesn't expire, unlike db-backed and
>> cache-based sessions. I'm not too sure if this is a bug or an intended (but
>> undocumented) design. I am under the impression that all session backends
>> should behave similarly.
>>
>> If this is an intended design, can someone explains why this is the case?
>>
>> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/tsclBizYprkJ.
>
> To post to this group, send email to django-developers@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-developers@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 File-based session doesn't expire

[ej]

Anyone?

On Tuesday, April 17, 2012 4:11:28 PM UTC-7, ej wrote:
>
> File-based session backend doesn't expire, unlike db-backed and 
> cache-based sessions. I'm not too sure if this is a bug or an intended (but 
> undocumented) design. I am under the impression that all session backends 
> should behave similarly.
>
> If this is an intended design, can someone explains why this is the case?
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/tsclBizYprkJ.
To post to this group, send email to django-developers@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: GitHub migration planning

[Alex Ogier]

On Thu, Apr 19, 2012 at 1:15 PM, philipn  wrote:
>
>
>
> On Wednesday, April 18, 2012 5:26:27 PM UTC-7, dstufft wrote:
>>
>> Github issues do not have the ability for anyone to close, tag, or create
>> milestones. You have to be the creator of the ticket or someone with
>> commit access. Django's track instance allows anyone to participate
>> in this way and is one of the major reasons to my knowledge that
>> Django will keep it's trace instance.
>>
>>
> I just investigated and it's indeed the case that non-commit members
> cannot add/delete tags or milestones from issues.  Is this a dealbreaker for
> GitHub Issues, or could this be worked around?  E.g. commit members could do
> tagging and milestone labeling.  Looking through the Trac instance, most
> milestone setting appears to be done by core devs.
>

Lack of milestones could probably be worked around, but without the
ability to tag issues Django's triage process would be dead in the
water. I don't know if Django could support that, we are up to ticket
#18xxx now. That doesn't mean there aren't ways to improve the status
quo: maybe pull requests could be supported as an explicit alternative
to attached patches. That might mean we lose explicit notification of
all code changes on a ticket.

A Trac plugin that follows changes to a GitHub pull request sounds
like a powerful tool, and could be widely useful. There's not actually
a way to notify Trac of changes to pull requests as far as I can tell,
but you can query and check for recent updates. I'll look into this
more.

As an aside, just because we are starting to use git doesn't mean that
linear history isn't valuable. I know of several successful projects
that use git that use patch-based workflows rather than merging. The
advantage of that is a linear history with each feature packaged into
a neat commit. The extra detail is great for developing, but not so
great for a mainline history (it breaks 'git bisect' for example).

Best,
Alex Ogier

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

[philipn]

On Wednesday, April 18, 2012 5:26:27 PM UTC-7, dstufft wrote:
>
>  Github issues do not have the ability for anyone to close, tag, or create
> milestones. You have to be the creator of the ticket or someone with
> commit access. Django's track instance allows anyone to participate
> in this way and is one of the major reasons to my knowledge that
> Django will keep it's trace instance.
>  
>
> I just investigated and it's indeed the case that non-commit members 
cannot add/delete tags or milestones from issues.  Is this a dealbreaker 
for GitHub Issues, or could this be worked around?  E.g. commit members 
could do tagging and milestone labeling.  Looking through the Trac 
instance, most milestone setting appears to be done by core devs.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/gl024aKQ-48J.
To post to this group, send email to django-developers@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.

Improved assignment_tag

[Choongmin Lee]

Is it only me who needs a simple tag with optional assignment, e.g. that 
both {% mytag %} and {% mytag as varname %} are possible?

Attached is a patch that make the assignment optional for assignment_tag.

If this change of behavior of assignment_tag is not acceptable, then how 
about adding a new decorator like 'optional_assignment_tag', or adding a 
new parameter to assignment_tag?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/kf4o1HEDJ3oJ.
To post to this group, send email to django-developers@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.

Index: django/template/base.py
===
--- django/template/base.py	(revision 17915)
+++ django/template/base.py	(working copy)
@@ -1130,14 +1130,18 @@
 params, varargs, varkw, defaults = getargspec(func)
 
 class AssignmentNode(TagHelperNode):
-def __init__(self, takes_context, args, kwargs, target_var):
+def __init__(self, takes_context, args, kwargs, target_var=None):
 super(AssignmentNode, self).__init__(takes_context, args, kwargs)
 self.target_var = target_var
 
 def render(self, context):
 resolved_args, resolved_kwargs = self.get_resolved_arguments(context)
-context[self.target_var] = func(*resolved_args, **resolved_kwargs)
-return ''
+output = func(*resolved_args, **resolved_kwargs)
+if self.target_var is None:
+return output
+else:
+context[self.target_var] = output
+return ''
 
 function_name = (name or
 getattr(func, '_decorated_function', func).__name__)
@@ -1145,11 +1149,10 @@
 def compile_func(parser, token):
 bits = token.split_contents()[1:]
 if len(bits) < 2 or bits[-2] != 'as':
-raise TemplateSyntaxError(
-"'%s' tag takes at least 2 arguments and the "
-"second last argument must be 'as'" % function_name)
-target_var = bits[-1]
-bits = bits[:-2]
+target_var = None
+else:
+target_var = bits[-1]
+bits = bits[:-2]
 args, kwargs = parse_bits(parser, bits, params,
 varargs, varkw, defaults, takes_context, function_name)
 return AssignmentNode(takes_context, args, kwargs, target_var)

Re: GSoC 2012: Security Enhancements

[Rohan Jain]

I hosted a simple app which responds with the request details for
testing purposes:
https://request-mirror.herokuapp.com/
(source: https://github.com/crodjer/request-mirror)

On 12:05 -0700 / 18 Apr, Paul McMillan wrote:
> There seems to be  some confusion about CORS (a hairy draft spec that
> is not fully implemented in any browser, and not appropriate for
> inclusion in Django at this time) and the "Origin" header (aka Web
> Origin, rfc6454).
> 
> http://tools.ietf.org/html/rfc6454
> https://wiki.mozilla.org/Security/Origin
> http://www.w3.org/TR/access-control/#origin-request-header
> 
> The Origin header defined in rfc6454 is compatible with the CORS
> origin header, but does not require full CORS support from the browser
> or the server to be useful.
> 
> In my tests with Firefox and Chrome, both sent the origin header
> properly when making potentially state-changing cross-origin requests
> (both AJAX and standard form POST requests).
> 

How did you test the form POST requests with firefox?

For me, with a normal POST, Iceweasel (firefox for debian) 10 does not
seem to be sending any origin headers but Chrome (18) is.
MDN says that this should work firefox >= 3.5
(https://developer.mozilla.org/en/http_access_control#The_HTTP_request_headers)
and the Origin header should be present:
https://wiki.mozilla.org/Security/Origin#Origin_header_format

I tried testing these cross domain (between the secure remote and
local, between local aliases) through HTTP Post, but the browser never
complained or did a Preflighted request (HTTP OPTIONS request) or sent
back the origin header.

But it apparently isn't with mine (Hopefully I am doing something
wrong here)

> My suggestion here is to include optional support for the Origin
> header as follows:
> - if present and null, fail the CSRF check
> - if present and not null, use in alongside the Referer header
> - if absent, keep current behavior
> 
> As a general rule, if a browser sends an origin header, that value is
> more reliable (harder for malicious sites to manipulate, less often
> stripped by firewalls, less often disabled by users) than the referer
> header. This addition won't improve CSRF protection for older
> browsers, but it also won't break anything for them. For users with
> newer browsers, it should prevent CSRF even in cases when the CSRF
> token is stolen due to misconfiguration or user error.
> 
> -Paul

I second this. The selective origin checking, though not completely,
will improve CSRF protection for some clients. We can then be sure
about an automatic increase in security with the shift towards such
clients.

--
Rohan

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