search

stamen / maps.stamen.com

Stamen Maps
http://maps.stamen.com
BSD 3-Clause "New" or "Revised" License
229 stars 34 forks source link

HTTPS #75

Open mojodna opened 8 years ago

mojodna commented 8 years ago

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.

gverbake commented 7 years ago

We recently enabled SSL as well on our sites. The https://letsencrypt.org/ initiative could help, with free certificates and automated renewals...

pemontto commented 7 years ago

b.tile.stamen.com issues noted in #77

techgique commented 7 years ago

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?