Couchdb: Replicator _session support incompatible with require_valid_user=true setting

[adrienverge]

Hi,

After updating to CouchDB 2.2.0, replication stops working and logs show the following line:

[notice] 2018-08-09T10:46:14.759423Z [email protected] <0.9646.0> 332c814281 localhost:15984 127.0.0.1 undefined POST /_session 401 ok 1

It may be related to https://github.com/apache/couchdb/pull/1462.

• What works:

  • Logging in with Fauxton, listing databases, creating a database, etc., using root:password.
  • curl -X PUT -u root:password http://127.0.0.1:15984/new_db

• What doesn't work:

  • Initiating a local replication with Fauxton, even when providing credentials for both source and target. State stays "retrying", and logs show errors 401.

  • ```
    curl -X POST -u root:password http://127.0.0.1:15984/_replicate \
    -H "Content-Type: application/json" \
    -d '{"source":"existing_db", "target":"new_db"}'

  fails with:
  

  {"error":"replication_auth_error","reason":"{session_request_unauthorized,\"http://127.0.0.1:15984/_session\",\"root\"}"}
  ```

  • Same with the Python client.

For info, I use a 3-node cluster on Fedora. Replication always worked (from 2.0.0-beta to 2.1.2). My local.d/config.ini contains:

[chttpd]
require_valid_user = true
...

[cors]
credentials = true
...

[couch_httpd_auth]
allow_persistent_cookies = true
secret = --

[admins]
root = password

...

I'd be glad to help by providing more details!

[wohali]

Hi @adrienverge ,

I suspect this is an incompatibility of the new _session support with the require_valid_user=true setting.

As a temporary workaround, you can disable the new _session support in the replicator by setting:

[replicator]
auth_plugins = couch_replicator_auth_noop

Before making that change, do you have the same issue if you:

• Post a document to the _replicator DB using curl from the command line?
• Post to the /_replicate endpoint using curl from the command line?
• Post a document to the _replicator DB using Fauxton?

[adrienverge]

Hi @wohali, thanks for your answer.

• You're right, removing require_valid_user = true solves the problem.

• curl -X POST -u root:password http://127.0.0.1:15984/_replicator \
     -H "Content-Type: application/json" \
     -d '{"_id": "rep_1", "source":"existing_db", "target":"new_db", "create_target": true}'
  

  → The document is created, but the copy DB is not created (hence not replicated).

• curl -X POST -u root:password http://127.0.0.1:15984/_replicate \
     -H "Content-Type: application/json" \
     -d '{"source":"existing_db", "target":"new_db"}'
  

  {"error":"replication_auth_error","reason":"{session_request_unauthorized,\"http://127.0.0.1:15984/_session\",\"root\"}"}
  

• Post a document to the _replicator DB using Fauxton:
  → The document is created, but the copy DB is not created (hence not replicated).

Do I understand correctly that this is a temporary problem that happens in our special use-case (require_valid_user = true), and should be fixed in a future release? Or do we have a real forward-incompatibility in our configuration, and we must change it?

Thanks!

[janl]

cc @nickva: do you think we can add a “use basic auth against _session if no session id exists yet“ mode for this?

[wohali]

@adrienverge Yes, you understand correctly, this is a bug, we'll work out how to fix it.

Couch should be falling back to the non-session based authentication when the session-based authentication fails, but for some reason, it's not.

The workaround is a perfectly fine thing to do, it's not forward-incompatible. When session-based auth is fixed to work with require_valid_user=true, you'll be able to re-add that functionality back in by removing the 2 lines from your local.ini file.

[adrienverge]

Thanks, it's clear!

In this case I'll simply wait for the next version. Feel free to ask if you need someone to test the fix!

[nickva]

@wohali @adrienverge

In the default case, session based auth plugin would fall back to basic auth if when it tries to use /_session endpoint it gets back a 404 (it doesn't exist). It assumes that endpoint doesn't support session and falls back to using basic auth.

In case of require_valid_user=true when it initializes is sends a POST request to _session with the user and name in the form body

POST /_session HTTP/1.1
Content-Type: application/x-www-form-urlencoded

name=adm&password=pass

That fails with a 401. On a 401 failure, session plugin assumes it is a bad username or password.

I made PR to specifically handle the case when 401 response is because of the require_valid_user=true setting and fall back to using basic auth only.

https://github.com/apache/couchdb/pull/1551

[SCdF]

Should we expect this to work in 2.3? It still fails for me:

$ curl -X POST http://admin:pass@localhost:5984/_replicate
    -d '{"source":"my-source-db","target":"my-target-db"}'
    -H "Content-Type: application/json"
{"error":"replication_auth_error","reason":"{session_request_unauthorized,\"http://127.0.0.1:5984/_session\",\"admin\"}"}
$ curl http://admin:pass@localhost:5984/
{"couchdb":"Welcome","version":"2.3.0","git_sha":"07ea0c7","uuid":"8517c5d22122b1e331ec01a0690e9adb","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

I have require_valid_user set to true. MacOS.

[wohali]

@SCdF Use full URLs for source and target. In fact, the "short" syntax is deprecated and doesn't work right in any version of 2.x.

This is a sore point that hasn't been fully addressed in documentation/Fauxton.

[SCdF]

@wohali thanks for the reply. Would moving forward be fixing short syntax in 2.x, or fixing documentation / fauxton to not point toward the short syntax?

[wohali]

@SCdF From what I've heard, the latter.

[bgold0]

Has this been fixed in 2.3? Seem to still have this issue @wohali