Page MenuHomePhabricator

Drop URL parameter setlang
Open, Needs TriagePublic

Description

At the moment it is possible to change the user interface language with the URL parameter setlang in a GET request. GET should be a safe method which should not change the state of the server.[1]

Bug 49299 gets WONTFIXed by comment 1: "Given that the user will get a popup to switch back easily, and that changing the language (afaict) is just an annoyance for the user, I'm not convinced."[2]
A possibility to switch back does not make this behavior to a safe method.

I suggest to drop the URL parameter setlang completely and suggest two alternatives:

  1. Change the user interface language via API and open the page without parameter in the desired language. Described in bug 44649 and implemented in https://gerrit.wikimedia.org/r/110360 for mw.uls.changeLanguage().

The language can still changed with a single click and the new page has no troublesome URL parameter.

  1. On situations where no API call is possible use uselang instead of setlang and implement a popup to easily keep this language instead of the popup to switch back easily. The user has explicitly to confirm the change of the user setting by a single click. This is important because the link can come from a foreign page.

For a transition time the parameter setlang can have the same behavior as the parameter uselang.

[1] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=49299#c1


Version: master
Severity: enhancement

Details

Reference
bz61115

Event Timeline

bzimport raised the priority of this task from to Needs Triage.
bzimport set Reference to bz61115.
bzimport added a subscriber: Unknown Object (MLST).
Fomafix created this task.Feb 9 2014, 7:28 PM

(In reply to comment #0)

  1. On situations where no API call is possible use uselang instead of setlang and implement a popup to easily keep this language

I might misunderstand some technical details as I'm not part of language engineering, but uselang and setlang feel like two different usecases to me.
I appreciate uselang to be able to quickly and "one-time" test a problem, using values "en" or "qqx", but I'd never want to set qqx as prefered "language". ;)

(In reply to comment #1)

I appreciate uselang to be able to quickly and "one-time" test a problem,
using
values "en" or "qqx", but I'd never want to set qqx as prefered "language".

Languages that are now excluded for setlang like qqx should not present a popup to easily keep this language as default language when given as uselang. So it is not possible to set qqx as preferred language.

You can still use uselang for a quickly and "one-time" test and you can keep this language as default language with a single click on the popup.

I find the setlang parameter useful and I don't see any convincing reason to remove it. I don't consider its availability a problem. It is useful to force a language using a parameter.

Replacing its use in some places, such as mw.uls.changeLanguage() can be considered, but it should not be removed entirely.

(In reply to Amir E. Aharoni from comment #3)

I find the setlang parameter useful and I don't see any convincing reason to
remove it. I don't consider its availability a problem. It is useful to
force a language using a parameter.

setlang is a security risk. Here is a demonstrator for this risk:
https://bugzilla.wikimedia.org/attachment.cgi?id=14788

uselang allows to force a language using a parameter without a risk.

(In reply to Amir E. Aharoni from comment #3)

Replacing its use in some places, such as mw.uls.changeLanguage() can be
considered, but it should not be removed entirely.

In https://gerrit.wikimedia.org/r/110360 is a implementation for mw.uls.changeLanguage() with the same functionality without setlang. Other uses of setlang can also changed on this way.

(In reply to Fomafix from comment #4)

setlang is a security risk. Here is a demonstrator for this risk:
https://bugzilla.wikimedia.org/attachment.cgi?id=14788

Your attachment only proves that the security risk you claim is actually standard behaviour: you have two inclusions there, one of a setlang call and one of userlogout; if userlogout is acceptable, setlang is too.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 18 2016, 6:11 PM

if userlogout is acceptable, setlang is too.

userlogout does not change user settings but setlang changes user settings.

T25227 requires a token for logout.

Legoktm reopened this task as Open.Apr 20 2019, 2:40 AM
Legoktm added a subscriber: Legoktm.

Changing server state like this (user options) should not be possible solely using GET parameters.

jhsoby added a subscriber: jhsoby.Thu, Apr 25, 4:34 PM

Might I suggest that setlang should be changed so it doesn't actually change the language instantly but rather open a dialogue where the user can accept or deny that change?