Thanks for your answer. I'll go point by point through it:
Why would you not use subdomain.example.com/i18n/setlang
<http://subdomain.example.com/i18n/setlang> to change the user's
language? That seems like it would work.
It would, but then the setlang view has to be routed to all subdomains.
Why this might not be a big deal if you only have a few subdomains, one
might argue it violates DRY. Also, that would mean extra work will be
needed when reversing the setlang pattern (e.g. in templates), as each
subdomain would have to reverse to its own setlang pattern.
I'm not sure Django should support your suggested way of splitting up
domains out of the box.
I don't think Django should *support* multi-tenancy functionnality
either, as almost every part of the framework is
subdomain/host-agnostic. It is fine to rely on third-party packages for
this.
In fact, this is basically my point: as the rest of the framework, I
think the setlang view has to be host-agnostic. While having a safeguard
on both the Referer and next param might be a good thing, I don't see
any good reason to enforce this kind of specific behavior.
In my experience multi-domain setups are very diverse. Every site
seems to divide functionality and auth between domains differently.
Agreed, and in my opinion, this is exactly why this rather strict
behavior is not a good thing. I think the framework and its components
should be as unopinionated as they can -reasonnably- be.
Ultimately the set_language view is "set a cookie and redirect" and I
don't think that's much functionality to reimplement yourself, as a
cost for choosing a particular pattern of splitting up functionality
between subdomains.
For sure it is not, and that is exactly what we are doing for now
(basically, remplementing the view in a separate app only for this). I
just thought it would be a good improvement of the framework, that would
save extra work -and I can't think of any drawback of matching against
ALLOWED_HOSTS instead of restricting to the current host.
Le 04/04/2021 à 13:23, 'Adam Johnson' via Django developers
(Contributions to Django itself) a écrit :
For exemple, if a user changes language at
subdomain.exemple.com/whatever
<http://subdomain.exemple.com/whatever>, by sending a POST request
to exemple.com/i18n/setlang <http://exemple.com/i18n/setlang>, it
will be redirected to exemple.com/ <http://exemple.com/>.
Why would you not use subdomain.example.com/i18n/setlang
<http://subdomain.example.com/i18n/setlang> to change the user's
language? That seems like it would work.
In my experience multi-domain setups are very diverse. Every site
seems to divide functionality and auth between domains differently.
I'm not sure Django should support your suggested way of splitting up
domains out of the box. Ultimately the set_language view is "set a
cookie and redirect" and I don't think that's much functionality to
reimplement yourself, as a cost for choosing a particular pattern of
splitting up functionality between subdomains.
(P.S. in future please use "example.com <http://example.com>" in
examples - it seems "exemple.com <http://exemple.com>" is registered
for commercial purposes)
On Sat, 3 Apr 2021 at 23:05, LeMinaw <lemi...@gmail.com
<mailto:lemi...@gmail.com>> wrote:
Hello,
I'd like to get some input about a -rather simple- suggestion
concerning the set_language view.
According to the docs, for now:
/After setting the language choice, Django looks for a next
parameter in the POST or GET data. If that is found and Django
considers it to be a safe URL (i.e. *it doesn’t point to a
different host* and uses a safe scheme), a redirect to that URL
will be performed. Otherwise, Django may fall back to redirecting
the user to the URL from the Referer header or, if it is not set,
to / [...]./
Note: looking at the source
<https://github.com/django/django/blob/8f6a7a0e9e7c5404af6520ae606927e32415eb00/django/views/i18n.py#L43>,
the Referer header host is checked in the same way the next
POST/GET params are (it is not that clear in the docs atm, but
that is another story :) ).
While this behavior seems reasonable, it is not conveniant at all
when dealing with multi-tenancy (i.e. when Django serves requests
from several subdomains).
For exemple, if a user changes language at
subdomain.exemple.com/whatever
<http://subdomain.exemple.com/whatever>, by sending a POST request
to exemple.com/i18n/setlang <http://exemple.com/i18n/setlang>, it
will be redirected to exemple.com/ <http://exemple.com/>.
As the title suggets, this could be avoided by matching both the
next param and the Referer header to the ALLOWED_HOSTS setting
instead of restricting it to the current host only (taking
wildcards, such as .exemple.com <http://exemple.com>, into account).
If this looks like a good improvement to you, I can start filling
a ticket/working on a patch for this.
Kind regards,
Renaud
--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/cdc7c839-dd3d-4d21-8d4d-7c377a0e1051n%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/cdc7c839-dd3d-4d21-8d4d-7c377a0e1051n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
Adam
--
You received this message because you are subscribed to a topic in the
Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-developers/fjrDmq1KSAQ/unsubscribe
<https://groups.google.com/d/topic/django-developers/fjrDmq1KSAQ/unsubscribe>.
To unsubscribe from this group and all its topics, send an email to
django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM0QyiumTbcevxriZh09rK8_bptj4U7oDo1XLWJcz%3D6itg%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMyDDM0QyiumTbcevxriZh09rK8_bptj4U7oDo1XLWJcz%3D6itg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/58596175-5242-9921-a451-d57d7d67b4c6%40gmail.com.
