> 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 <[email protected]> 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" <[email protected]> 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? > > >
