When i used this on my server, it gave me a valid cookie, even when the json was:
Content-Type: application/json
{
“name”: “chef123”,
“password”: “TotallyNotMyPassword”
}
Does it not check the password? If not, which function do we use to check the password?
Kind regards,
David
You are probably making the call on the ADMIN Rest API on port 4985, in this case the password is ignored as you have the privileges to change the users password.
If you make the call on the Public REST API, then the password will be validated.
Andy
When I make the call on the Public REST API, I get:
0 NO RESPONSE
Doesn’t matter if I have the correct password or not.
Kind regards,
David
It works with the following config file and curl commands:
{
"log": ["*"],
"databases": {
"db": {
"server": "walrus:",
"users": {
"GUEST": {"disabled": true},
"chef123": {"password": "letmein"}
}
}
}
}
With the correct password:
curl -vX POST -H 'Content-Type: application/json' \
:4984/db/_session \
-d '{"name": "chef123", "password": "letmein"}'
* Hostname was NOT found in DNS cache
* Trying ::1...
* Connected to (::1) port 4984 (#0)
> POST /db/_session HTTP/1.1
> User-Agent: curl/7.37.1
> Host: :4984
> Accept: */*
> Content-Type: application/json
> Content-Length: 42
>
* upload completely sent off: 42 out of 42 bytes
< HTTP/1.1 200 OK
< Content-Length: 106
< Content-Type: application/json
* Server Couchbase Sync Gateway/1.1.0 is not blacklisted
< Server: Couchbase Sync Gateway/1.1.0
< Set-Cookie: SyncGatewaySession=481fd89a06a964cd3a25c72a63abdbef9932f1b7; Path=/db/; Expires=Sat, 18 Jul 2015 14:17:04 UTC
< Date: Fri, 17 Jul 2015 14:17:04 GMT
<
* Connection #0 to host left intact
{"authentication_handlers":["default","cookie"],"ok":true,"userCtx":{"channels":{"!":1},"name":"chef123"}}⏎
Incorrect password:
curl -vX POST -H 'Content-Type: application/json' \
:4984/db/_session \
-d '{"name": "chef123", "password": "TotallyNotMyPassword"}'
* Hostname was NOT found in DNS cache
* Trying ::1...
* Connected to (::1) port 4984 (#0)
> POST /db/_session HTTP/1.1
> User-Agent: curl/7.37.1
> Host: :4984
> Accept: */*
> Content-Type: application/json
> Content-Length: 55
>
* upload completely sent off: 55 out of 55 bytes
< HTTP/1.1 401 Unauthorized
< Content-Type: application/json
* Server Couchbase Sync Gateway/1.1.0 is not blacklisted
< Server: Couchbase Sync Gateway/1.1.0
< Date: Fri, 17 Jul 2015 14:15:30 GMT
< Content-Length: 49
<
* Connection #0 to host left intact
{"error":"Unauthorized","reason":"Invalid login"}⏎
James
Nope, still doesn’t work for me. My install of cbserver && gateway are on the internet, so I’ll provide the details so you can verify I’m not crazy.
Here’s the REST endpoint:
http://104.154.90.14:4984/gamesim-sample/_session
I’m using Advanced REST client through my Chrome browser.
And below is the config file gateway is currently running:
{
"log":["*"],
"verbose": true,
"interface": ":4984",
"adminInterface": ":4985",
"facebook" : {
"register" : true
},
"databases":{
"gamesim-sample":{
"server": "http://cb-server1:8091",
"users": {
"GUEST": {"disabled": false, "admin_channels": ["*"]},
"chef123": {"password": "letmein"}
},
"bucket": "gamesim-sample",
"sync": `function(doc) {channel(doc.channels);}`
}
}
}
I don’t know if this helps, but here’s the output on the gateway console when I try _session on the public port:
net/http.func·011()
/usr/local/go/src/net/http/server.go:1130 +0xbb
github.com/couchbase/sync_gateway/rest.(*handler).handleSessionPOST(0xc20805ea20, 0x0, 0x0)
/home/couchbase/jenkins/workspace/sync-gateway-unix-builds/release/1.1.0/community/app-under-test/sync_gateway/src/github.com/couchbase/sync_gateway/rest/session_api.go:43 +0x35d
github.com/couchbase/sync_gateway/rest.(*handler).invoke(0xc20805ea20, 0xd8c750, 0x0, 0x0)
/home/couchbase/jenkins/workspace/sync-gateway-unix-builds/release/1.1.0/community/app-under-test/sync_gateway/src/github.com/couchbase/sync_gateway/rest/handler.go:159 +0x4b8
github.com/couchbase/sync_gateway/rest.func·015(0x7fb122f0f448, 0xc20827bd60, 0xc2081c4820)
/home/couchbase/jenkins/workspace/sync-gateway-unix-builds/release/1.1.0/community/app-under-test/sync_gateway/src/github.com/couchbase/sync_gateway/rest/handler.go:86 +0x7d
net/http.HandlerFunc.ServeHTTP(0xc2080d0b00, 0x7fb122f0f448, 0xc20827bd60, 0xc2081c4820)
/usr/local/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc20803b5e0, 0x7fb122f0f448, 0xc20827bd60, 0xc2081c4820)
/home/couchbase/jenkins/workspace/sync-gateway-unix-builds/release/1.1.0/community/app-under-test/sync_gateway/src/github.com/gorilla/mux/mux.go:86 +0x29e
github.com/couchbase/sync_gateway/rest.func·017(0x7fb122f0f448, 0xc20827bd60, 0xc2081c4820)
/home/couchbase/jenkins/workspace/sync-gateway-unix-builds/release/1.1.0/community/app-under-test/sync_gateway/src/github.com/couchbase/sync_gateway/rest/routing.go:236 +0x32f
net/http.HandlerFunc.ServeHTTP(0xc208136b00, 0x7fb122f0f448, 0xc20827bd60, 0xc2081c4820)
/usr/local/go/src/net/http/server.go:1265 +0x41
net/http.serverHandler.ServeHTTP(0xc20825d080, 0x7fb122f0f448, 0xc20827bd60, 0xc2081c4820)
/usr/local/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc20827bcc0)
/usr/local/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:1751 +0x35e
Thanks for your help.
Kind regards,
David
Using CURL that endpoint is functioning correctly:
curl -i -X POST http://104.154.90.14:4984/gamesim-sample/_session -d '{ "name":"chef123", "password":"letmein" }' -H "Content-Type: application/json"
HTTP/1.1 200 OK
Content-Length: 106
Content-Type: application/json
Server: Couchbase Sync Gateway/1.1.0
Set-Cookie: SyncGatewaySession=ee06eb25d86b90ce82bbc4abb4860c2866a6c717; Path=/gamesim-sample/; Expires=Sat, 18 Jul 2015 14:40:34 UTC
Date: Fri, 17 Jul 2015 14:40:34 GMT
{"authentication_handlers":["default","cookie"],"ok":true,"userCtx":{"channels":{"!":1},"name":"chef123"}}
It looks like the issue might be related to your advanced rest client sending an “Origin” CORS header, which is not allowed for login.
Andy
It looks like the issue might be related to your advanced rest client sending an “Origin” CORS header, which is not allowed for login.
Oy! I never would have figured that out!
What’s the rationale behind that?
There are a couple of tickets that cover the CORS issues quite well here and here
You can configure CORS login support in the sync gateway config.json, e.g.
"CORS": {
"Origin":["http://localhost:8000"],
"LoginOrigin":["http://localhost:8000"],
"Headers":["Content-Type"],
"MaxAge": 1728000
},
There is CORS support documentation at the bottom of the page here
Thanks so much Andy! Very helpful.
I know writing documentation is everybody’s favorite pasttime but I think it should be updated to explain all this.
I was under the impression that _session only worked on the Admin port, because REST API >> Authentication makes no mention of it. It’s only mentioned on the Admin REST API section.
The function page for _session (which, again, is filed under Admin REST) states that password is required, which leads one to believe that it’s going to try to validate it. Further, nowhere does it say that using _session on the admin port does not validate and automatically creates a cookie (which, apparently, is what it does).
The aforementioned _session page doesn’t say boo about CORS or the origin header.
Anyway, glad it’s working for me.
Kind regards,
David
@dbergan Thanks for providing your feedback on the docs! Fixing this asap and should be updated soon.
James
Sounds good, James.
Here’s another area to fix in the docs:
An app server can create a session for a user by sending a POST request to /dbname/_session. This works only on the admin port.