Wikibase Cloud might run into the same issue on upgrade.

FWIW the warning is skippable.

I guess not skippable via createOAuthConsumer.php. It should probably have an ignorewarnings option.

Anyway, while having lots of configuration flags for all kinds of business logic customizations is an antipattern, in this case it would probably make sense to add a config flag.
Or we could go in the opposite direction, add a hook for custom warnings, and move this specific warning to Wikimedia config.

We should fix this at some point, it does sound annoying.

Hi @Tgr,

thanks a lot for looking into it.

I agree: If the web interface has an ignore-warning option, the programmatic interface should have the same option. At the same time, I would not like to base our logic on an "ignoring warnings" flag. I think the configuration we are aiming for is sane and totally valid in a "third party case". The warning is only correct in the "MediaWiki as internal product" case, not in the "MediaWiki as third party product" case.

Option I could see moving forward:

1. Remove the warning completely, as it classifies OAuth consumers on the same domain in general as "invalid", at the same time suggesting that the domain MW is running on is not owned by the user.
2. Retain the warning, but trigger it on a hard coded list of WikiMedia domains (I think this is close to the original intention of this code).

What do you think?

Best,
Robert

Hi @Tgr,

Do you like any of the above suggestions? Do you have another one?
I would be happy to write the patch.

Best,
Robert

After looking at this at the hackathon with some folks, probably the OAuth extension should just have this check be configurable in terms of if it is performed or not.
Probably default to doing the check, but that allows Wikibase Cloud and Wikibase Suite Team to easily disable the check for their deployments.
Unless @Tgr thinks the default should be for the check to be off, and then enable it in WM production?
I wonder how often this case comes about in third party installs

Thanks a lot for the input. This is indeed an interesting idea.

If this extension is considered being an "external product" for the community too, I'd strongly gravitate towards "the WMF-special behavior should be off by default". This eases the usage for external users, because they would need to climb quite a learning curve finding this setting, understanding it and setting it properly otherwise. I guess it should be easy for the WMF deployments to set this setting, because all the specific knowledge about this quirk is available already.

Wikibase Cloud was indeed also bitten by this in T407478. I would assume many 3rd party hosters that run OAuth tools will have a similar issue if they are autogenerating OAuth consumers for tools.

I wonder what is the best solution also. Maybe it's still to warn but not be blocking when done using the maintenance script?

Sorry for the very late response. Disallowing the wiki domain is a convenience for Wikimedia wikis (which get a lot of clueless drive-by client proposals). There is no security rationale for it; in theory, a wiki could even have JS-based clients which run on the wiki domain and use OAuth (although it doesn't seem practical). I agree it would make sense to move the check to a default-off configuration setting or a hook.