search

davideshay / groceries

MIT License
217 stars 7 forks source link

Error: The server is incorrectly configured with no unique ID, or is not accessible from the client. #120

Closed Radoom closed 8 months ago

Radoom commented 9 months ago

Hi, trying to try this out in docker, but ... Possibly my odd setup plus limited knowledge, but I can't get it to work.

Managed to get couchDB up, change keys and passwords, adjust docker-compose and "up" the "container of clementines".

Getting to the login page, setting the API URL to http://10.x.y.z:3333 (running with fixed IPs, no proper local DNS setup, and for now only want the thing on my local network), and am able to create a user account (and can verify that it gets entered into the users table in couchDB).

I can then log in, but get The server is incorrectly configured with no unique ID, or is not accessible from the client. Please ensure the server process is running [OK] I do see "Lists", "Actions" and sub-items from "create new list" down to "login" in the nav bar on the left in my browser though.

Where's that unique ID to be set (in docker-compose.yml?)?

Or has this something to do with names, URLs, IPs really? I've changed all host names in docker-compose.yml from e.g. groceries.mytld.com to 10.x.y.z (IP only)

PS: It's a bit painful (for me) to get this up and running (for my setup, with my limited knowledge of docker and stuff), compared to e.g. kitchen-owl (also evaluating that), where I was up and running in about 5 minutes really - on the same underlying dockerhost and network setup, i.e. all with fixed IPs and ports (different of course to the port numbers "clementine" uses, so no collisions there between the different containers). It also has a database backend, and a web frontend... and "docks" out of the box... couldn't the setup of "clementine" be equally simplified maybe?

davideshay commented 9 months ago

I do need to clean up the docs for sure. First, try extracting docker-simple.tar.gz from the docker instruction page and just doing a docker compose up in that directory to see if it works.

The unique id it's referring to is created automatically by the backend on the first run, along with all the default items (bananas, apples, etc). Are those in the couchdb if you browse through the couchdb GUI? If not the backend didn't start correctly.

davideshay commented 9 months ago

Also if you want a demo, you can go to ,

https://www.specificallyclementines.com/

Radoom commented 9 months ago

Thanks for taking this up!

  1. To test, I started fresh, un-tar'ed, no passwords or keys or anything changed this time anywhere by hand.
  2. Directly did docker compose up, then went to the clementines web interface on myServerIP:8100 and created myself a user, and the error comes up again immediately on login.
  3. Went into couchDB. It's all there I'd say, table "groceries" has 327-ish entries from bread to alcohol and country codes.
  4. Looking at the docker logs for the container groceries-server there's one line pretty much at the start saying [07:20:31] INFO: UUID created in DB: b2599b35-fa64-4e01-bd4c-fc1905aa888c Would that be the uniqueID it complains about?

Did some more poking around; registered the dockerhost hostname for the local domain in my pihole, so all clients can now also resolve to dockerhost.mylocal.domain or simply dockerhost. But no matter what urls I set in docker-compose.yml, I can't get it to accept the api URL then, neither with https (as is in the template file), nor http.
Shouldn't these do?

DEFAULT_API_URL: https://dockerhost.mylocal.domain/api
COUCHDB_URL: https://dockerhost.mylocal.domain
GROCERY_URL: https://dockerhost.mylocal.domain
GROCERY_API_URL: https://dockerhost.mylocal.domain/api

But DNS aside: it should work with the DockerhostIP in the first place, no?

Edit: OT: know about the demo, had a look, decided worthwhile to give it a shot myself. Also, with the demo, I couldn't get a Android Client to work, both the latest from github and the one from playstore complained about version mismatch with server and after several seconds "idling" without being responsive just "die". Would it be possible to offer the user who connects with a wrong client apk to download the version that matches the server directly from such a notification message maybe?

davideshay commented 9 months ago

Assuming those are the environment variables for the backend app, if you are not using caddy or anything else, both the default couchdb container and the clementines backend just use basic http and are relying on caddy or another ingress to https-enable it, so out-of-the-box you would need the default http paths.

The API server/backend must be accessible to your frontends (a web browser or android app) using the API you normally manually enter there (you can provide a default API url for the web browser version, but if you are using a pre-build android APK you will need to manually enter it at least once).

