Add proper authentication
Currently Silver Bullet either runs unauthenticated (anybody access to your machine has full access) or in a super basic "password" mode when adding the --password mypassword flag.
This isn't great, we probably want to have proper authentication. As suggested by @Willyfrog here, it could make sense to use a library like PassportJS to add a proper authentication mechanism.
One thing to consider is: do we have a multi-user use case and do we want to support that (if so, quickly we'd also get into the whole authorization, permission and real-time collab topic)? And if not, how complicated an authentication system do we want for effectively just one account? Perhaps a simple username/password combo with temporary session tokens is sufficient?
Btw, this is one of those tickets where I see it as important (security in general), but I have very personal little interest in implementing this myself. So if there's any takers, feel very free :)
I'm partially interested, as for me to use SB daily, I need to serve that outside my house and I haven't set up a vpn or similar at my house (never found the personal use case for it).
Multi user is a separate issue. It might be interesting in the sense that we could have MM to serve it as a service for staff if we are able to provide some basic features. But that would also open it to be run using S3 (which might be possible right now, haven't checked), etc. Definitely multiuser is a separate issue, although related.
I've had it set up in two ways over time.
Earlier I simply ran a tiny little $5 Linode, installed SB, put Caddy in front of it to add SSL and used the --password mechanism. Probably wouldn't win awards in terms of security.
Currently I have it running on a local server in my house and I use Tailscale to access it from outside. Tailscale is pretty amazingly easy to set up.
Regarding mutli-user: I agree, I don't think we need to go there yet. But having somewhat better single-user authentication would be good.
A OpenID connect login would be awesome to integrate the wiki with other services
I currently don't have time and energy to implement the whole authentication.
So, if someone would implement the groundwork for authentication using password.js, I could easily add OpenID connect support using https://www.passportjs.org/packages/passport-openidconnect/
I've also got an idea regarding permission management:
In the simple but expandable spirit of the project, each user could belong to multiple groups.
Each group has a JavaScript function taking the path name (and maybe some other data) as input and returning the permissions of the group.
Each user gets the union of all group permissions. (Which means if they are in a group that gives them access to a page and one that does not, they will have access)
An ACL manager plug could later provide a UI that generates these functions automatically from regex matches etc.
Until now SB has been single user, recently with the exception of Collaboration on individual pages should it remain that way or not? Adding authentication makes sense even for the single user use case, adding a permission system may not?
If SB should support teams, a permission system would make sense, but that's just the tip of the ice berg. What else should change? Likely all pages should be collaboratively editable, for instance. Version control support likely would need to be put in place. Any thoughts on that?
Well, the optimal knowledge base setup I've been chasing and trying to build for quite some time is each person having their own wiki and being able to synchronize them with each other using an intermediate server.
The solution I've settled on in the past is a git submodule based solution with automatic commits so that people can “mount” a shared wiki into their own namespace.
While this is a powerful idea, the problem I encountered while trying to collaborate with other people is that most people don't want to have to set up all this just to access the latest rules for our role-play games.
The more practical solution I instead settled for is way simpler:
Just put my whole knowledge base in a wiki with a proper Access Control System for it and let people interact with it using only their browser and login. (Here some collaborative editing like HedgeDoc with yjs would be awesome)
If I want to let people synchronize their wiki with mine, that can be implemented later.
Also a note regarding the collab plug for sharing pages, while it seems to work great and is a nice idea, in mosts contexts I want to give people access to many pages and collaborate with them on it.
Like for example when I invite a new team member into my team and want to give them access to all the brainstorming notes.
Or when I'm writing a roleplay game or novel and want to have a cowriter for the world building and want to give them access to these notes but not all of them, so they can be surprised later and enjoy the book/game.
Here's a thought: if I could bind Silverbullet to my Tailscale address, I could access it from all of my computers and also share with family or friends, no further authentication needed. It seems that there is currently no way to specify the address(es), just a port?
True, binding an IP would be easy to add. I currently use it with Tailscale too, just binding to 0.0.0.0 trusting people in my network. I'll add specifying the bind IP, should be trivial.
Oops, I had already started looking at how the application is set up and just made a PR. I hope there was not too much overlapping work.
I haven't done anything yet and won't be able to for a few days. If you can add this, I'll happily take a PR.
Ah just saw you already did. Great!
I think it's worth noting that you can use authentication now with auth systems like Authelia sitting in front of this. It might be preferable to adding a custom authentication solution.
I'd be happy to "outsource" this part, but somehow the client (webapp) needs to understand when and how this authentication needs to happen.
Authentication happens before traffic makes it to the app so the app would never need to re-direct a user to a login page. Instead of just deploying the app, users need to deploy a proxy (like Traefik or Nginx) to ensure requests are authenticated before sending them to SB. If you wanted to display user metadata like names and email in the app you could then pull that from trusted headers.
I'm using Authelia in front of SB now for my personal notes. If it'd be helpful I'm happy to whip up a docker-compose file to demonstrate the concept.
Yeah, some sort of documentation of how to do this would be appreciated. I'd happily include it as documentation on the website.
Started to put something together but Authelia docs probably articulate this best. Just swap out the example "whoami" container with a SilverBullet container everything else remains the same.