Many (32) mixed content issue on main page

[TheZoker]

All map tiles are loaded via http, but should be loaded via https.

Easiest way would be to move these files from http://tiles.got.show/bg/... to https://got.show/tiles/bg/

Or alternatively add a lets encrypt script to the titles subdomain.

[sacdallago]

Those are just warnings... But let's see:

If you really want to make it that way, I only approve if the tiles are imported via git submodules on project C10's tiles. Otherwise we run into duplicating data in too many locations!

Or the much, much easier solution of changing the requests to https, as it is serviced already implemented. @mbandle @AlexBeischl @tPiffrader

Anyway, http requests are a fraction quicker than https requests, and I see no reason to have this on a security layer, really.

[TheZoker]

@sacdallago I just saw 32 warning spamming my console. And even if they are only warning, they should be fixed (in my opinion). That's also the reason, why we are not getting the little nice green lock in the browser bar:

[yashha]

Thats true ;)

[yashha]

And it would be no problem to change to https adresses

[sacdallago]

Also leaflet icons are fetched over http, so neither solution will solve the problem.

[bandle]

I'll fix this with the next pull. Related to https://github.com/Rostlab/JS16_ProjectC_Group10/issues/230

[sacdallago]

@mbandle could you set it as an option? In the configuration, for instance? Because it's not said that everyone will always service tiles on https :)

[sacdallago]

and the problem of leaflet fetching over http stays:

got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-icon.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-shadow.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-icon.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-shadow.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-icon.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-shadow.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-icon.png'. This content should also be served over HTTPS.
got.show/:1 Mixed Content: The page at 'https://got.show/' was loaded over HTTPS, but requested an insecure image 'http://cdn.leafletjs.com/leaflet/v0.7.7/images/marker-shadow.png'. This content should also be served over HTTPS.

[bandle]

@sacdallago :+1: I'll call it markerBasePath, This directory than has to contain these two images.

[sacdallago]

alrighty

[bandle]

Done. When changing this I actually realized that Group F also had the possibility to fix this.

[yashha]

I thought when somebody has to do this than we :( I haven't seen you post at that time

[yashha]

@mbandle Becareful now your map is down https://map.got.show/

[sacdallago]

OMG what happened?! I didn't even pull! :D Now I did, but it didn't solve the problem... Thanks good the map on the main page didn't crash. The hype over this portal is accumulating, careful with implementing new things :P

P.S.: your gh-pages version seems to be unaffected @mbandle @tPiffrader @AlexBeischl

[mammuth]

Sidenote: That's why using a deployment-flow like local -> staging -> production that is doing all the jobs automatically makes sense :wink:

I'd pee myself when I'd be on the production server and need to manually checkout the develop branch that has not been tested on the same environment, running some build commands by hand and hope everything goes well. :grin:

And no, I don't suggest adding it now. We missed that chance. It's just some bashing afterwards^^ If the site screws up, chances are high, that @sacdallago could have avoided it by putting some time into a proper deployment pipeline, as suggested. :stuck_out_tongue_winking_eye: :kissing_heart:

[sacdallago]

@mammuth :D if you have read @yassha 's message the error doesn't occur on your repo, it occurs on the map repo. Also: it occurs out of the blue after not pulling and even after pulling. For what I know: stable = older, and curated = more stable.

If anything, not auto-updating the stuff you stage is the safest way to avoid having unexpected behaviour.

Also: If you want to have a testing/staging server then the machine we are using now is wrong anyway, because I would never put testing code on the same machine where production is running.

Next semester you can be the PM of 40 constructing everything on the fly with limited resources and limited time :) I'm sure you will do a better job

[mammuth]

@sacdallago Nah, I wasn't following this issue, I wanted just to whine around a bit ^^ (Because I love well working and sexy CI pipelines).

For the case someone is interested in how cool deployment can be: (otherwise, just don't go ahead reading). At the teams I mostly work with, we're all using the same Vagrant VM for local development. This way there is never a "it worked on my machine" or "How do I get this working?".

Inside the Vagrant we have two environments:

• a normal local setup, which uses development servers and runtimes etc.
• a local environment (also with all debugging/development middlewares) that mimics the staging/production environment. In this environment we use the exact same setup as our staging and production environments (webservers, tasks, preprocessing, ...). So if it's working in this local environment, it's gonna work to 99% on staging as well.

Our* staging and production* environments are the exact same boxes, but on different machines/app servers (as you mentioned as well :wink: ), and they also use different DB servers.. So if it works on staging it (more or less) needs work on production seamlessly.

Those staging/production environments are setup 100% by scripts. So their setup is completely reproducible. Need to scale horizontally (by hand)? Or need to change app-servers? Damn easy: Get the box up. Run the scripts. Add the machine to the CI.

Deployment works completely automatic: At one of the projects we have a single repo which contains multiple applications/sites (it's a multistore ecommerce shop with a corresponding administration-backend in which they can handle all those different shops. The shops share a lot of code (most of the logic, and most of the base templates), that's why we're handling them as one big application). We merge into the staging branch, tests are run automatically. If they fail, it won't continue. Otherwise it's going to deploy the different apps automatically on the their corresponding staging-machines. To deploy to production we simple merge the staging branch into a production branch and it's doing the tests + deploy.

Fancy, huh :wink: Don't tell my you don't get wet when reading this.

Thanks for your managing @sacdallago

Next semester you can be the PM of 40 constructing everything on the fly with limited resources and limited time :) I'm sure you will do a better job

I doubt I'd do a better job. You did a pretty good job managing such a bunch of (at first) uncoordinated young people! :+1: :kissing_heart: I think we all learned a lot during this seminar.

PS: Sorry for offtopic in this issue^^ Shame on me.

[sacdallago]

@mammuth I know vagrant :laughing: Why didn't you set this up then yourselves to begin with? :P

Also: Vagrant? So 2013... Why not docker! ACTUALLY, great idea!!!.. Can you set up a docker script in the project F repo? I will create the docker org!

Thx for the final note :P you are still very welcome to do PM next semester, it was not a rant!

[mammuth]

Vagrant? So 2013... Why not docker!

Because vagrant and docker are for different use-cases :wink: There is an awesome SO question, where the authors of both are answering! Check it out here: http://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment

Can you set up a docker script in the project F repo? I will create the docker org!

Puh, my experience with docker is pretty limited. Do you really think it makes sense do start doing such stuff after the release, where everything is already running fine in production?

[sacdallago]

The idea of docker is to have a "ready package". Similarly to Vagrant, except you don't carry the whole VM around, and it's really just about that service. In other words, while with the VM you would still kinda play around, Docker is: this is the "package", you can change some of the config (twitter keys, database, blablabla), but it can run out of the box without changing one thing, if the dependencies (mongo) are met. Think it as a .deb package. It is per definition the best thing to do after releases, in order to avoid the "it doesn't work on my machine" problem.

I know both Vagrant and Docker to some extent, I'm sorry I cannot put more thought into this, but I'm a bit overloaded :) anyway, it would be a nice to have, but definitely not 1.1