You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Seb (Created) (JIRA)" <ji...@apache.org> on 2012/04/01 15:06:28 UTC

[jira] [Created] (COUCHDB-1452) Can't POST /_session with require_valid_user=true (Cookie authentication)

Can't POST /_session with require_valid_user=true (Cookie authentication)
-------------------------------------------------------------------------

                 Key: COUCHDB-1452
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1452
             Project: CouchDB
          Issue Type: Bug
    Affects Versions: 1.1.1
         Environment: Fedora 16

[root@CouchDBTest ~]# uname -a
Linux CouchDBTest 3.3.0-8.fc16.x86_64 #1 SMP Thu Mar 29 18:37:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
            Reporter: Seb


Hello

I'm playing with couchdb and having a small problem with authentication (I would like to be cookie+https only)

With require_valid_user, every action must be authenticated.

Then we need to authenticate to couchdb in order to POST to /_session.

So, if you disable classical HTTP auth, you can't authenticate users on couchdb only with cookie.

[root@CouchDBTest ~]# curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=admin&password=this_is_a_test'
* About to connect() to localhost port 5984 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> POST /_session HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: localhost:5984
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 34
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm="administrator"
< Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
< Date: Sun, 01 Apr 2012 14:58:13 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 61
< Cache-Control: must-revalidate
< 
{"error":"unauthorized","reason":"Authentication required."}
* Connection #0 to host localhost left intact
* Closing connection #0

The workaround to obtain a cookie with require_valid_user=true is to authenticate with classical HTTP auth then to auth again with a POST on _session.

Not POST /_session should be allowed even for require_valid_user=true ?





--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (COUCHDB-1452) Can't POST /_session with require_valid_user=true (Cookie authentication)

Posted by "Seb (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/COUCHDB-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Seb updated COUCHDB-1452:
-------------------------

    Description: 
Hello

I'm playing with couchdb and having a small problem with authentication (I would like to be cookie+https only)

With require_valid_user, every action must be authenticated.

Then we need to authenticate to couchdb in order to POST to /_session.

So, if you disable classical HTTP auth, you can't authenticate users on couchdb only with cookie.

[root@CouchDBTest ~]# curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=admin&password=this_is_a_test'
* About to connect() to localhost port 5984 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> POST /_session HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: localhost:5984
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 34
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm="administrator"
< Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
< Date: Sun, 01 Apr 2012 14:58:13 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 61
< Cache-Control: must-revalidate
< 
{"error":"unauthorized","reason":"Authentication required."}
* Connection #0 to host localhost left intact
* Closing connection #0

The workaround to obtain a cookie with require_valid_user=true is to authenticate with classical HTTP auth then to auth again with a POST on _session.

Not POST /_session should be allowed even for require_valid_user=true ?


Thank in advance :)


  was:
Hello

I'm playing with couchdb and having a small problem with authentication (I would like to be cookie+https only)

With require_valid_user, every action must be authenticated.

Then we need to authenticate to couchdb in order to POST to /_session.

So, if you disable classical HTTP auth, you can't authenticate users on couchdb only with cookie.

[root@CouchDBTest ~]# curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=admin&password=this_is_a_test'
* About to connect() to localhost port 5984 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> POST /_session HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: localhost:5984
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 34
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm="administrator"
< Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
< Date: Sun, 01 Apr 2012 14:58:13 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 61
< Cache-Control: must-revalidate
< 
{"error":"unauthorized","reason":"Authentication required."}
* Connection #0 to host localhost left intact
* Closing connection #0

The workaround to obtain a cookie with require_valid_user=true is to authenticate with classical HTTP auth then to auth again with a POST on _session.

