this post was submitted on 17 Jun 2023

6 points (100.0% liked)

Beehaw Support

2794 readers

1 users here now

Support and meta community for Beehaw. Ask your questions about the community, technical issues, and other such things here.

A brief FAQ for lurkers and new users can be found here.

Our September 2024 financial update is here.

For a refresher on our philosophy, see also What is Beehaw?, The spirit of the rules, and Beehaw is a Community

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago

MODERATORS

[email protected]

Missing CORS prevents third-party web clients (beehaw.org)

submitted 1 year ago by [email protected] to c/[email protected]

11 comments fedilink hide all child comments

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

all 13 comments

sorted by: hot top controversial new old

[–] [email protected] 3 points 1 year ago (1 children)

Not a mod but looking forward to see what you come up with. Not a. If fan of the lemmy web ui

[–] [email protected] 2 points 1 year ago

Here's what I have planned at the moment: https://hachyderm.io/@diamond/110564684274449852

I don't plan on making it feature-complete, just enough to be a Lemmy reader with some reply capabilities.

[–] [email protected] 3 points 1 year ago

@[email protected] - Relevant CORS headers have been applied to /api endpoint. Please let us know if this is sufficient for your continued testing.

[+] [email protected] 2 points 1 year ago* (last edited 9 months ago) (1 children)

[deleted]

[–] [email protected] 1 points 1 year ago (1 children)

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.

[+] [email protected] 2 points 1 year ago* (last edited 9 months ago) (1 children)

[deleted]

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year ago* (last edited 9 months ago) (1 children)

[This comment has been deleted by an automated system]

[–] [email protected] 2 points 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.

[–] [email protected] 0 points 1 year ago (1 children)

CC: @[email protected]

Would be nice to fix so they can developer further Slemmy without hindrance

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

I see the request, thanks for the ping. Those CORS headers are not appropriate, it would essentially remove any protections that CORS offers. I'd rather not completely strip away that security for a single app, when others can certainly abuse or try to exploit such.

The asterisk wild-card permits scripts hosted on any site to load your resources; listing a specific will permit scripts hosted on the specified site -- and no others -- to load your resources.

@[email protected] Happy to work with you on this, but I'd request a much more specific source and which resources of Beehaw you'd want that on.

[–] [email protected] 2 points 1 year ago (1 children)

Thank you for the reply, I really appreciate it! Currently, my app has been migrated to the WS API so development can continue for now until the WS is removed completely in a later release or Lemmy addresses the CORS issue upstream.

As for the security concerns, I believe that most of them are addressed in this comment that is in the particular issue that I linked above.

It's worth noting that CORS really only applies in the browser and that the WS API currently bypasses this protection (hence me being able to continue with the development).

[–] [email protected] 2 points 1 year ago

P/S: the app currently lives at https://slemmy.libdb.so.