couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ido Ran <ido....@gmail.com>
Subject Re: Authentication Question
Date Sun, 23 Oct 2011 11:34:55 GMT
Hi Marcus,

Sounds like you really solve the login via 3rd party cleanly.
Can you please refere me to some code or document explain it in more
details?
Also, is it possible to extend such solution to use CouchDB replication?

Thank you,
Ido

On Thu, Oct 20, 2011 at 4:55 AM, Wordit <wordituk@gmail.com> wrote:

> On Wed, Oct 19, 2011 at 11:59 AM, Paul Hirst <paul.hirst@sophos.com>
> wrote:
> >
> > If I can avoid it I'd rather not have users really exist in the _users
> database but if this is unavoidable maybe I could create them on the fly?
>
>
> Paul, I added users with existing logins to a couch db as needed. The
> existing system in my case was to use OpenID (and Facebook) logins,
> but the principal is the same.
>
> Authentication goes via another system, which talks to the third party
> login systems and then to the couch. It adds users to the couch as
> needed. Passwords are auto-generated and saved in an admin-only couch
> db.
>
> The neat thing being that even if anybody compromises the couch, the
> passwords are useless outside of this application. The actual login
> info the user enters is elsewhere, and the couch has no access to
> those systems (in this case being OpenIDs they are kept by Google,
> Yahoo, myOpenID etc).
>
> Once authenticated, the user is automatically logged in to the couch
> by getting the login details of the user's couch account, which it
> created earlier, and which is kept in a couch db. The _users db is
> also used, but users cannot login directly because they do not know
> the password which is stored in an admin-only db.
>
> The external authentication system sends info to the browser so the
> user can be logged in to the couch, with a cookie token. However, it
> never trusts the browser. All the browser sends over is the username
> of the user logged into the couch. Authentication is rechecked each
> time, which is easy and occurs without further user intervention.
> Users only do one login per session with their existing account. You
> can set a short-term session cookie or let the authentication system
> do its thing each time.
>
> Sounds a bit complicated and it was due the same-domain-policy issues
> (the elegant solution being PostMessage). It is rather good though
> because it gives you full control over the data and authentication.
>
> HTH,
>
> Marcus
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message