Recherche avancée

Sur d’autres sites (4155)

• Anomalie #4012 : pipeline post_insertion n’affiche pas toutes les valeurs insérées

  9 octobre 2017, par Peet du

  ok ok !

  Donc lors de la création d’une nouvelle instance d’un objet, SPIP fait les choses en deux temps.

  1er temps¶

  objet_inserer() va ’préparer’ la nouvelle instance et tenter, si les champs existent dans l’objet, d’enregistrer les valeurs de :
  

  [’id_rubrique’]
  [’id_secteur’]
  [’lang’]
  [’langue_choisie’]
  [’statut’]
  [’date’]
  

  Donc au mieux le pipeline post_insertion renvoi un tableau contenant l’id de l’objet + le tableau des champs ci-dessus et leurs valeurs.

  2e temps¶

  si objet_inserer() renvoie bien un id_objet, objet_modifier() va lui enregistrer le reste, c’est à dire les valeurs correspondants aux champs déclarés comme editables dans plugins/base/mon_objet.php

  Il faut donc utiliser le pipeline post_edition si on veut pouvoir lire une des valeurs dites "editables".

  Donc pas d’anomalie, juste une incompréhension de la doc.

  On peut fermer le ticket
  ps : merci marcimat et jluc

• Anomalie #3894 : Jointures (erronées ?) avec les boucles documents et leurs critères

  27 janvier 2017, par marcimat ☺☮☯♫

  Jointure avec Documents / id_mot¶

  Par ailleurs pour les mots la jointure que montre tcharles est correcte justement. Cependant, là il cherche les mots clés présents sur les documents, ce qui contredit ce que je disais en 2012 là http://marcimat.magraine.net/SPIP-3-Documents-Mots :

  Ce que SPIP va décider lorsqu’il y a ambiguïté, c’est à dire comme ici (DOCUMENTS){id_mot} alors qu’il existe les 2 tables spip_documents_liens et spip_mots_liens, c’est qu’il va préférer interpréter cela comme une liaison sur la table de lien de la boucle en cours, c’est à dire sur spip_documents_liens, ce qui signifie donc que ça va retourner « les documents attachés à un mot clé »

  Donc, pour ce point, quelque part à un moment donné il y a eu un changement.

  Autres test.¶

  Je viens de remarquer que le problème survient dès lors qu’il y a plusieurs critères optionnels sur la boucle. De telle sorte les boucles suivantes ont une seule jointure sur spip_documents_liens :
  -
  -
  - (+ 1 jointure sur spip_mots_liens)

  C’est dès lors qu’on utilise plusieurs critères optionnels que les problèmes surviennent :
  -

  Si on appelle page=test&id_breve=1 (1er critère) on aura 1 seule jointure :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L1.id_objet = 1)
      AND (L1.objet = ’breve’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Si on appelle page=test&id_article=1 (2è critère) on aura 2 jointures :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.id_objet = 1)
      AND (L2.objet = ’article’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Si on appelle page=test&id_rubrique=1 (3è critère) on aura 2 jointures (le L s’incrémente à L3) :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L3.id_objet = 1)
      AND (L3.objet = ’rubrique’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Autrement dit, je pense que SPIP crée une jointure pour la possibilité d’avoir id_breve dans l’URL (L1), pareil pour id_article (L2), etc pour les suivantes.
  Le champ "vu" utilise la première jointure possible (toujours L1 du coup ici). Ensuite SPIP nettoie les jointures inutiles en fonction des paramètres d’environnement reçus, mais il ne peut enlever L1 car le champ "vu" l’utilise (alors qu’il faudrait qu’il utilise une autre jointure, L3 par exemple si id_rubrique dans l’env, et enlever L1).

• Anomalie #4129 (En cours) : Echec de la première connexion des utilisateurs LDAP et non création d...

  11 avril 2018, par Franck R

  version de SPIP : 3.2.1 [23954]
  version de PHP : 5.6.33
  version de MySQL : 14.14

  Jusqu’à il n’y a pas si longtemps (désolé pour l’imprécision, on ajoute pas des utilisateurs si fréquemment), les utilisateurs LDAP pouvaient s’authentifier sur SPIP et l’utilisateur SPIP était créé dans la base de donnée. J’ai remarqué récemment que les nouveaux arrivants ne pouvaient plus s’authentifier, et donc créer leur compte, de cette manière.

  Problème¶

  Ce problème a été remarqué sur le site en production mis à jour en 3.2.1, ainsi que sur une installation de test 3.2.1 propre (attention au bug de config LDAP ).

  1. Le site SPIP est configuré pour utiliser l’authentification LDAP ;
  2. Un nouvel utilisateur est créé dans le LDAP ;
  3. Il se connecte au site SPIP avec ses identifiants LDAP ;
  4. La connexion échoue systématiquement.

  La demande #3824 offre une solution avec _AUTORISER_AUTH_FAIBLE mais elle ne me semble pas satisfaisante sachant que LDAP est configurable à l’installation de SPIP, le mode par défaut devrait assurer que l’on puisse se connecter.

  Workaround¶

  Il y a au moins deux solutions qui fonctionnent :

  1. La création de l’utilisateur à la main dans la base de donnée permet à l’utilisateur de se connecter (insert into spip_auteurs ...)
  2. Mettre define ('_AUTORISER_AUTH_FAIBLE', true);

  Analyse¶

  Lors de la toute première authentification d’un utilisateur inconnu de SPIP, le mot de passe est envoyé sécurisé par défaut (hachage réalisé par le javascript avec les aleas actuel/futur). Seulement l’authentification LDAP requiert le mot de passe en clair. Lorsque l’utilisateur existe déjà et que la source est ldap, alors la sécurisation du mot de passe est désactivée (login.js, login-sha-min.js, le cadenas à côté du champ mot de passe disparait), d’où le fonctionnement du workaround 1. Si on désactive la sécurisation du mot de passe, workaround 2, alors cela fonctionne lors de la première authentification, et l’utilisateur est bien créé dans SPIP.

  Remarque¶

  L’envoi en clair n’est pas un gros problème dans notre cas, le site est forcé en HTTPS.