Re: [Wikitech-l] Revisiting becoming an OpenID Provider

2010-05-28 Thread Robb Shecter


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


[Wikitech-l] Revisiting becoming an OpenID Provider

2010-05-27 Thread Robb Shecter
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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Revisiting becoming an OpenID Provider

2010-05-27 Thread Robb Shecter


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