Self hosted 2FA app
Closed this issue · 9 comments
With the imminent Authy for Desktop End of Life EOL in [EDIT: see next comment] August 2024 March 19, 2024 , self hosting option/s such as:
will likely be more in-need.
Note: the EOL for Auth Desktop as rather unhelpfully been brought forward to 19th March 2024!
From: https://authy.com/download/ we have:
The Authy Desktop app will reach End-of-Life on March 19, 2024.
@phillxnet I've done some research and set up a Rockon file for the 2FAuth Docker container. Unfortunately, it seems there's an issue with the latest version (or I am doing something wrong), it installs correctly, but when going to the UI the screen is blank and it looks like there are some js code not being pulled. I am not sure this is related to Rockstor, because I did find an issue that someone reported last week (albeit using a different package, YunoHost):
So, if you or @FroggyFlox or anybody else wants to/can check it out, I have now posted the json as a draft PR. Or, we look for a different one, though I feel the 2FAuth is a nice version that does one thing well, and that's authentication ...
@Hooverdan96 Thanks for pushing this on forward.
Re:
Unfortunately, it seems there's an issue with the latest version (or I am doing something wrong), it installs correctly, but when going to the UI the screen is blank and it looks like there are some js code not being pulled.
Maybe there is a genuine over site re js code changes upstream. I.e. an automated docker image update has not accounted/tested for some dependency change. It may be useful all-around if your findings thus far were reported upstream? Ideally with some browser dev mode indicating your js code issue suspicion.
Thanks again for this likely key Rock-on progress thought. I will try to have a look at your draft PR shortly. I really think this will be a popular Rock-on as/once we get it sorted :) .
From their docker hub page we have:
The Docker image 2fauth/2fauth is built on every commit pushed to the master branch.
@Hooverdan96 It may be, given the more recent extensions to auth in the image, that we need to set both of these:
- APP_URL
- ASSET_URL
To our IP address:port
Bubka/2FAuth#284
&
https://github.com/Bubka/2FAuth/releases/tag/v5.0.3
&
Bubka/2FAuth#284 (comment)
if you running 2FAuth on External Server or Cloud, Change ASSET_URL & APP_URL that pointing to your Server IP:PORT or URL FIX the problem
FYI what worked for me was adjusting (and in the case of ASSET_URL, adding) the variables to be as such (adjust "myservername" to your server name + port number to whatever you assigned it to be:
- APP_URL=http://myservername:8000 #Bubka/2FAuth#284
- ASSET_URL=http://myservername:8000 #Bubka/2FAuth#284
And that was it! I added the explicit IP address of the server.
While this is a bit awkward that one has to enter the UI port, and then enter the same URL and port twice, it works now. I assume, I can't do a "variable injection" in the Rockon so it could be automatically be assembled for those two parameters?
The one thing that can be a challenge:
When maintaining the APP_URL/ASSET_URL with Rockstor's IP address, it all works when launching the UI from the Rockon page.
When maintaining the two variables with the server name, launching the webpage from the Rockon page (i.e. the IP address), it won't work. Only when calling the page using also the server name in the browser, things start working again.
I think it's the same observed problem have run into before, if you log into Rockstor using the servername, Rockon links are also called using the servername. If you log in using the IP address, Rockon UIs are called using the IP address.
I assume, I can't do a "variable injection" in the Rockon so it could be automatically be assembled for those two parameters?
I'm pretty sure we can't do this yet. But feel free to define an issue to extend our Rock-on interpreter code in rockstor-core so we can start to raise our game on this front. I was thinking we already create a Web-UI 'button' link from Web-UI:Port entries. And here we end up, as you say, re-entering these multiple times. Maybe we establish a 'weburl' variable in rockstor-core constucted from hostname:port-entered-in-rock-on that we can then enter in Rock-on definitions. And we interpret accordingly: as stated we kind of do this already.
@Hooverdan96 Re the:
if you log into Rockstor using the servername, Rockon links are also called using the servername. If you log in using the IP address, Rockon UIs are called using the IP address.
Yes: that is curious. We likely need to formalise/document that behaviour somewhere: likely in the Rock-ons doc section I'm thinking. Feel free to create an issue for that in the doc repo, as we then have it noted as it were.
I'll take a look at your Rock-on PR, as I'm super eager to get this in ready for folks having the rug pulled from under them re the Authy desktop bringing forward their termination of function by 5 month !!!
From memory, we build the web UI link using hostname from either JS or python so that might explain such dynamism.