Le client Subversion passe la plupart de son temps à gérer des copies de travail. Cependant, quand il a besoin d'informations disponibles dans un dépôt distant, il envoie une requête sur le réseau et le serveur lui répond. Les détails du protocole réseau sont cachés à l'utilisateur : le client essaie d'accéder à une URL et, suivant le format de cette URL, utilise un protocole particulier pour contacter le serveur (voir URL du dépôt).

Quand le serveur reçoit une requête d'un client, il demande souvent au client de s'identifier. Il envoie un défi d'authentification vers le client et le client répond en fournissant les éléments d'authentification au serveur. Une fois cette authentification terminée, le serveur répond à la requête originale du client. Remarquez que ce fonctionnement est différent de celui de CVS où le client envoie systématiquement au préalable ses identifiants de connexion (procédure de « log in »), avant même de formuler la moindre requête. Dans Subversion, le serveur requiert explicitement l'authentification du client (par un défi d'authentification) au moment approprié, au lieu que ce soit le client qui s'authentifie a priori. Certaines opérations sont donc effectuées plus élégamment. Par exemple, si un serveur est configuré pour laisser tout le monde accéder au dépôt en lecture, alors le serveur n'envoie jamais de défi d'authentification quand un client tente un svn checkout.

Si une requête d'un client conduit à la création d'une nouvelle révision du dépôt (par exemple un svn commit), alors Subversion utilise le nom d'utilisateur fourni lors de la phase d'authentification comme auteur de la révision. C'est-à-dire que le nom d'utilisateur est stocké dans la propriété svn:author de la nouvelle révision (voir la section intitulée « Propriétés dans Subversion »). Si le client n'a pas été authentifié (en d'autres termes, si le serveur n'a jamais envoyé de défi d'authentification), alors la propriété svn:author de la révision est vide.

Beaucoup de serveurs sont configurés pour demander une authentification à chaque requête. Ce serait particulièrement pénible pour les utilisateurs s'ils devaient taper leur mot de passe à chaque fois. Heureusement, le client Subversion a une solution : la mise en cache sur le disque des éléments d'authentification. Par défaut, si le client en ligne de commande s'authentifie avec succès auprès d'un serveur, le client sauvegarde les éléments d'authentification dans une zone privée propre à l'utilisateur (~/.subversion/auth/ sur les systèmes de type Unix ou %APPDATA%/Subversion/auth/ sur Windows) ; voir la section intitulée « Zone de configuration des exécutables » pour plus de détails). Les éléments d'authentification sont mis en cache sur le disque, classés suivant une combinaison du nom, du port et du domaine d'authentification du serveur.

Quand le client reçoit un défi d'authentification, il regarde d'abord s'il dispose des éléments appropriés dans le cache disque de l'utilisateur. Si ce n'est pas le cas, ou si les éléments conduisent à un échec lors de la tentative d'authentification, le client demande alors (c'est son comportement par défaut) à l'utilisateur les informations nécessaires.

Ici, le lecteur soucieux de sécurité va immédiatement commencer à s'inquiéter : « Mettre en cache des mots de passe sur le disque ? Quelle horreur ! Jamais ! »

Les développeurs de Subversion reconnaissent le bien fondé du problème et c'est pourquoi Subversion est capable de fonctionner avec les différents mécanismes offerts par le système d'exploitation et l'environnement de travail pour minimiser les risques de fuites d'information. Voici ce que cela veut dire sur les plateformes les plus courantes :

Bien sûr, si vous êtes complètement paranoïaque, aucun de ces mécanismes n'est parfait. Ainsi, pour ceux qui sont prêts à sacrifier le confort d'utilisation au profit de la sécurité absolue, Subversion fournit de nombreuses façons de désactiver le système de cache d'authentification.

Pour désactiver le système de cache pour une seule commande, utilisez l'option --no-auth-cache :

$ svn commit -F log_msg.txt --no-auth-cache
Domaine d'authentification : <svn://hote.exemple.com:3690> exemple de domaine
Nom d'utilisateur :  paul
Mot de passe pour 'paul' :

Ajout         nouveau_fichier
Transmission des données .
Révision 2324 propagée.

# le mot de passe n'a pas été mis dans le cache, donc la deuxième propagation
# nous redemandera le mot de passe

$ svn delete nouveau_fichier
$ svn commit -F nouveau_msg.txt
Domaine d'authentification : <svn://hote.exemple.com:3690> exemple de domaine
Nom d'utilisateur :  paul
…

Autrement, si vous voulez désactiver la mise en cache des éléments d'authentification de manière permanente, vous pouvez éditer le fichier config de votre zone de configuration et mettre l'option store-auth-creds à no. La mise en cache des éléments d'authentification est alors désactivée pour toutes les commandes Subversion que vous effectuez sur cet ordinateur. Ceci peut être étendu à l'ensemble des utilisateurs de l'ordinateur en modifiant la configuration globale de Subversion (voir la section intitulée « Agencement de la zone de configuration »).

[auth]
store-auth-creds = no

Il arrive que les utilisateurs veuillent effacer certains mots de passe du cache disque. Pour ce faire, vous devez vous rendre dans la zone auth/ et effacer manuellement le fichier de cache approprié. Les éléments d'authentification sont mis en cache dans des fichiers individuels ; si vous affichez chaque fichier, vous voyez des clés et des valeurs. La clé svn:realmstring décrit le domaine du serveur auquel est associé le fichier :

$ ls ~/.subversion/auth/svn.simple/
5671adf2865e267db74f09ba6f872c28
3893ed123b39500bca8a0b382839198e
5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8
username
V 3
paul
K 8
password
V 4
blah
K 15
svn:realmstring
V 45
<https://svn.domaine.com:443> Dépôt de Paul
END

Une fois le bon fichier trouvé, effacez-le.

Un dernier mot sur la façon dont svn gère l'authentification, avec un zoom sur les options --username et --password. Beaucoup de sous-commandes du client acceptent ces options, mais il est important de comprendre que l'utilisation de ces options n'envoie pas automatiquement les éléments d'authentification au serveur. Comme vu précédemment, le serveur demande explicitement l'authentification au client quand il estime que c'est nécessaire ; le client ne les envoie pas à sa convenance. Même si un nom d'utilisateur et/ou un mot de passe sont passés en option, ils ne sont envoyés au serveur que si celui-ci les demande. Ces options sont couramment utilisées pour s'authentifier sous un nom d'utilisateur différent de celui que Subversion aurait choisi par défaut (comme votre nom de compte système), ou quand on ne veut pas de commande interactive (par exemple, utilisation de la commande svn dans un script).

En résumé, voici comment un client Subversion se comporte quand il reçoit un défi d'authentification :

Si le client réussit à s'authentifier par l'une ou l'autre de ces méthodes, il essaie de mettre en cache les éléments d'authentification sur le disque (à moins que cette fonctionnalité ne soit désactivée, comme indiqué auparavant).