#303 [FEEDBACK WANTED] Soft-launching subdomain support for codeberg.page

Open
opened 4 months ago by hw · 17 comments
hw commented 4 months ago
Owner

Hi all,

we are soft-launching subdomain support for https://codeberg.page. User repositories are mapped to https://<username>.codeberg.page/.

Please have a look and let us know how it works for you!

The traditional URLs https://pages.codeberg.org/<username> continue to work for the time being, but might get phased out at some point in time as some reports claim an increased attack surface with this approach (even if we are not aware of any real threat we’d of course love to reduce possible attack vectors as much as possible to keep the platform safe).

There is a caveat for users and organizations containing a dot in the username: SSL certificates do not support multilevel subdomains. If your username contains a dot and you'd like to use codeberg pages on subdomains, please consider replacing these characters in your username. (right now these repos are not redirected, so that https://pages.codeberg.org/<username> will work).

As you know, we also have registered the domain https://codeberg.eu, which is still linked to the testing server https://codeberg-test.org, and currently used for testing. We have not made up our minds about the future use. Please have your say. Thinkable options are:

  • run it in parallel to .page, and leave the choice to the user what URL to give out,
  • keep it as testing domain and fallback if ever needed.

Independently we might want to discuss how to handle redirects, and if one of the domains should have priority.

If there are any preferences please all raise your voice, if appropriate we will organize a poll for decision.

Hi all, we are soft-launching subdomain support for https://codeberg.page. User repositories are mapped to `https://<username>.codeberg.page/`. Please have a look and let us know how it works for you! The traditional URLs `https://pages.codeberg.org/<username>` continue to work for the time being, but might get phased out at some point in time as some reports claim an increased attack surface with this approach (even if we are not aware of any real threat we’d of course love to reduce possible attack vectors as much as possible to keep the platform safe). There is a caveat for users and organizations containing a dot in the username: SSL certificates do not support multilevel subdomains. If your username contains a dot and you'd like to use codeberg pages on subdomains, please consider replacing these characters in your username. (right now these repos are not redirected, so that `https://pages.codeberg.org/<username>` will work). As you know, we also have registered the domain https://codeberg.eu, which is still linked to the testing server https://codeberg-test.org, and currently used for testing. We have not made up our minds about the future use. Please have your say. Thinkable options are: - run it in parallel to .page, and leave the choice to the user what URL to give out, - keep it as testing domain and fallback if ever needed. Independently we might want to discuss how to handle redirects, and if one of the domains should have priority. If there are any preferences please all raise your voice, if appropriate we will organize a poll for decision.
Poster

It is a great improvement to the URL now used. I had to regen my site, as it broke the links, but the redirect works fine. I notice it is slower in loading images.

PS. Is custom domain support like GH still in consideration (or I will have to use GH)

It is a great improvement to the URL now used. I had to regen my site, as it broke the links, but the redirect works fine. I notice it is slower in loading images. PS. Is custom domain support like GH still in consideration (or I will have to use GH)
Poster

Calling myusername.codeberg.page worked flawlessly for me, certificate works fine, page and links work fine. Awesome improvement!

Calling myusername.codeberg.page worked flawlessly for me, certificate works fine, page and links work fine. Awesome improvement!
nac commented 4 months ago
Poster

I like it, thanks for a great job.

I like it, thanks for a great job.
Poster

Very nice work 👍 And I like the idea of keeping the two domains in parallel and letting users choose which one to use.

Very nice work :thumbsup: And I like the idea of keeping the two domains in parallel and letting users choose which one to use.
Poster
Owner

@circlebuilder

Custom domains, under consideration, yes, but nothing decided.

There would have to be some mutual trust, I do not want to give that ability to everyone anonymous who just want to have some racist nazi domain and point that to questionable content.

Codeberg pages was meant to complement free projects and moving to far into being a webspace for everyone is something we have to consider very carefully.

@circlebuilder Custom domains, under consideration, yes, but nothing decided. There would have to be some mutual trust, I do not want to give that ability to everyone anonymous who just want to have some racist nazi domain and point that to questionable content. Codeberg pages was meant to complement free projects and moving to far into being a webspace for everyone is something we have to consider *very* carefully.
Poster

@ashimokawa entirely agree! There could be some 'intake' process where a suggested custom domain is either voted on by other Codeberg users, or vetted by a selected team.

@ashimokawa entirely agree! There could be some 'intake' process where a suggested custom domain is either voted on by other Codeberg users, or vetted by a selected team.
Poster

@ashimokawa @circlebuilder - Maybe I just don't understand it right, but what would be the difference between external domains and internal USERNAME.codeberg.page subdomains in the regard of unwanted content and domain names?

