Service worker and external authentication: can't login again

[otaconix]

Situation

I am self-hosting Silverbullet, and have my reverse proxy configured to forward requests to a SSO solution (in my case: Authentik).

Upon initial loading of Silverbullet, I am redirected to the login page of my SSO provider, and everything works fine. But as soon as my session with the SSO provider is invalidated (for whatever reason: I logged out, the session expires, etc.), I am stuck in limbo, as the service worker intercepts all requests, and concludes that the backend is offline.

What seems to happen is this:

1. Session expires
2. Requests intercepted by service worker are forwarded to the backend, which results in a 302 Found redirect response (which lead to the login page of the SSO provider)
3. Service worker catches exception, and concludes the backend is offline, returning a 503 Service Unavailable to the frontend

Environment

• Browser: Firefox 128.0.3
• OS: macOS Sonoma 14.5, M1 Pro
• Silverbullet version: 0.9.0 (Docker image hash: sha256:2e9c82f40588ef41095192cba864691eed69feb62190355dc734ff85aa552b06)

Expected outcome

Somehow follow redirect so I, as a user, can login through SSO again, and have a working connection to the Silverbullet backend.

Additional notes

I'm not quite sure what the best possible solution would be in this case. At first glance, it would seem that following the redirect to the SSO provider indicated location would solve my issue, but it's entirely possible that Silverbullet would want to use the 302 Found statuscode itself.

If there's any extra information I can provide, please let me know!

[zefhemel]

You say the service worker catches the exception, can you post a screenshot of the error that it shows? This would help.

[otaconix]

Here's what it looks like in Firefox (which unfortunately doesn't show network requests performed by service workers anywhere I could find):

And here it is in Chrome:

And now that I have a better look at it in Chrome, I can tell that there's a CORS issue, which I'm going to try to fix to see what happens.

[otaconix]

As it turns out, CORS was the issue indeed. After allowing requests to my SSO provider from my Silverbullet instance's host, Silverbullet does in fact redirect me to the login page!

I do wonder though, and I'm basically just thinking out loud here, but does it make sense to let the service worker follow redirects itself? Looking at the fetch API documentation, there's a link to a discussion on the whatwg issue tracker that seems to be about exactly this issue (a service worker that can't follow a cross-domain redirect due to CORS): https://github.com/whatwg/fetch/issues/66. So maybe using fetch(url, {redirect: "manual"}), and return a redirect response from the service worker might actually work.

I don't think I'll soon have much time to experiment with this myself, but if you're busy, I'd be happy to have a go at it at some point in the future.

Either way, it might be helpful to add some text warning about CORS issues to the docs somewhere?

[alexyao2015]

To help out the next person who finds this, I set this on the ingress to my sso which fixed the issue.

if ($request_method = OPTIONS) {
  add_header Access-Control-Allow-Origin https://silverbullet.md;
  add_header Access-Control-Allow-Headers *;
  add_header Content-Type text/plain;
  add_header Content-Length 0;
  return 204;
}
add_header Access-Control-Allow-Origin https://silverbullet.md;