boswelja
App crashes when trying to add a new server
The app crashes after trying to add a new server using the API login. When an incorrect address is given, I get an error that the address is incorrect. However woth the correct address, the app keeps crashing.
Thanks for reporting! Currently if the address is not truenas.local then you must use https, which then needs a valid certificate.
I do want to avoid that in the future, I just haven't found a reasonable way beyond "allow all clear text traffic", which is probably not a good idea 😅
For anyone looking for a workaround instead of creating certs (provided you're comfortable with creating a hosts file):
- Download a host-file VPN such as Virtual Hosts or Personal DNS Filter
- Create a hosts file which lists the local IP address of your TrueNAS server followed by "truenas.local". It should look something like this:
192.168.0.1 truenas.local - Save this to your device somewhere accessible
- Launch your host-file VPN and select the hosts file. Follow the steps to turn on the VPN and allow it to create a new VPN on your device
- Get your API key from TrueNAS and ensure it's copied to your clipboard
- Launch NASdroid
- Enter
truenas.localas the host and paste your API key into the field below - Connect - it should work provided the IP address specified in the hosts file is correct
Note: this will only work when the VPN is turned on, and you may experience issues combining it with other VPNs. It is only intended as a workaround for those unable to get certs working for their server.
If you're rooted, you may also edit etc/hosts to get the same effect without relying on a VPN app.
Interesting that your truenas instance isn't just available on truenas.local by default 🤔
In any case, if you're really not worried about it you can just install the certificate used on your server to your phone, Settings -> search "certificate".
Thanks for reporting! Currently if the address is not
truenas.localthen you must usehttps, which then needs a valid certificate.
Why not just prompt the user with a warning that the traffic could be unsafe instead of crashing? I mean I presume most people would be using an Android app for remote connections to either Tailscale or WireGuard, which should be already encrypted, either way it's a risk that comes with HTTP and they have to understand it.
Because the app is in very early days, and I am dealing with a complete rewrite of the API interaction instead of https right now 😅
I think a warning is probably a good idea, but then that raises extra questions, including but not limited to
- How often should we be showing said warning?
- Every time someone logs in?
- Every time they add a server
- Once when they try to add a non-https server?
- What should happen if users back out of the warning?
- Should we block all non-https interactions until the warning is acknowledged?
We do accept contributions to the source (wink wink), but it's probably a good idea to hold off until a bit more headway is made on #484 unfortunately
Interesting that your truenas instance isn't just available on truenas.local by default 🤔
In any case, if you're really not worried about it you can just install the certificate used on your server to your phone, Settings -> search "certificate".
I think it's just a quirk with the router that our ISP gave us, unfortunately I live with the in-laws so tweaking the router isn't an option till I move out.
As for generating the certs, at some point I do want to put everything of mine behind a reverse proxy which should handle certs and HTTPS for me but till then I'm fine with only using HTTP for the connection as I use Tailscale outside my network like @hideki2k02 said.
It's another good workaround though in the meantime for those who don't mind installing the cert.
I think a warning is probably a good idea, but then that raises extra questions, including but not limited to
How often should we be showing said warning?
- Every time someone logs in?
- Every time they add a server
- Once when they try to add a non-https server?
What should happen if users back out of the warning?
Should we block all non-https interactions until the warning is acknowledged?
So I've been giving this some thought for the past day or so, and I think that this is how it should go:
A user adds a connection that is not secure. When they tap "Connect" they are presented with a dialogue ("This connection is insecure and susceptible to interception, blah blah") and three options:
- Ok (continue connection)
- Don't show again (continue connection, don't show message again)
- Disconnect
Given you can still get a 403 out of TrueNAS without needing to send anything other than a dummy request over the wire, it will be quite trivial to determine whether the server accepts HTTPS or not.
This dialogue would also show for HTTPS connections that have expired certs, etc.
For each connection, there should be an associated flag that is configurable with it. It should be named in the UI something like "Warn if connection is insecure", or something along those lines. Clicking "Don't show again" basically turns that flag off. This allows the user to re-enable the warning message later.
I think along with this a little padlock icon that appears somewhere in the UI (probably in the top bar) that the user can use to determine if the connection is HTTP/S. Unlocked for insecure, locked for secure.
I would try to add this myself but unfortunately my Android/Kotlin experience is next to none. Maybe I might give it a shot anyway and see how far I get. But that's how I think the security message should work in my opinion.
determine whether the server accepts HTTPS or not.
The good news is, as far as I can tell TrueNAS will always accept an HTTPS connection. The issue we're seeing is entirely client-side, where it does not trust the certificate and therefore refuses to connect. Typically you'd want users to generate their own certificate, since the default TrueNAS one is just publicly available (thereby defeating the purpose of the cert)
HTTPS
Probably worth mentioning the protocol we're using will be entirely ws/wss, and I haven't checked whether the API supports wss yet. 😓
This dialogue would also show for HTTPS connections that have expired certs, etc.
Seems reasonable - we can do this now by capturing the exception thrown (though we don't have the means of letting users progress)
For each connection, there should be an associated flag that is configurable with it. It should be named in the UI something like "Warn if connection is insecure", or something along those lines. Clicking "Don't show again" basically turns that flag off. This allows the user to re-enable the warning message later.
So the "Don't show again" would apply only to that saved server connection? (We don't have anything set up for preferences like this right now - that'd be a potential good first issue)
I think along with this a little padlock icon that appears somewhere in the UI (probably in the top bar) that the user can use to determine if the connection is HTTP/S. Unlocked for insecure, locked for secure.
We've got a nifty header in the navigation drawer with some basic connection info right now, I think it'd make a lot of sense to have this there!
Maybe I might give it a shot anyway and see how far I get.
This is gonna be a pretty big undertaking considering where the app is right now, so it'd make sense to split it up a bit first. I'm already working on migrating to websockets, but a couple of other smaller items might be
- Managing a list of allowed/denied cleartext connections
- Creating the error messages and such that should be displayed when a connection is not allowed etc
I'll create some sub-issues for these and link them here 😄
To clarify some of the points:
- Yes, the "Don't show again" would only apply to that particular connection as I can see in a few circumstances where a user would want to allow cleartext for one connection and not another (for example if they need to use a different IP address for accessing in/outside their network and want to ensure it's a secure connection when outside the network, or they're an admin at their workplace but have their own TrueNAS instance at home)
- I think this can mostly be applied to WS too, as the WebSocket protocol initiates a connection with an HTTP upgrade followed by a 101 Switching Protocols response from the server. If we could somehow grab the security status from that it could be an easy way to test it without sending sensitive data over the wire. This will depend on how abstracted the initial handshake is (if we even can access it)
(shamelessley stolen from Wikipedia)
A "connection preferences" feature would be excellent though, and I think we'll be able to devise some settings that users will want to configure. The "Allow insecure connections" settings will be a good first setting to add.