This page doesn't seam to reflect the OAuth plans that I've seen people discussing. Especially with that minimum MediaWiki bit. The plans I've seen people talk about necessitate that every change made by a 3rd party that's authenticated through something like OAuth be attributable to that app. ie: Every edit, log, etc... needs a field and code that associates an app. And there are many features expected to be generic rather than OAuth dependent (things like authorizing/blacklisting apps and listing authorizations), while the actual OAuth itself would be an extension. Under those plans, I don't see OAuth support working in anything but a new version of MediaWiki. Core would have the generic functionality baked into it and an extension would tie in actual OAuth implementation etc...
Topic on Talk:OAuth/Flow
Hi Daniel,
I am curious to know where those discussions happened as I haven't been able to find them :) I would like to hear the use-case where we would want a 3rd party app make actions on behalf of it's user without the user explicitly taking the action self. In our proposal we assume that all actions are always taken by an individual and hence each action is always attributable to an individual.
Best,
Diederik
Drdee 00:25, 18 November 2011 (UTC)
Hi Daniel,
I am curious to know where those discussions happened as I haven't been able to find them :) I would like to hear the use-case where we would want a 3rd party app make actions on behalf of it's user without the user explicitly taking the action self. In our proposal we assume that all actions are always taken by an individual and hence each action is always attributable to an individual.
Best,
Diederik
Drdee 00:25, 18 November 2011 (UTC)
We don't want an app to make actions using a user's account that the user didn't want to be made. But it's 3rd party code, there's no way to guarantee that. So, every change gets associated with what app made it. So when an app goes rogue and starts abusing dozen's of users accounts to spread goatee images, we know precisely which app is responsible, and we can blacklist it and revoke it's permission to do anything with any user account.
Ok, I'll add that to the requirements & datamodel.
Daniel, that's correct – we definitely want to have the ability to revoke permanently and globally permissions for an app and to mass-revert or mass-redact any abusive edits produced by that app and the requirements should reflect this possibility. We'll need to figure out the legal and technical implications, as for the technical aspects the ability to tag specific revisions with a unique id associated with the key used by the app is an obvious requirement if we want to be able to mass-revert.
That wikitech-l discussion should cover a lot. One small relevant OAuth discussions in irc: http://toolserver.org/~mwbot/logs/%23mediawiki/20110816.txt
Hi Daniel,
You mentioned that "Every edit, log, etc... needs a field and code that associates an app." I am not sure if that is the way to go. That is a super major overhaul of the MediaWiki platform, has performance and storage implications. I think we should search for a solution using a mix of the following components:
1) Having a log table that contains user_id, app_id and timestamp so we can revert actions done by a particular user and app combination for a certain date range.
2) Having a policy where we clearly state under what circumstances we are free to to undo certain actions and ban a third party app.
3) The approval process by which we review third-party apps.
Drdee 03:58, 18 November 2011 (UTC)
We've been overhauling portions of MediaWiki for awhile, I see no reason to cut corners, not overhaul something that seams like it calls for it, and come out with a half-baked feature for something like this.
The only performance implications new columns have is in schema updates. New tables can also add other performance implications such as JOINS. So we're not going to get away with cutting corners and pretending that we shouldn't overhaul something and instead implement something that doesn't need to take the best decision for performance into account. Whether that's a column change or another table with say a pair of columns that point to a table and a primary key.
And something that doesn't properly associate the app/user to a change in an absolute way, especially something at the granularity of just a timestamp feels very fragile and liable to not work right.
What we're talking about here is code that will allow for a user session that only has partial permissions of a normal user session. Something that MediaWiki naturally was not coded to expect. Naturally it's possible that a feature like this will require a partial overhaul to make work correctly.
Also I don't like the idea of the core functionality of associating a change with an app being implemented in an extension. That seams like something that's liable to not be very compatible with extending into extensions. Some extensions add new api portions, and I'd hate to see an implementation of a feature that includes OAuth and the 3rd parties using it can't use something like LQT's api because LQT can't integrate the code needed to support OAuth in it's api. Or see that such a feature requires a bunch of tests all over extension code to ensure that the extension can actually work when the OAuth extension is not installed.