You're right. Simple and works, too. To recap: - a roundtrip to the endpoint verifies user claim of <openid> - the user with id org.couchdb.user:<openid> is loaded or created and loaded - a cookie is installed using couch_httpd_auth:cookie_auth_header
from now on _session returns the right stuff. Some stuff is not quite right yet: - salt is not random - it only sopports openid 1.1 - it has only been tested against my blog and myopenid.com eopeind author suggested another library that may support openid 2, I'll try to add it after a code cleanup and some tests. To test, hit http://caprazzi.net:5984/_session?openid=auth-request&openid-identifier=<your_openid_identifier> You should be redirected to your your provider and then back to caprazzi.net. After that go to _utils and see how futon likes it. cheers On Tue, Jan 12, 2010 at 4:52 PM, Chris Anderson <[email protected]> wrote: > On Tue, Jan 12, 2010 at 2:01 AM, Matteo Caprari > <[email protected]> wrote: >> An openid signup should create a real user in the system, so apps need >> not to know about openid. As for roles I think by defult no roles >> should be added, but I may be wromg here. >> >> The implementation is so short of functionalities that everything is >> up for debate, but in short this is my plan: >> >> - user, couch and endpoint interact so that the couch verifies that >> the user owns the id >> - couch tries to find a user mapped the userid >> - if a user is found, a cookie compatible with couch_httpd_auth is installed >> >> - if a user is not found, this is a signup process: a new user >> document is stored and a cookie is given to the client. The user can >> then optionally be prompted to change his username. >> >> As a user may be mapped to multiple openids, I think the user document >> could contain a an array of verified openids for that user. >> >> { >> _id: 'org.couchdb.user:<openid>', >> username: <openid>, >> openid: [<openid>], >> roles: [] >> } >> >> - openid-to-user mappings could also be stored in separate documents, >> especially if we don't want to bloat the user document with all future >> authentication schemes. >> - I haven't figured out exactly how to generate a cookie that works >> with the standard auth. > > This sounds reasonable to me. The cookie-making code should be in > there, I think it is pretty simple. > >> >> -teo >> >> On Tue, Jan 12, 2010 at 9:28 AM, Brian Candler <[email protected]> wrote: >>> On Mon, Jan 11, 2010 at 02:34:23PM +0000, Matteo Caprari wrote: >>>> - It uses its own cookie scheme to maintain authentication. Ideally it >>>> should install >>>> a cookie compatible with couch_httpd_auth, but that requires mapping >>>> an openid to a real user or >>>> creating a real user. >>> >>> How do openid users get assigned to roles, or is that not done? >>> >>> Does that mean that your application's validate_doc_update currently has to >>> have hard-coded the capabilities for individual openids? >>> >>> Thanks, >>> >>> Brian. >>> >> >> >> >> -- >> :Matteo Caprari >> [email protected] >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > -- :Matteo Caprari [email protected]
