[stand by] HTTPS ?

Message par **Dominique** » 03 juil. 2016, 20:01

Dominique a écrit :Par contre, ça y est: une requête bloquée pour contenu non sécurisé !
Plus d'OSM-OVERPASS.

leaflet.js?1467562984:315 Mixed Content: The page at 'https://www.refuges.info/nav/433' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://api.openstreetmap.fr/oapi/interp ... 2811678675'. This request has been blocked; the content must be served over HTTPS.reload @ leaflet.js?1467562984:315fireEvent @ leaflet.js?1467562984:33_resetView @ leaflet.js?1467562984:70(anonymous function) @ leaflet.js?1467562984:164(anonymous function) @ leaflet.js?1467562984:27
leaflet.js?1467562984:315 XMLHttpRequest cannot load http://api.openstreetmap.fr/oapi/interp ... 2811678675. Failed to start loading.

Et pourtant, j'ai passé toutes les URL en HTTPS !
Je ne vois pas où il prend le HTTP qu'il envoie ?

C'est l'enfer HTTPS !!!

Bingo: c'était dans conf_privee.php (donc hors de mes recherches GIHUB)

Bon, maintenant, reste à comprendre pourquoi le résultat des recherches donne un lien http.
Tu disais que toutes les URL sont relatives dans WRI ??

Message par **sly** » 03 juil. 2016, 22:59

Dominique a écrit :Heu... je ne sais pas si c'est un gros travail, mais est il possible d'avoir https://dom.refuges.info , ... ?

Fait

Message par **sly** » 03 juil. 2016, 23:04

Dominique a écrit : C'est l'enfer HTTPS !!!

Ouais !
Pour moi, tout fonctionne très bien en http (j'utilise un navigateur qui ne me prive pas de ma liberté) j'avoue bien honteusement que ma motivation pour faire plaisir à chrome est tout en bas de la pile de mes priorités.

Message par **sly** » 03 juil. 2016, 23:15

Dominique a écrit : Bon, maintenant, reste à comprendre pourquoi le résultat des recherches donne un lien http.

La fonction qui génère un lien vers un point possède une option "lien local/lien avec schéma http://" la recherche n'activait pas le lien local (qui n'est pas le par défaut)

Donc corrigé

Message par **Dominique** » 04 juil. 2016, 08:21

