The user block was set directly on the User objects,
instead change the enviroment to load the correct block.
This is done by inserting the block into the database via
DatabaseBlockStore, that is enought for user blocks.
For ip blocks also the connection between the blocked ip and the testing
user has to be prepared, that is done via global state, similiar to a
user session.
Not setting User class internals helps on deprecation and remove of
class properties
Change-Id: I4ceec2c1a998e962648669c43fb8cf812fab8432
This call was added in 04bdfa50f0, so that
errors for global blocks would be displayed properly.
The GlobalBlocking extension now does this via the GetBlockErrorMessageKey
hook, since I92a426745a9a4cb05beb0d546c238c2826a2b615.
Bug: T322553
Change-Id: I0a996da46e50a95d0664e87b6f800c500f946092
The authentication provider's testUserForCreation() method is for
checking whether a given user name is available. The current
user being IP-blocked has nothing to do with that username's
availability so stop checking that. (AuthManager will check it
via AuthManager::authorizeCreateAccount() elsewhere. Although
that method doesn't seem to be doing anything useful and could
probably just be replaced with a direct call to
PermissionManager, but that's left for a separate, less risky
patch.)
Special-case autocreation though, which doesn't use
the more appropiate AuthManager::authorizeCreateAccount() for
performance reasons so it does need an IP block check.
(At least I think it is for performance reasons. Maybe it's
just an unintentional omission, and that should be used instead?)
While we are at it, also fix a TODO in AuthManager where partial
blocks were taken into account for $wgBlockDisablesLogin, and
clarify in the config schema that they aren't, improve some
comments to make it more obvious why some things are/aren't
done in CheckBlocksSecondaryAuthenticationProvider, and make
the logic more similar to the one in testUserForCreation().
Functional changes:
* Partial blocks are ignored for authentication, account
creation and autocreation.
* On $wgBlockDisablesLogin wikis IP blocks won't prevent
login anymore.
* On $wgBlockDisablesLogin wikis, blocks will now prevent
account autocreation even if they are not configured to
prevent account creation. The assumption is that on such
wikis account creation is restricted via some means.
This probably isn't necessary as blocks should also prevent
the conditions needed for autocreation (e.g. log the user
out centrally), but can serve as defense in depth.
Along with the special-casing of autocreation, this means
on such wikis any IP block will prevent autocreation, which
is not great but seems not worth even more code complexity
to avoid.
* The action=query&list=users&usprop=cancreate API won't take
blocks into account anymore.
Bug: T306018
Bug: T208895
Change-Id: Ie94d61640301192b287275311f3452e606469d25
Make the tests clearer and more comprehensive. They won't make much
sense for the current business logic but make upcoming changes
easier to verify.
Change-Id: I2d2407c6b02a13a1c6c2543798bd175225338f90
createMock() is still relatively new. This code was using more
complicated mock builders before. This was changed just recently.
createMock() is now so short, the extra helper methods don't make
the code more readable, I would argue.
Change-Id: Ia7e24827157d5f49fc7da102418c79ae33c8e053
This sets MainCacheType to 'hash', so the main cache is functional
within test cases. Between tests we are already calling ObjectCache::clear,
so the cache will not leak data into other test cases.
It turned out that the way we have been overriding configuration
settings in MediaWikiIntegrationTestCase is insufficient, since the
overrides would only apply in the main Config object, not in global
variables. This means they could not be overwritten with setMwGlobals.
So this patch also changes how we apply config overrides for test setup.
Config overrides that happen during tests work as before.
Depends-On: Ic36e92b73f22fd64e2d0b680d8e900f598158460
Change-Id: Ia60cb0bc18b235f23d9778da8241f65accfc0d35
The main object cache is disabled during testing. Some integration tests
need it though. This provides a clean way to enable it, to replace the hacks
that were used so far.
Note that we may want to enable the main cache during testing soon. When
that happens, this method is still useful to disable the cache in certain
tests, and to set a specific cache instance.
Change-Id: I04ae1bf1b6b2c8f6310acd2edf89459d01a9c870
overrideConfigValues() is introduced as a replacement for
setMwGlobals(). Since we are moving away from reading configuration
from global variables, test cases should not use global variables to set
configuration.
Bug: T294739
Change-Id: I9d41045bd13932bd853f53e00322233fc4f1321c
Deprecate AuthManager::checkAccountCreatePermissions in favour of
::authorizeCreateAccount, for full permissions checks and
::probablyCanCreateAccount, for quick permissions checks.
Update SpecialCreateAccount to use the appropriate checks, and
add SpecialCreateAccountTest.
Bug: T283265
Change-Id: I385f2b56ef61f64a4c61e9c97683bef564892dce
This reverts commit ec3da4589bebeb46d7f1544dc46f24baec334966.
Caused frequent session loss in the Wikimedia cluster.
Bug: T299193
Bug: T309616
Change-Id: I3a410df88071d72078672cf1b670e81c11b28117
(cherry picked from commit d1a1fcedc9eace8a5f4a8454eff44a7ed898848a)
The getConfig of a ContextSource should only be used, if the
ContextSource is available. Getting the global context just for the
config looks harder to fix/inject as using the MainConfig from
MediaWikiServices
Change-Id: Iaf14bfc7bd68cc315672e1c256887faf87e22542
SessionBackend::resetId() is prone to race conditions with
cookie-based session providers, where MediaWiki receives
a request with the old session and forces the client to log
out. To handle that, add a tombstone mechanism to
SessionBackend, so instead of deleting the old session from
the store on ID reset, it is marked as invalid. Tombstoned
sessions are handled as nonexistent ones, except unpersist()
is not called.
Unlike Iffd69c7f246adff40b07668328a07329440dbd6f this doesn't
prevent overwriting the session if the MediaWiki endpoint calls
persist() or unpersist(), but it is vastly simpler, and very
few endpoints persist the session.
The behavior of SessionManager::loadSessionInfoFromStore()
with a tombstoned session and SessionInfo::forceUse()===true
does not make much sense, but that's a nonsensical scenario
in the first place (it only happens when the session provider
returns true from persistsSessionId() but sets the forceUse
flag which is meant for providers which can't change the
session ID) and we are only really concerned here about
cookie-based sessions anyway.
Bug: T299193
Change-Id: I3a76b67aa51159ebf0195db15cf7c34e00a64a2e
Add a hook "TempUserCreatedRedirect" which allows an extension to modify
the post-save redirect after a temporary user is created. CentralAuth
will handle this hook in order to redirect to loginwiki. Loginwiki will
redirect back to the page being saved.
In LoginHelper::showReturnToPage add an "anchor" parameter to specify
the URL fragment to redirect to. This is intended for section editing
with a redirect via loginwiki.
In AuthManager::autoCreateUser(), just allow any valid username, don't
require it to be creatable. Previously a non-creatable username was
allowed only with $source=AUTOCREATE_SOURCE_TEMP, but CentralAuth
depends on user autocreation from the session during refreshCookies. The
session is already validated at this point, so it's not like a user can
exploit this to create arbitrary names.
Change-Id: I623330dbf5d0573c93ae22f962618d6ddbd126d9
This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
All callers in Wikimedia gerrit repos have since been migrated to
incrWithInit(), which is usually what is desired and is easier to
implement in various backends. Newer memcached versions of the
memcached protocol even support auto-initializing increments
(including an initial TTL) via the 'ma' command. The incr()/decr()
methods currently bloat the interface and subclasses (often with
slow and buggy implementations). These methods are also hard to
implement in a multi-DC store (either extremely slow or racey)
even though callers might assume they handle high concurrency.
Also, force each MediumSpecificBagOStuff subclass to implement
incrWithInit() instead of having some rely on the base method
In mcc.php, add incrWithInit() and simplify parameters, making
it possible to test non-memcached backends.
Change-Id: I53c9c2c839a1e71d5c104913fea0680c30d11108
Without a default the preference is treat as unknown and possible values
identical to the default are not excluded from javascript code or
database.
Bug: T291748
Change-Id: I37cf1cd87a5ef1fd91aba0c3cc4b0e3f9c9c08b4
This reverts commit ecf826a2ee.
Reason for revert: need to edit the patch and then it will be GTG in order to finish hard deprecating of User ::getCanonicalName, ::isUsableName, ::isCreatableName
Change-Id: I2f57f56728fcbeada96dc2228f07dc8bcaa5d4f6
Create new AuthenticationProviderTestTrait and AuthenticationProviderTestTrait
::initProvider method. Replace uses of AbstractAuthenticationProvider::init with new method in
tests.
Bug: T282781
Change-Id: Ie65c7558bfbacbf6678eea77e4a9b2cf68026456
Replacing the mock InterwikiLookup used in
MediaWikiTitleCodecTest revealed that that test was,
because of the mock not behaving correctly, testing the
wrong thing - interwiki prefixes are *not* case sensitive,
and are always converted to lowercase in the actual
ClassicInterwikiLookup. Fixed those expectations.
Change-Id: I242431e88860b7700a9f93f77a0fe195fd748800
