Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Stefano Crosta]

Hello! Anything new on this matter?

I could not find a bug opened on django on this subject...

On Friday, May 18, 2012 7:37:51 AM UTC+2, Paul McMillan wrote:
> No. please open a new bug detailing this issue.
> 
> 
> 
> -Paul
> 
> 
> 
> On Tue, May 15, 2012 at 6:53 AM, Rafał Stożek  wrote:
> 
> > Should we reopen https://code.djangoproject.com/ticket/15863 then?
> 
> >
> 
> >
> 
> > On Mon, May 14, 2012 at 4:39 PM, Suteepat Damrongyingsupab
> 
> >  wrote:
> 
> >>
> 
> >> Hi all,
> 
> >> Thanks for your help to investigate the issue. I didn't have a chance to
> 
> >> look further into it.
> 
> >> So every class-based views that subclass from TemplateResponseMixin are
> 
> >> affected by this bug because it uses TemplateResponse as its 
> >> response_class.
> 
> >>
> 
> >>
> 
> >>
> 
> >> On Monday, May 14, 2012 7:28:50 PM UTC+7, Rafał Stożek wrote:
> 
> >>>
> 
> >>> Oh, I see where the bug is. SimpleTemplateResponse.__getstate__ does not
> 
> >>> call super(). And HttpResponse class serializes cookies in its 
> >>> __getstate__
> 
> >>> method. So basically SimpleTemplateResponse doesn't serialize cookies
> 
> >>> correctly.
> 
> >>>
> 
> >>> On Mon, May 14, 2012 at 1:25 PM, Rafał Stożek  wrote:
> 
> 
> 
>  Could you try again to cause bug with SafeView class, but this time
> 
>  using TemplateResponse class instead of render_to_response shortcut?
> 
> 
> 
> 
> 
>  On Mon, May 14, 2012 at 10:24 AM, Suteepat Damrongyingsupab
> 
>   wrote:
> 
> >
> 
> > I've just found the root cause of the problem.
> 
> > The bug occurs when using ListView (I haven't tested other CBV though)
> 
> > and decorating it with cache_page and csrf_protect.
> 
> > I've tested it with a new clean project and left settings.py as a
> 
> > default.
> 
> > The simple code I used to test is as follows:
> 
> >
> 
> > urls.py (excerpt):
> 
> >     url(r'safe/$', cache_page(1800)(csrf_protect(SafeView.as_view(,
> 
> >     url(r'bug/$', cache_page(1800)(csrf_protect(BugView.as_view(,
> 
> >
> 
> > views.py:
> 
> > from django.template import RequestContext
> 
> > from django.views.generic import View, ListView
> 
> >
> 
> > class SafeView(View):
> 
> >     template_name = 'basic/index.html'
> 
> >
> 
> >     def get(self, request):
> 
> >     return render_to_response('basic/index.html', {'msg': 'Hello,
> 
> > world'}, context_instance=RequestContext(request))
> 
> >
> 
> > class BugView(ListView):
> 
> >     template_name = 'basic/index.html'
> 
> >     queryset = []
> 
> >
> 
> > template (basic/index.html):
> 
> > Today message: {{ msg }}{% csrf_token %}
> 
> >
> 
> > I kept reloading the SafeView page (20+ times) and the bug didn't
> 
> > occur.
> 
> > You should try reloading the BugView page and the bug will occur within
> 
> > 10 reloading times.
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:
> 
> >>
> 
> >> That looks a lot like 15863.
> 
> >> https://code.djangoproject.com/ticket/15863
> 
> >>
> 
> >> Which cache backend are you using? Which session backend? Are you
> 
> >> absolutely positive you are using Django 1.4, and not a
> 
> >> system-installed version of 1.3? Does your code pickle or unpickle
> 
> >> sessions or cookies anywhere outside of the caching framework?
> 
> >>
> 
> >> I thought we fixed that bug, but if you can provide minimal steps to
> 
> >> reproduce it in Django 1.4, we'll have to reopen the ticket.
> 
> >>
> 
> >> -Paul
> 
> >>
> 
> >> On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab
> 
> >>  wrote:
> 
> >> > I'm using Django 1.4.
> 
> >> > According to the Django csrf docs, I decorate my class-based view in
> 
> >> > the
> 
> >> > urls.py as follows:
> 
> >> >
> 
> >> > cache_page(1800)(csrf_protect(MyView.as_view()))
> 
> >> >
> 
> >> > I kept reloading MyView page url and Set-Cookie header would be
> 
> >> > recursive
> 
> >> > like this:
> 
> >> >
> 
> >> > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie:
> 
> >> > csrftoken=XeRCBpXuNpuRie17OqWrDIM3xKt9hV3Q\\073 expires=Sat\\054
> 
> >> > 11-May-2013
> 
> >> > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""
> 
> >> >
> 
> >> > I don't know what's a trigger to this behavior.
> 
> >> > Has anyone found a problem like this? Please help.
> 
> >> > Thanks.
> 
> >> >
> 
> >> >
> 
> >> >
> 
> >> >
> 
> >> > --
> 
> >> > You received this message because you are subscribed to the Google
> 
> >> > Groups
> 
> >> > "Django developers" group.
> 
> >> > To view this discussion on the web visit
> 
> >> > 

Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Paul McMillan]

No. please open a new bug detailing this issue.

-Paul

On Tue, May 15, 2012 at 6:53 AM, Rafał Stożek  wrote:
> Should we reopen https://code.djangoproject.com/ticket/15863 then?
>
>
> On Mon, May 14, 2012 at 4:39 PM, Suteepat Damrongyingsupab
>  wrote:
>>
>> Hi all,
>> Thanks for your help to investigate the issue. I didn't have a chance to
>> look further into it.
>> So every class-based views that subclass from TemplateResponseMixin are
>> affected by this bug because it uses TemplateResponse as its response_class.
>>
>>
>>
>> On Monday, May 14, 2012 7:28:50 PM UTC+7, Rafał Stożek wrote:
>>>
>>> Oh, I see where the bug is. SimpleTemplateResponse.__getstate__ does not
>>> call super(). And HttpResponse class serializes cookies in its __getstate__
>>> method. So basically SimpleTemplateResponse doesn't serialize cookies
>>> correctly.
>>>
>>> On Mon, May 14, 2012 at 1:25 PM, Rafał Stożek  wrote:

 Could you try again to cause bug with SafeView class, but this time
 using TemplateResponse class instead of render_to_response shortcut?


 On Mon, May 14, 2012 at 10:24 AM, Suteepat Damrongyingsupab
  wrote:
>
> I've just found the root cause of the problem.
> The bug occurs when using ListView (I haven't tested other CBV though)
> and decorating it with cache_page and csrf_protect.
> I've tested it with a new clean project and left settings.py as a
> default.
> The simple code I used to test is as follows:
>
> urls.py (excerpt):
>     url(r'safe/$', cache_page(1800)(csrf_protect(SafeView.as_view(,
>     url(r'bug/$', cache_page(1800)(csrf_protect(BugView.as_view(,
>
> views.py:
> from django.template import RequestContext
> from django.views.generic import View, ListView
>
> class SafeView(View):
>     template_name = 'basic/index.html'
>
>     def get(self, request):
>     return render_to_response('basic/index.html', {'msg': 'Hello,
> world'}, context_instance=RequestContext(request))
>
> class BugView(ListView):
>     template_name = 'basic/index.html'
>     queryset = []
>
> template (basic/index.html):
> Today message: {{ msg }}{% csrf_token %}
>
> I kept reloading the SafeView page (20+ times) and the bug didn't
> occur.
> You should try reloading the BugView page and the bug will occur within
> 10 reloading times.
>
>
>
>
> On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:
>>
>> That looks a lot like 15863.
>> https://code.djangoproject.com/ticket/15863
>>
>> Which cache backend are you using? Which session backend? Are you
>> absolutely positive you are using Django 1.4, and not a
>> system-installed version of 1.3? Does your code pickle or unpickle
>> sessions or cookies anywhere outside of the caching framework?
>>
>> I thought we fixed that bug, but if you can provide minimal steps to
>> reproduce it in Django 1.4, we'll have to reopen the ticket.
>>
>> -Paul
>>
>> On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab
>>  wrote:
>> > I'm using Django 1.4.
>> > According to the Django csrf docs, I decorate my class-based view in
>> > the
>> > urls.py as follows:
>> >
>> > cache_page(1800)(csrf_protect(MyView.as_view()))
>> >
>> > I kept reloading MyView page url and Set-Cookie header would be
>> > recursive
>> > like this:
>> >
>> > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie:
>> > csrftoken=XeRCBpXuNpuRie17OqWrDIM3xKt9hV3Q\\073 expires=Sat\\054
>> > 11-May-2013
>> > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""
>> >
>> > I don't know what's a trigger to this behavior.
>> > Has anyone found a problem like this? Please help.
>> > 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/-/Q5Ywwf3O0sIJ.
>> > 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 view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/9YkZgDFQTfYJ.
>
> To post to this group, send email to
> django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> 

Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Rafał Stożek]

Should we reopen https://code.djangoproject.com/ticket/15863 then?

On Mon, May 14, 2012 at 4:39 PM, Suteepat Damrongyingsupab <
tianiss...@gmail.com> wrote:

> Hi all,
> Thanks for your help to investigate the issue. I didn't have a chance to
> look further into it.
> So every class-based views that subclass from TemplateResponseMixin are
> affected by this bug because it uses TemplateResponse as its response_class.
>
>
>
> On Monday, May 14, 2012 7:28:50 PM UTC+7, Rafał Stożek wrote:
>>
>> Oh, I see where the bug is. SimpleTemplateResponse.__**getstate__ does
>> not call super(). And HttpResponse class serializes cookies in its
>> __getstate__ method. So basically SimpleTemplateResponse doesn't serialize
>> cookies correctly.
>>
>> On Mon, May 14, 2012 at 1:25 PM, Rafał Stożek  wrote:
>>
>>> Could you try again to cause bug with SafeView class, but this time
>>> using TemplateResponse class instead of render_to_response shortcut?
>>>
>>>
>>> On Mon, May 14, 2012 at 10:24 AM, Suteepat Damrongyingsupab <
>>> tianiss...@gmail.com> wrote:
>>>
 I've just found the root cause of the problem.
 The bug occurs when using ListView (I haven't tested other CBV though)
 and decorating it with cache_page and csrf_protect.
 I've tested it with a new clean project and left settings.py as a
 default.
 The simple code I used to test is as follows:

 *urls.py (excerpt):*
 url(r'safe/$', cache_page(1800)(csrf_protect(**
 SafeView.as_view(,
 url(r'bug/$', cache_page(1800)(csrf_protect(**BugView.as_view(,

 *views.py:*
 from django.template import RequestContext
 from django.views.generic import View, ListView

 class SafeView(View):
 template_name = 'basic/index.html'

 def get(self, request):
 return render_to_response('basic/**index.html', {'msg':
 'Hello, world'}, context_instance=**RequestContext(request))

 class BugView(ListView):
 template_name = 'basic/index.html'
 queryset = []

 *template (basic/index.html):*
 Today message: {{ msg }}{% csrf_token %}

 I kept reloading the SafeView page (20+ times) and the bug didn't occur.
 You should try reloading the BugView page and the bug will occur within
 10 reloading times.




 On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:
>
> That looks a lot like 15863.
> https://code.djangoproject.**com**/ticket/15863
>
> Which cache backend are you using? Which session backend? Are you
> absolutely positive you are using Django 1.4, and not a
> system-installed version of 1.3? Does your code pickle or unpickle
> sessions or cookies anywhere outside of the caching framework?
>
> I thought we fixed that bug, but if you can provide minimal steps to
> reproduce it in Django 1.4, we'll have to reopen the ticket.
>
> -Paul
>
> On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab
>  wrote:
> > I'm using Django 1.4.
> > According to the Django csrf docs, I decorate my class-based view in
> the
> > urls.py as follows:
> >
> > cache_page(1800)(csrf_protect(MyView.as_view()))
> >
> > I kept reloading MyView page url and Set-Cookie header would be
> recursive
> > like this:
> >
> > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie:
> > csrftoken=**XeRCBpXuNpuRie17OqWr**DIM3xKt9hV**3Q\\073
> expires=Sat\\054 11-May-2013
> > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""
> >
> > I don't know what's a trigger to this behavior.
> > Has anyone found a problem like this? Please help.
> > 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/**ms**g/django-developers/-/**Q5Ywwf3O**
> 0sIJ.
>
> > To post to this group, send email to django-developers@**
> googlegroups**.com .
> > To unsubscribe from this group, send email to
> > django-developers+unsubscribe@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 view this discussion on the web visit https://groups.google.com/d/**
 msg/django-developers/-/**9YkZgDFQTfYJ
 .

 

Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Suteepat Damrongyingsupab]

Hi all,
Thanks for your help to investigate the issue. I didn't have a chance to 
look further into it.
So every class-based views that subclass from TemplateResponseMixin are 
affected by this bug because it uses TemplateResponse as its response_class.


On Monday, May 14, 2012 7:28:50 PM UTC+7, Rafał Stożek wrote:
>
> Oh, I see where the bug is. SimpleTemplateResponse.__getstate__ does not 
> call super(). And HttpResponse class serializes cookies in its __getstate__ 
> method. So basically SimpleTemplateResponse doesn't serialize cookies 
> correctly.
>
> On Mon, May 14, 2012 at 1:25 PM, Rafał Stożek  wrote:
>
>> Could you try again to cause bug with SafeView class, but this time using 
>> TemplateResponse class instead of render_to_response shortcut?
>>
>>
>> On Mon, May 14, 2012 at 10:24 AM, Suteepat Damrongyingsupab <
>> tianiss...@gmail.com> wrote:
>>
>>> I've just found the root cause of the problem.
>>> The bug occurs when using ListView (I haven't tested other CBV though) 
>>> and decorating it with cache_page and csrf_protect.
>>> I've tested it with a new clean project and left settings.py as a 
>>> default.
>>> The simple code I used to test is as follows:
>>>
>>> *urls.py (excerpt):*
>>> url(r'safe/$', cache_page(1800)(csrf_protect(SafeView.as_view(,
>>> url(r'bug/$', cache_page(1800)(csrf_protect(BugView.as_view(,
>>>
>>> *views.py:*
>>> from django.template import RequestContext
>>> from django.views.generic import View, ListView
>>>
>>> class SafeView(View):
>>> template_name = 'basic/index.html'
>>>
>>> def get(self, request):
>>> return render_to_response('basic/index.html', {'msg': 'Hello, 
>>> world'}, context_instance=RequestContext(request))
>>>
>>> class BugView(ListView):
>>> template_name = 'basic/index.html'
>>> queryset = []
>>>
>>> *template (basic/index.html):*
>>> Today message: {{ msg }}{% csrf_token %}
>>>
>>> I kept reloading the SafeView page (20+ times) and the bug didn't occur.
>>> You should try reloading the BugView page and the bug will occur within 
>>> 10 reloading times.
>>>
>>>
>>>
>>>
>>> On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:

 That looks a lot like 15863. 
 https://code.djangoproject.**com/ticket/15863
  

 Which cache backend are you using? Which session backend? Are you 
 absolutely positive you are using Django 1.4, and not a 
 system-installed version of 1.3? Does your code pickle or unpickle 
 sessions or cookies anywhere outside of the caching framework? 

 I thought we fixed that bug, but if you can provide minimal steps to 
 reproduce it in Django 1.4, we'll have to reopen the ticket. 

 -Paul 

 On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab 
  wrote: 
 > I'm using Django 1.4. 
 > According to the Django csrf docs, I decorate my class-based view in 
 the 
 > urls.py as follows: 
 > 
 > cache_page(1800)(csrf_protect(**MyView.as_view())) 
 > 
 > I kept reloading MyView page url and Set-Cookie header would be 
 recursive 
 > like this: 
 > 
 > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie: 
 > csrftoken=**XeRCBpXuNpuRie17OqWrDIM3xKt9hV**3Q\\073 expires=Sat\\054 
 11-May-2013 
 > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\"" 
 > 
 > I don't know what's a trigger to this behavior. 
 > Has anyone found a problem like this? Please help. 
 > 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/-/**Q5Ywwf3O0sIJ.
 >  

 > To post to this group, send email to django-developers@**
 googlegroups.com . 
 > To unsubscribe from this group, send email to 
 > django-developers+unsubscribe@**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 view this discussion on the web visit 
>>> https://groups.google.com/d/msg/django-developers/-/9YkZgDFQTfYJ.
>>>
>>> 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 

Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Rafał Stożek]

Oh, I see where the bug is. SimpleTemplateResponse.__getstate__ does not
call super(). And HttpResponse class serializes cookies in its __getstate__
method. So basically SimpleTemplateResponse doesn't serialize cookies
correctly.

On Mon, May 14, 2012 at 1:25 PM, Rafał Stożek  wrote:

> Could you try again to cause bug with SafeView class, but this time using
> TemplateResponse class instead of render_to_response shortcut?
>
>
> On Mon, May 14, 2012 at 10:24 AM, Suteepat Damrongyingsupab <
> tianiss...@gmail.com> wrote:
>
>> I've just found the root cause of the problem.
>> The bug occurs when using ListView (I haven't tested other CBV though)
>> and decorating it with cache_page and csrf_protect.
>> I've tested it with a new clean project and left settings.py as a default.
>> The simple code I used to test is as follows:
>>
>> *urls.py (excerpt):*
>> url(r'safe/$', cache_page(1800)(csrf_protect(SafeView.as_view(,
>> url(r'bug/$', cache_page(1800)(csrf_protect(BugView.as_view(,
>>
>> *views.py:*
>> from django.template import RequestContext
>> from django.views.generic import View, ListView
>>
>> class SafeView(View):
>> template_name = 'basic/index.html'
>>
>> def get(self, request):
>> return render_to_response('basic/index.html', {'msg': 'Hello,
>> world'}, context_instance=RequestContext(request))
>>
>> class BugView(ListView):
>> template_name = 'basic/index.html'
>> queryset = []
>>
>> *template (basic/index.html):*
>> Today message: {{ msg }}{% csrf_token %}
>>
>> I kept reloading the SafeView page (20+ times) and the bug didn't occur.
>> You should try reloading the BugView page and the bug will occur within
>> 10 reloading times.
>>
>>
>>
>>
>> On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:
>>>
>>> That looks a lot like 15863.
>>> https://code.djangoproject.**com/ticket/15863
>>>
>>> Which cache backend are you using? Which session backend? Are you
>>> absolutely positive you are using Django 1.4, and not a
>>> system-installed version of 1.3? Does your code pickle or unpickle
>>> sessions or cookies anywhere outside of the caching framework?
>>>
>>> I thought we fixed that bug, but if you can provide minimal steps to
>>> reproduce it in Django 1.4, we'll have to reopen the ticket.
>>>
>>> -Paul
>>>
>>> On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab
>>>  wrote:
>>> > I'm using Django 1.4.
>>> > According to the Django csrf docs, I decorate my class-based view in
>>> the
>>> > urls.py as follows:
>>> >
>>> > cache_page(1800)(csrf_protect(**MyView.as_view()))
>>> >
>>> > I kept reloading MyView page url and Set-Cookie header would be
>>> recursive
>>> > like this:
>>> >
>>> > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie:
>>> > csrftoken=**XeRCBpXuNpuRie17OqWrDIM3xKt9hV**3Q\\073 expires=Sat\\054
>>> 11-May-2013
>>> > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""
>>> >
>>> > I don't know what's a trigger to this behavior.
>>> > Has anyone found a problem like this? Please help.
>>> > 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/-/**Q5Ywwf3O0sIJ.
>>>
>>> > To post to this group, send email to django-developers@**
>>> googlegroups.com .
>>> > To unsubscribe from this group, send email to
>>> > django-developers+unsubscribe@**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 view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/9YkZgDFQTfYJ.
>>
>> 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 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Rafał Stożek]

Could you try again to cause bug with SafeView class, but this time using
TemplateResponse class instead of render_to_response shortcut?

On Mon, May 14, 2012 at 10:24 AM, Suteepat Damrongyingsupab <
tianiss...@gmail.com> wrote:

> I've just found the root cause of the problem.
> The bug occurs when using ListView (I haven't tested other CBV though) and
> decorating it with cache_page and csrf_protect.
> I've tested it with a new clean project and left settings.py as a default.
> The simple code I used to test is as follows:
>
> *urls.py (excerpt):*
> url(r'safe/$', cache_page(1800)(csrf_protect(SafeView.as_view(,
> url(r'bug/$', cache_page(1800)(csrf_protect(BugView.as_view(,
>
> *views.py:*
> from django.template import RequestContext
> from django.views.generic import View, ListView
>
> class SafeView(View):
> template_name = 'basic/index.html'
>
> def get(self, request):
> return render_to_response('basic/index.html', {'msg': 'Hello,
> world'}, context_instance=RequestContext(request))
>
> class BugView(ListView):
> template_name = 'basic/index.html'
> queryset = []
>
> *template (basic/index.html):*
> Today message: {{ msg }}{% csrf_token %}
>
> I kept reloading the SafeView page (20+ times) and the bug didn't occur.
> You should try reloading the BugView page and the bug will occur within 10
> reloading times.
>
>
>
>
> On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:
>>
>> That looks a lot like 15863.
>> https://code.djangoproject.**com/ticket/15863
>>
>> Which cache backend are you using? Which session backend? Are you
>> absolutely positive you are using Django 1.4, and not a
>> system-installed version of 1.3? Does your code pickle or unpickle
>> sessions or cookies anywhere outside of the caching framework?
>>
>> I thought we fixed that bug, but if you can provide minimal steps to
>> reproduce it in Django 1.4, we'll have to reopen the ticket.
>>
>> -Paul
>>
>> On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab
>>  wrote:
>> > I'm using Django 1.4.
>> > According to the Django csrf docs, I decorate my class-based view in
>> the
>> > urls.py as follows:
>> >
>> > cache_page(1800)(csrf_protect(**MyView.as_view()))
>> >
>> > I kept reloading MyView page url and Set-Cookie header would be
>> recursive
>> > like this:
>> >
>> > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie:
>> > csrftoken=**XeRCBpXuNpuRie17OqWrDIM3xKt9hV**3Q\\073 expires=Sat\\054
>> 11-May-2013
>> > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""
>> >
>> > I don't know what's a trigger to this behavior.
>> > Has anyone found a problem like this? Please help.
>> > 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/-/**Q5Ywwf3O0sIJ.
>>
>> > To post to this group, send email to django-developers@**
>> googlegroups.com .
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscribe@**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 view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/9YkZgDFQTfYJ.
>
> 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 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Suteepat Damrongyingsupab]

I've just found the root cause of the problem.
The bug occurs when using ListView (I haven't tested other CBV though) and 
decorating it with cache_page and csrf_protect.
I've tested it with a new clean project and left settings.py as a default.
The simple code I used to test is as follows:

*urls.py (excerpt):*
url(r'safe/$', cache_page(1800)(csrf_protect(SafeView.as_view(,
url(r'bug/$', cache_page(1800)(csrf_protect(BugView.as_view(,

*views.py:*
from django.template import RequestContext
from django.views.generic import View, ListView

class SafeView(View):
template_name = 'basic/index.html'

def get(self, request):
return render_to_response('basic/index.html', {'msg': 'Hello, 
world'}, context_instance=RequestContext(request))

class BugView(ListView):
template_name = 'basic/index.html'
queryset = []

*template (basic/index.html):*
Today message: {{ msg }}{% csrf_token %}

I kept reloading the SafeView page (20+ times) and the bug didn't occur.
You should try reloading the BugView page and the bug will occur within 10 
reloading times.



On Monday, May 14, 2012 12:14:21 AM UTC+7, Paul McMillan wrote:
>
> That looks a lot like 15863. 
> https://code.djangoproject.com/ticket/15863 
>
> Which cache backend are you using? Which session backend? Are you 
> absolutely positive you are using Django 1.4, and not a 
> system-installed version of 1.3? Does your code pickle or unpickle 
> sessions or cookies anywhere outside of the caching framework? 
>
> I thought we fixed that bug, but if you can provide minimal steps to 
> reproduce it in Django 1.4, we'll have to reopen the ticket. 
>
> -Paul 
>
> On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab 
>  wrote: 
> > I'm using Django 1.4. 
> > According to the Django csrf docs, I decorate my class-based view in the 
> > urls.py as follows: 
> > 
> > cache_page(1800)(csrf_protect(MyView.as_view())) 
> > 
> > I kept reloading MyView page url and Set-Cookie header would be 
> recursive 
> > like this: 
> > 
> > Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie: 
> > csrftoken=XeRCBpXuNpuRie17OqWrDIM3xKt9hV3Q\\073 expires=Sat\\054 
> 11-May-2013 
> > 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\"" 
> > 
> > I don't know what's a trigger to this behavior. 
> > Has anyone found a problem like this? Please help. 
> > 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/-/Q5Ywwf3O0sIJ. 
> > 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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/9YkZgDFQTfYJ.
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 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

[Paul McMillan]

That looks a lot like 15863.
https://code.djangoproject.com/ticket/15863

Which cache backend are you using? Which session backend? Are you
absolutely positive you are using Django 1.4, and not a
system-installed version of 1.3? Does your code pickle or unpickle
sessions or cookies anywhere outside of the caching framework?

I thought we fixed that bug, but if you can provide minimal steps to
reproduce it in Django 1.4, we'll have to reopen the ticket.

-Paul

On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab
 wrote:
> I'm using Django 1.4.
> According to the Django csrf docs, I decorate my class-based view in the
> urls.py as follows:
>
> cache_page(1800)(csrf_protect(MyView.as_view()))
>
> I kept reloading MyView page url and Set-Cookie header would be recursive
> like this:
>
> Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie:
> csrftoken=XeRCBpXuNpuRie17OqWrDIM3xKt9hV3Q\\073 expires=Sat\\054 11-May-2013
> 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""
>
> I don't know what's a trigger to this behavior.
> Has anyone found a problem like this? Please help.
> 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/-/Q5Ywwf3O0sIJ.
> 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.