les sessions

Coté public, toutes les pages de squelette appellent inc-public qui appelle inc-public-global qui appelle ecrire/inc_session.
Coté privé, les pages appellent inc.php3 qui appelle inc_auth qui appelle inc_session.

inc_session contient tout ce qu’il faut pour gérer une variable globale auteur_session contenant presque tout ce qu’on sait sur l’utilisateur courant.
inc_session initialise auteur_session à vide.

Coté privé, l’inclusion de inc_auth se termine par un appel à la fonction auth() qui permet de rendre l’identification obligatoire (sinon, redirect vers la page de login).

les formulaires

Les balises #LOGIN_PRIVE et #LOGIN_PUBLIC permettent d’afficher un formulaire de login. Cela génère en fait un include de inc-login.php3 suivi d’un appel à la fonction login.

C’est donc cette fonction qui contient le coeurdumachin ...

l’authentification

Il y en a plusieurs types de prévus :
  formulaire spip
  identification http par php
  .htaccess
  identification sur un ldap

• On commence par vérifier qu’il n’y a pas un login actif par un .htaccess
  • si oui, on récupère le login associé (mais s’il y a une entrée de .htaccess qui n’est pas en base ???° (bill) Heu, si j’ai bien compris, SPIP maintient .htpasswd et .htpasswd-admin et il ne fait que ca (ce qui est deja pas mal). Je crois que le fichier est reécrit à chaque fois qu’un utilisateur est créé, modifié ou supprimé.

• On commence par poser un cookie de test
  • S’il ne passe pas, on demande une identification http
    • on récupère directement login et password
  • Sinon, on propose un formulaire avec saisie du login.
    • S’il est trouvé en base, ou que l’identification ldap est autorisée, on demande un password
  • Si le login n’était pas en base (cas du ldap) on tente de se connecter au ldap avec ce login/password
  • Si le password est validé, on met la session en place

Implémentation

  /ecrire/inc_auth.php3 La fonction auth() fait tout le travail, et est un record spipesque à elle seul, 21 arguments en globals ! C’est ici que l’on vérifie les rubriques qu’il a le droit de gérer.
  /ecrire/inc_session.php3
  /spip_cookie.php3 L’appel des plugins d’authentification se fait ici, ainsi que la mise en place des cookies. Pour neutraliser la fonction rester authentifié quelques jours, il faut forcer la variable $session_remember à ’non’ et modifier dans inc-login.php3 l’affichage de la question dans le HTML (une recherche sur _T(’login_rester_identifie’) permet de trouver facilement).
  /spip_login.php3 Juste un pointeur pour afficher la page en 2 étapes, login, puis password. Ces deux étapes permettent de passer des arguments au javascript pour envoyer des données en md5 avec le sel.
  /inc-login.php3 Tout le code utilisé par /spip_login.php3.

Authentification LDAP

Spip utilise un plugin : Auth_ldap dans inc_auth_ldap.php3

Pour des raisons de simplicité, dans tous les cas, les informations de l’utilisateur sont stockées en base SQL pour une utilisation future. L’accés au LDAP se fait en lecture seule, et Spip essaye différentes combinaisons pour trouver les réglages du LDAP, et l’authentification est ensuite confiée au LDAP.

Authentification par challenge MD5

Pour la version Spip, l’authentification se fait avec un challenge MD5 avec ajout de sel. Le mot de passe peut être envoyé hashé par un javascript ou en clair.

et ça marche !

---