Update docs on private DB security
See original GitHub issueHi,
From the current documentation in the readme, and looking into the code, I think the privateDBs are not restricted to just the user_ids they are based on. E.g. If I am logged in as A so long as I know B’s user_id (and private DB URL), I can read/write to it.
Considering the above assumption is right, how can I add a design doc with validate_doc_update
function to disallow users whose id won’t match with the DB name? If I can do that, then even if the userID is leaked, a different user won’t be able to read/write into this user’s DB even after guessing the DBURL. Although CouchDB is new to me, I don’t think I can get DB Name within the validate_doc_update
function. As an alternative, is there a way in which I can match the logged in user’s ID with the DBUrl on the server (although I take it that once the client has the DB URL, all requests would directly hit the remote CouchDB, not go through the express app)?
My intention is to prevent any user other than the privateDB user from having any access to it.
Thanks in advance!
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (5 by maintainers)
Top GitHub Comments
I agree the README needs some clarity. I am going to leave this issue open to remind me.
Great, so looks like Superlogin already takes care of some of the steps to ensure privateDBs remain accessible only to their owners. IMHO, it may help adopters if the readme has some more clarity on the concept of privateDBs like how they are initialized and what default security features are already added. And what responsibilities should be handled by the adopters.
Thanks for all your help Colin, I am closing this issue.