Dropserver Progress - April 2025
This is the progress report for Dropserver for April 2025. The previous report is here.
Tailscale Integration for the Admin Side of Dropserver
Recapping where I was: I got Tailscale integration working pretty well for appspaces (an appspace is a running app in Dropserver, see here.) Meaning that you can access the apps that you host on Dropserver via tailnet node in addition to via the regular Internet. Now I want to give access to the admin side of ds-host via Tailscale. This is where Dropserver users go to install apps, create appspaces, and generally manage their Dropserver stuff.
After completing the work of making my tsnet integration code more generic (it was heavily geared towards serving appspaces) it was time to work on connecting a node for user and admin side of ds-host.
Setting up users with tailnet credentials
As with appspaces I decided that access via a tailnet node should be one of multiple ways of accessing Dropserver. A user can have tailnet credentials, and can also have a username and password should they choose to log in via a more traditional network.
I had to make having an email and password optional. If a user connects via a tailnet, the authentication is taken care of, so forcing them to choose an email and pw is just an obstruction. This required some DB changes because of course the email and password columns were NOT NULL and I had a unique index on email. There was also a domino effect of changes in the UI.
Associating tailnet peers with ds-host users
After pondering on the possible situations that a ds-host admin may face:
- They have existing users on their
ds-hostinstance, and just connected to a tailnet. They have to associate peer users from that tailnet with existingds-hostusers. - They are connected to a tailnet and want to give access to someone new. This implies creating a new
ds-hostuser with credentials from that tailnet. - They made a mistake in any of the above and have to break associations and start over
I settled on these UI choices:
- When looking at tailnet settings, for each peer user of the tailnet, the admin can use a dropdown to select the ds-host user that should be associated, the last option in the dropdown is “create new user”.
- When looking at a user, the admin can select which tailnet peer user to associate.
In both cases, the UI respects the requirement that there is only a one-to-one relation between ds-host and tailnet users. One tailnet user can not be associated with two ds-host users, and vice versa.
Connecting tsnet to user and admin routes
As mentioned above a tailnet is but one way to access your Dropserver instance. ds-host has multiple servers: one for responding to requests from the Internet, and one that is on a tailnet and responds to requests from that world.
Both serve routes like the user home page, and the admin pages just the same, but the authentication and authorization steps are different. Also, the “Internet” routes include the login, logout, and user registration pages, which are not reachable while accessing ds-host from a tailnet (because they make no sense there).
So there are two routers, one called FromPublic and the other FromTSNet.
- The
FromPublicrouter can serve login/logout routes, and takes a request’s cookie to determine the authenticated user, adds the ID to the request’s context and passes control to the “user routes” router. - The
FromTSNetrouter looks up the user id based on the tailnet peer’s ID, puts that in the context and passes the control onwards.
This arrangement helps me keep things decoupled and clear.
Once I had it all wired up, it worked on the first shot*. I was able to access ds-host running on my iMac from my phone through a tunnel managed by Tailscale. It felt great. I feel like I’m almost there.
Getting close
With that functional, I turned to my todo list which is still quite long but many items are fairly quick. I started by knocking out validations, which was a bit of work because Tailscale’s naming limitations are not intuitive:
- Machine names: alpha numeric and dashes are allowed; must start and end with alpha or numeric.
- ACL tags: alpha numeric and dashes allowed, must start with alpha (not numeric!), can end in dash 🤷♂️
Commit ab6183b.
Bye For Now
I’ll be unable to work for part of May, so the next progress report will be shorter.
*: 11 months of work were necessary to get to that magical “it worked on the first shot”.