Not POST /_session should be allowed even for require_valid_user=true ?





    
> Can't POST /_session with require_valid_user=true (Cookie authentication)
> -------------------------------------------------------------------------
>
>                 Key: COUCHDB-1452
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1452
>             Project: CouchDB
>          Issue Type: Bug
>    Affects Versions: 1.1.1
>         Environment: Fedora 16
> [root@CouchDBTest ~]# uname -a
> Linux CouchDBTest 3.3.0-8.fc16.x86_64 #1 SMP Thu Mar 29 18:37:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Seb
>
> Hello
> I'm playing with couchdb and having a small problem with authentication (I would like to be cookie+https only)
> With require_valid_user, every action must be authenticated.
> Then we need to authenticate to couchdb in order to POST to /_session.
> So, if you disable classical HTTP auth, you can't authenticate users on couchdb only with cookie.
> [root@CouchDBTest ~]# curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=admin&password=this_is_a_test'
> * About to connect() to localhost port 5984 (#0)
> *   Trying ::1... Connection refused
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > POST /_session HTTP/1.1
> > User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> > Host: localhost:5984
> > Accept: */*
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 34
> > 
> < HTTP/1.1 401 Unauthorized
> < WWW-Authenticate: Basic realm="administrator"
> < Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
> < Date: Sun, 01 Apr 2012 14:58:13 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 61
> < Cache-Control: must-revalidate
> < 
> {"error":"unauthorized","reason":"Authentication required."}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> The workaround to obtain a cookie with require_valid_user=true is to authenticate with classical HTTP auth then to auth again with a POST on _session.
> Not POST /_session should be allowed even for require_valid_user=true ?
> Thank in advance :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (COUCHDB-1452) Can't POST /_session with require_valid_user=true (Cookie authentication)

Posted by "Keith Mashinter (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/COUCHDB-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475693#comment-13475693 ] 

Keith Mashinter commented on COUCHDB-1452:
------------------------------------------

We were able to work around this (in v1.2) by sending BOTH the Authorization: Base64(user:pass) AND Content-Type: application/x-www-form-urlencoded of the name=user&password=pass to POST /_session which then allow authentication to happen and the Set-Cookie was returned since we have a name&password to the POST /_session whereas if we didn't supply a name&password to the POST it didn't give us a Set-Cookie.

This is tricky since, depending on the situation, the client may end up sending an old Authorization with a POST /_session of a new name=&password=.  But still, a POST /_session even without user&password content, should be OK to create a session and generate a Set-Cookie response so long as it has a valid Authorization.  Some web frameworks, e.g. our experience with Tomcat/Java, do act a bit strangely when trying to establish a new Authorization on top of an existing one, so it's probably best to continue supporting sending both Authorization user:password and POST content name=&password=.
                
> Can't POST /_session with require_valid_user=true (Cookie authentication)
> -------------------------------------------------------------------------
>
>                 Key: COUCHDB-1452
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1452
>             Project: CouchDB
>          Issue Type: Bug
>    Affects Versions: 1.1.1
>         Environment: Fedora 16
> [root@CouchDBTest ~]# uname -a
> Linux CouchDBTest 3.3.0-8.fc16.x86_64 #1 SMP Thu Mar 29 18:37:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Seb
>
> Hello
> I'm playing with couchdb and having a small problem with authentication (I would like to be cookie+https only)
> With require_valid_user, every action must be authenticated.
> Then we need to authenticate to couchdb in order to POST to /_session.
> So, if you disable classical HTTP auth, you can't authenticate users on couchdb only with cookie.
> [root@CouchDBTest ~]# curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=admin&password=this_is_a_test'
> * About to connect() to localhost port 5984 (#0)
> *   Trying ::1... Connection refused
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > POST /_session HTTP/1.1
> > User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> > Host: localhost:5984
> > Accept: */*
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 34
> > 
> < HTTP/1.1 401 Unauthorized
> < WWW-Authenticate: Basic realm="administrator"
> < Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
> < Date: Sun, 01 Apr 2012 14:58:13 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 61
> < Cache-Control: must-revalidate
> < 
> {"error":"unauthorized","reason":"Authentication required."}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> The workaround to obtain a cookie with require_valid_user=true is to authenticate with classical HTTP auth then to auth again with a POST on _session.
> Not POST /_session should be allowed even for require_valid_user=true ?
> Thank in advance :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira