Open mojodna opened 8 years ago
We recently enabled SSL as well on our sites. The https://letsencrypt.org/ initiative could help, with free certificates and automated renewals...
b.tile.stamen.com issues noted in #77
I updated a map to work over HTTPS but the Fastly URL for the JS library (https://github.com/stamen/maps.stamen.com/blob/master/index.html#L453) doesn't load the tiles through HTTPS the way the next line suggests. I had to download the file, modify it, and serve it locally.
I also had to modify it differently than the page instructs. Replacing http://tile.stamen.com
with //stamen-tiles-{s}.a.ssl.fastly.net/
results in the JS generating links with two periods such as https://stamen-tiles-b..a.ssl.fastly.net/
and the tiles fail to load. It had to be replaced with //stamen-tiles-{s}a.ssl.fastly.net/
without the extra period to work.
This would be much friendlier if the files served on maps.stamen.com and Fastly were already protocol-agnostic. Is there any downside to making it protocol-agnostic?
maps.stamen.com should support HTTPS. Period. That it facilitates the incorporation of the Braintree donation form is an added bonus.
However, it's not as simple as getting an SSL cert for maps.stamen.com and configuring it. For mixed-content reasons, all of the map tiles (and everything else) also need to be served over HTTPS.
We can (and probably should) use the existing Fastly SSL endpoint for HTTPS tiles. The alternative is to pay Fastly money to SSL-enable *.tile.stamen.com.
Terrain may further complicate things, as newly-rendered tiles are served from a Cloudfront endpoint (*.b.tile.stamen.com, where
b
stands for "bucket") after redirection that doesn't currently have a matching SSL certificate.