Feature: Basic Auth to UI

[digitalbase]

Keep running into SSL issues, copy pasting, camera so i want to get my signet instance running on a public instance but for that i need authentication.

This is a very basic implementation of authentication that is totally optional. If you agree/like the idea i can update docs and double/triple check

[digitalbase]

This is WIP. Doesn't work yet as i also need to secure the daemon and the communication between UI and daemon. Might be not as easy as i was hoping, still digging code

[digitalbase]

Ok. Think i'm done. I need to test but running into issues running the daemon locally #37

[Letdown2491]

I'll do dome testing once the security audit is done but i can see where you're going so might work!

[digitalbase]

Still working on this. The auth/token stuff works but when deploying it i ran into some issues where i couldn't fully configure the set-up and then went down rabbit hole with env variables and configuration possibilities.

I think, for maximum configuration in different setups (tailscale, local, internal, umbrel, ssl/non-ssl), signet needs a way to:

• change the bind host:ports for both services.
• change the external host:ports for both services (which i believe what DAEMON_URL and EXTERNAL_URL are for)

In an easy setup/locally the bind/external are the same.

So I'm making those changes but now i need to make sure everything plays well with those different config options.

[Letdown2491]

So I had a chance to review and wanted to throw some thoughts your way to help guide this a bit:

• The UI server currently reads the daemon's config file to get the API token. Would an environment variable (SIGNET_API_TOKEN) work better? The shared filesystem requirement could be tricky for some deployments.
• Should the API token be scoped more narrowly? Right now it bypasses JWT, CSRF, and rate limiting entirely. One option would be to use it only to authenticate the proxy connection, but still require the browser to have a valid JWT session.
• Was changing requireAuth default to true intentional? Existing users would be locked out after upgrading.
• Was the Docker volume change (bind mount to named volume) intentional? Existing data wouldn't be accessible after upgrade.
• Any plans to add rate limiting to Basic Auth to prevent brute-force attempts?

Happy to help work through these once we align on the direction!

[digitalbase]

Thanks!

1. Could work. The tradeoff is that the user needs to set the token and with the signet.conf we can generate it. Both work for me i was thinking about UX e5dcfca
2. Yes, good idea. I have to admit that i don't fully understand the tokens/auth UI<>Daemon information flow so i stayed on the surface aa9c6ec
3. I think with this we should consider dropping requireAuth all together. What do you think?
4. Volume change, no. That's a change only for my set-up and will be dropped in the final PR
5. Haven't considered it yet but good idea 27e9fe5

I will continue with getting everything working and then maybe looking into