This is basically a workaround for T163277 and T170996: it’s hard to
tell whether the IDs returned by a CentralIdLookup are actually safe to
use cross-wiki or not, so add a factory method which only returns a
CentralIdLookup that can be expected to provide cross-wiki IDs, and
otherwise gives up and returns null.
This is a port of the Wikibase CentralIdLookupFactory class, originally
added in change Ie7b9c482cf by Matthew Flaschen.
Bug: T258390
Change-Id: I903c126be413608bd366875ecc7ac007d4da8e3f
Create a method in UserFactory to instantiate an anonymous
user with an optional IP address.
Bug: T257464
Change-Id: I557620f9bcd4b646288b4a76b26c4730fccbc3d8
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I17e5e92e24c708ffc846945a136347670a3a20c7
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: If560596f5e1e0a3da91afc36e656e7c27f040968
Deprecated since 1.30; It was probably supposed to be removed in Ic9cc2a5
(where test for the functionality was also removed).
Bug: T232864
Change-Id: I9eb23c536b3dff07b6b1e2e4fe648ef6fe08bc6e
Also remove dependent internal method
Deprecated since 1.27, unused in deployed code.
Note that this method has not worked the way it should
since 2016; see T256620#6270262 and subsequent comment
Bug: T249181
Change-Id: I840c4e98ab88401d60b714420ba4233288d94e10
Going through some more abstract classes in core, and
marking those that are extended by extensions as
stable.
I have limited knowledge on the uses of these classes so
marking for vibisility/review.
Bug: T247862
Change-Id: I1939bb11038ec2536eebbdbd12524e83d615b86b
The following glasses are marked as newable per the
Stable Interface Policy, even though logically, they should not be
newable. This is done for classes that are currently instantiated
by extensions, and lack an alternative.
A better way for obtaining an instance of these classes should be
created in the future. At that point, direct instantiation should
be deprecated and replaced.
- includes/ApiMain.php - needs factory
- includes/media/BitmapMetadataHandler.php - should become a stateless service or use handler pattern
- includes/GitInfo.php - should become a stateless service
- includes/logging/LogPage.php - should become a stateless service or use command pattern
- includes/logging/ManualLogEntry.php - should become a stateless service or use command pattern
- includes/poolcounter/PoolCounterWorkViaCallback.php - needs a factory
- includes/context/RequestContext.php - needs to be narrowed down, and should use a factory
- includes/search/SearchHighlighter.php - should have a factory
- includes/TitleArrayFromResult.php - should perhaps be part of TitleFactory
- includes/user/User.php - should at least get a factory method for anons
- includes/diff/Diff.php: needs a TextDiffGenerator service or a factory
- includes/EditPage.php: needs a factory
Bug: T247862
Change-Id: I033158e693c98630ee167d9528fc8c9936f978d4
This annotates classes that can safely be instantiated by
extensions, per the Stable Interface Policy.
Bug: T247862
Change-Id: Ia280f559874fc0750265ddeb7f831e65fd7d7d6a
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
Deprecated since 1.27, unused in deployed code.
There's one usage in one extension that's already broken for other reasons
Bug: T249181
Change-Id: I2b868060dd394fb29e389628b659c0d1b3f11833
Remove call to AbstractBlock::appliesToRight, because it always
returns true for 'edit', so checking it is equivalent to adding
&& true.
Although this method is deprecated, this is worth tidying this up
since it is confusing and gets us one step closer to removing the
'edit' case altogether.
Change-Id: I479d6c866ec13a791873042e623fa841dd5bebf2
It was previously forging keys without any makeKey() call in a way
that does produce the same string regardless of wiki, however
bypassing makeKey() means the cache key might end up containing
illegal characters (and thus fatal). It also means that any
logic for detecting local vs global keys for sharding purposes
would wrongly intepret this as a wiki-local key which could cause
split-brain scenarios.
Bug: T246991
Change-Id: I83d0e11d84e3cdcfc8916b2a9b8d85db7c42d2a7
Deprecating something means to say something nasty about it, or to draw
its character into question. For example, "this function is lazy and good
for nothing". Deprecatory remarks by a developer are generally taken as a
warning that violence will soon be done against the function in question.
Other developers are thus warned to avoid associating with the deprecated
function.
However, since wfDeprecated() was introduced, it has become obvious that
the targets of deprecation are not limited to functions. Developers can
deprecate literally anything: a parameter, a return value, a file
format, Mondays, the concept of being, etc. wfDeprecated() requires
every deprecatory statement to begin with "use of", leading to some
awkward sentences. For example, one might say: "Use of your mouth to
cough without it being covered by your arm is deprecated since 2020."
So, introduce wfDeprecatedMsg(), which allows deprecation messages to be
specified in plain text, with the caller description being optionally
appended. Migrate incorrect or gramatically awkward uses of wfDeprecated()
to wfDeprecatedMsg().
Change-Id: Ib3dd2fe37677d98425d0f3692db5c9e988943ae8
When no validation is wanted, a UserNameUtils constant must be passed
to UserFactory::newFromName, whereas User::newFromName accepts false.
Also pass a constant as the default parameter, rather than the string
value of that constant.
Bug: T255611
Change-Id: Iffd405cb8b38debe9d0a7106a76c430956351583
1. User::addGroup has to be allowed to update the old group
2. Replace use of string constants to identify cache class,
that's prone to typos and errors. Instead, use private constants
3. Update cached user group memberships in place upon modification.
Before UserGroupManager, we've used to do that - this saves some
DB queries, and is better for correctness - for example UserrightsPage
is adding new memberships and then immediately reads from replica,
expecting it's changes to be there already.
We do not know however how many other cases there are which rely
on this pattern, so implement in-place cache update.
Bug: T255330
Change-Id: Ia5ae0e22d4156fd5e4b9aa7eeb801902e79803d1
Additionally, User::checkAndSetTouched was made public and
marked as @internal. Eventually, as User class refactoring
continues, I would expect this to be replaced by some service.
Bug: T252621
Change-Id: I53533f494950d08ee5ed1ec54d24958c21e7b3aa
Makes it possible to mock static User methods in tests;
actually introducing dependency injection to the User class is left for
the future.
New class has 100% code coverage
Bug: T253432
Change-Id: I0b93da09124d95beafd84e932b214909ce920230
