Mobile app enhancement suggestions
Been doing some testing/usage with VPN remote access scenarios, have the following suggestions to improve usability:
App configuration setting to control"auto login to Security Spy server when app is launched. Currently, once a server has been configured, launching the app immediately tries to connect.
If VPN is not activated, or want to switch to using a different SecuritySpy server, have to wait for a connection timeout before can edit the RECENT server settings.
Saving multiple server settings - Only one server configuration is listed under RECENT. Would like to be able to list multiple servers and then select one to connect. When testing both port forwarding and different VPN scenarios, or switching to a client's server remotely to help them with camera settings/configuration, would be convenient to have multiple server configurations listed and just pick the desired one for connection.
Minor addition to above - currently, the server connection automatically displays the server name that has been configured in Securityspy itself for the website "name". I would like to be able to have my own "friendly name" saved as part of the target server configuration in the mobile app.
So fields would be Address, Port, Username, Password and a new field "Description".
Connections could be shown as "Web Server Name (Description)" when list of possible servers is shown and when displaying the camera feed after being connected.
Comments
-
If you are using the VPN only intermittently to connect to a particular SecuritySpy server, then you must also set up the normal port forwarding / DDNS remote access method as described in our Installation Manual under Remote Access.
As long as you have set up port forwarding-based remote access, and you subsequently add a server manually over a VPN using its VPN IP address, then the iOS app will remember the VPN address, and it will additionally automatically detect and remember both the DDNS/WAN address and the local (Bonjour/LAN) address, so that subsequently, whether you are on the VPN or not, and whether you are remote or local, the connection will work in all cases.
The key is to make sure that you have configured the port forwarding method and have confirmed that this works, before adding the server to the app manually over the VPN.
Then, you should never have to wait for a timeout when you connect - it should work in all cases.
As for the server name, since this can be set on the server, we don't think that this needs an additional, different, setting in the iOS app.
-
Not sure why you have this technical requirement, but you are missing a crucial point.
The entire reason to use a VPN is to avoid having any port forwarding configuration in the first place.
Port forwarding is really an obsolete technology because of the tremendous security risks it poses.
Security best practices is to use a VPN or a NAT traversal WebRTC technology instead as used by Ring, Nest, and other consumer products.
I didn’t realize that SecuritySpy still requires port forwarding to be configured to have reasonable usability from the mobile app.
I think you need to revisit this design decision.
In my particular use case, I use the mobile app both when I am at home (local network, no VPN, no port forwarding), and when I am a remote (on celluar or wifi at another location - no port forwarding, traditional VPN or Tailscale VPN enabled)
-
I think we are misunderstanding each other. When using a VPN, port forwarding is NOT required. My response was based on your description that you are trying to connect to a SecuritySpy server remotely when not on the VPN - this is what would require port forwarding.
When using a VPN to connect to your SecuritySpy server, I would recommend you leave your device always connected to the VPN - then the connection will be always available wherever you are. And if you have multiple SecuritySpy servers, simply make sure they are all connected to the same VPN, so that they are all accessible at all times without switching between different VPNs.
-
Ok, my original request was to be able to have a list of several SecuritySpy servers manually configured and saved in the mobile app.
Motivated by the desire to have the same server listed with both the local LAN address and the alternate Tailscale address.
Your reply was that I needed to have it configured at the server using port forwarding, which is something I do not need or want - whether I use it locally with the actual local LAN address, or over the VPN using the tailscale address.
If I was able to configure a list of servers, then I wouldn't have this problem, and when occasionally helping a client with their server, the server would stay in the list even if it wasn't auto-detected or accessible every time I use the mobile app if I could keep it listed in the app.
Does that clarify?
-
The app can only save one instance of each server - we are not planning to change this specific aspect of how the app works (I'm happy to explain the reasons for this if you would like). But, this one instance of the server can have multiple addresses associated with it. If you are using the VPN to connect remotely, you would add the server manually using the VPN address, and the LAN address is automatically saved along with it, so that the connection then works whether you are remote (on the VPN) or local (on the LAN).
If I am understanding you correctly, the main problem you are experiencing comes when you disconnect from the VPN, but are still remote (i.e. not on the same LAN as the server), and then open the SecuritySpy app, and it will then automatically attempt to connect to the last server that you were viewing, which then times out, which takes time. Is this an accurate description of the problem?
The solution would then be an option in the app to control auto-login, with an option to turn it off. We haven't added this yet because it won't be useful for the vast majority of users, where automatically logging into the last-used server is almost always the right thing to do. But, we will consider this for a future update, because I suspect it might be useful for enough users to warrant adding a special setting.
-
An option to disable auto-login, which would not affect normal users, would be a good compromise.
-
Thanks, we will see if we can implement this in a future update.
