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" <gti...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