Once the frontend contacts the API server via the entered URL, the server responds back with the URL for the couchDB server, which the frontend must also be able to access directly via that ip address or domain name (so ensure you have no firewalls in between and that whatever the contents of COUCHDB_URL specified for the API server is resolvable by the client. If you have no real DNS active, and couchDB is running on 10.20.1.2, then you could set the COUCHDB_URL to http://10.20.1.2:5984. What I have typically done is setup couchdb.mytld.com with an ingress or caddy so that it points directly to the right IP address and port.

There is also a COUCHDB_INTERNAL_URL which is a URL for the backend API server to access the database. You can point this to a name that is resolvable from only the backend but not the frontend if required. For instance, I route this directly to port 5984 without going through an https proxy since it's not necessary in my case.

Also a bit confused on the above, because the frontend web server (basically nginx) only takes two environment variables -- DEFAULT_API_URL and LOG_LEVEL. It does not use or process any other environment variables.

The backend API server does NOT take DEFAULT_API_URL. It does use GROCERY_API_URL, but only for scenarios like sending emails to reset passwords, not core functionality. Same with GROCERY_URL, so neither of those should be causing an issue immediately.

I'm fairly confident that you are serving up a COUCHDB_URL to your clients that is unresolvable. You can check this by going to one of the clients and browsing to that exact url, appending "/_utils" for example, and seeing what happens. Very likely not resolving in DNS. Check that and let me know.

davideshay commented 9 months ago

Also, the demo site should be upgraded to match the play store version... I had forgotten on that one. Also, I added instructions on the main website for the API URL as well as a link to the play store.

Radoom commented 9 months ago

Thanks for the explanations. And: Thanks for your valuable time!

tl;dr: Damn me, sorry to have wasted your time - but not entirely though, as the android APK still misbehaves in one combination. Details at the end below.

Longer version:

The posted variables were the respective lines from the docker-compose.yml as I would set them, given that clients can resolve "dockerhost" or "dockerhost.mydomain.local" to the correct IP 10.0.10.106. Basically, I only changed hostname and local domain from the examples given in there, not knowing whether your docker setup includes https capabilities or not. As the examples were all with httpS, I assumed that'd be built in in your container setup. I understand now that there's no httpS built in.

No caddy or ingress running (both of which I didn't know up to now), just docker running on "dockerhost" and your container tar downloaded and unpacked. No Firewall between the PC (client) I'm typing these lines on and which I use to ssh into dockerhost (nor the android phone if I'd ever get to that point), and the dockerhost server itself for these tests. (Note: if behind a firewall, all that is needed are ports 3333, 8100, 5984 open/forwarded; tested, works)

Did many test in various combinations before I understood what was going on. Kinda solved, culprit was uMatrix extension in firefox which blocked some XHR stuff and I didn't notice - until I tried a different browser as last resort.

Oddly, the problem occurred (occurs) depending on the combination of settings in docker-compose.yaml and the way the frontend is accessed in the browser and the way the API URL is entered on the logon screen.

  1. Having hostnames in the variables in d-c.yaml file and a. calling everything by hostname works. b. calling everything by IP allows to login but gives the "no unique ID" error c. calling frontend by IP and API by hostname or vice versa prevents login
  2. Having IPs in the variables in d-c.yaml file and d. calling everything by IP works e. calling everything by hostname allows login but gives "no unique ID" error f. like 1.c. above

Accessing couchDB _utils for logon to database frontend through IP or hostname was working all the time, so no scripts/XHR stuff there where uMatrix would have interfered. That didn't really help as a test, this part of the setup seems rather unimpressed of what's going on around it.

Name resolution wasn't the problem as we now know.

Working IP variables in d-c.yaml are (for my IP network structure):

And here is still a problem I can't solve. When I set the hostname in those variables, web client works, but APK does not if I enter the API URL as IP there. The apk then throws the same "no unique ID" error as encountered in firefox with wrong uMatrix settings. Huh? Is your apk using Androids webview, and as mine might be based on "bromite" for privacy reasons, that's maybe interfering with scripts as uMatrix does in my desktop firefox which are run by your apk? Wild guessing, won't dig into that now.

Anyhow... I'll set d-c.yaml back to IPs for now and dig into usability of your platform itself in the next days.

Another one, cosmetics though: short user names please :) as the minimum 6 letters check isn't really necessary I think. We've some family members with 3 and 4 letter first names, and do trust one another enough to not use fake names ;) where anyone would anyhow conclude who put certain preferred items on the list - not clementines though ;-)

Again and again: Thanks for your valuable time! I wish you happy holidays!

Will be back after evaluating a bit ;-)

protonaut commented 8 months ago

I got the same error. Don't know how to solve it. I used both of the examples: docker-full.tar.gz and docker-full.tar.gz

