CORS error when fetching codeberg api in codeberg page #673

Open
opened 1 week ago by AquaBx · 6 comments
AquaBx commented 1 week ago

Hi !

I don't know if it is a bug or a feature, but when we call the api of codeberg (https://codeberg.org/api/...) in a codeberg page (https://username.codeberg.page/...) we result with a cors error. I guess it is because of the difference between the domains name.

Hi ! I don't know if it is a bug or a feature, but when we call the api of codeberg (https://codeberg.org/api/...) in a codeberg page (https://username.codeberg.page/...) we result with a cors error. I guess it is because of the difference between the domains name. <!-- NOTE: If your issue is a security concern, please send an email to contact@codeberg.org (and if related to Gitea also to security@gitea.io) instead of opening a public issue. Thank you. Welcome to the Codeberg Community Tracker. This is the right place for bug reports, feature requests and feedback. It's the central place where we track progress and discuss, so please open issues here unless you are sure it's directly related to a specific Codeberg product and only some contributors there need to join the discussion. Easy rule: If you are unsure, report it here. When reporting bugs or asking for features in the software itself, please understand that Codeberg is a fork of Gitea. Please always check upstream (→ see FAQ) if your there is already an open issue. If not, you'd really help us if you could directly get in touch with the maintainers and open an issue here if you think a wider audience should know about that (e. g. when discussing hotfixes, backports or when discussing whether some feature should become part of Gitea or a Codeberg "add-on"). If you don't have a GitHub account, please mention this and we'll gladly forward your report to the Gitea maintainers. Thank you for reporting your findings and giving feedback on Codeberg. ## Some FAQ: ### What does upstream mean? Upstream refers to Gitea, the software Codeberg is built upon. If we ask you if you can report upstream, please visit https://github.com/go-gitea/gitea/issues and check for the bug there and report elsewise. It's usually good if the person interested in a feature or bugfix opens the request to react to questions and join the discussion. We would usually just fire the report, but won't find the time to properly react to that ... **If you do not have a GitHub account**, just tell us and we'll happily forward the report for you. ### I just noticed a typo in the sign_up / sing_up route when regis... No, this is not a typo, but intentional. It was a quick fix to avoid spammers targetting our instance and it actually worked out quite well to rename the route from sign_up to sing_up (few people notice, nice to see you have sharp eyes) ... we might have to take more effective countermeasures in the future, but for now we're actually quite good with that one ... ### How can I help? If you want to help improving Codeberg as a community home for software development, we'll gladly welcome your contribution. Check out the docs about improving Codeberg https://docs.codeberg.org/improving-codeberg/ and have a look at the open issues, especially those that are looking for contribution https://codeberg.org/Codeberg/Community/issues?state=open&labels=105 - some of them don't even require much coding knowledge. We are also happy if you forward bug reports to Gitea if the original author hasn't done that yet or hasn't got a GitHub account. -->
Collaborator

I think this is supposed to be disabled. AFAIK, if this would be allowed, you could impersonate every visitor of your page by running API queries to Codeberg.org in their name.

I think this is supposed to be disabled. AFAIK, if this would be allowed, you could impersonate every visitor of your page by running API queries to Codeberg.org in their name.
Poster

For sensitive requests, you need a token given by the user. And for example, Github allows the cross-origin, even with external domains.

For sensitive requests, you need a token given by the user. And for example, Github allows the cross-origin, even with external domains.
rwa added the
pages
codeberg
labels 6 days ago
Collaborator

I think this is supposed to be disabled. AFAIK, if this would be allowed, you could impersonate every visitor of your page by running API queries to Codeberg.org in their name.

Well that won't work in practice as codeberg pages is ran on a different domain than codeberg.org

> I think this is supposed to be disabled. AFAIK, if this would be allowed, you could impersonate every visitor of your page by running API queries to Codeberg.org in their name. Well that won't work in practice as codeberg pages is ran on a different domain than codeberg.org

Funny this discussion is only 5 days old, but just today I stumbled over the same problem as in trying to run some Javascript served from codeberg.page to access the api of codeberg.org.

(Actually all I would need is "file browsing" on user.codeberg.page. Not sure what the OP needs, but if there is a way ...?)

