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

2012-05-17 Thread 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: Exception Middleware not run [was Re: Subclass handle_uncaught_exception]

2012-05-17 Thread Tom Evans 
On Thu, May 17, 2012 at 9:51 AM, rorycl  wrote:
> Hi Tom
>
> Thanks for your email.
>
> On May 16, 4:14 pm, Tom Evans  wrote:
>> On Wed, May 16, 2012 at 12:32 PM, Rory Campbell-Lange
>>
>>  wrote:
>
>> > I have a view raising a specific exception I would like to catch and
>> > provide an HttpResponse based on this exception.
>>
>> If it is one view raising one specific exception, why aren't you
>> catching it in that view? Exception middleware is used to provide a
>> more generic error page, or for advanced error handling, or to handle
>> errors from a number of views. If it is just for one view, one
>> exception, it is more coherent to handle the error in the view.
>
> As noted before in this thread I have a lazy rowgetter that only
> triggers an exception
>  in the template. In other words, the except clause in my view isn't
> triggered.
>
>    try:
>        rota = self.model.xmlapi_get_location (**kwargs)
>    except DBException, e:
>        code, message = [epart.strip() for epart in e.msg.split(':')]
>        return HttpResponse(message, status=code,
>                            content_type="text/plain")
>
>> > My middleware is as follows -- its simply a sketch at present:
>>
>> >    class ExceptCatcher(object):
>> >        def process_exception(self, request, exception):
>> >            HttpResponse("Error encountered")
>>
>> Is this code verbatim? If so, you aren't returning the newly generated
>> HttpResponse, just creating it.
>
> I'm simply trying to trigger the exception handler in ipdb and that is
> not happening
> using either either the standard middleware or
> decorator_from_middleware
> methodologies. I guess this might be because control has passed from
> the view?
> decorators.py:handle_uncaught_exception _is_ called, but I am unable
> to interject my
> ExceptCatcher with it.
>
>> These sorts of questions should be on django-users really.
>
> Sorry if this is the wrong place to post. However there are a number
> of people on the
> web reporting that they are unable to trigger process_exception. Hence
> my query here.
>
>

Ah, you are returning a TemplateResponse? This changes things.

TemplateResponses are rendered outside of the view. Exception
middleware processes exceptions raised by the view, which this is not
- the view successfully completes and returns a valid HttpResponse
object.

I expect this may be a bug, or at least an unintended consequence.

This is all handled in django.core.handlers.base.BaseHandler. The view
is called here:

https://github.com/django/django/blob/master/django/core/handlers/base.py#L109

and if that raises an exception, Django will try to use the middleware
classes that have handle_exception() methods to generate a response.

If the returned response from the view is a template response, it is
rendered here:

https://github.com/django/django/blob/master/django/core/handlers/base.py#L133

if that raises an exception that isnt http.Http404,
exceptions.PermissionDenied or SystemExit, then it will use the
handle_uncaught_exception to handle the exception and return a
response.

I think this would need a new feature to fix. If a TemplateResponse
fails to render and throws an exception, you would want any middleware
that handles this to be passed both the exception and the
TemplateResponse that caused the exception, not just the exception
object.

I think you should raise a feature request ticket for this.

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-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-mssql with the dream of passing the test suite

2012-05-17 Thread VernonCole 
I should mention that if you use pywin32 build 215 or newer, an appropriate 
version of adodbapi will already be included.  You do not need to download 
it separately from sourceforge or PyPi unless you are running IronPython. 
Since pywin32 is already a dependency for django-mssql, you should be 
covered.  Also, it should not be too hard to add support for ACCESS and 3rd 
party databases.
--
Vernon

