Hey Beehaw mods!

I’m currently working on a Lemmy web client, but the lack of proper CORS headers is preventing anything from working :(

I just wanted to ask if the appropriate CORS headers could be added to the front-facing proxy layer. If you’re using Caddy, I believe something like this should do the trick:

reverse_proxy ... {
  header_down Access-Control-Allow-Origin *
  header_down Access-Control-Allow-Methods *
  header_down Access-Control-Allow-Headers *
}

Relevant issue: https://github.com/LemmyNet/lemmy/issues/3109

  • Skull giver@popplesburger.hilciferous.nl
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Correct me if I’m wrong, but the Websocket API should work without CORS issues, shouldn’t it? Perhaps you could use that as a backup for the many Lemmy instances with a standard CORS setup?

    • diamond (she/they)@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Websocket handshakes are done over HTTP. The endpoint for Beehaw’s WS API would be wss://beehaw.org/, so it’s still going to use the same CORS policies as accessing the / (root) path.

      • Skull giver@popplesburger.hilciferous.nl
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        Websockets aren’t bound by normal CORS, though. They send an Origin header that the server needs to check, but beehaw doesn’t seem to refuse any origins and neither do the other servers I’ve tried.

        You’re correct that websockets are negotiated through HTTP(S) requests, but the browser exempts them from many CORS limitations.

        I’ve tried this myself, and you can do it too: open https://lemmy.world in a private tab, get the dev tools out, navigate to sources/js/client.js, hit control+f and look for “wsUri:”. If you set a breakpoint on the line where this gets logged, reload, and change the wsUri variable (named yi in my tests) to something like wss://beehaw.org/api/v3/ws and then resume code execution, you’ll find the websocket connect and exchange data with Beehaw.

        If you hit the next button at the bottom (the first page of results were part of the original HTML) you’ll even be browsing Beehaw communities despite visiting the URL of an instance that has been defederated by beehaw!

        It’s possible that Lemmy servers will start checking the Origin header in the future, but for now any web app can log in to almost any Lemmy instance through the websocket API.

        • diamond (she/they)@beehaw.orgOP
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          Huh, interesting. It seems that a WS connection to wss://beehaw.org/api/v3/ws works, but not wss://beehaw.org. I remember reading somewhere that the WS API will eventually be removed, though.

          I’ll continue development w/ the REST API until I feel like it’s in a mostly-working state, and then I’ll probably subject myself to the WS API after. Working with the REST API does feel a lot easier.

          • Skull giver@popplesburger.hilciferous.nl
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            The websocket needs the right URL or it won’t work, you can’t always assume the websocket endpoint is at the root of the domain.

            If the WS API is being deprecated then I agree. That’s annoying, though, because setting up the right CORS headers to allow arbitrary online clients is a pain and I suspect many instance admins won’t do it.

            As a side note, are you implementing the API from scratch? Because there’s a Javascript (Typescript) API that gets auto generated from the Lemmy sources that’s ready to use (supports both REST and WS).

            • diamond (she/they)@beehaw.orgOP
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              The websocket needs the right URL or it won’t work, you can’t always assume the websocket endpoint is at the root of the domain.

              Right. I was reading a code snippet from somewhere else where they called into the root path, but the library that they were using probably did the appending in the background which I didn’t know.

              That’s annoying, though, because setting up the right CORS headers to allow arbitrary online clients is a pain and I suspect many instance admins won’t do it.

              There is an issue upstream tracking this. For now, I only mostly use Beehaw, so that’s fine.

              As a side note, are you implementing the API from scratch? Because there’s a Javascript (Typescript) API that gets auto generated from the Lemmy sources that’s ready to use (supports both REST and WS).

              Nope, I’m using lemmy-js-client. The WS part of it doesn’t do much, so I didn’t bother using it. The LemmyWebsocket type wasn’t also in the main import for some reason, but that wasn’t much of an issue.