Attempt at fixing docker build
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
SilverBullet supports simple authentication for one or many users.
|
||||
|
||||
**Note**: This feature is experimental and will likely change significantly over time.
|
||||
|
||||
## Single User
|
||||
By simply passing the `--user` flag with a username:password combination, you enable authentication for a single user. For instance:
|
||||
|
||||
```shell
|
||||
silverbullet --user pete:1234 .
|
||||
```
|
||||
|
||||
Will let `pete` authenticate with password `1234`.
|
||||
|
||||
## Multiple users
|
||||
Although multi-user support is still rudimentary, it is possible to have multiple users authenticate. These users can be configured using an JSON authentication file that SB can generate for you. It is usually named `.auth.json`.
|
||||
|
||||
You can enable authentication as follows:
|
||||
|
||||
```shell
|
||||
silverbullet --auth /path/to/.auth.json
|
||||
```
|
||||
|
||||
To create and manage an `.auth.json` file you can use the following commands:
|
||||
|
||||
* `silverbullet user:add --auth /path/to/.auth.json [username]` to add a user
|
||||
* `silverbullet user:delete --auth /path/to/.auth.json [username]` to delete a user
|
||||
* `silverbullet user:passwd --auth /path/to/.auth.json [username]` to update a password
|
||||
|
||||
If the `.auth.json` file does not yet exist, it will be created.
|
||||
|
||||
When SB is run with a `--auth` flag, this fill will automatically be reloaded upon change.
|
||||
|
||||
### Group management
|
||||
While this functionality is not yet used, users can also be added to groups, which can be arbitrarily named. Likely the `admin` group will have special meaning down the line.
|
||||
|
||||
When adding a user, you can add one more `-G` or `--group` flags:
|
||||
|
||||
```shell
|
||||
silverbullet user:add --auth /path/to/.auth.json -G admin pete
|
||||
```
|
||||
|
||||
And you can update these groups later with `silverbullet user:chgrp`:
|
||||
|
||||
```shell
|
||||
silverbullet user:chgrp --auth /path/to/.auth.json -G admin pete
|
||||
```
|
||||
@@ -3,8 +3,12 @@ release.
|
||||
|
||||
## Next
|
||||
|
||||
* **Real-time collaboration support** between clients: Open the same page in multiple windows (browser tabs, mobile devices) and within a few seconds you should get kicked into real-time collaboration mode, showing other participants cursors, selections and edits in real time (Google doc style). This only works when a connection with the server can be established.
|
||||
* This **breaks** existing [[🔌 Collab]] links, since we switched real-time collaboration libraries. We’re still looking at the best way to keep supporting this feature.
|
||||
* [[Authentication|Multi-user authentication]]: you can now allow multiple user accounts authenticate, which makes the real-time collaboration support actually useful. This feature is still experimental and will likely evolve over time.
|
||||
* Added `spaceIgnore` setting to not sync specific folders or file patterns to the client, see [[SETTINGS]] for documentation
|
||||
* Much improved image loading behavior on page (previously scroll bars would jump up and down like a mad person)
|
||||
* Various bug fixes and quality of life improvements* Much improved image loading behavior on page (previously scroll bars would jump up and down like a mad person)
|
||||
|
||||
|
||||
---
|
||||
@@ -24,7 +28,7 @@ A detailed description of what happened [can be found in this PR](https://github
|
||||
* From a UI perspective little changes, except for a few things related to sync:
|
||||
* While SB is in an out-of-sync state, the title bar will appear yellow. This will also happen when it cannot reach the server. SB is still fully functional in this state. Once the connection is restored, all changes while offline are synced back to the server.
|
||||
* Upon initial load, a full sync will take place, which — depending on the size of your space — may take some time. Or even blow up completely, if you have a big amount of data there.
|
||||
* To reset your browser state (flush out your entire space, caches and data stores) visit the `/.client/reset.html` page, e.g. at http://localhost:3000/.client/reset.html and push the button. Note that any unsynced changes will be wiped.
|
||||
* To reset your browser state (flush out your entire space, caches and data stores) visit the `/.client/logout.html` page, e.g. at http://localhost:3000/.client/logout.html and push the button. Note that any unsynced changes will be wiped.
|
||||
|
||||
Besides these architectural changes, a few other breaking changes were made to seize the moment:
|
||||
* **In plugs**:
|
||||
|
||||
+10
-2
@@ -32,7 +32,7 @@ silverbullet <pages-path>
|
||||
|
||||
By default, SilverBullet will bind to port `3000`; to use a different port, use the `-p` flag.
|
||||
|
||||
For security reasons, by default, SilverBullet only allows connections via `localhost` (or `127.0.0.1`). To also allow connections from the network, pass a `-L 0.0.0.0` flag (0.0.0.0 for all connections, or insert a specific address to limit the host), ideally combined with `--user username:password` to add BasicAuth password protection. Credentials can also be specified with the `SB_USER` environment variable, `SB_USER=username:password`. If both are specified, the `--user` flag takes precedence.
|
||||
For security reasons, by default, SilverBullet only allows connections via `localhost` (or `127.0.0.1`). To also allow connections from the network, pass a `-L 0.0.0.0` flag (0.0.0.0 for all connections, or insert a specific address to limit the host), ideally combined with `--user username:password` to add BasicAuth password protection.
|
||||
|
||||
Once downloaded and booted, SilverBullet will print out a URL to open SB in your browser. Please make note of [[@tls|the use of HTTPs]].
|
||||
|
||||
@@ -103,4 +103,12 @@ Caddy can automatically find these certificates once provisioned, so you can jus
|
||||
$ sudo caddy reverse-proxy --to :3000 --from yourserver.yourtsdomain.ts.net:443
|
||||
```
|
||||
|
||||
If you access SilverBullet via plain HTTP (outside of localhost) everything _should_ still mostly work, except offline mode.
|
||||
If you access SilverBullet via plain HTTP (outside of localhost) everything _should_ still mostly work, except offline mode.
|
||||
|
||||
## Environment variables
|
||||
You can configure SB with environment variables instead of flags as well. The following environment variables are supported:
|
||||
|
||||
* `SB_USER`: Sets single-user credentials (like `--user`), e.g. `SB_USER=pete:1234`
|
||||
* `SB_PORT`: Sets the port to listen to, e.g. `SB_PORT=1234`
|
||||
* `SB_FOLDER`: Sets the folder to expose, e.g. `SB_FOLDER=/space`
|
||||
* `SB_AUTH`: Loads an [[Authentication]] database from a (JSON encoded) string, e.g. `SB_AUTH=$(cat /path/to/.auth.json)`
|
||||
+6
-5
@@ -4,7 +4,7 @@ repo: https://github.com/silverbulletmd/silverbullet
|
||||
share-support: true
|
||||
---
|
||||
|
||||
The Collab plug implements real-time “Google Doc” style collaboration with other SilverBullet users using the [Yjs](https://yjs.dev) library. It supports:
|
||||
The Collab plug implements real-time “Google Doc” style collaboration with other SilverBullet users using the [Hocuspocus](https://hocuspocus.dev/) library. It supports:
|
||||
|
||||
* Real-time editing
|
||||
* Showing other participant’s cursors and selections
|
||||
@@ -27,14 +27,15 @@ To use it:
|
||||
5. If the collaborator wants to keep a persistent copy of the page collaborated page, they can simply _rename_ the page to something not prefixed with `collab:`. Everything will keep working for as long as the `collab:` will appear in the `$share` attribute of [[Frontmatter]]
|
||||
|
||||
## How it works
|
||||
The Collab plug uses Yjs for real-time collaboration via a WebSocket. A random ID is assigned to every shared page, and a copy of this page (as well as its history) will be stored on the collaboration server. Therefore, be cautious about what you share, especially when using a public collab server like `collab.silverbullet.md`. For “production use” we recommend deploying your own collab server.
|
||||
The Collab plug uses Hocuspocus for real-time collaboration via a WebSocket. A random ID is assigned to every shared page, and a copy of this page (as well as its history) will be stored on the collaboration server. Therefore, be cautious about what you share, especially when using a public collab server like `collab.silverbullet.md`. For “production use” we recommend deploying your own collab server.
|
||||
|
||||
## Deploying your own collab server
|
||||
$deploy
|
||||
A detailed description of how to deploy your own collab server [can be found here](https://github.com/yjs/y-websocket). The short version is:
|
||||
|
||||
Collaboration uses the excellent Hocuspocus library. You can easily deploy your own collaboration server as follows (requires node.js and npm):
|
||||
|
||||
```shell
|
||||
HOST=0.0.0.0 PORT=1337 YPERSISTENCE=./store npx y-websocket
|
||||
npx @hocuspocus/cli@2.0.6 --sqlite documents.db --port 1337
|
||||
```
|
||||
|
||||
This will run the `y-websocket` server on port 1337, and store page data persistently in `./store`. You can connect to this server via `ws://ip:1337`. To use SSL, put a TLS server in front of it, in which case you can use `wss://` instead.
|
||||
This will run the hocuspocus server on port 1337, and store page data persistently in a SQLite database `documents.db`. You can connect to this server via `ws://ip:1337`. To use SSL, put a TLS terminator in front of it, in which case you can use `wss://` instead.
|
||||
Reference in New Issue
Block a user