Sync failures with Cloudflare

If I set SB_SYNC_ONLY=true e.g. in docker-compose I see the sync button on “online” mode on the toolbar and errors like this in the console:

System not yet ready, not rendering panel widgets.
document_editor_skeleton.ts:1 Loading plugs
document_editor_skeleton.ts:1 (Re)loading plugs
codemirror-vim.mjs:14 Activated plug core
codemirror-vim.mjs:14 Activated plug editor
codemirror-vim.mjs:14 Activated plug emoji
codemirror-vim.mjs:14 Activated plug image-viewer
codemirror-vim.mjs:14 Activated plug index
codemirror-vim.mjs:14 Activated plug markdown
codemirror-vim.mjs:14 Booting up worker for markdown
codemirror-vim.mjs:14 Activated plug plug-manager
codemirror-vim.mjs:14 Activated plug search
codemirror-vim.mjs:14 Activated plug share
codemirror-vim.mjs:14 Activated plug sync
codemirror-vim.mjs:14 Activated plug tasks
lua_widget.ts:215 Not rendering widgets
ajv.mjs:4 System not yet ready, not rendering panel widgets.

This is with a completely “fresh browser” - the palette is unavailable, no pages retrieved, can’t switch page, can’t edit, however clicking the sync button (to enable sync mode) seems to kick everything into life. However the next browser will be the same (sync button click required).

If I remove the SB_SYNC_ONLY environment variable, it starts in sync mode as expected and all good.

Hope this helps someone.

The SB_SYNC_ONLY option shouldn’t do anything (it’s now the only mode) and the sync button has been removed. Are you sure you’re on v2 and don’t have an old version cached?

AHA :light_bulb:

It was cloudflare. I had no problems with the v0.1 site using Online mode, but with Synced mode it has apparently become necessary to bypass Cloudflare auth for the service worker etc. as per your guide Cloudflare and Portainer, following this part closely:

Now it all seems to work.

@zef thanks for your patience, hopefully this will help someone else in the future. Why are the bypasses required?

Nick

@nickb I’ve recently dealt with this issue (and solved it without any external help, so that took a while lol). This is what I’ve found.

.client/manifest.json shouldn’t be needed anymore if you’re running edge. .client/manifest.json is the manifest for the SB PWA app, and it’s linked using

<link rel=manifest href=.client/manifest.json>

However for some reason, this does not send cookies (for authentication). Newer versions have this fixed with

<link rel=manifest href=.client/manifest.json crossorigin=use-credentials>

.client/[a-zA-Z0-9_+]+.png : I’ve never had any issues with this, not sure what this is for (at least not with CloudFlare ZT Access).

With service_worker.js, this is the thing that let’s SB work offline. When registering it with

navigator.serviceWorker.register("/service_worker.js", { type: "module" })

cookies are not set, and there’s no way in the JS SW API to send cookies, or to work around it. Weirdly, if using classic-style JS SWs,

navigator.serviceWorker.register("/service_worker.js", { type: "classic" })

it does send cookies. javascript moment.

1 Like