StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>There should be no problem with that aproach.</p> <p>Let's say you have a database "test", and have an admin account already:</p> <pre><code>curl -X PUT http://localhost:5984/test -u "admin:123" </code></pre> <p>Now you can create a _security document for it:</p> <pre><code>curl -X PUT http://localhost:5984/test/_security -u "admin:123" -d '{"admins":{"names":[], "roles":[]}, "readers":{"names":["joe"],"roles":[]}}' </code></pre> <p>Them only the user "joe" will be able to read the database. To create the user you must have already the sha1 hashed password:</p> <pre><code>curl -X POST http://localhost:5984/_users -d '{"_id":"org.couchdb.user:joe","type":"user","name":"joe","roles":[],"password_sha":"c348c1794df04a0473a11234389e74a236833822", "salt":"1"}' -H "Content-Type: application/json" </code></pre> <p>This user have the password "123" hashed using sha1 with salt "1" (sha1("123"+"1")), so he can read the database:</p> <pre><code>curl -X GET http://localhost:5984/test -u "joe:123" </code></pre> <p>He can read any document now on that database, and no other user (but him and admin) can.</p> <p><strong>UPDATED: Writer security</strong></p> <p>The above method issues the reader problem, but the reader permission here actually mean "read/write common docs", so it allows to write docs except for design-docs. The "admin"s in the _security doc are allowed to write do design-docs in this database.</p> <p>The other approach, as taken from your own answer, is the "validate_doc_update", you can have a validate_doc_update as follow in a file:</p> <pre><code>function(new_doc, old_doc, userCtx) { if(!userCtx || userCtx.name != "joe") { throw({forbidden: "Bad user"}); } } </code></pre> <p>And push it into a couchdb design:</p> <pre><code>curl -X PUT http://localhost:5984/test/_design/security -d "{ \"validate_doc_update\": \"function(new_doc,doc,userCtx) { if(userCtx || userCtx.name != 'joe') {throw({forbidden: 'Bad user'})}}\"}" --user 'admin:123' </code></pre> <p>Them "joe" can write to the database using Basic Authentication:</p> <pre><code>curl -X PUT http://localhost:5984/test/foobar -d '{"foo":"bar"}' -u 'joe:123' </code></pre> <p>As you also addressed you can use the _session api to get a cookie for authentication:</p> <pre><code>curl http://localhost:5984/_session -v -X POST -d 'name=joe&password=123' -H "Content-Type: application/x-www-form-urlencodeddata" </code></pre> <p>This will return a header like:</p> <pre><code>Set-Cookie: AuthSession=am9lOjRDRDE1NzQ1Oj_xIexerFtLI6EWrBN8IWYWoDRz; Version=1; Path=/; HttpOnly </code></pre> <p>So you can include the cookie "AuthSession=am9lOjRDRDE1NzQ1Oj_xIexerFtLI6EWrBN8IWYWoDRz" in your next requests and they will be authenticated.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload