Couchdb Sync not working

[wongalain]

My computer can connect to my couchdb within the same network through the browser, but Tapforms cannot sign in & sync.
But it works swiftly with another couchdb server over the internet.
Any ideas or solutions?

[Brendan]

It might be an address issue. Is CouchDB running on your Mac?

If so, then if that Mac is also running Tap Forms, then you would set the Server Address to http://127.0.0.1:5984

But from a different device on the network you’ll have to use http://#.#.#.#:5984 where the ### are whatever the IP address of the computer running CouchDB is. E.g. http://192.168.0.10:5984

Or, if you’d prefer to use a named device, then you’ll need to setup SSL and deal with certificates and then use port 6984.

[wongalain]

Dear Brendan,

It is not as I can use a browser on my Mac to log into the couchdb server & make configuration changes, but just the Tapforms cannot sign in that server & start syncing. Indeed Tapforms can sync when I use another couchdb server.

[Brendan]

Did you set your bind_address to 0.0.0.0? If not, then your CouchDB server won’t accept connections from another device, only from the local computer.

[wongalain]

Yes. I have set, but still not working

[Brendan]

Do you get any connection errors?

[wongalain]

No. Attached are two screenshots.
I can the same Mac to log in the Couchdb Server through web-brower, but Tapforms cannot sign in with the same username & password.
I am thinking is there something wrong with the Tapforms couchdb modules.

Attachments:

You must be logged in to view attached files.

[Brendan]

Is that web browser running on the same machine that’s running CouchDB?

[Sam Moffatt]

160.30.44.35 should be publicly routable IP space, what sort of network setup do you have?

Without knowing the internals of your network, it feels like something is dropping packets or otherwise interfering with communication.

[wongalain]

The web browser is running on my Mac while the couchdb is running on another server. Both are within the intranet in my office

[Sam Moffatt]

What is your local IP address and do you mind running a traceroute to show if there is anything in the path to the server? The error message indicates TF making a request but that request failing along the way. I’d also check the CouchDB server logs to see if it is seeing any requests. The first request TF will make will be to create a database on the server but given the screenshots even that simple question is failing.

[wongalain]

The traceroute seems to be ok

Attachments:

You must be logged in to view attached files.

[wongalain]

I think the problem is Tapforms cannot create a database despite correct URL, username & password

[Sam Moffatt]

Can you try the following with the correct username/password:

curl -v -c /tmp/tf.jar -XPOST --data-urlencode "name=USERNAME" --data-urlencode "password=PASSWORD" http://160.30.44.35:5984/_session

And then if you get a reasonable response (e.g. something like "ok":true) then try this one:
curl -v -b /tmp/tf.jar -c /tmp/tf.jar -XPUT http://160.30.44.35:5984/db-test

And share the results of both commands (excluding your password obviously).

[Brendan]

Tap Forms needs an admin account in order to create the database on the server. It happens automatically when you sign-in. Or you have to create it on the server yourself first and then you can use a regular user account if you wish.

[wongalain]

I tried both command, seems to be ok, but Tapforms still cannot connect to the couchdb.
What can i do?

Attachments:

You must be logged in to view attached files.

[Brendan]

Can you post your CouchDB.ini file?

Mine looks like this:

[couchdb]
database_dir = /Users/brendan/Library/Application Support/CouchDB2/var/lib/couchdb
view_index_dir = /Users/brendan/Library/Application Support/CouchDB2/var/lib/couchdb
uri_file = /Users/brendan/Library/Application Support/CouchDB2/var/run/couchdb/couch.uri
uuid = 36242477eed82d2a6fd90e28d45558cb

[cluster]
n = 1
q = 2

[log]
writer = file
file = /Users/brendan/Library/Logs/CouchDB2.log

[admins]
admin = some encoded password
brendan = some encoded password

[couch_httpd_auth]
secret = some secret

[chttpd]
bind_address = 0.0.0.0
port = 5984

[daemons]
httpsd = {chttpd, start_link, [https]}

[ssl]
port = 6984
key_file = /Users/brendan/server.key
cert_file = /Users/brendan/server.crt
ciphers = undefined
tls_versions = undefined
secure_renegotiate = undefined

[wongalain]

Dear Brendan,

attached is the content of the file

Regards,

Alain

Attachments:

You must be logged in to view attached files.

[Brendan]

Can you open up the Console application, type in Tap Forms into the Search field and see if there’s any messages that appear there at the moment you try to login?

[Sam Moffatt]

Do you have any firewall software that can block per application outbound traffic?

[wongalain]

Enclosed is the console log for Tapforms during login

Attachments:

You must be logged in to view attached files.

[Sam Moffatt]

Do you have a network proxy configured in your network settings under system preferences?

[wongalain]

yes… my network traffic must get through proxy server

[Sam Moffatt]

Is it possible to disable the proxy for the internal traffic? Or disable the proxy temporarily to test if the TF sync works properly without the proxy? Do you need to use the proxy server to get to your CouchDB server?

[Brendan]

Hmm… Ok, another piece of the puzzle.

I’m not really that familiar with how the proxy could interfere with communication between Tap Forms and your CouchDB server. Is your CouchDB server running on a Mac? If so, did you try launching Tap Forms on that Mac and just using http://127.0.0.1:5984 to see if that works? That’ll tell you if Tap Forms is able to connect directly to your CouchDB server or not.

If it was a router between your Mac and the CouchDB server, then it might be a port forwarding issue. Or if it was a firewall then maybe it was blocking port 5984. Although you did connect via the web browser. But the web browser probably handles proxies properly I suppose.

[Sam Moffatt]

It’s entirely possible that CouchbaseLite or CouchDB is generating something that the proxy dislikes. I’ve noticed in my logs it looks like CBL is over-encoding items that don’t need to be which could trigger a security filter in the proxy. Since curl can directly hit the server and I don’t think it’d go through a proxy, disabling the proxy to verify if it’s the cause would help. Ideally though the proxy wouldn’t activate for internal traffic, you should be able to configure a proxy bypass in system preferences in the network preference pane for those IP addresses.

[wongalain]

Dear Brendan & Sam,

Thank you so much for your kind assistance.
Both of you are correct. My couchdb server was on a QNAP NAS with docker. Some how I find a way to bypass the proxy server & it works smoothly & perfect.
I think it is the IT department change some setting with our proxy server which previously support port 5984 to the couchdb server.

[Sam Moffatt]

Good to hear you got it figured out :) Happy New Year!

[Brendan]

Oh that’s awesome! I’m glad you got it working now.

And yes, Happy New Year to you guys too!

[Author]

Posts