We currently have editable pages on Wikimedia sites with important legal strings, and AFAIK no one has caused a noteworthy incident by editing or vandalizing them. (Cc'ing Maggie to ask for verification.) However, the term "attack vector" gets my attention. Is there a way to keep the pages in wiki format while hardening OAuth against attempted attacks and simple mistakes?
By the way, I would support development of more sophisticated access controls for wiki pages in general.
Pine On Aug 10, 2015 6:23 PM, "Gergo Tisza" gtisza@wikimedia.org wrote:
tl;dr should OAuth [1] (the system by which external tools can register to be "Wikimedia applications" and users can grant them the right to act in their name) rely on community-maintained description pages or profile forms filled by application authors?
Hi all,
I would like to request wider input to decide which way Extension:OAuth should go. An OAuth application needs to provide various pieces of information (a description; a privacy policy; a link to the author; a link to the application; links to the source code, developer documentation and bug tracker; and icons and screenshots). There are two fundamentally different approaches to do this: either maintain the information as editable wiki pages and have the software extract it from there; or make the developer of the application provide the information via some web form on a Special:* page and store it in the database. Extension description pages are an example of the first approach; profile pages in pretty much any non-MediaWiki software are an example of the second one.
Some of the benefits and drawbacks of using wiki pages:
- they require very little development;
- it's a workflow we have a lot of experience with, and have high-quality
tools to support it (templates, editing tools, automated updates etc.);
- the information schema can be extended without the need to update
software / change DB schemas;
- easier to open up editing to anyone since there are mature change
tracking / anti-abuse tools in MediaWiki (but even so, open editing would be somewhat scary - some fields might have legal strings attached or become attack vectors);
- limited access control (MediaWiki namespace pages could be used, as they
are e.g. for gadgets, to limit editing of certain information to admins, but something like "owner can edit own application + OAuth admins can edit all aplications" is not possible);
- hard to access from the software in a structured way - one could rely on
naming conventions (e.g. the icon is always at File:OAuth-<application name>-icon.png) or use Wikidata somehow, but both of those sound awkward;
- design/usability/interface options are limited.
Some previous discussion on the issue can be found in T58946 [2] and T60193 [3].
Right now OAuth application descriptions are stored in the database, but in a very rough form (there is just a name and a plaintext description), so switching to wiki pages would not be that hard. Once we have a well-refined system, though, transitiong from one option to the other would be more painful, so I'd rather have a discussion about it now than a year from now. Which approach would you prefer?
[1] https://www.mediawiki.org/wiki/Extension:OAuth [2] https://phabricator.wikimedia.org/T58946 [3] https://phabricator.wikimedia.org/T60193 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l