creating new user in couchdb 3 without admin password - couchdb

I just downloaded and installed CouchDB v3.
On first start, it prompted me to set an admin password which I did.
For the web app that I'm building, I want to use the CouchDB user authentication feature, so I created a new _users database using the Fauxton UI.
After creating the _users database I made a call to the REST API to insert a new user (this is the example code taken from the documentation):
$ curl -X PUT http://localhost:5984/_users/org.couchdb.user:jan \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"name": "jan", "password": "apple", "roles": [], "type": "user"}'
Instead of the expected response
{"ok":true,"id":"org.couchdb.user:jan","rev":..."}
I'm getting
{"error":"unauthorized","reason":"You are not authorized to access this db."}
When adding the admin credentials to the API call, it works as expected:
$ curl -X PUT http://admin:____#localhost:5984/_users/org.couchdb.user:jan \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"name": "jan", "password": "apple", "roles": [], "type": "user"}'
{"ok":true,"id":"org.couchdb.user:jan","rev":"..."}
My question:
Are there any settings or permissions I can set to make the request work without having to add the admin credentials? (AFAIK this worked fine in v2.x)

You are missing the fun of the good old Admin Party, which for many years was the default setting for CouchDB, meaning it was installed with zero security as everyone was effectively an admin.
From The Road to CouchDB 3.0: Security[1]
One of the aspects of getting started easily was a 1.x-era choice to
make it easy to use CouchDB: the Admin Party. Admin Party means that,
by default, any request made against CouchDB was done in the context
of an admin user, i.e. you were allowed to do anything.
3.0 changed all of that by shutting down the Admin Party - what a bunch of buzz kills!
I suspect there are more sophisticated solutions, but for those that want to party on[2] quickly, minor changes to etc/local.ini and any permissions on _users will satisfy.
The key is the configuration property require_valid_user[3].
In etc/local.ini, modify the chttpd and couch_httpd_auth sections
[chttpd]
require_valid_user = false
[couch_httpd_auth]
require_valid_user = false
That's all that is needed unless there are members and/or roles defined for the _users database. If there are, they must be deleted (easily with Fauxton).
After cleaning up members/roles and altering the etc/local.ini restart CouchDB and you should be able to create users without a problem. Party on! 👍
Just be sure to consider the ramifications of such changes.
Disclaimer - I don't recommend running CouchDB in any security context resembling Admin Party!
1 The Road to CouchDB 3.0: Security
2 Party On
3 require_valid_user

Related

How to get only specific fields in Gitlab API response?

For example I want to receive only project names:
https://gitlab.com/api/v4/groups/:id/projects?fields=name
Is that possible?
That's not possible in the REST API. But, GitLab is working on GraphQL support, and you'd be able to express that in GraphQL.
https://docs.gitlab.com/ee/api/graphql/
To iterate on Vonc & King Chung Huang 's answers, using the following GraphQL query, you can get only the name field of the projects inside your group :
{
group(fullPath: "your_group_name") {
projects {
nodes {
name
}
}
}
}
You can go to the following URL : https://$gitlab_url/-/graphql-explorer and past the above query
Using curl & jq :
gitlab_url=<your gitlab host>
access_token=<your access token>
group_name=<your group name>
curl -s -H "Authorization: Bearer $access_token" \
-H "Content-Type:application/json" \
-d '{
"query": "{ group(fullPath: \"'$group_name'\") { projects { nodes { name }}}}"
}' "https://$gitlab_url/api/graphql" | jq '.'
GitLab 1.11 (May 2019) has now introduced a "basic support for group GraphQL queries "
GraphQL APIs allows users to request exactly the data they need, making it possible to get all required data in a limited number of requests.
In this release, GitLab is now supporting basic group information support in the GraphQL API.
See Issue 60786 and documentation: "Available queries"
A first iteration of a GraphQL API includes the following queries
project : Within a project it is also possible to fetch a mergeRequest by IID.
group : Only basic group information is currently supported.

User signup feathers-authentication with passport-facebook-token

