The gopherjs website should use https.

[dmitshur]

Now that Let's Encrypt makes it possible to create automated SSL/TLS certificates for free, is there anything stopping us from having https://www.gopherjs.org and https://www.gopherjs.org/playground/?

/cc @neelance

[dmitshur]

Or is it blocking on isaacs/github#156?

[broady]

Use CloudFlare?

[dmitshur]

I'm fine with using CloudFlare, but I don't know how it's meant to be used with GitHub Pages.

Googling for github pages cloudflare finds this recent article:

https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/

Thanks for the suggestion!

[steveoc64]

Was OK on https (IFAICR)

Currently showing an error. Did you end up using CloudFlare in the end, or sticking with LetsEncrypt ?

[dmitshur]

I don't think it ever worked. There wasn't any action taken yet.

[r-l-x]

Could we make it work at https://gopherjs.github.io/playground/ until github supports HTTPS for custom domains ? Right now, this redirects to http://www.gopherjs.org/playground but if we could avoid this redirection, that would be a first step.

Then the connection to the snippet server would also have do be done over HTTPS in order to avoid mixed content errors, but there is also a certificate problem with this server: https://snippets.gopherjs.org presents a certificate issued for gotools.org and www.gotools.org instead of snippets.gopherjs.org.

[dmitshur]

Then the connection to the snippet server would also have do be done over HTTPS in order to avoid mixed content errors, but there is also a certificate problem with this server:

That's not a blocking problem, I can make snippet server support HTTPS as soon as the first step is done.

Could we make it work at https://gopherjs.github.io/playground/ until github supports HTTPS for custom domains ?

Isn't that what this issue is about? Do you know how that can be done? I don't know of a way. It's GitHub Pages, which I don't know how to make use HTTPS.

Edit: Ah, I didn't notice that you mentioned https://gopherjs.github.io/playground/, which is not the same as https://www.gopherjs.org/playground/ which the original issue was about.

[dmitshur]

Oh, apparently there's been an update at isaacs/github#156 since I created this issue in 2015. There's now:

https://github.com/blog/2186-https-for-github-pages

So it should be possible, at least for https://gopherjs.github.io/playground/!

The only (minor?) issue with that is that it's not the canonical URL of the playground.

[neelance]

https://help.github.com/articles/securing-your-github-pages-site-with-https/ says HTTPS is not supported for GitHub Pages using custom domains..

I would not be opposed to dropping the custom domain.

[r-l-x]

Apparently the redirection https://gopherjs.github.io/playground => http://www.gopherjs.org/playground occurs as soon as a custom domain is set: https://help.github.com/articles/custom-domain-redirects-for-github-pages-sites/
It does not seem possible to disable it while keeping the custom domain.

A few points to consider:

• Once/If the custom domain is disabled and we switch to gopherjs.github.io/playground, HTTPS may be enforced by GitHub (see https://help.github.com/articles/securing-your-github-pages-site-with-https/) and right now this would break the playground because of mixed content and wrong certificate for snippets.gopherjs.org. It could a good idea to fix those 2 problems first (This shouldn't break anything in the current playground, it's not a problem to load HTTPS resources on a HTTP page).
• It would be nice that the old URLs still redirect to the new playground address (http://www.gopherjs.org/playground/#/FOO => http://gopherjs.github.io/playground/#/FOO). I saw the following page describing a way to have custom redirect: https://help.github.com/articles/redirects-on-github-pages/. But given the fact the opposite redirection (http://gopherjs.github.io/playground=>http://www.gopherjs.org/playground) is in place right now, we have to be careful not to create a redirection loop.

[dmitshur]

It could a good idea to fix those 2 problems first (This shouldn't break anything in the current playground, it's not a problem to load HTTPS resources on a HTTP page).

It would take me a few minutes to fix that... Ok, might as well. I've done that. Now https://snippets.gopherjs.org/p/hy-CTQOoiM and http://snippets.gopherjs.org/p/hy-CTQOoiM both work.

Before we move forward, I'm also not extremely attached to the http://www.gopherjs.org domain name (also because I don't like the www. prefix in front) and I'm okay with https://gopherjs.github.io. That said, I do feel that gopherjs.org/playground feels nice and I'm not sure if losing that as the canonical playground URL is a good idea...

[dmitshur]

it's not a problem to load HTTPS resources on a HTTP page

Oh, is that so? Then I'd happily drop http support for snippets.gopherjs.org (by having it redirect to https).

The only reason I made snippet.gopherjs.org work over HTTP is because I thought we had to. I actually had to go out of my way to make it work (my HTTP router is otherwise nothing more than a redirector to HTTPS).

[r-l-x]

Oh, is that so?

Yes, I can confirm this point. Mixed content only applies to HTTP resources loaded from a HTTPS page, not the other way around. Here are a few references:
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content
http://stackoverflow.com/q/20516584

[dmitshur]

Thank you. I'll make a PR (edit: made #62) to update playground to always use HTTPS to access snippet store, since it sounds like we can make that part of the upgrade seamlessly now in a completely backwards compatible way. Then I can get rid of the machinery for HTTP snippet server support. :D