From the start of the OAuth idea I've been thinking we should handle the
code in an abstract way.
ie: Applications and Authorizations should be something MediaWiki
implements internally in an abstract way. And then we write an OAuth
extension that extends this and lets you authorize OAuth 2 clients.
Things like mass-reverts by application, authorization revocation, and
displaying what application was responsible for an edit would be handled
from within MediaWiki abstractly instead of being OAuth specific.
-- Skip for TL;DR version --
Originally I had some ideas like implementing some custom auth system for
other wiki. Implementing OAuth 1.0 in addition to OAuth 2 (at the time it
appeared signatures had disappeared and OAuth 2 was worse than OAuth 1 in
some cases). And supporting something along the lines of Google's
application passwords.
I'm not focused on that right now. But I still think it would be a good
idea to do. We don't know what'll happen in the future. Someone could
write an OAuth 3 that is also not backwards compatible and we want to
implement. Or someone could come up with a different standard that does
things in a more secure way or supports discovery in a very well thought
out way. So doing things abstractly will let us add those as things go
along without any trouble.
Additionally doing this abstractly allows us to test just small components
of the system in an isolated way without needing a whole OAuth stack.
-- / continue reading from here --
I had an interesting thought when I was thinking about how we'd do this
abstractly.
- I started thinking that every user instance should have some sort of
->getApplication()/->getAuthorization() connection. And this would be used
when noting what was responsible for various edits/logs/etc...
- To make things easy on code I thought that ->getApplication() should
always return an Application instance so you don't have to null test it.
Under that idea MediaWiki itself would have a dummy Application which
would be tied to every standard edit. The database would probably even
reflect this.
After this I started thinking of separating things a bit more.
- By default every blandly created User instance would be tied to an
"Unknown" application.
- While when a user instance is setup using session data we assign the
"Internal" application to it.
- As a result of this all dummy edits made through internal code would end
up associated with an "Unknown" application instead of the "Internal"
one.
In other words, we'd finally have a formal way to find system made edits
like the initial Main Page edit populated by the installer. That would be
an "Unknown" application. The same would go for various extensions that
made dummy edits.
- To top all this off we could potentially also make a special built-in
"Import" application. This would result in all edits made by importing
edits from another wiki being nicely annotated in the UI with information
saying they were imported rather than actually made on the wiki by said
person.
What does everyone think of this idea?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]