> > For exemple, if a user changes language at subdomain.exemple.com/whatever, > by sending a POST request to exemple.com/i18n/setlang, it will be > redirected to exemple.com/.
Why would you not use 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" in examples - it seems "exemple.com" is registered for commercial purposes) On Sat, 3 Apr 2021 at 23:05, LeMinaw <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, > by sending a POST request to exemple.com/i18n/setlang, it will be > redirected to 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, 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. > 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 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/CAMyDDM0QyiumTbcevxriZh09rK8_bptj4U7oDo1XLWJcz%3D6itg%40mail.gmail.com.
