If you're delving into OpenID support, there is code out there to use. Matt Pelletier gave a presentation on OpenID support at RailsConf. There is a consumer plugin available:
http://identity.eastmedia.com/identity/show/Consumer+Plugin and development ongoing for Rails support for identity servers too. You can see example consumer code in Rick Olson's Rails-Weenie app: http://svn.techno-weenie.net/projects/rails_help/ General info: http://identity.eastmedia.com/ http://wiki.rubyonrails.org/rails/pages/OpenID -- Josh Susser http://blog.hasmanythrough.com On Jul 13, 2006, at 6:31 AM, Scott Laird wrote: > Yes :-). > > There are a couple things that I'd like to see. First, OpenID is > probably the most useful one today, because it gets us LiveJournal, > and I *think* that TypeKey is supposed to be OpenID-able soon, if it > isn't already. > > The flip side of this is that Typo should be an OpenID server, too, so > we can publish our own identities. This way Typo users will be able > to authenticate ourselves to each other. > > I can work on the server side if you want to handle the client side. > At some point we'll need to add a check so that we won't try to use > OpenID to authenticate against ourself--on single-threaded servers > (Webrick, single-port Mongrel, single-dispatcher fcgi) that'll > deadlock. > > > Scott > > On 7/13/06, Piers Cawley <[EMAIL PROTECTED]> wrote: >> I got slightly sidetracked on the way to the TRAC, but I've been >> thinking about identity and blogging. I really, really, really don't >> want to have to add yet another login/password pair to a commenter's >> keychain if I can possibly help it. >> >> But, it would be cool for people to have some way of identifying >> themselves in some trusted fashion (so that, for example comments >> made >> by signed in users get added straight away, but all other comments >> get >> put into a queue pending approval). >> >> My thinking on this is that we need to come up with some sort of >> an identity control API. We define the ways in which Typo interacts >> with an authentication service, things like: >> >> authenticator.session_is_authenticated?(session) >> authenticator.session_user(session) - returns a user object >> authenticator.authenticate(controller, session) - May do >> redirects, >> hence the >> controller >> >> Then our user object will carry information like: >> >> user.memento - Unique string identifying this user (for use in any >> authorization system) >> user.email >> user.display_name >> user.icon >> user.url >> user.authenticated? >> >> Possibly more, possibly fewer. Methods like #icon can obviously >> return >> an empty string... >> >> Once we've worked out the protocols (and tweaked our current >> identification mechanism to use them) it should be relatively easy to >> write adaptors for Flickr; Yahoo; Google; OpenID; some kind of >> dumbass >> captcha system, if you really insist but don't expect it to get >> accepted into the trunk; or whatever other authentication services >> exist or arise. >> >> Of course, methods like 'authenticator.session_is_authenticated?' >> will >> generally be accessed via helper methods like: >> >> session.authenticated? >> >> Right, brain dump over, I shall proceed to the Trac directly. >> >> Note: Authentication is *not* the same as Authorization. About the >> only thing I'm sure of regarding authorization is that we shall have >> something. >> >> Note2: This isn't even remotely imminent. I'm just sketching here. >> >> -- >> Piers Cawley <[EMAIL PROTECTED]> >> http://www.bofh.org.uk/ _______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
