The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Add $wgForceHTTPS. When set to true:
* It makes the HTTP to HTTPS redirect unconditional and suppresses the
forceHTTPS cookie.
* It makes session cookies be secure.
* In the Action API, it triggers the existing deprecation warning and
avoids more expensive user/session checks.
* In login and signup, it suppresses the old hidden form fields for
protocol switching.
* It hides the prefershttps user preference.
Other changes:
* Factor out the HTTPS redirect in MediaWiki::main() into
maybeDoHttpsRedirect() and shouldDoHttpRedirect(). Improve
documentation.
* User::requiresHTTPS() reflects $wgForceHTTPS whereas the Session
concept of "force HTTPS" does not. The documentation of
User::requiresHTTPS() says that it includes configuration, and
retaining this definition was beneficial for some callers. Whereas
Session::shouldForceHTTPS() was used fairly narrowly as the value
of the forceHTTPS cookie, and injecting configuration into it is not
so easy or beneficial, so I left it as it was, except for clarifying
the documentation.
* Deprecate the following hooks: BeforeHttpsRedirect, UserRequiresHTTPS,
CanIPUseHTTPS. No known extension uses them, and they're not compatible
with the long-term goal of ending support for mixed-protocol wikis.
BeforeHttpsRedirect was documented as unstable from its inception.
CanIPUseHTTPS was a WMF config hack now superseded by GFOC's SNI
sniffing.
* For tests which failed with $wgForceHTTPS=true, I mostly split the
tests, testing each configuration value separately.
* Add ArrayUtils::cartesianProduct() as a helper for generating
combinations of boolean options in the session tests.
Bug: T256095
Change-Id: Iefb5ba55af35350dfc7c050f9fb8f4e8a79751cb
Uses User::getNewMessageLinks, which uses Revision objects
Only caller updated to use a new private method
Bug: T253949
Change-Id: I04c0558916e7216540dd7bd12a2a391a1ed7660a
Introduce a UserGroupManagerFactory and UserGroupManager.
The factory utilizes the same pattern as RevisionStore
for access to user groups of a foreign wiki.
Some user group related methods were ported from User
and UserGroupMembership and deprecated, more methods to
be moved over in future patches, not to make this one to large.
Eventually as all the group-related methods are moved and their
usages are replaced, the need for the UserRightsProxy will disappear,
thus it also will be deprecated and removed. Currently for backwards
compatibility, I've had to create artificial UserIdentityValue
objects in some of the deprecated methods to avoid making transitional
temporary methods in the UserGroupManager that would take user ID
instead of the UserIdentity. All of this will go away once migration
to UserGroupManager is completed.
Bug: T234921
Change-Id: If29c6a03dfdbb80b2e846243f7e384b334da9f07
The new HookContainer.php introduces a scopedRegister() method for
temporarily setting hooks. Let's use that in MediaWikiUnitTestCase
and MediaWikiIntegrationTestCase instead of directly accessing
global $wgHooks to do so.
Also introduces setTemporaryHook() and removeTemporaryHook()
methods in MWIntegrationTestCase for easily adding/removing of
temporary hooks.
Bug: T250300
Change-Id: I8cefd41b66f882c53646b76de76c51f0d8730f72
UserTest::testGetNewMessageLinks was sometimes failing under postgres,
when the two revisions got the same timestamp. The reason for this is
that User::getNewMessageLinks() is based on
TalkPageNotificationManager::getLatestSeenMessageTimestamp(). To
reliably test the behavior of User::getNewMessageLinks(), we need to
operate on revisions with distinct timestamps.
Change-Id: I701983c3b241a70167a6bf212c41a6571b9b0f62
In mysql the user_id and user_ip fields are not nullable,
but include a default 0 and '', however in Postgress the default
was not set, while user_id was set to not nullable. In the
code that uses this table, we set either user_id or user_ip
depending on whether the user is anon or registered. Thus both
fields should either be nullable, or contain a default.
Given that mysql has defaults set, I've opted for bringing
Postgress closer to what mysql does.
This was always broken and was discovered by adding new tests
for this functionality.
Bug: T239640
Change-Id: I75bf469a30225687a4b0cb550a4068cb07208c01
This converts user options management to a separate
service for use in DI context.
User options are accessed quite early on in installation
process and full-on options management depends on the
database. Prior we have protected from accessing the DB
by setting a hacky $wgUser with 0 id, and relying on the
implementation that it doesn't go into the database to
get the default user options. Now we can't really do that
since DBLoadBalancer is required to instantiate the options
manager. Instead, we redefine the options manager with
a DefaultOptionsManager, that only provides access to
default options and doesn't require DB access.
UserOptionsManager uses PreferencesFactory, however
injecting it will produce a cyclic dependency. The problem
is that we separate options to different kinds, which are
inferred from the PreferencesFactory declaration for those
options (e.g. if it's a radio button in the UI declaration,
the option is of multiselect kind). This is plain wrong,
the dependency should be wise versa. This will be addressed
separately, since it's requires larger refactoring. For now
the PreferencesFactory is obtained on demand. This will be
addressed in a followup.
Bug: T248527
Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
The code is appropriately logging when it encounters a database
'Duplicate entry' error. However, the CI interprets that as
an actual exception being thrown. Setting the logger to null
allows the CI to complete.
Bug: T248195
Change-Id: I6419fdb7a6ae54478da1236a3c14b491ade65022
This replaces User::isValidUserName, ::isUsableName, ::isCreatableName,
::getCanonicalName, and ::isIP.
Unlike User::isIP, UserNameUtils::isIP will //not// return true
for IPv6 ranges.
UserNameUtils::isIPRange, like User::isIPRange, accepts a name and
simply calls IPUtils::isValidRange.
User::isValidUserName, ::isUsableName, ::isCreatableName,
::getCanonical, ::isIP, and ::isValidRange are all soft deprecated
A follow up patch will add this to the release notes, to avoid merge
conflicts.
Bug: T245231
Bug: T239527
Change-Id: I46684bc492bb74b728ff102971f6cdd4d746a50a
This should be the exact same. Its more a style change than anything.
So why do it then?
* I believe this is much less confusing than code mentioning a weird
"standard class". Barely anybody knows what this is, and what the
difference between "object" and "stdClass" is.
* The code is shorter.
* It's even faster. In my micro benchmark it's twice as fast.
Change-Id: I7ee0e8ae6d9264a89b6cd1dd861f0466ae620ccc
* Make use of assertGreaterThan() where possible.
* Use the more trivial assertSame() for arrays with only 0 or 1
elements.
* Flip a few assertions where the expected and actual value have been
flipped.
* Remove some unused function arguments.
Change-Id: I1d3b5dd55736931fa484065a4aa8d7e336980682
Similar to checkPasswordCannotMatchUsername, MediaWiki should ensure
that users are unable to accidentally create or edit their username
to include their password as a substring of said username.
Bug: T241845
Change-Id: I437e91a5b83a792c5ad31e291915491bbb382dfa
Drawing from comments associated with `User::newSystemUser` for
checking if a user is a system user, a new method, `User:isSystemUser`
is split out to avoid duplication elsewhere.
Bug: T237356
Change-Id: I73f25a10df2c28a69f612eb1db3e91b7125383d9
DatabaseBlock methods for handling block cookies are deprecated, so
stop using these methods in tests and throw warnings.
Change-Id: I2b5cfd579aa14bbfc7a292587a288ee5032eb5ab
To avoid preference bloat, this preference is hidden unless the new
sysadmin config $wgSearchMatchRedirectPreference is set.
Bug: T235263
Change-Id: Ic16f53a4e6ddb6da071d63cd5da28d937d4692c8
Various maintenance scripts assume reserved usernames like
"MediaWiki default" exist, but since they're reserved
User::isUsableName() returns false and therefore the actor migration
created them as anonymous actors. Which would then prevent those
maintenance scripts from using User::newSystemUser() to ensure they
actually exist.
This adjusts User::newSystemUser() to be able to create users for
those anonymous actors.
This also adjusts uses of "MediaWiki default" in core to create it as a
system user.
Bug: T236444
Change-Id: I59a646df36ff9343cc43c05aa20b2b69b2ee124a
Before this commit, several tests in UserTest set User::mBlock, then
call BlockManager::trackBlockWithCookie, which indirectly sets
User::mBlock. These lines are safe to remove, ahead of deprecating
public access to the property (see T229035).
Change-Id: I36a833ee0904ed1573ac414c8524b60210d97feb
This was previously hardcoded from three places: 1) Upon viewing EditPage,
2) Upon viewing SpecialCreateAccount, 3) For any url if the user is
logged-in (User::loadFromSession/isLoggedIn).
== User::loadFromSession
Performing cookie blocks from here created a circular dependency because
Block may need the user language for localisation, which is determined by
asking the User object. This was previously worked around by using a
DeferredUpdate (T180050, T226777). Moving this logic explicitly to the
end of the pre-send cycle in MediaWiki::preOutputCommit breaks the cycle.
This is also where other request-specific handling resides already.
== Limited effect on unregistered users
When an unregistered user performs an edit, and gets blocked,
the cookie block is not applied until they open built-in editor
or CreateAccount page. This makes it more likely for a user's
IP to change meanwhile. Either intentionally, or simply due to
IPs varying naturally (e.g. between mobile locations, or when
going on/off WiFi). By applying it throughout sessioned page
views for unregistered users, it is more likely to get set.
Similar to what was already done for logged-in users.
This commit also makes the intent of not caching EditPage and
SpecialCreateAccount explicit. This was previously implicit
through nothing having called setCdnMaxage() and/or due to
Session::persist being checked for by OutputPage::sendCacheControl.
Bug: T233594
Change-Id: Icf5a00f9b41d31bb6d4742c049feca0039d0c9d9
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
