Configuring New whiteboard plugin (tldraw)

Admin Talk Configuration
1

I upgraded to 5.2.7 and was trying to get the new whiteboard plugin with tldraw to work.
The issue I’m facing is that I’m not a caddy user, rewriting the compose file was not a problem but as it seems the plugin is hardcoded to access port 6239 from the seatable installation:
I don’t really want to open up a new port but rather have it running under /tldraw for example.
So assuming my seatable is running under https://table.example.com I would want to have the whiteboad under https://table.example.com/tldraw

In my nginx I could accomplish this with

   location /tldraw/ {
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header CLIENT_IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_read_timeout 86400;
       proxy_pass http://10.10.10.10:6239/;
   }

now if I do a curl to https://table.example.com/tldraw/ping it am getting a correct response

{"status":"pong"}

so all I need is some magic setting to tell the whiteboard plugin to use a different URL for tldraw.
I checked the plugin zips but could only find the old excalidraw zips.

2

Sorry to tell you, but tldraw does currently not support a subfolder setup. The fact that you receive a “pong” shows, that you can reach the container, but nothing more.

Please try opening the port.

Best regards
Christoph

3

Opening the port creates additional complications. I’ll have to look at how I can get nginx proxy manager to do that, sure it’s possible but would then have to do the same at multiple clients.
But isn’t it similar to how seafile uses seadoc while it runs in a separate container, it sets up the reverse proxy to enable websocket for the path and passes it on internally to the container.
All it would need is a configuration value for the plugin where to reach tldraw.
Or am I missing something? I’m currently sick and my brain is a bit foggy.

Cris

5

And I’m back.
I have for example two instances of Seatable running, my own and one for a client, if I can’t change the way the whiteboard plugin is being accessed I would have to move this one instance on a different VM.
I don’t quite understand why I can’t just pass the locations /tldraw/ to the container on the desired port?
tldraw does not need to even know about this, this will all be done on the reverse proxy. All it would need is the possibility to configure the setting for tldraw in seatable.

6

We are currently occupied with all the preparations for version 5.3.

Would you be interested in getting access to the plugin source code? Then you can try to add subfolder-support by yourself.

You can send me a private message with your GitHub account.

7

Hi,

I’m not sure whether @lcx_at replied to that offer in private, I’d like to say that I’m very much interested in the source code. Two reasons:

  • Open ports being rare in our corporate firewall, I’d also like to run the tldraw worker in a path. Having a quick look at the JS client’s source code, I noticed two things:
    • The client seems to support a path, but it’s just not configurable I guess
    • Even it that is the case, the client (i.e. the web app / GUI) seems to be hard-coded to port 6239, no matter which port is configured via TLDRAW_PORT on the worker container. I could even live with the standard /connect/ path, because it does not seem to conflict with anything.
  • Again, the TLS / CA issue raises its head: Even on port 6239, the worker throws constant errors
    • Possible reason: We use an internal CA for our intranet, and the TLDRAW worker does not seem to know the internal Certificate Authorities. I’d like to have a look whether that could be configured.
Generate upload link
Axios error: {
  message: 'unable to get local issuer certificate',
  endpoint: 'https://seatable.lhs.stuttgart.de/api/v2.1/dtable/custom/app-upload-link/',
  response: null
}
Could not create upload link: Error: Request failed: unable to get local issuer certificate. 
    at makeRequest (/app/axios.ts:58:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async getCustomAssetUploadLink (/app/seatableActions.ts:102:22)
    at async Object.<anonymous> (/app/worker.node.ts:59:7)
8

@abaer yes, got it and already on it. Will test in my environment and report back.

9

For everyone who’s interested in bringing custom CAs (Certificate Authorities) into the TLDRAW worker container: 2 Methods, both in the relevant docker-compose.yml, solving my second point from the last post:

Method 1, UNSAFE because there will be no certificate verification at all:

---
services:
  trdraw-worker:
# more stuff here
    environment:
# more stuff here
      - NODE_TLS_REJECT_UNAUTHORIZED=0
# more stuff here

Mehod 2, the proper way

---
services:
  trdraw-worker:
# more stuff here
    environment:
# Configure Extra CA (chain) for node.js in container via environment
      - NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/MY-CA.pem
# more stuff here
    volumes:
# Custom Root CA mapped from host into container
     - /home/egov/cert/MY-CA.pem:/usr/local/share/ca-certificates/MY-CA.pem:ro
# more stuff here

@cdb, you might want to add this to seatable-release

10

Since this is a bit of complicated for me to open up new ports and also problematic if I have more than one SeaTable running, I will update the code of the plugin.

Instead of this:

const WORKER_URL = window.dtable?.server + ':6239';

I will go with

const WORKER_URL = window.dtable?.server + '/tldraw';

and then just add this to my nginx reverse proxy:

   location /tldraw/ {
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header CLIENT_IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_read_timeout 86400;
       proxy_pass http://10.10.10.10:6239/;
   }

This already contains the certificate which is automatically renewed and I don’t have to fiddle with updating the files and also don’t have to change the reverse proxy to listen to a new port.

11

Same idea here: Got it working in a similar fashion, but I’l like to get @rdb to comment whether that could be integrated into his mainstream development, and configurable if possible.

@lcx_at did you also check whether picture uploads work? The use the route ${WORKER_URL}/uploads and are not Websocket-connections like ${WORKER_URL}/connect.

Anyway, this is what needs to be done:

Plugin client:

I’d suggest making the WORKER_URL configurable with a separate path and port:

const WORKER_URL = window.dtable?.server + ':' + ${TLDRAW_PORT} + ${TLDRAW_PATH};

However, I have no idea whether clients can be configured (via the server), i.e. can read configuration settings from the server’s environment (via the window.app or window.dtable objects?). @rdb, is that possible? It seems that a lot of variables from the dtable_web_settings.py configuration make it into the window.dtable object.

Worker

The worker does not know the prefixed routes /tldraw/connect and /tldraw/uploads. I didn’t want to change the worker image. The port change (443 => 5858 instead of 6239 => 5858) is done via the edge router / reverse proxy (Traefik in my case, or Nginx for @lcx_at, or Caddy) anyway, so I went the same way for the path

      traefik.http.routers.tldraw.middlewares: "tldraw-prefixing@docker"
      traefik.http.middlewares.tldraw-prefixing.stripprefix.prefixes: "/tldraw"

These two lines strip the /tldraw prefix from the URI that the worker sees. /tldraw/connect becomes /connect as expected by the worker, and /tldraw/uploads becomes /uploads again.

@lcx_at as far as I remember my nginx days, ngninx does that by default? For everone else: Don’t know how to strip the prefix with Caddy.

12

@abaer yes images working fine and also the websockets. I however don’t see the need of changing any ports of the worker.
Using nginx as mentioned above:

   location /tldraw/ {
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header CLIENT_IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_read_timeout 86400;
       proxy_pass http://10.10.10.10:6239/;
   }

would route everything from /tldraw to the container on port 6239 so I can live with that as is.

13

@lcx_at , thanks, that satisfies my curiosity regarding long-forgotten nginx knowledge.

Just a remark: Would it be not more efficient to go directly to the worker’s port 5858?