search

gopherjs / gopherjs.github.io

GopherJS Playground
https://gopherjs.github.io/playground/
23 stars 12 forks source link

The gopherjs website should use https. #37

Closed dmitshur closed 7 years ago

dmitshur commented 8 years ago

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 commented 8 years ago

Or is it blocking on https://github.com/isaacs/github/issues/156?

broady commented 8 years ago

Use CloudFlare?

dmitshur commented 8 years ago

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 commented 7 years ago

Was OK on https (IFAICR)

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

dmitshur commented 7 years ago

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

r-l-x commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

dmitshur commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

r-l-x commented 7 years ago

There is still a little problem (e.g. when you load https://www.gopherjs.org/playground/#/X98vxh8Y97 and accept the certificate warning): XMLHttpRequest cannot load https://snippets.gopherjs.org/p/X98vxh8Y97. The 'Access-Control-Allow-Origin' header has a value 'http://www.gopherjs.org' that is not equal to the supplied origin. Origin 'https://www.gopherjs.org' is therefore not allowed access. It looks like the snippet store only allows requests coming from http://www.gopherjs.org and not from https://www.gopherjs.org.

dmitshur commented 7 years ago

It looks like the snippet store only allows requests coming from http://www.gopherjs.org and not from https://www.gopherjs.org.

Yes, it currently does. See https://github.com/gopherjs/snippet-store/blob/af71d7b00e2cbe970396736b6135e90d890d9c1b/main.go#L23.

I'll change it to support both http://www.gopherjs.org and https://www.gopherjs.org.

dmitshur commented 7 years ago

It seems you can't statically set that header to multiple domains. Instead, you need to dynamically see where the request is coming from, and if it's one of the allowed domains, set Access-Control-Allow-Origin to that.

See http://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains.

dmitshur commented 7 years ago

I'm not sure if it's worth doing that now, since https://www.gopherjs.org cannot be practically used at this time (due to the certificate warning).

dmitshur commented 7 years ago

Although if I read the spec, https://www.w3.org/TR/cors/#access-control-allow-origin-response-header, suggests:

Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"

And origin-list-or-null is:

   origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
   origin-list         = serialized-origin *( SP serialized-origin )
   serialized-origin   = scheme "://" host [ ":" port ]
                       ; <scheme>, <host>, <port> from RFC 3986

So this should work:

Access-Control-Allow-Origin: http://www.gopherjs.org https://www.gopherjs.org

However, it might be still the case that not all browsers implement the spec fully, according to http://stackoverflow.com/a/12818477/622447.

Edit: I think that's not what the spec says. See http://stackoverflow.com/a/25517194/622447.

dmitshur commented 7 years ago

I think this issue is fully resolved now, is it not?

The website is fully https and redirects from http to https.

r-l-x commented 7 years ago

Yes, it's working well, great job !