I am trying to allow users to sign up for my service via "login with facebook".
I have already done arrow 1-2. I need to do arrows 3-6. I have made a minimal Feathersjs example at https://github.com/morenoh149/feathers-chat-facebook-signup-api
I seem to be having trouble getting feathers-authentication and passport-facebook-token to generate the User object and sign them up. I've reviewed passport-facebook-token carefully. This answer explains that in the callback to passport-facebook-token you should create the User object. How do I do this with feathers-authentication?
When I provide the token in the body
curl localhost:3030/authentication \
--data-binary '{\
"strategy": "facebook-token", \
"access_token": "<phone token>" \
}'
I get
{"name":"NotAuthenticated",
"message":"You should provide access_token","code":401,
"className":"not-authenticated",
"data":{"message":"You should provide access_token"}
when I pass the token as a header
curl localhost:3030/authentication \
-X POST \
-H "Authorization: Bearer <access token>"
I get error
{"name":"GeneralError",
"message":"Cannot read property 'toLowerCase' of undefined",
"code":500,"className":"general-error","data":{},"errors":{}}
So I downloaded and ran the repo, I used VSCode to run the app and set break points. I created a breakpoint in the before create hooks on users.
The issue here is that the gravatar hook is expected the email to be context.data but it is in fact embedded within the facebook response. You will need to look at extracting the email from that data so that you can create a gravatar or just remove the gravatar hook altogether.

API call IBM Watson Natural Language Understanding-xq - Python or Postman

I'm struggling to connect to the IBM Watson API for Natural Language Understanding.
I've added it to the Resource list in my IAM account. I've got to the page with an example POST request to connect to the API, and I can't seem to authenticate. I've blanked out the API key from this request but in the pages the key is supplied so I'm struggling to see why it's not working
curl -X POST -u "#######" \
-H "Content-Type: application/json" \
-d '{ "text": "I still have a dream. It is a dream deeply rooted in the
American dream. I have a dream that one day this nation will rise up and
live out the true meaning of its creed: \"We hold these truths to be
self-evident, that all men are created equal.\"", "features": {
"sentiment": {}, "keywords": {} }}' \
"https://gateway-lon.watsonplatform.net/natural-language-
understanding/api/v1/analyze?version=2018-03-19"
I've tried pasting this into Postman but I just get a 401 Unauthorized response, which makes me think it's something in the account pages of the IAM, but they've chnage the interface and not update the documentation, and I'm going round in circles because the instructions don't match the menus.
Any pointers would be appreciated. I intend to query through Python, so I'm hoping once I can get past the authentication issue it's as simple as copying the Python code out of Postman
Your -u credentials should be:
-u "apikey:#######"
As per the API documentation -
https://cloud.ibm.com/apidocs/natural-language-understanding#authentication
Somehow the API credentials were not being recognised. I must have done something wrong in the initial IAM setup, which meant that when I deleted the credentials, re-created them and then copied the new key ... everything immediately started working. Complete mystery as to why but hopefully this helps someone. Here are the instructions I followed
https://console.bluemix.net/docs/services/natural-language-understanding/getting-started.html#getting-started-tutorial
I used the SDK as suggested by Simon O'Doherty
It might also be related to me having gone into the "Manage" >> "Account" and deleted any Access Groups and Service IDs I'd attempted to create by following the "Getting Started with IAM" instructions from here, which I suspect might have been what confused me
IAM getting started (not required)

One db per user and security

I'm trying to implement an app which uses couchdb as backend, But the problem is,
When installing couchdb , couchdb allows anyone to enter couchdb and create/delete/update databases, so we configure admin(super admin) for the couchdb server to prevent anonymous And if we configure superadmin while installing couchdb server, then normal users can't create databases, so userdb for the user isn't created. Only super admin has privilege to create database in couchdb. Even users with 'admins' role can't create db in couchdb.
I just dealt with all of this myself and couldn't find hardly anything about it...
From the documentation:
Users may only access (GET /_users/org.couchdb.user:Jan) or modify (PUT /_users/org.couchdb.user:Jan) documents that they own
This means that users can add themselves to the _users db. Thus, if you have couch_peruser turned on, running the following curl command will create the user jan along with the userdb-6a616e database.
curl -X PUT http://localhost:5984/_users/org.couchdb.user:jan \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"name": "jan", "password": "apple", "roles": [], "type": "user"}'
You can use the db.signUp() function from the PouchDB Authentication plugin to effectively do the same thing. Also, I had to manually encode the username when initially creating my db var for the new remote PouchDB instance:
function encode (str) {
return unescape(encodeURIComponent(str))
.split('').map(function (v) {
return v.charCodeAt(0).toString(16)
}).join('')
}
var db = new PouchDB('http://localhost:5984/userdb-' + encode(username), {
auth: {
username: username,
password: username
},
skip_setup: true // Because the DB won't exist initially
})

CouchDB Authorization on a Per-Database Basis

