Recherche avancée

Sur d’autres sites (12441)

• Evolution #3967 (Fermé) : Suivre les redirections http/https/proxy

  27 juin 2017, par goldstein goldstein

  De Willy Destrez (via spip-zone)

  pour faire suite à la discussion sur le forum http://forum.spip.net/fr_267345.html, je lance ce nouveau fil de discussion.

  Comme je le disais, le RSSI a effectué des tests et sa conclusion est la suivante :

  Alors pour faire court, le spip_loader construit ses connexions réseaux "à la main" (sans être péjoratif du tout) au travers d’appels de fsockopen.

  Le type de flux désiré (UDP, TCP, SSL/TLS) se fait au moment de l’ouverture de la socket réseau.
  fsockopen("www.ac-amiens.fr", 80, ... ) pour http
  fsockopen("udp ://dns.ac-amiens.fr", 53, ... ) pour DNS
  fsockopen("ssl ://www.ac-amiens.fr", 443, ... ) pour https
  fsockopen("tls ://smtp.ac-amiens.fr", 465, ... ) pour du smtps
  etc...

  Dans le cas d’un proxy, la connexion ne se fait pas vers le serveur de destination mais on ouvre une socket simple (tcp) vers le serveur proxy et ensuite, on effectue des demandes de connexions au "vrai" serveur au travers de cette socket.

  Là où ça se complique trop, c’est dans dans connexions "mixtes" : bascule http vers https lors d’une redirection (type 301 redirect) car le mode connexion pour un flux chiffré (TLS ou SSL) réclame de nombreuses opération supplémentaires (helo, handshake, vérification des certificats sources et destinations etc...) et toutes ces opérations ne sont pas implémentées dans les fonctions utilisées par spip_loader (et peut être spip aussi...).
  Bref, c’est une implémentation complète d’un client http qu’il faudrait intégrer.

  Ce qui était parfaitement suffisant dans le cas d’une connexion "en clair" se révèle maintenant inopérant.
  A moins de vouloir réinventer la roue, il semblerait bien plus efficace d’abandonner le mode "à la main" pour privilégier un client http plus complet (via la libcurl par exemple, exhaustive de ce point de vue).
  C’est, à ne pas douter, ce que les devs de spip vont prochaine devoir implémenter.

  En mode transitoire, la solution serait de ne pas faire de renvoi http=>https tant que les mises à jours ne sont pas disponibles, ou, à défaut, créer un miroir local des dépôts SPIP accessible en http.

  La dessus, il à modifier le spip_loader (fichier joint) pour prendre en charge les serveurs hébergés derrière un proxy.

  Cela permet de suivre un redirect (301) de http vers https qui n’est pas implémenter dans la version actuelle.

  Le script ne change rien à ceux qui n’ont pas php5-curl (ou php-curl en php7) ou qui n’ont pas de proxy de défini.

  Il continue ses investigations afin de permettre à nouveau le fonctionnement de la mise à jour des dépôts non fonctionnelle également (tout comme "mise à jour auto" de Couteau Suisse)
  Cordialement

• Anomalie #4160 (Nouveau) : Les rangs des mots ne sont pas affichés dans le sélecteur

  24 juillet 2018

  Bonjour,

  Les rangs (numéros de titre) des mots clefs ne sont pas affichés dans les listes déroulantes permettant de les affecter à des articles, rubriques... et autres objets.

  C’est une régression par rapport à SPIP 2.1 (je viens de vérifier).

  Ci-joint le patch pour SPIP 3.2.1 SVN.

  Si pas d’objection, je propose de commiter ça sur Dev, 3.2 et 3.1.

• Anomalie #4161 (Rejeté) : Manquent classes ajax sur les liens de pagination

  7 août 2018

  Bonjour,

  Dans le squelette ci-joint (testé en 3.3 dev), la pagination ajax ne se fait pas.

  Si je modifie le modèle de pagination en rajoutant ’ ajax’ après chaque ’lien_pagination’ (pour avoir ’lien_pagination ajax’), alors la pagination fonctionne comme attendue en ajax.

  Par ailleurs, je constate que la pagination fonctionne comme il faut dans le privé.
  Donc, où est le bug ?
  Est-ce qu’il manque quelque chose dans mon squelette ?