Re: Proposal: Constructing urls outside the request cycle

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

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 perform URL construction for other domains as
required?

On Thu, Apr 6, 2023 at 8:11 AM Sarah Boyce  wrote:

> Hello 👋
>
> This is a summary of some previous discussions which need opening up to
> the group 👍
>
> There is a need to have some kind of URL outside the request cycle (such
> as sending emails which need to create a link).
> For constructing a correct MEDIA_URL / STATIC_URL we wanted to use the
> script prefix to allow for more dynamic changes (ie allow a user to move to
> a subpath without having to change multiple variables). In the request
> cycle you can use get_script_prefix() for this but outside the request
> cycle this isn't currently very achievable (see related tickets #34028
>  #16734
> ).
>
> There is a current proposal from @Florian Apolloner:
> "I am really starting to lean towards introducing a setting (yes!) called
> BASE_URL that can be set to https://mysite.com/subpath. This would allow
> for a) generating URLs outside a request context and b) allow us to mostly
> ignore script prefix. We could also use a relative STATIC_URL and append it
> to BASE_URL. This way there would be just one setting that requires
> changing and many projects hopefully would make that configurable via env
> vars etc."
>
> New settings are a little controversial, so what do you think about this
> approach? Are there any other ideas or concerns?
>
> --
> 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/df82f370-e96a-498c-ac08-89d34d5cadd5n%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/CAMyDDM1Hwy5rd1j36BLt%3DeHzqaae6ypNqh_DYYZwfFAqg0f%2B7A%40mail.gmail.com.

Re: Proposal: Check constraints at the model field level

[David Sanders]

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 throw up the proposal to
elicit ideas on this because I wasn't sure whether reserving a field name
like this might've been the way to go 🤔


> but it should be noted that SQL has both CHECK on the field and table
level
and from Simon:
> CREATE TABLE / ADD COLUMN checks on the field level are really just
syntactic sugar for checks at the table level

Simon is correct here in that checks at column & table level are both
declarations for the same underlying mechanism (at least from what I've
seen with Postgres & MySQL).


> This proposal is not really nice from a maintenance point of view

Felix if there was no maintenance headache would it sound like a good idea
though? What if there was some way to make it work nicely? I was wondering
what ways that could be achieved:
 - if you use db_check() then there's no migration state conflict; only
potential conflict in the database which would be resolved with unique
constraint naming.
 - as an alternative could it somehow then be syntactic sugar to add to
meta.constraints? this would then have the benefit of automatically being
added to validation. The catch is migrations would need to take the fact
that fields could add to meta into consideration because from what I've
seen it keeps track of the "original" user-defined meta options.


On Fri, 7 Apr 2023 at 04:55, charettes  wrote:

> Small clarification here.
>
> > it should be noted that SQL has both CHECK on the field and table level,
>
> From my understanding CREATE TABLE / ADD COLUMN checks on the field level
> are really just syntactic sugar for checks at the table level like just
> like `REFERENCES` usage is syntactic sugar for foreign key constraints.
>
> > This is not true for unique constraints or indices.
>
> Unique constraints can be defined using the UNIQUE keyword just like CHECK
> is used to define a check per field, it's really just a different way of
> defining that a unique constraint on a field must be created.
>
> The question of whether or not we want to provide some Django syntactic
> sugar in the form of `Field.check` and the benefits it might provide to
> third-parties (and even ourselves for dog fooding PositiveIntegerField)
> remains but I think that it's important to point out that there's no
> distinction between field and table level constraints at the database level
> AFAIK (for Postgres and SQLite at least).
>
> Simon
> Le jeudi 6 avril 2023 à 01:47:48 UTC-4, Adam Johnson a écrit :
>
>> Mariusz, I agree with the burden, but it should be noted that SQL has
>> both CHECK on the field and table level, and CheckConstraint only defines
>> table-level constraints. This is not true for unique constraints or indices.
>>
>> Also, what do you think of a way for custom field classes to add
>> constraints, at least? db_check() is somewhat limiting given it must return
>> raw SQL, plus it's undocumented.
>>
>> On Thu, Apr 6, 2023 at 5:11 AM Mariusz Felisiak 
>> wrote:
>>
>>> Hi,
>>>
>>> This proposal is not really nice from a maintenance point of view as we
>>> will end with the same complicated situation we currently have with
>>> uniqueness checks or indexes i.e. many ways to define the same:
>>>
>>> - Field.unique/index
>>> - Meta.unique_together/index_together
>>> - Meta.constraints/indexes
>>>
>>> It's especially error-prone in migrations and different database
>>> behavior on fields already covered by the same constraints/indexes. I'm
>>> pretty sure that we've introduced Meta.contraints/indexes to avoid this
>>> happening in the future, and we are rather leaning to leave only
>>> Meta.constraints/indexes and remove other options in the future. Not
>>> creating a new one.
>>>
>>> Initial -1 from me.
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>>
>> 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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/954af838-2176-4877-b4ac-70525cddcbf5n%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/58ab388c-285

Select API choice when starting new project.

[Daniel Azubuine]

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 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/CAHRz_NYh8NpHzVGZ4PFNFc86Fz51uuwz%2BiTQAyR7hvXJFop7eg%40mail.gmail.com.

Drop CSRF middleware from the settings template

['Ryan Hiebert' via Django developers (Contributions to Django itself)]

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't 
need more than that for the session cookie.

It appears that Django has defaulted the session cookie to `Lax` since the 
SESSION_COOKIE_SAMESITE parameter was added in Django 2.1. All current 
browsers seem to have supported it since 2019. Is it time for us to remove 
the CSRF Middleware from the default settings template file?

-- 
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/f5c90c5e-a7b1-49f2-84da-0cce32f6f67dn%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

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 protection.
– Jacob

-- 
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/2b349cdb-7502-4d6d-b299-cf62e1edc265n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Curtis Maloney]

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 handle CSRF protection. And the response I got 
> lead me to the "Lax" SameSite cookie parameter, and that I really wouldn't 
> need more than that for the session cookie.

I think I missed a detail here.

What problem are you having with using CSRF?

What response did you get?

Was it different to what's in the Django docs here ?
https://docs.djangoproject.com/en/4.2/howto/csrf/#using-csrf-protection-with-ajax

> 
> It appears that Django has defaulted the session cookie to `Lax` since the 
> SESSION_COOKIE_SAMESITE parameter was added in Django 2.1. All current 
> browsers seem to have supported it since 2019. Is it time for us to remove 
> the CSRF Middleware from the default settings template file?

Are you implying that all CSRF attacks protected by Django's current machinery 
are entirely mitigated by SameSite=Lax on the _session_ cookiue?

--
Curtis

-- 
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/2398009a-928d-444e-888e-ed901f2b55de%40app.fastmail.com.