On Mon, 17 Apr 2023, at 04:25, 'Ryan Hiebert' via Django developers
(Contributions to Django itself) wrote:
> I've recently been working with other new frameworks, particularly Remix.
> Coming from Django, which has had excellent CSRF for many years, one of my
> first questions was how to handl
Actually, I attempted to forge POST requests on Django with disabled CSRF
protection – and failed.
Maybe I wasn't creative enough, but modern browsers do indeed have a good
protection against this attack vector.
I therefore welcome this proposal, unless someone can show how to bypass
this protec
I've recently been working with other new frameworks, particularly Remix.
Coming from Django, which has had excellent CSRF for many years, one of my
first questions was how to handle CSRF protection. And the response I got
lead me to the "Lax" SameSite cookie parameter, and that I really wouldn'
When starting a new Django project, the user can select if he wants to
build an API or use the Django template.
If he chooses API, then Django-rest framework will be installed, and then
serializers.py will be added to the folders.
--
You received this message because you are subscribed to the Goo
Hi Adam, Mariusz & Simon,
> The only thing I'm not a fan of in your proposal is repeating the field
name within the check expression, like "price" in
> ... 8< ...
> Perhaps we could support only a special name instead, like “self” or the
shorter “f”?
I was thinking the same thing +1 I wanted to
A setting isn't so mad. Many Django projects I've seen use a similar custom
setting for constructing URLs outside of requests.
One question though, how will we support projects that are served at
multiple domains? Would Django only support the "main" site through
BASE_URL and require you to perfor