Thanks for applying!

Thanks for applying! Also, thanks for the additional research links, they were interesting. Some comments:

• the ability to log wouldn't be really useful here - the data is public, and the queries are not flexible enough to be worth providing some kind of personalization.
• adding different export formats should not take much time (less than a day)
• charting probably won't take a week, given that this tool only needs simple line charts
• "Design the core elements of the app" OTOH will take more time and should be broken up. The funnel data, list of targeted editors and toplist require fairly different code. You should probably pick just one of those for Phase I and aim for an MVP, and do the others later.

Better sooner than later I guess, switching over to Proton is a Q4 goal and I'll probably have less time once the MediaWiki REST API project spins up.

Why is php-curl needed? I'd imagine it uses MediaWiki's request wrapper, which should work fine without curl.

No, it just needs to be done. They can review at any time if they have the capacity, but Proton is already in production and even if the patch doesn't work it cannot make it *less* secure.

In T132901#5080667, @Harej wrote:

As a general note, we tend to see ORES as a tool to aid human decision-making, rather than something that replaces human judgment.

@kaldari this would be a test deployment (throwaway demo wiki pages only) with the explicit goal of supporting the consultation (giving people a chance of seeing what they are being consulted about).

Yeah, that seems like a good approach.

I think this is a bug in RemexStripTagHandler (called via EchoMentionPresentationModel::getBodyMessage() -> EchoDiscussionParser::getTextSnippet() -> Sanitizer::stripAllTags()) which IMO tends to be used as a rough equivalent of Element.innerText and should behave somewhat along those lines (specifically, hidden elements should be ignored).

In T219277#5059958, @Tgr wrote:

The temporary password is stored in the user table, not in LDAP. And the user can't login with it due to $wgBlockDisablesLogin.

In T200184#5075876, @bd808 wrote:

We are still working on various fixes that have been determined to be blockers for restoring Developer account creation. There is no process today to create a new Developer account that is known to work due to some other bugs in the LdapAuthention system. (Namely that generating and sending a temporary password by email does not currently work and normal password reset mechanisms on Wikitech are currently disabled as well pending resolution of T219277).

Hi @Jwu96, I was only a helper on this project in the past (see T57081#3995251) and I probably won't be able to do that this year as I have less free time, I'm trying to run another outreach project, (T218277: Build statistics toolset to support WM-HU editor retention grant) and FlaggedRevs is sort-of-disabled on huwiki now (see T121995: Switch FlaggedRevs on Hungarian Wikipedia to a "flagged protection" mode, although that might get reverted soon, and not sure how much it affects the planned Pywikipediabot API). That doesn't mean much, I'm easy to replace; @jayvdb is the main mentor so you should discuss with him what the plans are for this project (AIUI it was grandfathered in to the task list from some previous year so there's no guarantee the people who planned to mentor it then are still planning to do so).

@Hjhimanshu sorry for taking so long to respond, things got busier at WMCON than expected. Not considering that it's in the middle of the GSoC application period was a planning fail on my side :/

There's nothing private in the table, but probably nothing worth taking up resources for replication, either (functionally it's more or less a materialized view of some of the Wikidata item tables). And maybe at some point there will be some kind of locking mechanism (task X is being held by user Y)? I'd just make it private for now, seems like less hassle. (For which AIUI it would still have to be deleted from $private_tables, and added to [[https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/production/modules/role/files/mariadb/filtered_tables.txt|filtered_tables.txt]] instead.)

I still don't see how

$status = $user->changeAuthenticationData( [
    'username' => $user->getName(),
    'password' => $password,
    'retype' => $password,
] );