Any hints?

protonaut commented 8 months ago

I could "solve" the problem with inventing three domains to the web:

I'm not so happy to open access to the database to the web, but without I couldn't get rid of the error about the missing unique ID.

davideshay commented 8 months ago

@protonaut -- you do have to open couchDB to the android app or web-based clients -- this is because the app and any browser instance communicates directly with couchDB to sync data, not through the API server. This is required to enable offline operation and the effective sync capabilities in couchdb.

Did you have other issues beyond that?

davideshay commented 8 months ago

Perhaps it helps to simplify this a bit.

We can remove a few variables/environment variables from the equation because they really don't impact what's going on here: On the frontend, DEFAULT_API_URL just provides a "default" for the UI on first login, and doesn't otherwise impact functionality. On the backend, GROCERY_URL and GROCERY_API_URL is only used to pass relevant text/links to the email service around resetting passwords/etc, which also isn't relevant here.

So really the only two relevant environment variables here are both for the backend and are:

COUCHDB_URL - which is a full URL that the backend passes to the frontend web client/android app, that the app will then use to access the database. This URL must be resolvable and routable to the couchDB database from whatever device is running the frontend web client/android app.

COUCHDB_INTERNAL_URL - This defaults to the same as the COUCHDB_URL, but can be overridden if you want or need to use a different URL for the API server/backend to access the couchDB server. For instance, in my environment, I don't need the backend to route through an https proxy such as caddy or kubernetes ingress, so I use a direct link to the docker/kubernetes service. As long as what you use for COUCHDB_URL is also routable/resolvable from the backend service, this isn't strictly necessary either, can just help improve network routing/performance overhead.

From all of the testing I have done, for both the web browser and the android app, I can specify the app server name in the app by IP address/port or fqdn/port and both work, and both work in both scenarios of the environment variables being set by IP address or fqdn/port.

Yes, to answer your question, the Android app does use webview, and I have no idea how bromite would work with that or not. If it somehow bromite replaces your standard system webview, than that could break - no idea how that works with ionic apps or couchdb references or any of the xhr stuff -- that hasn't been tested. If you think it's fixable via the app side, let me know and I can explore, but I don't use bromite.

  1. Having hostnames in the variables in d-c.yaml file and a. calling everything by hostname works. b. calling everything by IP allows to login but gives the "no unique ID" error c. calling frontend by IP and API by hostname or vice versa prevents login
  2. Having IPs in the variables in d-c.yaml file and d. calling everything by IP works e. calling everything by hostname allows login but gives "no unique ID" error f. like 1.c. above

Accessing couchDB _utils for logon to database frontend through IP or hostname was working all the time, so no scripts/XHR stuff there where uMatrix would have interfered. That didn't really help as a test, this part of the setup seems rather unimpressed of what's going on around it.

Name resolution wasn't the problem as we now know.

Working IP variables in d-c.yaml are (for my IP network structure):

  • For frontend-groceries-client:environment: section: DEFAULT_API_URL: http://10.0.10.106:3333

  • For backend-groceries-server:environment: section:

    • COUCHDB_URL: http://10.0.10.106:5984
    • GROCERY_URL: http://10.0.10.106
    • GROCERY_API_URL: http://10.0.10.106/api Alternatively, replace 10.0.10.106 with dockerhost in all above.

And here is still a problem I can't solve. When I set the hostname in those variables, web client works, but APK does not if I enter the API URL as IP there. The apk then throws the same "no unique ID" error as encountered in firefox with wrong uMatrix settings. Huh? Is your apk using Androids webview, and as mine might be based on "bromite" for privacy reasons, that's maybe interfering with scripts as uMatrix does in my desktop firefox which are run by your apk? Wild guessing, won't dig into that now.

Anyhow... I'll set d-c.yaml back to IPs for now and dig into usability of your platform itself in the next days.

Another one, cosmetics though: short user names please :) as the minimum 6 letters check isn't really necessary I think. We've some family members with 3 and 4 letter first names, and do trust one another enough to not use fake names ;) where anyone would anyhow conclude who put certain preferred items on the list - not clementines though ;-)

Again and again: Thanks for your valuable time! I wish you happy holidays!

Will be back after evaluating a bit ;-)

davideshay commented 8 months ago

I did update the Docker documentation and sample files to try to make some of this a bit clearer -- please review and see if it is better and if you have any other recommendations.

davideshay commented 8 months ago

Closing due to lack of any further questions/issues. Re-open if needed.