Open Fen-nix opened 1 year ago
This is most likely related to #187. Not sure what I can do about it, since it seems setup specific. (Most likely to some weird certificate resolving of flutter?)
Unless I'm missing it somewhere, the documentation doesn't really spell out how to connect the app to the selfhosted environment but the hint in the url entry when switching servers leads me to believe it needs to connect directly to the backend itself so I'd have expected at least one of the :5000 options above to work.
It doesn't, and the 5000 port mapping isn't required. It used to be like that, that's why the hint is outdated, thanks for the info! Will update the hint and add it to the documentation.
In my case I'm using my own CA on my LAN, the full chain for which is already imported in Android. I'm able to use a number of other apps from both F-Droid and the Appstore this way.
It looks like possibly this? https://github.com/flutter/flutter/issues/118286
I think this is the relevant dart issue https://github.com/dart-lang/sdk/issues/50435, will mark this as upstream.
So what about the issue? It's neither an option to use a development version (cronet) nor trust a specific certificate. Will there be a fix?
Yeah I'm not really sure what to do about it. Some other projects I've seen linked in the same issue just publish an additional APK that accepts all certificates (valid or not). I could do the same but feel like it's not a good solution. The only other thing I can do is wait until the flutter issue is resolved. I'm open to suggestions though.
I might have the same issue: I can load the webUI and login; but with the app I get the "hummmm" message with no other detail. I'm using a Let'sEncrypt certificate that's working fine with all my other apps on port 443.
It's working fine with HTTP via the same reverse proxy.
In my case I'm using my own CA on my LAN, the full chain for which is already imported in Android. I'm able to use a number of other apps from both F-Droid and the Appstore this way.
After finally getting the Docker instance #422 to run, I was hit by the same issue. :cry: @TomBursch: is there a preferred way to get logs from the app trying to connect? The Docker container logs don't show anything useful.
As for suggestions: I agree that silently accepting all certificates (even those which are failing checks) is more of a security nightmare than a solution. How about an "I know what I'm doing" option to manually disable certificate checks so the app can at least connect for now until a real solution is available upstream?
I'd like to suggest to add <certificates src="user" />
to the network_security_config.xml like mentioned here.
Provided a PR and hope I did that right (because it's the first ever :D): https://github.com/TomBursch/kitchenowl/pull/433
Apparently the PR hasn't fixed the issue, just like @TomBursch predicted :-(
Since you mentioned dart and http client, maybe this can be of any help: https://stackoverflow.com/questions/69511057/flutter-on-android-7-certificate-verify-failed-with-letsencrypt-ssl-cert-after-s
Since I don't know flutter enough, I cannot tell if this has to be compilated beforehand or if putting the ca cert into the docker container would be sufficient.
Is this urgent?
None
What parts are affected
Both
What are the Server/Client versions of KitchenOwl
Latest Client and Server (Docker)
What's the problem 🤔
I've configured a reverse proxy for Apache and through a browser KitchenOwl is functioning just fine; However the Android app simply displays the message "Hmmmm... couldn't reach server".
The logs from the android device don't show any errors.
May relate to #211 but in my case the web works fine just the mobile app doesn't.
I have tested every permutation of hostname, IP, port, in the Android App's Switch Server screen. Examples:
Unless I'm missing it somewhere, the documentation doesn't really spell out how to connect the app to the selfhosted environment but the hint in the url entry when switching servers leads me to believe it needs to connect directly to the backend itself so I'd have expected at least one of the :5000 options above to work.
This is reverse proxied via Apache (though I've also tried it without this and the problem persists there too). TCP/8080 and TCP/5000 are both permitted via firewall.
Apache configuration:
Share your logs
No response
Share your configuration