On 31 Aug 2015, at 14:24, Carl Meyer wrote:
This solution is more powerful than just using CSRF_COOKIE_DOMAIN,
since
it also allows for separate-domain CORS situations in addition to
cross-subdomain requests. So I would consider this to be a good fix
for
\#24496; I don't think we need another
On 08/31/2015 12:09 PM, Joshua Kehn wrote:
> On 31 Aug 2015, at 14:02, Tim Graham wrote:
>
> Is this related or duplicate to
> https://code.djangoproject.com/ticket/24496?
> That ticket has a patch that got stalled a bit, but might be worth
> reviving
> first in case this new o
On 31 Aug 2015, at 14:02, Tim Graham wrote:
Is this related or duplicate to
https://code.djangoproject.com/ticket/24496?
That ticket has a patch that got stalled a bit, but might be worth
reviving
first in case this new one causes it to go stale.
Looks related.
If we decide to go with Troy
On 31 Aug 2015, at 13:56, Carl Meyer wrote:
> No, I don't think `*` should be allowed in `CSRF_TRUSTED_REFERERS`; I
> don't think there is any scenario in which that is a safe or reasonable
> configuration.
>
> And I think that the fact that it's allowed in `ALLOWED_HOSTS` might be
> a reason to j
Is this related or duplicate to https://code.djangoproject.com/ticket/24496?
That ticket has a patch that got stalled a bit, but might be worth reviving
first in case this new one causes it to go stale.
On Monday, August 31, 2015 at 1:37:45 PM UTC-4, Joshua Kehn wrote:
>
> On 31 Aug 2015, at 13:
On 08/31/2015 11:37 AM, Joshua Kehn wrote:
> 2) If it's set, a match with the Host header (or maybe with any host in
> |ALLOWED_HOSTS|) should still be allowed, so you aren't forced to
> duplicate |ALLOWED_HOSTS| inside |CSRF_TRUSTED_REFERERS|.
>
> So the check here would look somethin
On 31 Aug 2015, at 13:25, Carl Meyer wrote:
A couple follow-up thoughts:
On 08/31/2015 11:22 AM, Joshua Kehn wrote:
On 31 Aug 2015, at 13:21, Carl Meyer wrote:
I think it would make sense to just add a |CSRF_ALLOWED_REFERERS|
setting, defaulting to |None| (which would give the current behavi
A couple follow-up thoughts:
On 08/31/2015 11:22 AM, Joshua Kehn wrote:
> On 31 Aug 2015, at 13:21, Carl Meyer wrote:
> I think it would make sense to just add a |CSRF_ALLOWED_REFERERS|
> setting, defaulting to |None| (which would give the current behavior of
> requiring a match with t
Anyone else see a problem with that that I'm missing?
I think this sounds fine.
You up for filing a ticket and maybe a patch/pull-request too?
Absolutely.
Thanks
--jk
***
[me](http://kehn.us) | [@joshkehn](https://twitter.com/joshkehn)
On 31 Aug 2015, at 13:21, Carl Meyer wrote:
Hi Jos
Hi Josh,
I think it would make sense to just add a `CSRF_ALLOWED_REFERERS`
setting, defaulting to `None` (which would give the current behavior of
requiring a match with the `Host` header). If set, it would be a list of
valid referer hosts. Documentation needs to be extremely clear that you
should
On 31 Aug 2015, at 12:35, Carl Meyer wrote:
I'm not sure what you mean by "unsafe but specifically cross-origin
request" here. I think the point is that the request is in fact safe,
because it's coming from an approved CORS source, but there's no way
to
tell the CSRF middleware that.
Yes, ex
Hi Josh,
On 08/31/2015 09:38 AM, Joshua Kehn wrote:
> I understand why the Referrer check for secure requests is in place.
> What is currently preventing cross-domain API requests is that the check
> is not configurable. I'm talking specifically about requests when
> |request.is_secure()| returns
I understand why the Referrer check for secure requests is in place.
What is currently preventing cross-domain API requests is that the check
is not configurable. I'm talking specifically about requests when
`request.is_secure()` returns `True` and an unsafe but specifically
cross-origin reques
13 matches
Mail list logo
