MediaWiki has never used this path for running the maintenance
scripts, only the class name provided in the other parameter.
Providing the parameter is no longer needed in MediaWiki 1.43.
Bug: T367918
Change-Id: I13b85b2f14bea802229a624ad0b8b2166845d1d1
Co-Authored credit to Ayush_Anand3310 who mostly wrote them on the task
Bug: T328577
Co-Authored-By: Ayush-Nautiyal007 <ayush.2020012016@tulas.edu.in>
Change-Id: Iea2d730bfe69c0ee72e894e7ea3bc31f141e546f
Use the same PHP library as UrlShortener (endroid/qr-code) to
generate QR codes, rather than the out-of-date JS library.
Bug: T348590
Change-Id: I560ac1b384e249aad1866752deac753c764ec553
This adds new database tables to support storing multiple authentication
factors for a single user. The current approach taken is to use a single
database row per 2fa method and key. The current module/key abstraction
will have to be updated to support having multiple module types for a
single user (for example for having a separate module for recovery
codes), but this patch does not address that and instead keeps the
existing limitations, however the needed updates for that should be
doable with this database schema.
I've decided to add a new table instead of modifying the existing
oathauth_users table. This is mainly because adding an auto_increment
column to the existing table would be difficult, but also allows us to
update the table definition to follow MW conventions (namely the column
name prefixes). I've also used the opportunity to normalize the device
types onto a separate table.
The migration stage variable is set to SCHEMA_COMPAT_NEW so that
third-party wikis can use update.php normally and don't have to adjust
anything. This means that it needs to be manually set to _OLD on
wmf-config before merging this patch.
Since we're already working with the database schema, this add a new,
currently unused column for the creation data, so that T242847 will not
require a new schema change.
Bug: T242031
Bug: T242847
Change-Id: I6aa69c089340434737b55201b80398708a70c355
This new service is separated from the previous OATHAuth class to give
the service a more accurate name. Also removed unnecessary injected
services and do some other minor cleanup.
Change-Id: I8d5fbc7594b69168dc0c8bfade1ac172a5aeef6f
Configure "ActionFilteredLogs" in extension.json to allow filtering
the oath log by its two actions, verify ("checking" in the UI) and
disable-other.
== Test plan ==
* Enable 2FA on your administrator account, use Special:VerifyOATHForUser
and Special:VerifyOATHForUser to generate two log entries.
* Visit Special:Log/oath and use the new action selector, testing each
state to verify the correct set of logs are shown.
* Screenshots showing this testing are posted at T310487#7999991.
Bug: T310487
Change-Id: I10632c86689e330b21b44a096b098436ebe47e3e
Notify users when 2FA is disabled on their account in case something was
fishy about it. This notification is a "system" notification that will
be displayed in the web UI and sent over email. It can't be opted out of
as a preference.
The notification links to Special:Preferences, where users can see their
2FA status and re-enable it if they want. A secondary help link goes to
[[mw:Help:Two-factor authentication]], but can be overridden by
adjusting the "oathauth-notifications-disable-helplink" message. The
notification text is different based on whether the user disabled 2FA on
their own, or an admin used the special page or a maint script to do it.
On Wikimedia wikis, we'll use the WikimediaMessages extension to
customize the messages.
The Echo (Notifications) extension is not required, this will gracefully
do nothing if it's not enabled.
Bug: T210075
Bug: T210963
Change-Id: I99077ea082b8483cc4fd77573a0d00fa98201f15
Users in groups listed in $wgOATHRequiredForGroups (default none) must
have two-factor authentication enabled otherwise their membership in
those groups will be disabled. This is done using the
UserEffectiveGroups hook, which allows dynamically adding or removing
user groups.
If a user doesn't have 2FA enabled, it will appear to them as if they
aren't a member of the group at all. Special:Preferences will show which
groups are disabled. In the future it would be good to have a hook into
PermissionsError to show this as well. The UserGetRights hook is used to
ensure the user still has the "oathauth-enable" user right in case it
was only granted to them as part of the user group they are disabled
from.
On the outside, Special:ListUsers will still show the user as a member
of the group. The API list=users&prop=groups|groupmemberships will show
inconsistent informaiton, groups will remove disabled groups while
groupmemberships will not.
This functionality was somewhat already available with
$wgOATHExclusiveRights, except that implementation has flaws outlined at
T150562#6078263 and haven't been resolved in I69af6a58e4 for over a year
now. If this works out, it's expected that will be deprecated/removed.
Bug: T150562
Change-Id: I07ebddafc6f2233ccec216fa8ac6e996553499fb
Since AbstractAuthenticationProvider ::setLogger, ::setManager,
::setConfig methods had been soft deprecated,
so its uses were removed.
* Also bump required MW version to 1.37.0
Bug: T281991
Change-Id: Ifd6ed1bc60d8a7fe6d10af1f08b6670a96ca2851
Hook was part of Extension:OpenStackManager, but removed by REL1_35, so unnecessary
I4741fcb073f8463f017bc1b477206dee801b662b / 46d9149c2db7c2b2d4573bede74b54779d66bee8
Change-Id: I2c5f99bfa9028c57a1eadbd81a51f84b47668848