Funny this discussion is only 5 days old, but just today I stumbled over the same problem as in trying to run some Javascript served from codeberg.page to access the api of codeberg.org. (Actually all I would need is "file browsing" on user.codeberg.page. Not sure what the OP needs, but if there is a way ...?)
Collaborator

Well that won't work in practice as codeberg pages is ran on a different domain than codeberg.org

To re-iterate on this. Currently cookies are set with:

  • Domain: codeberg.org (so this cookie is useable for codeberg.org and its subdomains).
  • Path: / (just means to always send it regardless of the path).
  • HostOnly: true (this means cookies that are set on codeberg.org cannot be read by its subdomains)
  • HttpOnly: true (Javascript on codeberg.org cannot use document.cookie to see the cookies)
  • SameSite: Lax (means that the cookie is not sent on cross-site requests, but is sent when a user is navigating to the codeberg.org from an (external) site)

So only when you're on codeberg.org or going to codeberg.org it will send the cookies. Thereby codeberg.page != codeberg.org and that means you will need third-party cookies to somewhat achieve this, but those don't exist anymore.

Making a fetch call to https://codeberg.org/api/v1/version from https://codeberg.page shows indeed no cookies are being sent.
image

I don't see a really good reason to not enable this. We could test with codeberg-test.org but like I said different domains, it shouldn't be possible. That's just a security issue from the browser.

> Well that won't work in practice as codeberg pages is ran on a different domain than codeberg.org To re-iterate on this. Currently cookies are set with: - Domain: `codeberg.org` (so this cookie is useable for codeberg.org and its subdomains). - Path: `/` (just means to always send it regardless of the path). - HostOnly: `true` (this means cookies that are set on codeberg.org cannot be read by its subdomains) - HttpOnly: `true` (Javascript on codeberg.org cannot use `document.cookie` to see the cookies) - SameSite: `Lax` (means that the cookie is not sent on cross-site requests, but is sent when a user is navigating to the codeberg.org from an (external) site) So only when you're on codeberg.org or going to codeberg.org it will send the cookies. Thereby codeberg.page != codeberg.org and that means you will need third-party cookies to somewhat achieve this, but those don't exist anymore. Making a fetch call to https://codeberg.org/api/v1/version from https://codeberg.page shows indeed no cookies are being sent. ![image](/attachments/494b3264-abc3-4024-9a78-b566eba0a800) I don't see a really good reason to not enable this. We could test with codeberg-test.org but like I said different domains, it shouldn't be possible. That's just a security issue from the browser.

For comparison, see what github does. Here is a file of an ancient repo of mine:

https://api.github.com/repos/HaraldKi/monqjfa/contents/build.xml

Paste the URL in a browser to see

  • that you get back some json and
  • check in your browser's developer tools that they do send access-control-allow-origin: *

All without any authentication.

For reference about CORS I got confused by gazillions of website writing confusing stuff and finally settled to just read https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS from which I gather that access-control-allow-origin: * is probably OK for a resource that is anyway publicly available. In addition I understand that the browser, according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials, will not provide the content if no Access-Control-Allow-Credentials: true, so make sure to not combine this with '*'. Even more, to cite:

If a request includes a credential (most commonly a Cookie header) and the response includes an Access-Control-Allow-Origin: * header (that is, with the wildcard), the browser will block access to the response, and report a CORS error in the devtools console.

So even if the server gets misconfigured, the browser will help out here.

For comparison, see what github does. Here is a file of an ancient repo of mine: https://api.github.com/repos/HaraldKi/monqjfa/contents/build.xml Paste the URL in a browser to see - that you get back some json and - check in your browser's developer tools that they do send `access-control-allow-origin: *` All without any authentication. For reference about CORS I got confused by gazillions of website writing confusing stuff and finally settled to just read https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS from which I gather that `access-control-allow-origin: *` is probably OK for a resource that is anyway publicly available. In addition I understand that the browser, according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials, will not provide the content if no `Access-Control-Allow-Credentials: true`, so make sure to not combine this with `'*'`. Even more, to cite: > If a request includes a credential (most commonly a Cookie header) and the response includes an Access-Control-Allow-Origin: * header (that is, with the wildcard), the browser will block access to the response, and report a CORS error in the devtools console. So even if the server gets misconfigured, the browser will help out here.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#673
Loading…
There is no content yet.