(what changePassword.php does now) is an unacceptable level of complexity / code duplication compared to $user->setPassword( $password ) (which also cripples error handling for compatibilty with the legacy method signature). Less elegant, sure (if someone wants to improve that, time is probably better spent on making changeAuthenticationData() autofill the username or making the handling of the retype field more intelligent so it's not required when the data does not come from $_GET/$_POST, both of which should be doable), but copying a single method call into your code is not exactly rocket science.

Adding new arguments to a hook should be safe, as long as it doesn't alter the handling of the existing ones.

setPasswordInternal is private so probably not much help. (setInternalPassword was also internal, as the name suggests, MediaWiki just hasn't been good traditionally about keeping internal methods private.) Password handling via the User class is deprecated, we just don't bother with deprecating non-public methods.

Welcome @Hjhimanshu! I'm at a conference, will follow up over the weekend.

In T91162#5065305, @daniel wrote:

I agree with this analysis: sharing any "active" content (like templates, modules, user scripts, gadgets, etc) across wikis is going to be more tricky.

We already have MediaWiki:Ipbreason-dropdown which gives common block reasons, so the easiest thing would be to extend or replace that somehow with a JSON page which gives values for the other form fields (and maybe generic per-type UI stuff, like a text box with guidelines / policy references).

You can, it will just behave weirdly if the other foreign repo also uses InstantCommons.

In T218816#5049334, @Legoktm wrote:

So apparently there is some difference, just not sure what exactly.

Supporting the location map feature would be an unreasonable amount of effort for a legacy feature that has now been replaced by proper software support for maps. Other software components don't support them either, see e.g. T193822: Pushpin disappears after opening image in mediaviewer or T64572: Media Viewer and location map overlays. I would suggest declining and pointing people to Maps (Kartographer) as a replacement for the template.

In T219277#5058989, @Tgr wrote:

Yeah, there's no reason why that wouldn't work, it looks like a legitimate use of password reset from MediaWiki's point of view. I guess it should check whether the user is blocked and $wgBlockDisablesLogin is set.

Yeah, there's no reason why that wouldn't work, it looks like a legitimate use of password reset from MediaWiki's point of view. I guess it should check whether the user is blocked and $wgBlockDisablesLogin is set.

Moved.

tgr@deployment-deploy01:~$ PHP=php7.2 mwscript shell.php --wiki=wikidatawiki
Psy Shell v0.9.9 (PHP 7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82+wmf1 — cli) by Justin Hileman
>>> sudo MediaWiki\Extension\WikimediaEditorTasks\Hooks::getCounters()
=> [
     MediaWiki\Extension\WikimediaEditorTasks\WikipediaAppDescriptionEditCounter {#3131},
     MediaWiki\Extension\WikimediaEditorTasks\WikipediaAppDescriptionEditCounter {#3134},
   ]

I'd guess the production config and the extension.json config gets merged together and both have the same rule.

I theory it's not hard to inject remote changes into the watchlist, Wikidata does that for example. Watchlists are fine-tuned for policing changes to the content maintained by the community though, they are not a generic notification interface (we have Echo for that), so I'd tread with care.

As a user registered in a MediaWiki instance and a Discourse instance through the same Wikimedia SUL account, I can receive any web notifications generated by Discourse as MediaWiki notifications.

Adding a default NIC type as suggested in the links does not seem to do anything. Maybe the vagrant box would have to be rebuilt?
Using a newer version of Virtualbox might not be an easy option since Virtualbox provides its own driver and secure boot requires signed drivers. At least the .deb files downloadable from Oracle do not take care of that.

In T218844#5045107, @Tgr wrote:

there's a related task but I'm unable to find it

Yeah. this is about links which will end up in somebody's git config as a git remote URL (so URL used for git clone, git remote add, .gitmodules and such). Sorry, I should have been clearer.

At this point I'd say, any time you want to use an interface, you should probably use an abstract class instead. (Except maybe if that class is not going to be exposed externally, but then what's the point of an interface in the first place?)

This task is probably more related to T195494: Handle mobile domains in core than the one it got merged into.

In T218608#5041064, @Anomie wrote:

For #4, I'd think we can consider the provisional "session user" to be the anon with the request's IP, which would usually convert #4 into #2. I note that's what User::getBlockedStatus() is already trying to do. Can you think of any cases where we wouldn't want to do that?

In T218608#5041135, @chasemp wrote:

Can we find a way to ensure toolsadmin.wikimedia.org doesn't start allowing LDAP user creations when this is fixed? Right now user creation is stopped via wikitech, and is broken there but it would be best to couple the two.

In T218608#5037102, @Anomie wrote: random

Possibly a good step would be to audit for where $user->getRights() is called on a User object that wasn't created by User::newFromSession(). Some, like API list=allusers and list=users, would be ok, while others may be suspect.

In T218608#5037102, @Anomie wrote:

Internally the request passed to User::newFromSession() is still needed, but I can't think of any need for it to be exposed publicly.

The other option I have been thinking about is moving $wgBlockDisablesLogin handling to SessionManager (which seems like a nice thing to do in general). So

1. SessionManager calls providers to determine the user identity (and they are not allowed to do block checks)
2. SessionManager sets the session in User::$mRequest (but not the global request yet; create a DerivativeReuqest, I guess? ugh)
3. SessionManager checks for blocks (which works because User::$mRequest now has a fully loaded session) and aborts authentication if necessary
4. SessionManager sets the session for the global request

In T218608#5035984, @Anomie wrote:

One question worth asking is whether User::newFromId( $id )->getRequest() === $wgRequest really makes sense.

User::getBlockedStatus has some ugly checks to see whether the User object whose status has been queried is the same as the global user (to determine whether the IP from $wgRequest can be used to check for IP blocks).

From IRC, maybe this was a clearer description of the problem: SessionManager asks OAuth to provide a session (= session id + identity of global user) -> OAuth session provider identifies user but wants to return null if user is blocked and $wgBlockDisablesLogin is set -> User::getBlockedStatus() checks whether the user is IP-blocked, which depends on whether the user has ipblock-exempt right -> User::getRights() asks the current session if any rights are revoked by the session provider -> session is not loaded yet, goto step 1

More precisely:

• SessionManager tries to determine the session user during setup phase.
• The OAuth session provider reads the user ID, loads the user and checks whether the user is blocked.
• User::getBlockedStatus() calls User::isAllowed() (before checking whether the session user is safe to load), that tries to call Session::getAllowedUserRights() (which is used by OAuth and similar extensions to limit user rights based on the authentication method), but getting the session triggers another call to the session provider, and a loop.

So the actual user object being checked here is actually safe to load (it's loaded by ID, it isn't the session user) but that doesn't help.

So, when OAuth is trying to authenticate the user and calls User::getBlockedStatus, that calls User::isAllowed, which triggers another authentication (the user will be cached in the WebRequest object, but only when the WebRequest::getSession call towards the top of the stack returns). Ugh. If the nonce check didn't fail, this would result in a loop.

In T204747#5034543, @Zer00CooL wrote:

If UserMerge is no longer supported, how do you do to remove spam users with the API?

We need a method that returns all case variants of a name that exist in LDAP; the rest of the patch does not require familiarity with LDAP. If that list is empty, allow user creation; if the list is exactly one element, only allow login/creation if it matches the casing provided by the user (since providers cannot change the casing of the MediaWiki user); if it's larger, probably just log and die. Also return the list in providerNormalizeUsername() for account creation UI checks.

Same issue in https://integration.wikimedia.org/ci/job/wmf-quibble-core-vendor-mysql-hhvm-docker/10779/console (for 497357):

16:24:01 ResourceLoaderFileModule::readStyleFile: style file not found: "/workspace/src/extensions/VisualEditor/lib/ve/lib/color-picker/color-picker.css"
...
16:24:01 Message 'visualeditor-diff-no-changes' required by 'ext.visualEditor.mwsave' must exist

We don't really have a good replacement for $wgUser right now; that will be provided by T218555: Provide access to WebRequest and associated information via a service object. There are benefits in switching to RequestContext, but it also means having to work twice.

There are no wikitech log records whatsoever in logstash, probably something is broken there.

Thanks! I couldn't remember where I heard about that.

Do we consider this good enough for enabling on Wikimedia wikis and/or core, or are we holding out for a more complex version that includes a grace period?

Well, it's an interface so it shouldn't assume that the implementation is always the same (and at least during the transition from Title to TitleValue it might not be). Also even if the two objects are of the same type, pure object comparison is not really reliable: === will differentiate between two instances of the same title, and == will do a recursive field equality check which might fail if e.g. comparing a fully loaded and a not fully loaded Title.

In T218449#5028787, @Aklapper wrote:

(Is MediaWiki-extensions-Auth_remoteuser a typo and should be MediaWiki-Core-AuthManager ?)

In T151425#5028457, @Tgr wrote:

although we might want to change it to have suggestChangeOnLogin => true for the default policy group (and false for the others), per above.