Update security docs re HOST header and ALLOWED_HOSTS?

['Michael Lissner' via Django developers (Contributions to Django itself)]

There's a vague warning in the security docs 
 
that says:

> many common web servers [have] a configuration that seems to validate the 
> Host header [that] may not in fact do so. For instance, even if Apache is 
> configured such that your Django site is served from a non-default 
virtual host 
> with the ServerName set, it is still possible for an HTTP request to 
match this
> virtual host and supply a fake Host header.

Does anybody know if this applies to *any* other server? The way it causes 
problems in Apache is very specific, and should be really really uncommon 
since the web has moved to HTTPS by default. (If the HOST header on the 
request doesn't match a named virtual host in Apache, and it doesn't match 
a host via SSL's Server Name Indication (SNI), Apache forwards the request 
to the first named virtual host 
).

If there's no other server we know of that this impacts, I'd suggest we 
tighten this warning to explain that it only applies to Apache without SSL, 
or maybe we even remove this warning altogether?

I spent some time today researching this because I wanted to make sure the 
issue didn't apply to the server I'm using (AWS ELB — It doesn't). It's 
always good to clean up old warnings if we can.

Thanks,

Mike

-- 
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/7e8c8674-55a6-4b63-b8d4-7626b56b72e6n%40googlegroups.com.

Re: Status of 4.1 pre-release.

[Florian Apolloner]

On Thursday, May 12, 2022 at 1:33:38 PM UTC+2 thinkwel...@gmail.com wrote:

> > Next step would be someone to pick the preliminary work up and push it 
> forward.
>
> I guess I thought the "preliminary work" was already done. There's a 
> driver written, and a PR for a django backend.
>

I don't think there is a PR anywhere yet. The preliminary work is indeed 
done (or mostly, I do not know the full state of 
https://github.com/dvarrazzo/django-psycopg3-backend/ ), but as Carlton 
pointed out it now needs someone to make a proper PR out of it. That one 
could be you!

Cheers,
Florian

-- 
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/0e25fd8a-6298-4ff7-bb68-a003f6b28a81n%40googlegroups.com.

Re: Status of 4.1 pre-release.

[thinkwel...@gmail.com]

> Next step would be someone to pick the preliminary work up and push it 
forward.

I guess I thought the "preliminary work" was already done. There's a driver 
written, and a PR for a django backend.

I'd asked [Daniel 
Varrazzo](https://github.com/dvarrazzo/django-psycopg3-backend/issues/6) if 
he was planning to do it, and he said:

> I am not actively working with the Django developers: I wrote the driver 
and the first iteration of the backend but I left the ball in their field. 
I give them feedback when they ask, but I'm not doing more than this. 

> You should hear from the Django project about their plans.
On Wednesday, May 11, 2022 at 8:04:20 AM UTC-4 carlton...@gmail.com wrote:

> On Wed, 11 May 2022 at 13:53, thinkwel...@gmail.com  
> wrote:
>
>> Will the psycopg3 backend  
>> land in time for the 4.1 release?  I'm looking forward to it, as it should 
>> support PyPy much better than psycopg2 does.
>>
>
> No. It's not been worked on recently as far as I know. Next step would be 
> someone to pick the preliminary work up and push it forward. (A major 
> feature like that isn't something we'd add to the roster the week before 
> the feature freeze: we'd likely see it coming the whole release cycle.) 
>

-- 
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/f4d15ee7-faee-4841-8518-970ab6a2c1a7n%40googlegroups.com.

Re: Blocking disposable or temporary email addresses

['Adam Johnson' via Django developers (Contributions to Django itself)]

I would say this feature is a bit more questionable these days, since even
big companies like Apple provide "disposable" email addresses for privacy
protection.

And I also agree this would be better in a separate package, where updating
the list of domains would be easier and not tied to Django's eight-monthly
release cycle.

On Thu, May 12, 2022 at 1:09 AM 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> Hi Yonas,
>
> Thanks for sharing this list. Even so, in my opinion, this feature lives
> best outside of Django where it can be appropriately customized as needed
> for a given project.
>
> I hope this helps.
>
> Best,
> Tobias
>
>
> On Wed, May 11, 2022, 6:46 PM Yonas 
> wrote:
>
>>
>> Would syncing the block list from repos like
>> https://github.com/disposable-email-domains/disposable-email-domains
>> (actively maintained since 2014) ease the burden of updating the list?
>> On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote:
>>
>>> On Wed, May 11, 2022 at 2:21 PM Yonas 
>>> wrote:
>>>
 What does the community think about adding a feature to Django where
 disposable or temporary emails are not accepted during account 
 registration?
>>>
>>>
>>> I used to try to do this in my django-registration package, but
>>> eventually gave up on it because maintaining an up-to-date list of all
>>> possible domains and other patterns was not feasible. I expect the same
>>> would be true with Django — it would require frequent updates to the list
>>> of domains/patterns to block, and people would complain that the updates
>>> weren’t fast enough, because Django only releases once a month (and that’s
>>> assuming updates to the blocked email list would be considered for
>>> inclusion in the monthly bugfix releases, rather than only at feature
>>> release updates).
>>>
>>> So I expect this isn’t something Django could or should do.
>>>
>> --
>> 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/b669801b-f695-49c2-9d04-2ff7db74dc58n%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/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%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/CAMyDDM3w6RGHhtj3%3DU7irivW4dbfUmbmZjOT0VdYKSWM9s-Bpw%40mail.gmail.com.