On Wednesday, May 16, 2012 2:27:00 PM UTC-6, Michael Manfre wrote:
>
> A few weeks ago, I started down the path of updating django-mssql so that 
> it supports Django 1.4. I moved the project over to bitbucket (
> http://bitbucket.org/Manfre/django-mssql/), docs are deployed to read the 
> docs (http://django-mssql.readthedocs.org), and have made it a policy of 
> deploying packages to PyPi. 
>
> Django 1.4 support is mostly there and so far is passing all testing for 
> the site responsible for the backend's existence (http://www.src.org). To 
> help avoid surprises and ensure life as a 3rd party database backend 
> maintainer is a lot less painful, I have set a goal of having django-mssql 
> pass the test suite. This is a non-trivial task that will require changes 
> to django and django-mssql. I've already submitted a few tickets that bring 
> me closer to my goal and it was advised that I send this message as a heads 
> up regarding my intentions to avoid tickets being closed with a "mssql 
> isn't officially supported by Django" comment.
>
> If you review one of these tickets, please keep my goal in the back of 
> your mind. I welcome feedback on better ways of approaching my proposed 
> changes.
>
> Regards,
> Michael Manfre
>

-- 
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/-/i4qYqPpLAnoJ.
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-mssql with the dream of passing the test suite

2012-05-17 Thread VernonCole 
Micheal:

   I note that your code is using the Adam Vandenberg fork of adodbapi.  I 
have rolled Adam's changes back into the main branch of adodbapi, so that 
django can have the advantages of numerous bug fixes, as well as the 
ability to run in Python3 and IronPython.  I have attempted to make all of 
the features that Adam added work exactly the same way -- except that you 
will have to add a line of code to inform adodbapi that it needs to switch 
paramstyle to 'format' when it connects.  As far as I know, this is the 
only db-api module which is capable of switching paramstyle at run time -- 
and I did it all for you.

  Please, please, please import my new django-compatible adodbapi from 
https://sourceforge.net/projects/adodbapi  
(or PyPi, same version in 
both places).

  Let me know if you need any help or changes.  I will modify the main fork 
to accommodate your needs.  I _really_ want this to work.
--
Vernon Cole

On Wednesday, May 16, 2012 2:27:00 PM UTC-6, Michael Manfre wrote:
>
> A few weeks ago, I started down the path of updating django-mssql so that 
> it supports Django 1.4. I moved the project over to bitbucket (
> http://bitbucket.org/Manfre/django-mssql/), docs are deployed to read the 
> docs (http://django-mssql.readthedocs.org), and have made it a policy of 
> deploying packages to PyPi. 
>
> Django 1.4 support is mostly there and so far is passing all testing for 
> the site responsible for the backend's existence (http://www.src.org). To 
> help avoid surprises and ensure life as a 3rd party database backend 
> maintainer is a lot less painful, I have set a goal of having django-mssql 
> pass the test suite. This is a non-trivial task that will require changes 
> to django and django-mssql. I've already submitted a few tickets that bring 
> me closer to my goal and it was advised that I send this message as a heads 
> up regarding my intentions to avoid tickets being closed with a "mssql 
> isn't officially supported by Django" comment.
>
> If you review one of these tickets, please keep my goal in the back of 
> your mind. I welcome feedback on better ways of approaching my proposed 
> changes.
>
> Regards,
> Michael Manfre
>

-- 
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/-/9Rq_YaZ8lKsJ.
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: Exception Middleware not run [was Re: Subclass handle_uncaught_exception]

2012-05-17 Thread rorycl 
Hi Tom

Thanks for your email.

On May 16, 4:14 pm, Tom Evans  wrote:
> On Wed, May 16, 2012 at 12:32 PM, Rory Campbell-Lange
>
>  wrote:

> > I have a view raising a specific exception I would like to catch and
> > provide an HttpResponse based on this exception.
>
> If it is one view raising one specific exception, why aren't you
> catching it in that view? Exception middleware is used to provide a
> more generic error page, or for advanced error handling, or to handle
> errors from a number of views. If it is just for one view, one
> exception, it is more coherent to handle the error in the view.

As noted before in this thread I have a lazy rowgetter that only
triggers an exception
 in the template. In other words, the except clause in my view isn't
triggered.

try:
rota = self.model.xmlapi_get_location (**kwargs)
except DBException, e:
code, message = [epart.strip() for epart in e.msg.split(':')]
return HttpResponse(message, status=code,
content_type="text/plain")

> > My middleware is as follows -- its simply a sketch at present:
>
> >    class ExceptCatcher(object):
> >        def process_exception(self, request, exception):
> >            HttpResponse("Error encountered")
>
> Is this code verbatim? If so, you aren't returning the newly generated
> HttpResponse, just creating it.

I'm simply trying to trigger the exception handler in ipdb and that is
not happening
using either either the standard middleware or
decorator_from_middleware
methodologies. I guess this might be because control has passed from
the view?
decorators.py:handle_uncaught_exception _is_ called, but I am unable
to interject my
ExceptCatcher with it.

> These sorts of questions should be on django-users really.

Sorry if this is the wrong place to post. However there are a number
of people on the
web reporting that they are unable to trigger process_exception. Hence
my query here.


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