6.7 Contrôle d'accès, étape 1 : vérification de la connexion

Lorsque vous tentez de vous connecte à un serveur MySQL, le serveur accepte ou rejete votre tentative en fonction de votre identité, et de votre capacité à fournir le mot de passe correct. Dans le cas contraire, le serveur refuse complètement l'accès. Sinon, le serveur accepte la connexion, et passe en niveau 2, pour attendre les requêtes.

L'identité lors de la connexion est basé sur deux éléments :

• L'hôte depuis lequel vous vous connectez
• Votre nom d'utilisateur MySQL

La vérification de l'identité est faite en utilisant les trois champs d'identité de la table user (Host, User et Password). Le serveur n'acceptera une connexion que si il existe un enregistrement qui contienne votre hôte, votre nom d'utilisateur et votre mot de passe.

Les valeurs de la table user peuvent être fournies avec les propriétés suivante :

• Host peut être un nom d'hôte, ou une adresse IP ou 'localhost' pour indiquer la machine locale.
• Vous pouvez utilisez les caractères spéciaux ``%'' et ``_'' dans le champs Host.
• Host qui vaut '%' accepte tous les hôtes. Host vide est équivalent à to '%'. Notez que ces valeurs accepte n'importe quel hôte qui peut créer une connexion avec votre serveur !
• Les caractères spéciaux ne sont pas autorisés dans le champs User, mais vous pouvez le laisser vide, ce qui équivaudra à '%'. Si un enregistrement de la table user a un champs User vide, cet utilisateur sera considéré comme anonyme (utilisateur sans nom) plutôt qu'étant l'utilisateur avec le nom spécifié par le client. Cela signifie que l'utilisateur vide sera utilisé ultérieurement pour toutes les vérifications de droits, durant toute la connexion.
• Le champs Password peut être laissé vide. Cela ne signifie pas que n'importe quel mot de passe sera accepté, mais que l'utilisateur doit se connecter SANS mot de passe.

Les valeurs de Password qui ne sont pas vides représentent des mots de passe cryptés. MySQL ne conserve pas les mots de passe en clair, qui risqueraient ainsi d'être vu par n'importe qui. Lors de la connexion, le mot de passe fourni est crypté de la même manière que le mot de passe enregistré, et les deux valeurs sont comparées. Si les deux correspondent, le mot de passe fourni est le bon.

Les exemples suivants montrent différentes combinaisons des colonnes Host et User de la table user :

Etant donné que l'on peut utiliser des jokers dans le champs Host (i.e., '144.155.166.%' pour accepter tout un sous domaine), il est possible que quelqu'un essaie d'exploiter ceci en prenant comme nom 144.155.166.petaouschnock.com. Pour contrer ce genre de tentatives, MySQL n'accepte pas les noms d'hôtes qui commencent par des chiffres suivis d'un point. Ainsi, un hote du genre 1.2.foo.com ne pourra jamais être accepté. Seule les IP numériques peuvent utiliser un joker.

Une connexion entrante peut disposer de plusieurs entrées dans la table user. Par exemple, la connexion thomas.loc.gov de fred pouurait être acceptée plusieurs fois dans les exemples ci-dessus. Comment le serveur fait il pour choisir une entrée ou une autre ? Il résoud la question en triant les utilisateurs au moment du démarrage, et en lisant les entrées dans cet ordre trié. La première ligne qu'il trouve est alors la bonne.

La table user fonctionne comme ceci. Supposons qu'elle ressemble à ceci :

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

Lorsque le serveur lit la table, il classe les lignes en commencant par les hôtes les moins généraux ('%' dans la colonne Host signifie ``tous les hôtes'' et c'est le cas le plus général). Les lignes avec le même hôte sont classé en commencant par les utilisateurs les moins généraux (un utilisateur en blanc signifie ``tous les utilisateurs'' et c'est le cas le plus général. Une fois triée, la table ressemble à ceci :

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

Lors d'une connexion, le serveur recherche parmi les lignes classées, et utilise la première ligne qui aille et l'utilise. Si la connexion entrante vient de l'hôte localhost et de l'utilisateur jeffrey, les premières lignes, avec 'localhost' sont trouvées. Parmi celles-ci, la ligne avec le champs utilisateur vide correspond à la connexion. (la linge avec '%'/'jeffrey' était aussi correcte mais elle apparaît plus tard dans la table).

Voici un autre exemple :. fonctionne comme ceci. Supposons que la table user ressemble à ceci :

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

Une fois triée, la table ressemble à ceci :

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

Une connexion par l'hôte thomas.loc.gov et l'utilisateur jeffrey utilisera la première ligne, et la même connexion depuis whitehouse.gov utilisera la seconde.

Une erreur commune est de penser que pour un nom d'utilisateur donné, toutes les lignes qui nomme explicitement cet utilisateur seront utilisées en premier par le serveur pour accepter la connexion. Ceci est tout simplement faux. L'exemple précédent l'illustre bien : la connexion depuis thomas.loc.gov par jeffrey n'utilise par la ligne contenant l'utilisateur 'jeffrey' mais la ligne sans nom d'utilisateur.

Si vous avez des problèmes à vous connecte au serveur, afficher la table user et trier la à la main, pour savoir quelle ligne est la première a accepter votre connexion.