Re: django-admin startproject settings.py has some security holes

[Adam Johnson]

There is such a link since 2013:
https://github.com/django/django/commit/912b5d2a6bc78067d6a7e130f10514c51bd1a58f

On Thu, 24 Oct 2019 at 23:31, Olivier Dalang 
wrote:

> Hi,
>
> Just a reminder about this page in the docs:
> https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
> It basically already covers it all. Maybe a direct link to that page from
> the settings file would be good enough?
>
> Cheers,
>
> Olivier
>
> On Thu, Oct 24, 2019, 04:45 Josh Smeaton  wrote:
>
>> A quick idea from the top of my head, is to change the assignment of
>> SECRET_KEY in the generated settings to something like:
>>
>> SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY",
>> "insecure-")
>>
>> It signals that secrets in the environment are a good idea, that the
>> default generated value is insecure, and it still has a random part so that
>> default sites aren't automatically hackable when deployed. There's no
>> impact to people just getting started.
>>
>> We could go a small step forward and use `check --deploy` to check for
>> the substring `insecure` (even though I believe the KEY is technically
>> bytes?).
>>
>> Just throwing something out there.
>>
>>
>> On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:
>>>
>>> Is the requirement here to avoid introduce additional barriers to
>>> getting up and running in local development, or to deploying a site so that
>>> it's accessible from the public internet?
>>>
>>> Both of these are important goals, but trading off security against the
>>> latter worries me. I don't think we're doing beginners any favors if we
>>> make it easier for them to deploy sites with security issues, especially
>>> since they won't be in a good position to appreciate the consequences.
>>> Ideally we'd make it easy for beginners to deploy sites without security
>>> issues, but that's a hard problem given the diversity of production
>>> environments; in the meantime, I think we need to accept the reality that
>>> figuring out how to store secrets *is* a prerequisite to deploying Django
>>> in production, notwithstanding how much we wish it weren't.
>>>
>>> I'd be interested in trying to contribute a solution more secure than
>>> the status quo without introducing more barriers to local development, if
>>> it would have a chance of being accepted.
>>>
>>> Taymon
>>>
>>> On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:

 It's just scope:

* Not clear we need to _replace_ the space for books, and blog
 posts, and so on, in the main docs.

 and bandwidth:

* These things are difficult to get right, and it needs someone to
 do them. (PRs always warmly received!)

 On balance, I have to say, I think the default project template does
 very well.
 Taking a beginner, say, and adding, "As well as the million things
 you're already dealing with, there are these things called environment
 variable and..." is a step I'd be very cautious about taking.

 Yes, granted, for professional deployment, you might want different —
 but we have to serve everyone.

>>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAExk7p0%3DzRMJi1ObZnSuKncYgXVuNT-k%3DqMj5ONVuEN_nVTEQw%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3jxm_x41otzdsqWeKG2munqrX5eqM-SG8kK_B9Y06c_w%40mail.gmail.com.

Deprecate HttpRequest.is_ajax

[Adam Johnson]

Django's HttpRequest.is_ajax method determines whether the request was made
with the JS API XMLHttpRequest
https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
. It does so by checking the X-Requested-With header.

The new way of making "AJAX" requests from the browser is the JavaScript
fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API .

I think the  is_ajax() documentation is at least a little misleading in
pretending XMLHttpRequest is the only JS API. There also aren't any special
headers set by fetch() so it's not possible to detect its requests.

I propose deprecating is_ajax() with no replacement.

Thoughts?

-- 
Adam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Tom Forbes]

I would agree. Flask has done the same:

DeprecationWarning: Request.is_xhr is deprecated. Given that the 
X-Requested-With header is not a part of any spec, it is not reliable

In my opinion there are not many good reasons to have to change behaviour if a 
request is made via XHR. I think the most common usage is to have a single view 
that returns a JSON response or a HTML response depending on if XHR is used 
(https://github.com/search?l=Python&q=request.is_ajax&type=Code 
), which isn’t 
great and isn’t reliable.


> On 16 Nov 2019, at 16:08, Adam Johnson  wrote:
> 
> Django's HttpRequest.is_ajax method determines whether the request was made 
> with the JS API XMLHttpRequest 
> https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
>  
> 
>  . It does so by checking the X-Requested-With header.
> 
> The new way of making "AJAX" requests from the browser is the JavaScript 
> fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API 
>  .
> 
> I think the  is_ajax() documentation is at least a little misleading in 
> pretending XMLHttpRequest is the only JS API. There also aren't any special 
> headers set by fetch() so it's not possible to detect its requests.
> 
> I propose deprecating is_ajax() with no replacement.
> 
> Thoughts?
> 
> -- 
> Adam
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es.