ring-mqtt
ring-mqtt copied to clipboard
tsightler
Allow to pass credentials as env.
JS is not my cup of tea, but this I think it should work. If you have any suggestions, feel free to apply them, or even close this PR :)
Hi! What is the use case for this? You still have to interact to enter the 2fa code so it seems of limited use.
Hi! What is the use case for this? You still have to interact to enter the 2fa code so it seems of limited use.
Sorry, didn't know that.
Was to make unattended installation. (So users don't need to visit shell to complete it)
I'm a core maintainer of TrueCharts catalog (A community "App" catalog for TrueNAS Scale).
I don't have any Ring gear, but app was added by another user.
Yeah, it's not possible to make this non-interactive. Ring requires 2fa for initial authentication, so even if you pass the base credential as an environment variable, it will then just wait for the 2fa code to be entered.
The code does include an optional web UI for generating the initial token which is used in cases like the Home Assistant addon since HA provides an easy way to wrap the web page into its own UI, so HA is able to provide the authentication and encryption to protect this.
However, I could potentially expose a variable that could be passed to force the web UI to start in any case, and this could be used to generate the initial token and then it would shut down. I'm not sure if that would help for your case or not, but it's fairly easy to implement since the code already works this way for the non-container installation method.
So, I found where the problem was. And I have a probably very easy solution And apparently wasn't that much connected with the credentials.
According to a user, the above login works fine (even with 2FA).
The "problem" is on the subsequent starts of the app. Because ( I assume, correct me here) it does not spin up the webui, (as it's already singed in) and healthcheck probes fail (they probe to / by default, but it's configurable).
If that's the case. For my case the solution would be as simple as adding an endpoint /health or /ping that it just responds with 200.
(We use healthchecks in Kubernetes to restart containers if they crash., just like docker)
The "problem" is on the subsequent starts of the app. Because ( I assume, correct me here) it does not spin up the webui, (as it's already singed in) and healthcheck probes fail (they probe to
/by default, but it's configurable).
This is correct, for standard operation the web based token generator only starts if there is no saved token or if establishing the connection with the saved token fails. This was mainly because I didn't want to deal with the security implications of a non-SSL, non-authenticated web service that handled user authentication for a user's cameras and alarm systems running all the time.
As noted above, when running with Home Assistant, the web UI does run all the time, but in that case it's not exposed directly and can only be accessed from within the, hopefully already secured, Home Assistant user interface.
Interestingly Home Assistant also has a similar health check/watchdog feature which does basically the same, it polls / on the web server every few minutes. I'm open to the idea starting an always on web service on a second port that answers to nothing but /ping.
Interestingly Home Assistant also has a similar health check/watchdog feature which does basically the same, it polls / on the web server every few minutes. I'm open to the idea starting an always on web service on a second port that answers to nothing but /ping.
Maybe use the same port. If saved token is in place. only respond on /ping. If not, respond on everything (including ping).
But additional port is also ok, whatever you think it fits better with your code base!
Closing as it's not the actual problem. Will eventually address in a future update.