Now that resetServices() will preserve (but reset) customized services,
it should be reasonably safe to call it every time globals are changed,
and much more effective than relying on tests to call it every time
themselves.
Depends-On: Iab8ea3a61bbc6803805d855ef23c071067646f71
Depends-On: I00e35ecea6a27468674b2a6e7d9d9eb6518e3bd5
Change-Id: Ie7a89f6ed7d52a0bc01672019ff92e7ee105a1f3
For preferences like 'skin' that have a limited number of values, null
is not a valid value, thus attempts to reset them fail with
"Validation error for \"skin\": This value is required."
Bug: T65080
Change-Id: I86554a6d30c8ab970740d8682fb2261476de0677
This normalizes handling of transformations on the boundaries between
preferences and generic form controls and removes the special case
where email-blacklist is passed around as an array internally, leaking
into the API.
As a result of this normalization, meta=userinfo no longer returns an
array of users, using the internal representation like action=options.
Bug: T198935
Change-Id: Iff63da0d215585cfcf083e7f7ec8ed45d5b77301
Directly use the UTF-8 encoding of the 'NO-BREAK SPACE' (U+00A0) instead of
the HTML/XML entities   or   or .
With the UTF-8 character the generated HTML is shorter and better to read.
Also change the special value for the label in HTMLForm from   to
U+00A0 but also support   for backward compability.
Bug: T154300
Change-Id: I882599ac1120789bb4e524c4394870680caca4f4
Quoting PHPUnit docs:
The $index parameter for the at() matcher refers to the index,
starting at zero, in all method invocations for a given mock object.
Exercise caution when using this matcher as it can lead to brittle
tests which are too closely tied to specific implementation details.
Indeed these test cases would break horribly with unintuitive error
messages ("Mocked method does not exist") if anything in preferences
or API code called any additional methods on the mocked user. For
example, it relied on the caching in Preferences::getPreferences(),
which is being removed in I92390120a16448383a25e9ba2dd35a434a2f21bf.
I'm pretty sure all that matters here is that all the setOption()
calls with different arguments happen, so let's test just that.
Change-Id: I30a814151a006e5f147eebb918344049807b2b97
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
* This does the same thing ApiOptions does to avoid these errors.
A new getInstanceForUpdate() method is now in the User class to
simplify this pattern.
* Avoid overriding $user in ApiOptions for code readability.
* Fixed IDEA errors around Preferences::getFormObject() return type.
Bug: T95839
Change-Id: If2385b7486c043bd70d7031ff35e37dfb079a4d2
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
- Removed double spaces
- Added space after if/switch/foreach
- Removed space on elseif
- Added space around parentheses
- Added newline at end of file
- Removed space before semicolon at end of line
Change-Id: Id40b87e04786c6111e6686d7f7eea1e588bdf37d
There are certain preferences, such as realname and emailaddress, that
are handled specially in Special:Preferences and are not accessible by
User::getOptions or User::setOptions. But action=options was allowing
a 'dummy' version to be set in User::setOptions.
Change-Id: I4c1b3d8e1eae9520228d7b6da9c41ada80f7c387
These are needed for OAuth grants.
Note that we don't bother with a 'viewmyoptions' right, since the
majority will be determinable from just observing the interface.
Note that the fact of having a confirmed email address cannot be
reliably hidden, and if the user has 'sendemail' they may be able to
determine the real name and email address by sending an email to another
account that they control.
Change-Id: I3f03dd010020e8d43cc2d3bca7b3ef7196d1c548
Added the "resetkinds" option to action=options, so that when the
"reset" option is set, the user can control which kinds of options
are reset, rather than having to do all or none.
Also added documentation to the "change" parameter, since passing
it option keys without any "=value" after it will result in resetting
that specific option to its default value.
Change-Id: Id5bc1fffa0d487c0f152b79115205d2722f380d3
Before change I98df55f2 it was possible to set arbitrary preferences (ie.
with anything as the key) using the action=options API. That change
removed this ability by enforcing full validation of the preferences, also
introducing several regressions which were fixed by follow-ups.
Per the discussion on bug 40124, this changeset aims to restore this
ability, but in a slightly restricted way: arbitrary preferences' names
must start with userjs- prefix, to avoid any possibility of conflicting
with new MediaWiki versions or extensions.
The contents of these preferences is not escaped, sanitized nor validated
in any way; script authors are expected to sanitize them themselves to
prevent XSS attacks and other security vulnerabilities.
This commit also adds the User::getOptionsKinds() method (to determine
whether given preference keys are used by MediaWiki itself or an extension,
intended to be used via the API, or entirely unknown) and enhances the
User::resetOptions() method to allow for resetting only preferences of
chosen kinds.
These changes allow for fixing of Special:Preferences not to clear those
additional fields when saving user settings.
Change-Id: I5f9ba5b0dfe7c2ea5458d836f03429cf6d93969d
Preferences options using HTMLForm's "multiselect" type are stored in
the user preferences table as one key with a boolean value for each
option in the multiselect. The validation code added in change I98df55f2
does not take this into account, and therefore considers all of these
option keys invalid.
This changeset fixes that, and adds a unit test to verify correct
behavior.
Change-Id: I137c74a6045c7b39e2119a8edde2705738879bc9
Change I98df55f2 broke action=options&reset=1, causing it to return an
error "No changes were requested" rather than resetting the options as
it should. Unfortunately, that change also broke the unit test that
would have caught this regression.
This changeset fixes the bug and the unit tests.
Change-Id: I7fe63640d54efab4572538e9d08f5b75c61243a4
Previously, there was no validation whatsoever and the module would
happily write any preference you asked it to. This, combined with the
fact that the code using the 'editfont' preference didn't perform any
validation or escaping, led to a CSS injection vulnerability.
Using Preferences::getPreferences breaks some existing test cases
because a MockUser doesn't have groups for preferences.
Change-Id: I98df55f2b16ac1b6fce578798b6f58b5dad96775
This commit depends on the introduction of
MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4.
Various tests already set their globals, but forgot to restore
them afterwards, or forgot to call the parent setUp, tearDown...
Either way they won't have to anymore with setMwGlobals.
Consistent use of function characteristics:
* protected function setUp
* protected function tearDown
* public static function (provide..)
(Matching the function signature with PHPUnit/Framework/TestCase.php)
Replaces:
* public function (setUp|tearDown)\(
* protected function $1(
* \tfunction (setUp|tearDown)\(
* \tprotected function $1(
* \tfunction (data|provide)\(
* \tpublic static function $1\(
Also renamed a few "data#", "provider#" and "provides#" functions
to "provide#" for consistency. This also removes confusion where
the /media tests had a few private methods called dataFile(),
which were sometimes expected to be data providers.
Fixes:
TimestampTest often failed due to a previous test setting a
different language (it tests "1 hour ago" so need to make sure
it is set to English).
MWNamespaceTest became a lot cleaner now that it executes with
a known context. Though the now-redundant code that was removed
didn't work anyway because wgContentNamespaces isn't keyed by
namespace id, it had them was values...
FileBackendTest:
* Fixed: "PHP Fatal: Using $this when not in object context"
HttpTest
* Added comment about:
"PHP Fatal: Call to protected MWHttpRequest::__construct()"
(too much unrelated code to fix in this commit)
ExternalStoreTest
* Add an assertTrue as well, without it the test is useless
because regardless of whether wgExternalStores is true or false
it only uses it if it is an array.
Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
During incident response, it was not possible to tell what API modules
were being requested and by whom, since the action parameter is often
posted. This change logs the API parameters whether they are posted or
sent in the query string.
I did try to get the API parameters from the module, but that turns out
to be difficult. Modules create submodules (generators, page sets) as
local variables, which are created in a procedural style and destroyed
before logging is done, so there is no easy way to query them for
parameter lists after execution completes.
In ApiOptionsTest, use a real ApiMain object like all the other API test
cases, rather than a mock object. Otherwise the test fails.
Change-Id: Idc786007fe61811d1874f29b5ce4762dd97b1847
I have created an API module for changing the preferences.
It allows resetting preferences (reset argument) and bulk changes
of preferences (change argument) in a format:
name1=value1|name2=value2
The change argument has a limitation imposed by the current API
implementation as it cannot accept | in values. There is
available a pair of arguments optionname and optionvalue, the
latter accepts values with |.
I have created optionstoken parameter in meta=userinfo to provide
a token. There is already preferencestoken there, but I would
like to have a consistent naming.
Change-Id: I0d6c654a7354ba77e65e338423952a6a78c1150f
