Re: Proposal: Track used headers and use that information to automatically populate Vary header.
> Accessing the value of a header doesn't necessarily mean that the response varies based up on, for example it might simply be accessed for storage in informational logs. True, probably a way to access headers without marking them as used would be required - maybe something like request.headers.get(XYZ, vary_response=False). However, right now people are commonly forgetting to patch Vary, which leads to problems with caching. This way - this won't happen ever again; but in some cases, we might make caching less efficient than possible, because somebody used request.headers[XYZ] and not request.headers.get(XYZ, vary_response=False). Given these two cases - I feel that working correctly is more important than perfectly-efficient caching - but opinions here may differ. > Additionally, Request.headers is not the only way to access the values now, Request.META has not been removed. I don't believe any of Django's internal header lookups have been changed to use Request.headers and it's unlike third party packages or applications will ever all be moved. It's not, but we can assume that all this code uses patch_vary_headers correctly, so we don't need to track it here. It's mostly about new code, that's going to be written with request.headers, so that it will work correctly without worrying about the Vary header. > Anyway I'm pretty sure you can write such a middleware yourself, replacing Request.headers with a proxy object (and maybe Request.META too), then adding 'Vary' on the way out based upon accessed keys, at least as a proof of concept. If it gets some usage that would prove it could be valuable to add to Django itself. I guess it isn't something that people are going to be looking for, it's always easier to add that another patch_vary_headers invocation than to add a new package, so the usage won't be high; but I'll probably do so, at least for my own usage. I'm already using it in one project, and I need it in others. On Fri, Jan 25, 2019 at 4:56 PM Adam Johnson wrote: > > On Fri, 25 Jan 2019 at 14:46, Linus Lewandowski < > linus.lewandow...@netguru.pl> wrote: > >> Right now, it's hard to report Vary header correctly. Headers might get >> accessed in many different places, like middlewares, subroutines (which >> can't use patch_vary_headers as they don't have access to the response >> object), etc - and all those cases should be reflected in the Vary header, >> or something might get cached incorrectly. >> >> However, thanks to the newly added request.headers property (see >> https://code.djangoproject.com/ticket/20147 and >> https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e), >> we now have a single place which is used to access request headers. We can >> track which ones were accessed, and then set Vary header automatically, for >> example in a middleware. >> >> What do you think about: >> 1) adding some code to track accessed headers in request.headers, >> 2) adding a new middleware (or expanding an existing one), that sets the >> Vary header based on 1), >> 3) deprecating patch_vary_headers function >> and vary_on_headers/vary_on_cookie decorators and recommending to use >> request.headers instead? >> >> Thanks, >> Linus >> >> PS. This is a follow-up to the >> https://code.djangoproject.com/ticket/28533 ticket. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at https://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Adam > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/LlQtbOm_YWw/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to
Proposal: Track used headers and use that information to automatically populate Vary header.
Right now, it's hard to report Vary header correctly. Headers might get accessed in many different places, like middlewares, subroutines (which can't use patch_vary_headers as they don't have access to the response object), etc - and all those cases should be reflected in the Vary header, or something might get cached incorrectly. However, thanks to the newly added request.headers property (see https://code.djangoproject.com/ticket/20147 and https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e), we now have a single place which is used to access request headers. We can track which ones were accessed, and then set Vary header automatically, for example in a middleware. What do you think about: 1) adding some code to track accessed headers in request.headers, 2) adding a new middleware (or expanding an existing one), that sets the Vary header based on 1), 3) deprecating patch_vary_headers function and vary_on_headers/vary_on_cookie decorators and recommending to use request.headers instead? Thanks, Linus PS. This is a follow-up to the https://code.djangoproject.com/ticket/28533 ticket. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Make bool(AnonymousUser) evaluate to false
In my mental model, the request either was sent by a user (that has a User object) or not (and in this case it should be None, or at least something that works like None). However, looks like the majority of you have a different model, so I'm not going to press for that. On the other hand, maybe it's a good idea to report a warning in the __bool__ method? In most cases, bool(AnonymousUser) is a programming error, and not a valid code, so this might be helpful. We could make it a warning forever, or use RemovedInDjango30Warning, and then switch to return False OR an exception in 3.0. Linus On Thu, Jun 1, 2017 at 9:34 AM Brice PARENT wrote: > Wouldn't that be better placed in a linter library (such as *django_linter > <https://github.com/geerk/django_linter>*)? The syntax is right, it > really does what it describes, but it may be wrongly understood, so the > syntax could be pointed out as possible cause of bug, but the behaviour we > have now seems totally logic and the change would probably have side > effects on many projects. > > I'm not using specific linters other than the one included in PyCharm, but > it would probably be a good idea, when you write "if request.user:" to have > it propose to rewrite it as "if request.user.is_authenticated:" if it's > what we meant. > > -- Brice > > Le 31/05/17 à 18:44, li...@lew21.net a écrit : > > I suggest adding __bool__() method returning False to the AnonymousUser > class. > > This way it'll be possible to check if the user is authenticated by simply > writing "if request.user:" > > It's a frequent source of bugs (at least for me, but probably I'm not > alone) that right now this code returns True for anonymous users. If > unnoticed, such bugs can also lead to security issues. > > Related ticket: https://code.djangoproject.com/ticket/28259 > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > > > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/065eb9a5-d935-466d-a301-d7de87e6fbb0%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/065eb9a5-d935-466d-a301-d7de87e6fbb0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/rGWdttZO06g/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/ba96fd99-43ce-2a0b-b79f-eed955bc7be8%40brice.xyz > <https://groups.google.com/d/msgid/django-developers/ba96fd99-43ce-2a0b-b79f-eed955bc7be8%40brice.xyz?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAB96mebXAH5SLN3p2wDCtvQs4POVD6Xrh-NHOLVM31Q%3DUvX_NQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Make bool(AnonymousUser) evaluate to false
I suggest adding __bool__() method returning False to the AnonymousUser class. This way it'll be possible to check if the user is authenticated by simply writing "if request.user:" It's a frequent source of bugs (at least for me, but probably I'm not alone) that right now this code returns True for anonymous users. If unnoticed, such bugs can also lead to security issues. Related ticket: https://code.djangoproject.com/ticket/28259 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/065eb9a5-d935-466d-a301-d7de87e6fbb0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Integrate dj-database-url into Django
There's also https://github.com/doismellburning/django12factor - and it simplifies all the boilerplate, that is still required in django-environ, into: import django12factorglobals().update(django12factor.factorise()) It would be quite nice if Django supported 12factor configuration natively, or at least with a single function call like this one. Regards, Linus On Sunday, May 28, 2017 at 12:09:57 AM UTC+2, Tim Allen wrote: > > I've recently been introduced to `django-environ`, a similar library that > has additional features to DB connect URLs that we may want to consider: > https://github.com/joke2k/django-environ > > It has the same issue with third party DB engines; for example, I recently > issued a PR to include `pyodbc` as an option. It has some nice newcomer > friendly features, such as a cleaner way of determining BASE_URL / > SITE_ROOT. Have a look at the URL for a good "before" and "after" settings > file example. > > Having full support for .env files would make Django projects easier to > bring in line with 12-factor. > > Regards, > > Tim > > On Saturday, May 27, 2017 at 3:52:23 PM UTC-4, Tom Forbes wrote: >> >> Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any arbitrary >> module you give it. If we accept that then I think we are accepting the >> risk of imports via an attacker controlling environment variables whilst >> Django starts up? >> >> On Sat, May 27, 2017 at 8:49 PM, Tom Forbes wrote: >> >>> > I'm wary of possible security ramifications: if we do this, changing a >>> configuration value will import an arbitrary module, which could make it >>> easier to run arbitrary code in some scenarios. I don't have a clear threat >>> model in mind here, though. >>> >>> Good point, it's not wise to enable this even without a clear threat >>> model. Django does import the settings based on an environment variable, >>> but it's relative and if you can use that to do anything nasty then you're >>> most likely already through the airtight hatch (so to speak). However >>> importing potentially global modules could be bad news. >>> >>> Ignoring it is always an option, but could we not specify that the third >>> party database provider has to be in the `INSTALLED_APPS`? That could >>> provide some form of whitelisting so not any old module is imported. Not >>> sure about any issues that may arise from this though. >>> >>> > One possibility would be to use entrypoints in setuptools, this way >>> 3rd party backends could specify a name which then has a fixed & verified >>> import path. >>> >>> This seems like it could get complex, and be quite unlike anything else >>> in Django. >>> >>> Perhaps just supporting this for first-party database backends is >>> easiest? >>> >>> On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin < >>> aymeric@polytechnique.org> wrote: >>> >>>> Hello, >>>> >>>> I'm wondering what the exact definition of the URL format is. Is it >>>> specified somewhere? Or is it just: >>>> >>>> [engine]://[username]:[password]@[host]:[port]/[name] >>>> >>>> where we create arbitrary [engine] values in an ad-hoc fashion? >>>> >>>> On 24 May 2017, at 21:21, Tom Forbes wrote: >>>> >>>> My two cents: connection strings/database URI's are a feature I've >>>> sorely missed in Django. >>>> >>>> Built-in functionality to convert environment variables like >>>> DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant >>>> DATABASE setting would make some deployment situations a lot simpler. >>>> Currently, unless you use dj-database-uri you have to define a bunch of >>>> ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary >>>> together yourself. >>>> >>>> >>>> Fully agreed. While relatively minor, it's an annoyance. >>>> >>>> How does this library complex keys like OPTIONS, TEST or DEPENDENCIES? >>>> >>>> >>>> I don't think it's reasonable to cram them in a URL. >>>> >>>> dj-database-url allows passing options as extra keyword arguments. >>>> Other values should be explicitly added in the settings module, by >>>> updating >>>> the dict generated from the URL. &
