Have a proxy that'll contain the consumer_secret that pywikibot (and others) can contact to actually sign the access request. This allows people to use OAuth without requiring them to know the consumer_secret.
- Mentioned In
- T289180: PAWS discloses ToolsDB password, disclosing various nonpublic user information
T243200: Move PAWS to OAuth 2.0
T125337: Add OAuth 2.0 support to MediaWiki to support Discourse
T196207: Does PAWS pass user credentials to the action API?
T192237: Support administrative actions in PAWS
See this article (section 2) for the threat model. In short,
- a hostile user can send requests (in their own name) which fool the wiki server into thinking they were made with PAWS. Probably not that significant given that PAWS already allows you to make any kind of request so seeing a PAWS tag on an edit does not give any kind of guarantee about its content.
- more problematically, a hostile application might be able to impersonate PAWS towards the user, send it to the authorization dialog, get the access secret and then do arbitrary actions in the user's name. This would require some kind of breach of network integrity as the consumer URL prefix would guarantee that information can only be sent to PAWS; but MITM-ing the user-PAWS connection is probably a lot easier than MITM-ing the user-Wikipedia connection.
After thinking about it a bit, I think the reasonable way to do this is to have an internal API (internal to PAWS but not the container) to which Pywikibot can hand off a request (or a request head, in case of huge POST requests) and get back a signature (or a signed request/head, if that's more convenient). The client would be in full control of the HTTPS connection; access to the API basically means the client can make preimage attacks against the signing process, and a SHA1 HMAC should be safe against that.