Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``
Thanks for the report -- but is there a particular reason that you're reporting this here, rather than on the ticket tracker? Yours, Russ Magee %-) On Mon, May 14, 2012 at 9:55 AM, Yo-Yo Ma wrote: > A request to: > > http://www.example.com:8080//foo-bar-baz.html > > leads to request.build_absolute_uri() returning: > > http://foo-bar.html > > -- > 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. > -- 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.
Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``
A request to: http://www.example.com:8080//foo-bar-baz.html leads to request.build_absolute_uri() returning: http://foo-bar.html -- 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.
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.
Re: Proposal: Signal connection via "my_app.MyModel"
It would not be a "hard link". Do you know the definition of "dependency graph", and do you know anything about Django's internals or about how Django already allows you to connect models' foreign keys this way? It would be simply "get me the model 'MyModel' from the app 'my_app'". The app could easily be moved around, and no extra imports would be used in the process (see models.get_models()). This gives you the ability to move the app around easily. The real benefit in my oppinion would be the ability to connect signals for models from app A inside of app B without having to worry about import order or errors, due to some crisscross in app A's dependency graph. On May 12, 4:24 am, Dougal Matthews wrote: > On 9 May 2012 22:14, Yo-Yo Ma wrote: > > > This would allow for better decoupling of code, as well as a far > > cleaner dependency graph. > > The dependancy will still be there, the string containing the dotted path > would be a hard link. However, this will be hidden and a less obvious > dependancy than a normal Python import. > > So, I'd be -1 as I don't see the advantage of this and rather it just adds > further complexity. -- 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.contrib.auth.models.get_hexdigest missing in 1.4
Hi, On Sun, May 13, 2012 at 3:08 PM, Shai Berger wrote: > Hi, > > In the process of upgrading to Django 1.4, I've run into a little problem: one > of our files uses django.contrib.auth.models.get_hexdigest, which is no longer > present. > > I searched, and could find no mention of this in release notes, tickets, or > the > developers group. > > Was this, for some reason, not considered a public API? It isn't documented so I believe it has never been part of the public API. > Of course, I can copy the function from a 1.3 installation and use that, but I > suspect that if it was removed, there was a good reason -- and I'd like to > know what it was, before deciding to ignore it... Django 1.4 added pluggable password hashers and this was all abstracted in django.contrib.auth.hashers. If you need to deal with passwords use make_password and check_password from this module: https://docs.djangoproject.com/en/dev/topics/auth/#manually-managing-a-user-s-password Regards, Bruno -- 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.
django.contrib.auth.models.get_hexdigest missing in 1.4
Hi, In the process of upgrading to Django 1.4, I've run into a little problem: one of our files uses django.contrib.auth.models.get_hexdigest, which is no longer present. I searched, and could find no mention of this in release notes, tickets, or the developers group. Was this, for some reason, not considered a public API? Of course, I can copy the function from a 1.3 installation and use that, but I suspect that if it was removed, there was a good reason -- and I'd like to know what it was, before deciding to ignore it... Thanks, Shai. -- 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.
