I do like this suggestion. I also find the current behaviour surprising. Do you have a plan for implementation? I guess this would have to go through the regular deprecation pathway?
On Tue, Oct 4, 2022 at 4:32 PM אורי <u...@speedy.net> wrote: > Hi Shai, > > Actually, I think this issue is very similar to what I wrote in the thread > of "Model-level validation". I have been using Django for 6 years, and I > was not aware that one can call translation.activate() with a language not > in django_settings.LANGUAGES. I was thinking this would raise an exception, > which it should in my opinion. If the language is not > in django_settings.LANGUAGES, so there are probably no .po files to > translate it, so all its strings will remain untranslated. I checked and we > have a few tests in Speedy Net, where we check if we can > call user.speedy_match_profile._set_active_languages with an unsupported > language, and it does raise an exception when saving the model. The field > is defined in a way that it has only specific valid choices. You can see > for example the following tests: > > > https://github.com/speedy-net/speedy-net/blob/master/speedy/match/accounts/tests/test_models.py#L767-L786 > > Another thing - we don't call translation.activate() with a language code > received from the user. Instead, we check our own language codes and > call translation.activate() if one of them matches the URL. Otherwise we > redirect to the default URL. I think one should never call > translation.activate() with a language code received from the user. > > for language_code, language_name in django_settings.LANGUAGES: > if (domain == > "{language_code}.{domain}".format(language_code=language_code, > domain=site.domain)): > translation.activate(language=language_code) > request.LANGUAGE_CODE = translation.get_language() > return self.get_response(request=request) > > Or, alternatively, you can check if the language_code is > in django_settings.LANGUAGES, and only then activate it. > > Thanks, > Uri Rodberg, Speedy Net. > אורי > u...@speedy.net > > > On Tue, Oct 4, 2022 at 5:05 PM Shai Berger <s...@platonix.com> wrote: > >> Hello Djangonauts, >> >> This suggestion is following from discussions of the security issue >> which was resolved in today's release. In essence, the issue is that >> language codes are optionally used as prefixes in URLs, and for this >> use they also become part of regular expressions used by the URL >> resolution mechanisms. So, if an attacker manages to convince the >> server to use a "language code" which encodes a pathologically complex >> regex, the server can be DOS'd. The solution was to modify the >> regex-inclusion part to regex-escape the language code -- ensuring >> that language codes are never interpreted, in this role, as anything >> other than a simple chain of single characters. This is the proper >> security fix: Prevents the problem where it could manifest, with >> minimal effects elsewhere. >> >> But looking forward, I think we should reconsider the fact that >> django.utils.translation.activate() will just activate whatever >> language code it is given. We do have a setting, LANGUAGES, which >> defines a list of the languages (and codes) supported by our site. Why >> should activate() accept anything that is not in this list? >> >> Two points have been raised in support of the current behavior: The >> existence of custom languages, and of fallback language codes (that is, >> e.g where the user asks for zh-hk and gets, instead, zh-hant). But in >> my opinion, they do not justify it: >> >> - A custom language should be included in settings.LANGUAGES if it is >> to be supported; otherwise, e.g. makemessages will not even handle >> its translation file. >> >> - When a language with a fallback is requested, the site should really >> activate the fallback language, not pretend to activate the requested >> one while actually using the fallback. As an example, if "en-us" is >> used as a fallback for "en-gb", and the URL has "en-gb" in it, then a >> British user would rightly be offended by all the American spelling >> they would see. The site should be honest enough to say "yes, you >> asked for en-gb, but we fell back to en-us; sorry, that's the best we >> have for you". >> >> Note that there are all sorts of functions that check if a language >> code is valid. For example, django.views.i18n.set_language() checks if >> a translation for the languages exists in the project or its apps (but >> not, AFAICT, the setting). d.u.translation.get_language_from_request() >> and get_language_from_path() do check the LANGUAGES setting. It is >> likely that including the check in activate() will do some double work. >> And yet, we found ourselves introducing the security fix. >> >> (I should note that this suggestion was also, independently, raised by >> Benjamin who reported the vulnerability) >> >> Opinions, suggestions, and explanations of the value I miss in allowing >> activate() to take random language codes welcome. >> >> Thanks, >> Shai. >> >> -- >> 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/20221004170511.4342ebc7.shai%40platonix.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/CABD5YeGxg1ogazpQE2YqAVq_P8RbhDSK0UPfw2yy6oc%3DUOjWow%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABD5YeGxg1ogazpQE2YqAVq_P8RbhDSK0UPfw2yy6oc%3DUOjWow%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/CAMyDDM2Td9f62rn2MEpoNKY-BCdgGCfjS0Q-JdJFGKK-9x1rJw%40mail.gmail.com.
