BUG: Altering the URL of a site from IP addy to a TLD causes a duplicate entry in the dashboard. One entry will have the IP address of the server, the other will have the new URL. The old IP based entry will fail to backup properly with snapshot, etc., in addition to simply cluttering up the dashboard.
Ideally, the result of such a change (or any change) would be that the original entry updates itself. I believe it’d be possible to enhance security of the service and provide this benefit all at the same time by having the dashboard generate a public and private keyset and unique identifier for the server on successful first-time authentication.
The ideal behavior then would be:
User uses the dashboard to log in (same as now), hitting the sign-in button creates a key-pair and a unique identifier for that instance. The dashboard would perform a check against IP (or whatever combination of checks is necessary to account for load-balancers, etc.,) and make a determination about whether to force the user to re-authenticate on the dashboard.
If the user attempts to authenticate on a server that fails on 2 out of 3 checks (maybe IP, URL, UID) then it’s likely it’s not the same installation and the user should authenticate again (generating a new entry in the dashboard). If they pass two out of three checks then it’s likely the same installation has moved to a new URL, a backup of the server has been restored on a new server, etc., in which case the current line-item for that server should be updated or this could generate an AJAX dialogue asking the user if this is a new site and acting on their response.
So the alterations to the user experience are the possibility of additional security checks and dialogues, but an increased sense of security and better maintenance.