I'm working on an application supported by CouchDB. Essentially, I want to create a database for each individual user of my app. To accomplish this, the admin user will create the database, but going forward, the user will need to access their database (using HTTP Auth over SSL). I've been having a hell of a time figuring this out.
The best resource I have found is in the CouchDB wiki, at this link:
http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization
It suggests that you can set per-database authorization by creating a document called "_security" to which you add a hash of admins and readers. When I attempt to create that document, the message I get back is "Bad special document member: _security".
$ curl -X GET http://localhost:5984
{"couchdb":"Welcome","version":"1.0.1"}
Any help would be appreciated!
Cheers,
Aaron.
There should be no problem with that aproach.
Let's say you have a database "test", and have an admin account already:
curl -X PUT http://localhost:5984/test -u "admin:123"
Now you can create a _security document for it:
curl -X PUT http://localhost:5984/test/_security -u "admin:123" -d '{"admins":{"names":[], "roles":[]}, "readers":{"names":["joe"],"roles":[]}}'
Them only the user "joe" will be able to read the database. To create the user you must have already the sha1 hashed password:
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"
This user have the password "123" hashed using sha1 with salt "1" (sha1("123"+"1")), so he can read the database:
curl -X GET http://localhost:5984/test -u "joe:123"
He can read any document now on that database, and no other user (but him and admin) can.
UPDATED: Writer security
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.
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:
function(new_doc, old_doc, userCtx) {
if(!userCtx || userCtx.name != "joe") {
throw({forbidden: "Bad user"});
}
}
And push it into a couchdb design:
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'
Them "joe" can write to the database using Basic Authentication:
curl -X PUT http://localhost:5984/test/foobar -d '{"foo":"bar"}' -u 'joe:123'
As you also addressed you can use the _session api to get a cookie for authentication:
curl http://localhost:5984/_session -v -X POST -d 'name=joe&password=123' -H "Content-Type: application/x-www-form-urlencodeddata"
This will return a header like:
Set-Cookie: AuthSession=am9lOjRDRDE1NzQ1Oj_xIexerFtLI6EWrBN8IWYWoDRz; Version=1; Path=/; HttpOnly
So you can include the cookie "AuthSession=am9lOjRDRDE1NzQ1Oj_xIexerFtLI6EWrBN8IWYWoDRz" in your next requests and they will be authenticated.
I've been doing more research and testing, and I want to summarize where I've gotten to, and what still isn't working for me.
First off, apologies for those who read this question: I was looking for ways to set permissions for people to write, not read, the database. It turns out be be a big difference: the techniques for creating a "reader" are entirely different from creating a "writer" (that term actually doesn't exist, though I wonder why).
In brief: you have to add a user to the _users database, which is a list of the users that have access to any database in your CouchDB instance. I was able to do that by issuing a command similar to:
curl -X PUT http://admin:password#localhost:5984/_users/org.couchdb.user:username -d '{"type":"user", "hashed_password":"2bf184a2d152aad139dc4facd7710ee848c2af27", "name":"username", "roles":[]}'
Note you need to apparently namespace the user name with the "org.couchdb.user" prefix. I used a Ruby hashing method to get the hashed_password value:
require 'digest/sha1'
pass_hash = Digest::SHA1.hexdigest(password)
This gets an apparently valid user into the database. The next step is to assign that user as a "writer" (ha, there it is again!) for the new database that I created. So I might do something like:
curl -X PUT http://admin:password#localhost:5984/newdatabase
and then
curl -X PUT http://admin:password#localhost:5984/newdatabase/_design/security -d #security.json
That .json file contains a Javascript function for the "validate_doc_update" key, and that function looks like this:
function(new_doc, old_doc, userCtx) {
if(userCtx.name != username) {
throw({forbidden: "Please log in first."});
}
}
It's roundabout, but it makes sense. However, I now am running into a problem: apparently the userCtx variable doesn't get populated until the user is authenticated. This article suggests that all you have to do is pass the credentials through an HTTP request to a special _session database, like so:
curl -X POST http://username:password#localhost:5984/_session
I can do that for my admin user, and the userCtx var will be populated. But for my newly-created user, it fails:
$ curl http://org.couchdb.user:username:password#localhost:5984/_session
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["cookie","oauth","default"]}}
Note the userCtx hash is null. I wonder if that namespace thing is causing the problem? It's got a freakin' colon in it, so maybe there's some confusion about the password? I've tried making it without the namespace, and it doesn't work at all; at least here my request appears to be hitting the database and getting a response.
I'm stuck at this point. If anyone can check my assumptions and progress thus far, I hope we can all figure out how to make this work.
Thanks!
Aaron.
You may want to check out Matt Woodward's - The Definitive Guide to CouchDB Authentication and Security http://blog.mattwoodward.com/2012/03/definitive-guide-to-couchdb.html

Resources