Tâche #21310
Scénario #21250: Le paramétrage safe-search de youtube doit prendre en compte la nouvelle interface
Étudier le mode de filtrage safesearch sur la nouvelle interface Youtube
Historique
#1 Mis à jour par Scrum Master il y a plus de 6 ans
- Statut changé de Nouveau à En cours
#2 Mis à jour par Fabrice Barconnière il y a plus de 6 ans
- % réalisé changé de 0 à 50
Le safesearch est toujours forcé sur la nouvelle interface Youtube.
Le problème est que l'indication donnée dans les paramètre de recherche Youtube ne correspond pas. Elle est toujours modifiable mais reste sans effet dù à la réécriture d'URL faite par e2guardian.
#3 Mis à jour par Fabrice Barconnière il y a plus de 6 ans
- % réalisé changé de 50 à 100
- Restant à faire (heures) changé de 3.0 à 0.25
L'interface Youtube se base sur le cookie PREF pour voir si le mode de recherche restreint est activé ou non.
e2guardian réécrit ce cookie (headerregexplist) pour activer ce mode restreint.
Or en https, il ne peut pas voir le cookie, donc il ne peut pas le réécrire.
Seule la réécriture d'URL permet de forcer ce mode.
L'interface en https ne verra pas l'état du mode restreint.
J'ai supprimé les pas concernant Youtube dans le test PROXY-T02-001 et ajouté Youtube dans le TOTO FIXME des pré-requis
#4 Mis à jour par Fabrice Barconnière il y a plus de 6 ans
- Statut changé de En cours à Résolu
#5 Mis à jour par Scrum Master il y a plus de 6 ans
- Statut changé de Résolu à Fermé
- Restant à faire (heures) changé de 0.25 à 0.0
#6 Mis à jour par Jean-Marc MELET il y a plus de 6 ans
Bonjour,
En effet nous constatons depuis peu que le filtrage restreint introduit par https://dev-eole.ac-dijon.fr/issues/19510 sur youtube n'est plus débrayable, les recherches affichent toujours "Certains résultats ont été supprimés, car votre administrateur réseau a activé le mode restreint."
Par contre je ne comprends pas trop le comportement. Si je comprend bien depuis https://dev-eole.ac-dijon.fr/issues/7256#note-7 il y a un traitement sur le cookie destiné à forcer le mode restreint en HTTP en plus de la réécriture d'URL dans les regexp pour le HTTPS, du coup cela a bien pour but de forcer le mode restreint dans les 2 cas non? A ce sujet, je ne vois pas de URLMOD dans les logs de e2guardian lors des accès à youtube, cela ne devrait-il pas être le cas si les regexp sont appliquées?
L'autre chose qui m'échappe est pourquoi pouvions-nous contourner le traitement de eguardian avant en ajoutant le domaine youtube.com en sites autorisés et apparement plus maintenant? l'ajout de youtube.com en sites autorisés n'est-il pas censé bypasser ces réécritures d'URL et de cookies?
J'avoue qu'un peu d'explication plus complète là-dessus serait bienvenue.
#7 Mis à jour par Klaas TJEBBES il y a presque 6 ans
Réponse à la remarque de Jean-Marc MELET.
Ce problème n’apparaît pas avec 2.6 (E2G version 4 contre E2G version 3.5 sur Amon 2.5).
Réponse du développeur :
"Cette version complétement est obsolète maintenant, cap vers la v5, le système de filtrage est complètement réécrit."
Au moment d'écrire ce commentaire, il reste moins de 10 mois de support pour Amon 2.5.