Follows-up changes I57a8e7ea1b3, I1e76d2f5ae, I98ea4670e8, and
more in a search for "parse_url" in Codesearch (WMF Deployed).
Bug: T319340
Change-Id: I2b389612f4d591080f7e6235ddfc72f832b31143
Follows-up 657872dee5, which fixed `../` access to preserve 0 or 1
above the module base directory. It didn't do that intentionally, but
it was a side-effect of the uncached .length check.
Once the array is empty, we reach the base directory, and interpret
`..` as something to push instead of pop. That's all great.
But, then the next `..` would pop again since it is now non-empty.
Fix this by remembering whether we reached the base, and only pushing
from that moment on. Don't switch from pushing back to popping.
Bug: T373065
Change-Id: I777f2c12e845a738edeac00e19818d4c939a1ef1
This test was added not long ago, see Ie5b8ae4. We see it failing in
unrelated patches, see I7dc9e26. Unfortunately the error message is
not helpful because assert.step() apparently ends being called with
incompatible arguments. This will probably not fix the issue, but
make the output more helpful.
Needed-By: I7dc9e26edc954d195dff8aeefa7d923ea7534fea
Change-Id: I75d74e74eca0bdfb592e2d3ababcaea062d09190
Update a few tests that relied on the feature flag to ignore
the 'requireemail' preference on "User1" to instead use "User2",
who doesn't have the preference set.
Bug: T242406
Change-Id: I996d3996272d704a071d1d2094c3568247b80f98
This method has a weird behavior where it resets the category *link* list
while not resetting the category *list*. It turns out that no one actually
needs that weird behavior; in fact no one needs this method at all, since
the only external user is the Translate extension, which could use the
OutputPage::addCategoryLinks() method instead, which has existed since
2014 (Id25041a7891f588ffa787fdd2c092342eecd30c8).
Deprecate this method with warnings.
Bug: T373480
Depends-On: Id25041a7891f588ffa787fdd2c092342eecd30c8
Change-Id: I7b07d761eb8cd5ad1e6da2dd836e969a0d492c2b
Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
Deprecated since Iaf7bd2986b7f4185923969899d61878e5ee5905b
and no longer it seems used in Wikimedia codebase or gadgets in
Wikidata or Wikimedia Commons, there was one userscript
in English Wikipedia (not a gadget and was in User: namespace),
which I notified them they can just use Vue module.
Change-Id: I0a45d97866519765be5c3bdff9c0a20b003f78ae
Add a new hook that can be used to prevent authentication just
before AuthManager takes the main action (writing the session
for login, creating the local user account for account creation).
The driving use case is a wiki which supports both a local and
a central (wiki-farm-level) login or signup flow - various
security options (such as 2FA) are needed during local login
but unnecessary during central login (which will have those
security features centrally), so we need to skip much of the
security when the user is taking the central route, and a bug
in how that's done could result in circumvention of security
features during local login. The hook makes it easy to inspect
and potentially interrupt login near the end, when we know for
sure what route it took. (Specifically, we know which primary
provider was used. The hook doesn't expose other details,
such as the list of preauth or secondary provders that were
invoked, because they were not needed for the immediate use
case, but they are easy to add in the future.)
The hook is called after the secondary providers for login
and before them for account creation, since secondaries can
interrupt login but cannot interrupt account creation.
A shortcoming is that since the hook is called after a primary
provider succeeded, it cannot prevent the primary provider from
doing work, ie. it cannot prevent creation of the remote account
during account creation (although it will prevent the creation
of the local account). This is not great but acceptable, since
creating a new account isn't very security-sensitive.
This also means the hook would not be useful during account
linking, as AuthManager does not do anything there, all the work
happens in the primary provider. This is even less great but
few authentication extensions implement account linking.
The hook is not called for authentication happening via
CreatedAccountAuthenticationRequest, which is a weird internal
hack hook handlers should not have to know about.
Also rename a confusingly named variable.
Change-Id: I835b2fe2f43e6e81f23348165cbb9c93832e6583
