Hello, I have a problem with CORS and I think this is right community to get help.

When I use this code:

import { LemmyHttp } from 'lemmy-js-client';
const client = new LemmyHttp('https://lemmy.ml');
const { posts } = await client.getPosts({
    limit: 10,
    page: 1
});

to get posts from lemmy.ml (using lemmy-js-client), I get:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://lemmy.ml/api/v3/post/list?limit=10&page=1. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 400.

I have tried to add header like this:

const client = new LemmyHttp('https://lemmy.ml', {
    headers: {
        'Access-Control-Allow-Origin': '*'
    }
});

but result is the same.

Can someone help me with this?

  • @starmanOP
    link
    English
    1
    edit-2
    1 year ago

    So I’ll have to wait for this PR to be merged. I think they will do it soon because it provides more positive value that negative at this moment

    • @RonSijm
      link
      English
      11 year ago

      I don’t know if the PR is going to solve it though.

      If I’m looking at the file changed: https://github.com/LemmyNet/lemmy/pull/3421/files

      It seems like the “Lemmy Instance Owner” would have to set an environment variable of “LEMMY_CORS_ORIGIN” - and if there’s no variable set it defaults back to:

      .allow_any_origin() .allow_any_method() .allow_any_header()

      I don’t know if instances are going to “allow *”

      • @starmanOP
        link
        English
        1
        edit-2
        1 year ago

        I haven’t found .allow_any_origin() in source (query), but isn’t it sorta equivalent to Access-Control-Allow-Origin: *? Or I’m misinterpreting something

        Edit: from the author of PR:

        It’s also worth noting that the behavior of allow_any_origin makes the server echo back CORS headers that respect the request’s Origin header, as opposed to send_wildcard which sends back * for the CORS headers. I don’t think this really matters, but it’s something to keep in mind.

        • @data0
          link
          English
          11 year ago

          Setting it to * will prevent the browser from including credentials in the request (cookies). Dynamically setting it to the origin of the requesting client effectively does the same but also allows for using credentials.

          • @RonSijm
            link
            English
            11 year ago

            I don’t think it would be a very good implementation to just let any site dynamically request to be allowed by CORS, including with credentials… A malicious site could do way too many things on the users behave

            A possible solution would be something like how reddit or github do it - have the user first accept an “Allow third party app / website to access my account” - and after that, add those sites to the Access-Control-Allow-Origin

            • @data0
              link
              English
              11 year ago

              What are the exact attack vectors you’re thinking of?

              • @RonSijm
                link
                English
                11 year ago

                Well I’m not expert on CORS, nor with the Lemmy API, so it’s probably better to read about CORS exploits in more detailed articles… https://www.freecodecamp.org/news/exploiting-cors-guide-to-pentesting/ for example

                It seems Lemmy is storing a JWT in the cookiejar, so with Access-Control-Allow-Credentials:true and the domain in Access-Control-Allow-Origin a site should be able to do authenticated get requests on a users behave with the JWT, and access personal data.

                The “GET https://programming.dev/api/v3/private_message/” endpoint for example, would let someone read the private messages someone has send/received

                I’m not sure whether someone could do POST requests and add credentials from the cookiejar this way though