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

hw commented 2020年10月08日 09:58:51 +02:00

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.

circlebuilder commented 2020年10月08日 17:11:22 +02:00

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)

martijndeb commented 2020年10月08日 17:18:30 +02:00

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 2020年10月08日 21:25:14 +02:00

I like it, thanks for a great job.

I like it, thanks for a great job.

lhinderberger commented 2020年10月09日 12:17:08 +02:00

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.

ashimokawa commented 2020年10月10日 16:09:11 +02:00

@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.

circlebuilder commented 2020年10月11日 08:54:28 +02:00

@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.

lhinderberger commented 2020年10月11日 11:48:21 +02:00

@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 2020年10月11日 12:57:16 +02:00

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.

sql-workbench commented 2020年10月14日 14:34:55 +02:00

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.

garrison commented 2020年10月14日 18:44:22 +02:00

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 2020年11月01日 18:58:10 +01:00

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 2020年12月11日 17:10:35 +01:00

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 2020年12月11日 18:03:17 +01:00

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 2020年12月13日 01:21:59 +01:00

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 2020年12月13日 13:52:26 +01:00

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 2020年12月13日 15:53:28 +01:00

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 2021年01月21日 12:13:10 +01:00

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.

fnetX commented 2021年04月26日 23:49:26 +02:00

I think we got enough feedback here and discussion got off-topic in the end, the codeberg.page feature is now commonly accepted. There are some feature requests tracked elsewhere, so I'm closing this.

Thanks to everyone who joined the discussion.

I think we got enough feedback here and discussion got off-topic in the end, the codeberg.page feature is now commonly accepted. There are some feature requests tracked elsewhere, so I'm closing this. Thanks to everyone who joined the discussion.