sly a écrit :Pour moi, tout fonctionne très bien en http (j'utilise un navigateur qui ne me prive pas de ma liberté) j'avoue bien honteusement que ma motivation pour faire plaisir à chrome est tout en bas de la pile de mes priorités.

Pas faux. Je me suis peut être précipité sur cette histoire de https. Il faut dire que ça m'a passablement énervé que GG se permette de me barrer une fonction sans me donner le choix ni prévenir.
Si une page https charge des données pas sures, il faut prévenir l'utilisateur mais pas tout arrêter au nom de je ne sais quoi !
M'enfin, je suis bien content quand même d'avoir fait le tour du pb et de proposer l’accès https. Comme dit Léo, il faut préparer la suite...

Je suis de plus en plus déçu par Chrome, notamment sur l'affichage sur un écran haute définition (une TV 4k) : il affiche des tailles de polices tout à fait fantaisistes, trop petites.
C'est décidé, je reviens à FF que j'avais délaissé parce que les fonctions de debug CSS étaient meilleurs sur Chrome. Mais ils se sont mis à niveau depuis.

J'ai optimisé l’accès aux couche cartes en appelant en priorité des images http quand la page est chargée en http, idem avec +s suite à la judicieuse remarque de SQFP.info.
Priorité à l'efficacité

Merci pour ton support.

Message par **Claude Mauguier** » 14 juil. 2016, 19:25

Juste en remarque annexe à votre débat http/https ; lorsque je charge un lien sur chemineur (WRI ne voulant pas de lien...), et lorsqu'il apparait en https, je scratche systématiquement le "s" final, car sinon le lien est inactif au clic et il faut copier==> coller dans le navigateur ==> cliquer, et pendant tout ce temps-là le café refroidit... ou le vin se réchauffe, ça dépend. Et on s'énerve.

Message par **Dominique** » 14 juil. 2016, 22:53

Je pense que c'est un sujet à traiter dans chemineur
(en+, ça marche chez moi)

Message par **Dominique** » 05 août 2016, 12:59

SQFP.info a écrit :Une remarque en passant :

dans des coins trèèès reculés où le réseau GSM est ultra-capricieux (devinez où ), l'utilisation du httpS ajoute une lenteur sensible (surplus de connexions à établir et de données à échanger...) quand ce n'est pas l'échec complet du chargement d'un site (du fait de connexions-déconnexions-pertes de signal-changement d'IP qui rendent la sécurisation invalide).

Donc le https, c'est bien, mangez-en tout plein ; mais pour des usages sur mobile dont on peut s'attendre qu'ils s'effectuent dans des coins à très bas débit, pour l'échange de données non sensibles et/ou "d'urgence", le simple http peut malgré tout rester de mise.

/ceci était un message de qqn qui s'est récemment surpris à maudire les serveurs qui forcent le passage en SSL/TLS.

Étant depuis 2 semaines dans un de ces coins paradisiaques trèèès reculés où le réseau GSM est ultra-capricieux (devinez où

), je confirme qu'il est très difficile, voire impossible d'accéder à des sites https (le grand G et le grandissime WRI inclus).
Et je vous passe FTP, VPN et autres protocoles GIT...
J'ai pourtant un magnifique relais HSDPA+, 100ms de latence juste en face !
Sorti de 4G, plus de salut !

Message par **sly** » 05 août 2016, 13:09

Dominique a écrit :je confirme qu'il est très difficile, voire impossible d'accéder à des sites https (le grand G et le grandissime WRI inclus).

Initialement je n'avais pas trop compris pourquoi, mais après cette lecture :
** lien cassé qui parlait de la latence liée à https **

ça commence à mieux s'expliquer.

Cela confirme qu'il est préférable que l'on garde bien, côte à côte, au moins pour la partie publique, le http et le https sans forcer le passage sur l'un ou l'autre.
(Cela inclus les parties javascript qui devraient pouvoir aller chercher par http / https selon que l'internaute est choisi initialement l'un ou l'autre)

Message par **Dominique** » 05 août 2016, 13:37

sly a écrit :Initialement je n'avais pas trop compris pourquoi, mais après cette lecture :
** lien cassé qui parlait de la latence liée à https **

La latence et les ack/nack ajoutés par SSL y sont certainement pour quelque chose mais n'expliquent pas tout. Le keep-alive et les caches (peut être quelque chose au niveau de l'accélération de la connexion au niveau du réseau) ont peut être une influence : à certains moments (très tôt le matin par ex) même un site en https est extraordinairement rapide. Plus tard, part en tempo de connexion.
Et puis j'ai 100ms de latence end2end... pas si mal pourtant !

Message par **Dominique** » 13 nov. 2016, 14:29

Help SLY
Le certificat a expiré.
Peux tu faire quelque chose ?
Merci

Message par **sly** » 13 nov. 2016, 15:00

Dominique a écrit : Le certificat a expiré.

T'es Sûr ?

Dans le certificat pour https://www.refuges.info je liste ça :
Validity
Not Before: Sep 20 20:28:00 2016 GMT
Not After : Dec 19 20:28:00 2016 GMT

Avec firefox, ça se confirme, et pis je n'ai pas d'alerte

Message par **Dominique** » 13 nov. 2016, 17:49

Ups ! J'ai oublié les www
https://refuges.info

Message par **sly** » 13 nov. 2016, 18:40

Dominique a écrit :Ups ! J'ai oublié les www
https://refuges.info :oops:

En réservant le certificat let's encrypt je n'avais pas fais attention à ce qu'il n'était valable que pour www.refuges.info mais pas pour refuges.info

(Je suis habitué aux certifs payant comme celui de chez gandi à 12 € /an : https://www.gandi.net/ssl/standard#single inclus automatiquement les adresses avec et sans le www je n'ai donc pas fait attention)

Après un combat un peu plus poussé j'arrive à préciser que je veux un certif pour www.refuges.info et refuges.info en même temps.
Pour au final avoir un redirection vers http://www.refuges.info à cause du .htaccess
Bon, après un combat encore plus poussé j'arrive à avoir une redirection de https://refuges.info vers https://www.refuges.info

Ouf...

Message par **Dominique** » 13 nov. 2016, 20:32

Ha! pas mal

Le truc, c'est que j'ai utilisé les cartes de WRI en portfolio sur une réponse à appel d'offre que je ne peux plus modifier et que j'avais besoin de https pour démontrer la géolocalisation.
Merci pour le coup de main