The way it seems to me, in both scenarios unacceptable content is possible and unacceptable usernames are also possible. Wouldn't it be better to focus on removing content and users that clash with our Terms of Service instead of restricting access to custom domains?

@ashimokawa @circlebuilder - Maybe I just don't understand it right, but what would be the difference between external domains and internal USERNAME.codeberg.page subdomains in the regard of unwanted content and domain names? The way it seems to me, in both scenarios unacceptable content is possible and unacceptable usernames are also possible. Wouldn't it be better to focus on removing content and users that clash with our Terms of Service instead of restricting access to custom domains?
hw commented 4 months ago
Poster
Owner

There is some risk of abuse of Codeberg for hosting arbitrary web projects no in any way related to FOSS -- causing traffic and load without any tangible benefit for the community.

There is some risk of abuse of Codeberg for hosting arbitrary web projects no in any way related to FOSS -- causing traffic and load without any tangible benefit for the community.
Poster

Regarding the .eu domain: I personally would love to see it active. My project's homepage is also hosted on a .eu homepage, and if the link to the repository did also point to an .eu domain that would quite nice.

Regarding the .eu domain: I personally would love to see it active. My project's homepage is also hosted on a .eu homepage, and if the link to the repository did also point to an .eu domain that would quite nice.
Poster

I would recommend adding codeberg.page to the public suffix list. https://publicsuffix.org/

I would recommend adding codeberg.page to the public suffix list. https://publicsuffix.org/
hw commented 4 months ago
Poster
Owner

I would recommend adding codeberg.page to the public suffix list. https://publicsuffix.org/

Great idea! Somewhat overwhelmed right now tho, and not familiar with the format ... how would the PR have to look like that needs to be submitted?

> I would recommend adding codeberg.page to the public suffix list. https://publicsuffix.org/ Great idea! Somewhat overwhelmed right now tho, and not familiar with the format ... how would the PR have to look like that needs to be submitted?
Ghost commented 2 months ago
Poster

I was curious about using codeberg.io (to match Pages domain for *.github.io and *.gitlab.io) and notice that someone registered it 6 days ago for 1 year. It would cost about $300 USD to register for 10 years.

I was curious about using `codeberg.io` (to match Pages domain for `*.github.io` and `*.gitlab.io`) and notice that someone registered it 6 days ago for 1 year. It would cost [about $300 USD](https://tld-list.com/tld/io) to register for 10 years.
hw commented 2 months ago
Poster
Owner

cost about $300 USD [...]

yes, 3fold price was one of the reasons to decide against this and the many other alternatives, ... .org and .page are still the most cost-efficient options.

Namegrabbing seems common these days, we also get regular emails from domain scammers trying to re-sell us country-specific grabs.

> cost about $300 USD [...] yes, 3fold price was one of the reasons to decide against this and the many other alternatives, ... .org and .page are still the most cost-efficient options. Namegrabbing seems common these days, we also get regular emails from domain scammers trying to re-sell us country-specific grabs.
fnetX commented 2 months ago
Poster
Collaborator

What's the issue with dots in the username? This sounds possible ... is it related to your webserver stack?

What's the issue with dots in the username? This sounds possible ... is it related to your webserver stack?
hw commented 2 months ago
Poster
Owner

SSL certificate name does not match, don't know if there is a workaround for this. We are using a wildcard certificate *.codeberg.page, and browsers somehow do not match this to *.*.codeberg.page, not sure why...

SSL certificate name does not match, don't know if there is a workaround for this. We are using a wildcard certificate `*.codeberg.page`, and browsers somehow do not match this to `*.*.codeberg.page`, not sure why...
fnetX commented 2 months ago
Poster
Collaborator

Hmm well, yeah it technically requires more wildcard certificates or something like Caddy's HTTPS on demand feature, which actually obtains SSL certs for the domains when required ... :-)

Hmm well, yeah it technically requires more wildcard certificates or something like Caddy's HTTPS on demand feature, which actually obtains SSL certs for the domains when required ... :-)
ojn commented 1 month ago
Poster

Regarding .io domains and why I might be a bad idea to use it for your project, yarmo wrote a good blog post on this: https://yarmo.eu/post/no-io-yes-xyz

The only difficulty with .page domain is that it is relatively obscure domain ending, the eu domain should be easier to remember because it has been around for much longer.

Regarding .io domains and why I might be a bad idea to use it for your project, yarmo wrote a good blog post on this: https://yarmo.eu/post/no-io-yes-xyz The only difficulty with .page domain is that it is relatively obscure domain ending, the eu domain should be easier to remember because it has been around for much longer.
Sign in to join this conversation.
Loading…
There is no content yet.