Re-allow hosting HTML, JS & CSS from *.org #50
No reviewers
Labels
No labels
inadvertently closed
Kind: Breaking
Kind: Bug
Kind: Enhancement
Kind: Feature
Kind: Maintenance
Kind: Question
Kind: Security
Kind: Testing
Priority: Critical
Priority: High
Priority: Low
Priority: Medium
Status: Blocked
Status: Completed
Status: Help wanted
Status: In progress
Status: Needs feedback
Status: Stale
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Codeberg-Infrastructure/build-deploy-forgejo!50
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "momar/build-deploy-gitea:bugfix/fix-raw-content-type"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This resolves a regression from
5553585631-Content-Type: text/plainwas mistakenly set on pages like fonts.codeberg.org for HTML, JS and CSS files.Can you please also review #52?
Did that, I guess they're quite closely related and don't work at the same time, but solve different issues 🙈
df67f0f85ftob23d3e83acThis has now been rebased to include #52, together with some changes (see Codeberg/build-deploy-gitea#52 (comment)).
I have deployed this to codeberg-test.org, and raw content it works when adding
116.203.144.175 raw.codeberg.euto/etc/hosts(.euinstead of.pagebecause it doesn't have HSTS;.pageinstead of.orgbecauseraw.*doesn't work on.org, as seen in #52).not sure if I understand, where is the reference to
.pagecoming from?Because I'm not sure what domain is intended to be used for
raw.*- it doesn't seem to beraw.codeberg.org, becauseCodeberg/build-deploy-gitea@b23d3e83ac/var/www/pages/index.php (L47)is in theelsebranch, so it won't work on*.org- my question mainly is if that was intended.684342ffadtob23d3e83acb23d3e83acto48c37c9d8dI just rebased this onto master - what's missing here @hw? Do you want raw.codeberg.org, raw.codeberg.page or raw.codeberg.eu? Security-wise it shouldn't matter.
raw.*content must be served from dedicated domain (can be included from any site, the reason people asked for this is to be able to securely embed cross-site content).Either
.page/.eu, or a new dedicated domain (if we think this is worth it). The main missing bit was a thourough review ;)Hm, you're right that Cookies might be set across subdomains.
I just disabled CORS to get-it-on.codeberg.org and docs.codeberg.org with an additional commit; it's needed though for design.codeberg.org and fonts.codeberg.org.
I think codeberg-raw.org or something makes sense for the raw content? But as this basically contains everything CORS-related, what can we do to make design.codeberg.org finally work? Deploy this as it is so raw.codeberg.page and raw.codeberg.eu works?
c6582ad10bto4bc21c7082Alright, it's now using the Gitea API and contains a lot of extra measurements to make sure that the path is safe.
URL format is now: https://raw.codeberg.page/username/reponame/@branch/path/to/file, with the
@branchcomponent being optional. LFS or other identifiers than the branch are not possible with this version, but I guess that's alright for now.Fun fact: I'm also working on a new Pages server in Go that supports repositories with a
pagesbranch (like https://example.codeberg.page/myrepo/), caching, compression, and custom domains with Let's Encrypt.We should set the
Link: <URL>; rel="canonical"HTTP header for branches, to avoid redundant indexing by search engines, and keep crawler traffic within reasonable bounds, also add a disallow wildcard torobots.txt.Shouldn't badges be embeddable across sites?
Merged for early testing, let's address the comments above in follow-up PR.
They are - CORS is basically only needed when requesting something directly from JavaScript, or if it's a web font. Embedding pictures or even scripts and stylesheets doesn't need CORS.