Manual talk:Bot passwords/Flow

I am developing a MediaWiki Bot that will run as a desktop CLI application. Because it will not be running in a web browser, I will not have a callback URL for the OAuth2 authentication flow.

I believe that OAuth2 can be used when the authorization token needs to be copy/pasted into the desktop application: https://developers.google.com/identity/protocols/oauth2/native-app#ios

Alternatively, a custom URI scheme may be used. However, is this supported by MediaWiki? Or would a Bot password be the way to go?

This is the approach that Huggle takes: https://www.mediawiki.org/wiki/Manual:Huggle/Bot_passwords

Is a Bot password the only option for a CLI application?

Just check "This consumer is for use only by ..." when registering your OAuth app.

Hi,

I am running a private wiki on version 1.28. I have created bots on Special:BotPasswords page to access my private wiki through Action APIs.

Everything works fine except the bot users got denied by img_auth.php.

Is there any walk around on this issue?

Also, does Action APIs (/w/api.php) through bot users have the same RequestContext with the normal user?

Thanks,

-Sean

img_auth is not part of the API so bot passwords do not work there. It is probably possible to hack your way around it via authentication hooks or whatnot, but I don't think there's a nice solution (other than writing an API for getting the images, which I imagine will happen eventually via T66214, but "eventually" might be a long time).

RequestContext works the same way for bot passwords.

@Tgr Thanks for the reply!

I my case here, I have all media files stored on AWS S3. So it is easier to fetch media directly from S3 as a quick walk around.

I've set up a bot password and I get a "You do not have permission to edit pages in the Page namespace" when I try to edit a page using the API.

I've granted all the available permissions to the bot password. What am I missing? How do I give the bot password Page edit rights beyond all the permissions available?

How are permissions for editing that namespace restricted?

I realize I set up special roles for editing pages. Thank you.

Is there a group I can target in LocalSettings to modify bot password permissions?

I'm thinking something similar to

$wgGroupPermissions['user']['specialpermission'] = true;

but a different group than 'user'

Do you mean adding permissions which are only available when logged in via a bot password, not normally? I don't think that's possible, short of horrible hacks with the UserGetRights hook.

I have a protected namespace

$wgNamespaceProtection[NS_NEW] = array( 'editnew' );

I've added "editnew" as a grant in bp_grants, but I still can't edit the namespace.

Any thoughts about how to enable my bot password bot to edit pages in this namespace?

Grants are bundles of permissions. See $wgGrantPermissions. You'll probably need something like $wgGrantPermissions['editnew']['editnew'] = true;.

Omg. That helps so much. Thank you

To insert a new permission in the form "Special:Bot password", you can add this code in the file extension.json of your extension :

"GrantPermissions": {
 "rightsname": {
    "rightname" : true
 }
}

Hello I have a protected custom namespace "Data". I can write in my custom namespace but my bot cannot write in this namespace : {"error":{"code":"protectednamespace","info":"You do not have permission to edit pages in the Data namespace."...

I suppose I have to allow my bot to write in this namespace via the page "Special:Bot password" but I cannot see my namespace in the list.

How can I add a new custom namespace in the list on the page of "Special:Bot password" ? (may be via extension.json ? an example ?)

Thanks

I found. I inserted in my extension.json :

"GrantPermissions": {
  "rightsname": {
     "rightname" : true
  }
}

Bye

Hey y'all, say a bot password gets exposed to insecurity. Is there actually non-backend way to revoke said password? Is changing the account password sufficient?

Yeah, just go to Special:BotPasswords and remove it, or edit it and check the "reset password" option before saving. Alternatively, changing your main account password will invalidate your bot passwords as well.

Hi!

I've been reading quite a bit of documentation about OAuth1 and OAuth2 lately, both of which I've understood to be (relatively) insecure in the case of public clients (such as bots on the user's computer, or mobile applications).

So, when I read that “If the wiki and the bot support OAuth, use that instead; it is more secure, especially on wikis without robust HTTPS support.”, I wonder if there's something I've misunderstood or if that statement is not somewhat misleading…

Without robust HTTPS, that statement is obviously true, as using bot passwords is vulnerable to MITM, like using regular passwords and unlike OAuth1. In that case, one's main concern should probably be to get robust HTTPS first (as only HTTPS can protect regular passwords used by the users to authenticate to the server to authorize the OAuth client), but anyway: OAuth is for sure a security improvement over bot passwords.

But, with robust HTTPS (which I'm going to assume should be the norm in 2018) is there any reason to think OAuth is more secure than bot passwords?

I'm asking mostly out of curiosity and for my own understanding, but I'm also considering using bot passwords for a mobile application, as the bot password form is “just complicated” for the end user, whereas the OAuth token form is “horribly complicated” (no offense to be taken: I think it's perfectly fine for the public of developers it was designed for — it's just being used out of its scope, for legitimate reasons).

Thanks a lot for any clarification :)

I've been reading quite a bit of documentation about OAuth1 and OAuth2 lately, both of which I've understood to be (relatively) insecure in the case of public clients (such as bots on the user's computer, or mobile applications).

It's insecure if the OAuth key and secret are bundled with the code (ie. different people running the bot use the same OAuth consumer). It's not insecure if you create your own consumer for the bot, as recommended for Pywikibot for example.

But, with robust HTTPS (which I'm going to assume should be the norm in 2018) is there any reason to think OAuth is more secure than bot passwords?

If the communication channel is secure, then the security advantage is minimal. That's a big if, though - we are used to taking it for granted that HTTPS is safe, because browsers have gotten very good at implementing it securely, but most bots do not use a browser, and a lot can go wrong with SSL support of whatever request library is being used, system-default CA bundles etc. I wouldn't worry about using bot passwords, but I wouldn't say the difference is negligible, either. (I am not a security expert, though.)

the bot password form is “just complicated” for the end user, whereas the OAuth token form is “horribly complicated”

Yeah it sucks currently. T142282 subtasks and especially T165219 are some relevant issues.

Tgr: thank you very much for you answer!

(And sorry for the late reply; I've seen your message just today.)

The editmyprivateinfo right is required to create bot passwords.

I'm using MW1.27. My BotPasswords page does not load. It should be enabled, I've checked the LocalSettings.php.

The page reports:

Are you logged in? Try the "Log in" link in the upper right.

You do not have permission to edit your private information, for the following reason:

You are not allowed to execute the action you have requested.

I'm the sysadmin. I have every possible permission.

I've read through the code and I can't see anything that would be preventing me.

Ok. The problem is that the "editmyprivateinfo" permission was disabled. I was following the guidance for setting up Extension:PluggableAuth