Here's the last post I could find on the subject:
For my part, I'm firmly against joining the "provider but not consumer" camp. It's of no benefit to anyone . . .
I just thought of a great benefit, however. Consider this true scenario: I want to write a MediaWiki API client for editors; something like the Wordpress Dashboard. Really give editors a modern web experience. I'd want to do this as a Rails app: I could build it quickly and find lots of collaborators via GitHub.
But there's one problem: people would need to log in to Wikipedia *through my app*. They'd have to enter their username and password to my app, which would turn around an authenticate via the MediaWiki API. Policy-wise, this isn't a good thing; that is, giving people the message that it's ok to type in your credentials to something other than Wikipedia sites.
And I believe that this is why no such app exists. And further, why the only similar apps that have been made were fat clients, and e.g. Windows only. Because then, the credentials stay on the user's computer.
But imagine: If Wikipedia was an OpenID Provider, or provided OAuth, then my Rails app would be the OpenID Consumer. It'd send people to Wikipedia to log in, and they'd bounce back and begin using the Rails app. My app would never see any private information.
I believe this would encourage a new wave of 3rd party app development; everything from big ambitious projects (like my editor dashboard) to small focussed apps (say, a simple web app just for editing one's talk page).
Just thinking out loud here! Robb
On Thu, May 27, 2010 at 6:13 PM, Robb Shecter robb@weblaws.org wrote:
Here's the last post I could find on the subject:
For my part, I'm firmly against joining the "provider but not consumer" camp. It's of no benefit to anyone . . .
Not totally sure who wrote that. It may have been a while ago though. Some context would be good.
I just thought of a great benefit, however. Consider this true scenario: I want to write a MediaWiki API client for editors; something like the Wordpress Dashboard. Really give editors a modern web experience. I'd want to do this as a Rails app: I could build it quickly and find lots of collaborators via GitHub.
But there's one problem: people would need to log in to Wikipedia *through my app*. They'd have to enter their username and password to my app, which would turn around an authenticate via the MediaWiki API. Policy-wise, this isn't a good thing; that is, giving people the message that it's ok to type in your credentials to something other than Wikipedia sites.
And I believe that this is why no such app exists. And further, why the only similar apps that have been made were fat clients, and e.g. Windows only. Because then, the credentials stay on the user's computer.
This really calls for OAuth support.
As a warning, it is very likely your application will be blocked if you store user credentials in your third party app. OAuth support was originally brought up about a year ago because of a third party app that did this.
But imagine: If Wikipedia was an OpenID Provider, or provided OAuth, then my Rails app would be the OpenID Consumer. It'd send people to Wikipedia to log in, and they'd bounce back and begin using the Rails app. My app would never see any private information.
I believe this would encourage a new wave of 3rd party app development; everything from big ambitious projects (like my editor dashboard) to small focussed apps (say, a simple web app just for editing one's talk page).
OAuth and OpenID as both a provider and a consumer were discussed at the Berlin developer's workshop, and everyone seemed to agree that all three were a good idea. OAuth and OpenID can and should be worked separately. I was planning on working on all three. I don't have time to tackle this right now. If you want to submit patches for OAuth, I'm sure you'll get some good feedback, and will get inclusion if done properly. You may want to do an RFC beforehand.
Consumer support for OpenID is likely going to be more difficult, and will happen much later than OAuth or OpenID as a provider. Neither OAuth nor OpenID are likely to get dedicated developer time in the immediate future.
Respectfully,
Ryan Lane
I could see some real use cases for OAuth. Especially with regards to the cases mentioned above. People could potentially build apps like AWB and Huggle using OAuth. In general I think this would be a "cool thing" to have for all MediaWiki installs.
As for being an OpenID provider... only one major thought: Having this Foundation be a provider would be a lot of additional server load (It is 100% non-cacheable) without any benefit to the main goal of providing free information.
On Thu, May 27, 2010 at 7:08 PM, Jon Davis wiki@konsoletek.com wrote:
I could see some real use cases for OAuth. Especially with regards to the cases mentioned above. People could potentially build apps like AWB and Huggle using OAuth. In general I think this would be a "cool thing" to have for all MediaWiki installs.
As for being an OpenID provider... only one major thought: Having this Foundation be a provider would be a lot of additional server load (It is 100% non-cacheable) without any benefit to the main goal of providing free information.
The biggest immediate benefit to becoming a provider is for non-MediaWiki based apps that the foundation uses. If we become a provider, our Wordpress, Bugzilla, Ideatorrent, etc. apps don't need to have separate username/password databases. As someone mentioned earlier, it would be extremely useful for the toolserver.
Even for third-party applications, if we just provide OAuth, they would still need to handle user account databases, and that isn't optimal. It is especially less optimal for WMF users, who would need to have user accounts in a number of spots, and possibly have to remember multiple passwords.
Respectfully,
Ryan Lane
Ryan Lane wrote:
On Thu, May 27, 2010 at 7:08 PM, Jon Davis wiki@konsoletek.com wrote:
I could see some real use cases for OAuth. Especially with regards to the cases mentioned above. People could potentially build apps like AWB and Huggle using OAuth. In general I think this would be a "cool thing" to have for all MediaWiki installs.
As for being an OpenID provider... only one major thought: Having this Foundation be a provider would be a lot of additional server load (It is 100% non-cacheable) without any benefit to the main goal of providing free information.
The biggest immediate benefit to becoming a provider is for non-MediaWiki based apps that the foundation uses. If we become a provider, our Wordpress, Bugzilla, Ideatorrent, etc. apps don't need to have separate username/password databases. As someone mentioned earlier, it would be extremely useful for the toolserver.
Even for third-party applications, if we just provide OAuth, they would still need to handle user account databases, and that isn't optimal. It is especially less optimal for WMF users, who would need to have user accounts in a number of spots, and possibly have to remember multiple passwords.
Respectfully,
Ryan Lane
You sure you can't use pure OAuth similarly to the way you can with OpenID? I know they have their own user management, but disqus is using OAuth to turn twitter accounts into a login.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Thu, May 27, 2010 at 8:08 PM, Jon Davis wiki@konsoletek.com wrote:
As for being an OpenID provider... only one major thought: Having this Foundation be a provider would be a lot of additional server load (It is 100% non-cacheable) without any benefit to the main goal of providing free information.
I imagine the load wouldn't be a big deal. An OpenID server is pretty simple, no?
On Thu, May 27, 2010 at 10:48 PM, Ryan Lane rlane32@gmail.com wrote:
The biggest immediate benefit to becoming a provider is for non-MediaWiki based apps that the foundation uses. If we become a provider, our Wordpress, Bugzilla, Ideatorrent, etc. apps don't need to have separate username/password databases.
Assuming all of these actually support OpenID as consumers, without annoying limitations. Do they?
On Fri, May 28, 2010 at 12:09 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Thu, May 27, 2010 at 8:08 PM, Jon Davis wiki@konsoletek.com wrote:
As for being an OpenID provider... only one major thought: Having this Foundation be a provider would be a lot of additional server load (It is 100% non-cacheable) without any benefit to the main goal of providing free information.
I imagine the load wouldn't be a big deal. An OpenID server is pretty simple, no?
Yeah. I couldn't imagine it adding much load.
The biggest immediate benefit to becoming a provider is for non-MediaWiki based apps that the foundation uses. If we become a provider, our Wordpress, Bugzilla, Ideatorrent, etc. apps don't need to have separate username/password databases.
Assuming all of these actually support OpenID as consumers, without annoying limitations. Do they?
Bugzilla's looks like it has limitations, but the others have consumer support without limitations as far as I can see. We'd likely want to modify them slightly, so that we can have a simple button like "log in with your Wikimedia account".
Respectfully,
Ryan Lane
I imagine the load wouldn't be a big deal. An OpenID server is pretty simple, no?
Yeah. I couldn't imagine it adding much load.
I've done several OpenID client implementations; so watching the conversation with the server, it seems like there's no overhead at all beyond a normal login sequence. So in a sense, that's where the overhead is: additional requests to the login pages and scripts corresponding with new traffic to the new openid client apps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 37-01--10 03:59 PM, Robb Shecter wrote:
But there's one problem: people would need to log in to Wikipedia *through my app*. They'd have to enter their username and password to my app, which would turn around an authenticate via the MediaWiki API. Policy-wise, this isn't a good thing; that is, giving people the message that it's ok to type in your credentials to something other than Wikipedia sites.
This is a perennial problem for many Toolserver tools as well. It has resulted in such hacks as http://toolserver.org/~magnus/tusc.php - an OpenID-based solution is clearly preferable.
- -Mike
Robb Shecter wrote:
Consider this true scenario: I want to write a MediaWiki API client for editors; something like the Wordpress Dashboard. Really give editors a modern web experience. I'd want to do this as a Rails app: I could build it quickly and find lots of collaborators via GitHub.
Not to "derail" the open-id idea I think we should support oAuth 100% and it certainly would help with persistent applications and scalability...
But ...for the most part you can build these types of applications in pure javascript. Anytime you need to run an api action that requires you to be on the target domain you call a bit of code to iframe proxy that action on the target domain and communicate its results to the client domain with another iframe back to the client.
mwEmbed provides iFrame proxy as part of a uniform api request system with the "mw.getJSON()" function. This that lets you just call that function and mwEmbed works out if it needs to spawn a proxy or if it can make the request directly.
Presently I hard-code the approved domains, but it would not be difficult to add in process where users could approve domains / applications. We could even do explicit approval for the set of allowable api actions being requested. ( ie edit pages "OK" upload "NO" )
This has been in use for a while and its how the uploading to commons from the English encyclopedia page works with the add-media-wizard gadget. http://bit.ly/9P144i You can test it by simply by enabling that gadget, then while editing click "insert image", then the "upload" button, then upload to commons.
~Right now~ its a pure javascript gadget that is enabled on (en.wikipedia) which calls another gadget on ( commons.wikimedia ) and they setup two-way communication that way. To make things more complicated all the javascript and html proxy pages are hosted on a 3rd domain ( prototype.wikimedia.org ) and its not just simple api calls, rather its full file uploading proxy with progress indicators and two way error interactions.
In the context of the mwEmbed gadget this is more complicated than it needs to be. I should package a apiProxy extension that could simplify things like having an actual proxy entry point that does not load the entire set of mediaWiki view page assets on every proxy interaction. Also it could use some HTML5 type enhancements around cross domain communication so the application could send and receive the msgs directly where the domain is approved and the browser supports it. Furthermore some versions of IE have to request user approval for the iFrame to carry user credentials, but this can be avoided with a p3p policy added to the response header. http://bit.ly/13kpV
That being said it has worked oky for what I needed it for, and I think it could be used for prototyping the "editors portal" as you have described it.
peace, --michael
Not to "derail" the open-id idea I think we should support oAuth 100% and it certainly would help with persistent applications and scalability...
I don't think that's a derail at all. I don't know OAuth that well, but it seems to provide the same benefits of OpenID Provider.
Now... going to a 100% Ajax solution for apps... :-) Yeah, I've seen that used to solve interesting authentication & session problems. But that does limit the developer pool and range of apps that'll get built. (Witness the current scarcity of web-based auth-enabled wikimedia apps.)
On Fri, May 28, 2010 at 12:11 AM, Robb Shecter robb@weblaws.org wrote:
Not to "derail" the open-id idea I think we should support oAuth 100% and it certainly would help with persistent applications and scalability...
I don't think that's a derail at all. I don't know OAuth that well, but it seems to provide the same benefits of OpenID Provider.
OpenID and OAuth are different. The former provides a decentralized, yet single, login service, while the latter provides an authorization service from a consumer application to a provider application. They seem similar at first, but do different things. Both would be nice to have. The following article gives a good idea of the differences:
http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-th...
Respectfully,
Ryan Lane
Not to "derail" the open-id idea I think we should support oAuth 100% and it certainly would help with persistent applications and scalability...
But ...for the most part you can build these types of applications in pure javascript. Anytime you need to run an api action that requires you to be on the target domain you call a bit of code to iframe proxy that action on the target domain and communicate its results to the client domain with another iframe back to the client.
That is fine for applications that require user interaction, but one of the major benefits of OAuth is that an application can do an action on behalf of a user without their direct interaction; they don't even need to be logged in. Also, OAuth is a standard that is becoming fairly widely used. We shouldn't force third parties to use our custom made solution.
That said, the javascript solution could be useful for lightweight applications that don't need to do actions on a user's behalf without direct interaction.
Respectfully,
Ryan Lane
wikitech-l@lists.wikimedia.org