Match i18n.set_language view next param / Referer header against ALLOWED_HOSTS

[LeMinaw]

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, 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

[Adam Johnson]

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)

--
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/cdc7c839-dd3d-4d21-8d4d-7c377a0e1051n%40googlegroups.com.

--

Adam

[Le minaw]

Thanks for your answer. I'll go point by point through it:

Why would you not use 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.

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.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0QyiumTbcevxriZh09rK8_bptj4U7oDo1XLWJcz%3D6itg%40mail.gmail.com.