Ils font de la pub pour leur bouton Aime jusque dans les liens !

Je serais extrêmement surpris qu'un Pebkac dans le genre n'ait pas encore été publié. Voir plusieurs.

C'est le coup classique de l'URL bloqué, mais pas de l'IP du site.
Très souvent, les organismes publique utilisent une proxy "user friendly" et sans aucune mise a jour.

Je dirais pas PEBKAC, mais plus un manque de moyen.

On risque d'avoir une recrudescence de ce type de PEBKAC vers mi-septembre / octobre, date approximative à laquelle les élèves de Seconde découvrent la faille dans le système.

Si tu as un moyen de connaitre toutes les IP d'un réseau social (ou d'un domaine en général) je suis preneur.

Il y a déjà eu 2 PEBKAC sur le fait que ce soit bloqué en HTTP et pas en HTTPS mais pas encore en version mobile, ou alors ma mémoire me fait défaut.

Ah alors si c'est différent ça va.

Oh wait.

Pourquoi ne pas bloquer directement .visagelivre. ? sur http et https ? Déjà ça limiterait le nombre de connexions. PS, je ne connait pas la syntaxe exate pour le faire, mais je doutes qu'un pare-feu ne comprenne pas d'expression rationnelle.

@ygnobl
Oui je suis bien d'accord mais c'était suite à l'argument de ctrl+alt+suppr comme quoi le blocage par IP est mieux que le blocage par URL (enfin, c'est comme ça que je le comprend).

Pour répondre à ta question, le blocage HTTP est très simple à mettre en place, par contre le blocage par HTTPS implique un décryptage (déchiffrage? Je ne sais jamais) des trames et ça c'est plus compliqué et surtout il faut prévenir les utilisateurs. Au passage il me semble que tu n'as pas le droit de décrypter une trame venant d'un site de banque comme tu le ferais pour une trame venant d'un réseau social.

@Kelgarath

Effectivement, ça n'a rien a voir, je n'aurais pas pensé aux versions mobiles des sites internet. :)

@seb : ça dépend de ce que tu veux dire.

Décryptage : retrouver le code original sans connaître la clé (ce qui n'est pas supposé arriver)
Déchiffrage : retrouver le code original avec la clé de chiffrement (ce que font les clients/serveur HTTPS)

Cela dit ça m'étonne car je crois me souvenir que certaines données, comme l'URL ou au moins le domaine sont transmises en clair, pour la simple et bonne raison que le serveur DNS doit recevoir cette information en clair.

Mais n'étant pas spécialiste je peux me planter.

@seb : Apparemment tu n'es pas le seul ;-)

L'url initiale est envoyée en clair. Heureusement car elle ne saurait être déchiffrée. Mais les url contenues dans le code HTML est lui codé. Par contre, en cliquant, la requête est envoyer en clair -même principe de communication avec les serveurs-.

@aDev, il semblerait logique que l'url ne soit pas cryptée pour permettre la résolution DNS, donc qu'un filtrage d'url soit applicable aussi sur https. Pour le filtrage par ip, par contre, je crois me souvenir qu'il y a des problèmes liés à la fois à l'effet de bord si plusieurs sites sont hébergés sur la même ip, et à la relative mobilité des adresses des serveurs (si un serveur ou un pool d'iceux est ajouté, avec une adresse différente)

Pour avoir un peu pratiqué un proxy "user friendly" assez courant dans les lycées ce n'est pas vraiment un question de mise à jour mais juste un problème de config :
en mettant http://www.domaine.com dans la liste noire https://www.domaine.com passera sans problème (de même que toto.domaine.com)
Par contre en mettant domaine.com toute adresse contenant domaine.com (donc http, https et sous-domaines) sera bloquée

Du coup le pebkac c'est le mec qui configure les filtres...