couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Caprari <>
Subject Re: draft openid implementation
Date Tue, 12 Jan 2010 10:01:33 GMT
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.


On Tue, Jan 12, 2010 at 9:28 AM, Brian Candler <> 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

View raw message