CouchDB
  1. CouchDB
  2. COUCHDB-1452

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

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • 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

    • Skill Level:
      Dont Know

      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

        Activity

        Seb created issue -
        Seb made changes -
        Field Original Value New Value
        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 ?



        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 :)
        Hide
        Keith Mashinter added a comment -

        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=.

        Show
        Keith Mashinter added a comment - 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=.
        Hide
        Nathan Vander Wilt added a comment -

        +1 on somehow whitelisting _session (and other authorization plugin handlers?) even when couch_httpd_auth/require_valid_user=true

        I think Keith's suggested workaround (send credentials twice as Basic Auth header alongside previously-normal cookie requests) is a good recommendation against the current situation though. Basically, any code that was written to use CouchDB as a session store needs to be prepared for a 401 (rather than just null user info) back from _session queries, as well as sending the username/password twice when authenticating (once in headers to get past the require_valid_user "firewall" and again in the body for the cookie generating code).

        Show
        Nathan Vander Wilt added a comment - +1 on somehow whitelisting _session (and other authorization plugin handlers?) even when couch_httpd_auth/require_valid_user=true I think Keith's suggested workaround (send credentials twice as Basic Auth header alongside previously-normal cookie requests) is a good recommendation against the current situation though. Basically, any code that was written to use CouchDB as a session store needs to be prepared for a 401 (rather than just null user info) back from _session queries, as well as sending the username/password twice when authenticating (once in headers to get past the require_valid_user "firewall" and again in the body for the cookie generating code).

          People

          • Assignee:
            Unassigned
            Reporter:
            Seb
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development