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
Huh, interesting. It seems that a WS connection to
wss://beehaw.org/api/v3/ws
works, but notwss://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.
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).
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.
There is an issue upstream tracking this. For now, I only mostly use Beehaw, so that’s fine.
Nope, I’m using
lemmy-js-client
. The WS part of it doesn’t do much, so I didn’t bother using it. TheLemmyWebsocket
type wasn’t also in the main import for some reason, but that wasn’t much of an issue.