> Do you mean you load it at your application layer and then use it to
filter your other views?
Yes, that pretty much sums it up. I have no special module for users. It
is just part of my application code.
This is not just for page serving. I use websockets and they also log in.
The code to support the sockets filters the views. This is especially
important when I access the db directly from the web page. DB accesses
through the websockets are proxied by my app just so I can check
permissions. I'd love for the app to access the couchdb port directly but
I couldn't find any way to make that secure. I consider this another
example of a couchdb access-control flaw.
On Sat, Feb 11, 2012 at 6:34 PM, Daniel Bryan <danbryan@gmail.com> wrote:
> Could you explain what you mean about loading the user doc? Do you mean you
> load it at your application layer and then use it to filter your other
> views?
> On Feb 12, 2012 1:25 PM, "Mark Hahn" <mark@hahnca.com> wrote:
>
> > I'm doing something similar in one database. I had to ignore couch's
> > built-in user system and roll my own. Couch's built-in permission
> control
> > is too limited. I found it simple to create a doc type of 'user' and
> save
> > the doc id in cookies. Then I keep a list of permissions to other docs
> in
> > my user doc. Then on every access I load the user doc and the use the
> > permissions to control the db lookups (view keys). This is no more
> complex
> > than what I used to do in mysql.
> >
> > I know other people have used one db per user, but I found that too
> > complex. How would you do replication?
> >
>
|