FluxBB.fr

Le site des utilisateurs francophones de FluxBB.

Recherche rapide

Gestion des utilisateurs MySql

La gestion des utilisateurs permet :

  1. de mettre en place un contrôle d'accès, c'est-à-dire déterminer si un utilisateur a le droit de se connecter à un serveur MySQL,
  2. si l'utilisateur a le droit de se connecter, déterminer ce qu'il peut y faire.

Le système de contrôle d'accès MySQL est spécifique par rapport à la norme SQL. Il lui manque la gestion des rôles mais ce contrôle distingue les utilisateurs selon l'endroit d'où ils se connectent. Il existe deux phases du contrôle d'accès :

  • la connexion au serveur,
  • la vérification des privilèges.

L'ensemble des informations relatives à la gestion des utilisateurs est stocké de manière relationnelle, en l'occurrence dans une base de données dédiée, nommée tout simplement mysql. La base de données mysql est l'une des deux bases créées automatiquement lors de l'installation de MySQL (l'autre étant information_schema). S'il est fortement déconseillé d'y faire la moindre modification de structure, nous pouvons y ajouter, modifier et supprimer des données, de deux manières différentes :

  • en utilisant les ordres DCL (Data Control Language) de MySQL, comme : Create User, Rename User, Drop User, Set Password, Grant, Revoke. C'est la méthode conseillée dans la plupart des cas.
  • en modifiant directement le contenu des tables avec les ordres « classiques » (Insert, Update, Delete). Cette méthode, très délicate, qui suppose de très bien connaître le système, est fortement déconseillée.

Pour vous connecter à un serveur MySQL, vous devez disposer d'un nom d'utilisateur et, le cas échéant, du mot de passe associé. La liste des utilisateurs autorisés, ainsi que leur éventuel mot de passe, correspond au contenu de la table user de la base mysql.

Notion de compte utilisateur

Si la plupart des SGBD caractérisent un compte par un nom d'utilisateur (souvent appelé login), MySQL prend en considération un paramètre supplémentaire : le nom (ou l'adresse IP) de la machine depuis laquelle l'utilisateur essaie de se connecter (appelée « hôte »). Un compte utilisateur est donc l'association entre un nom d'utilisateur et l'hôte de cet utilisateur. Ainsi,on peut par exemple laisser root@localhost (le super administrateur travaillant directement sur le serveur) se connecter, et refuser root@provider.com (le super administrateur travaillant de chez lui, avec sa connexion Internet… ou un imposteur mal intentionné), ou bien le déclasser en utilisateur standard.

Créer un compte nommé

Nota : les commandes ci-dessous sont effectuées à partir de la « console » MySql aussi nommée ligne de commande MySQL. (Sous Wampserver, Icône, Clic gauche, MySql, Console MySql où il vous sera demandé d'entrer le mot de passe éventuellement défini pour root@localhost. (1) Nota : Les utilisateurs peuvent aussi être ajoutés, modifiés, supprimés via PhpMyAdmin, par l'option Privilèges. (2) Commencez par créer un compte pour accéder au serveur en local : Création d'un compte sans mot de passe :

CREATE USER 'moi'@'localhost' ;

Ou de manière moins formelle si les noms ne comportent ni espace, ni caractère spécial, ni joker :

CREATE USER moi@localhost ;

Si vous souhaitez accéder à MySQL depuis un autre ordinateur, il vous faut créer un autre compte. Si vous vous baladez d'un poste à l'autre, cela pourrait devenir vite laborieux ! Heureusement, vous pouvez utiliser le joker ”%” selon le degré d'ouverture que vous estimez sûr. Exemples d'hôtes (notez les apostrophes obligatoires pour utiliser le joker %)

Instruction de création de compte L'utilisateur moi pourra se connecter depuis…
CREATE USER moi@localhost Le serveur MySQL lui-même
CREATE USER moi@monordi L'ordinateur appelé monordi
CREATE USER moi@192.168.1.123 L'ordinateur dont l'IP est 192.168.1.123
CREATE USER moi@'l92.l68.%' N'importe quel ordinateur dont l'IP est de la classe 192.168
CREATE USER moi@'%.microapp.com' N'importe quel ordinateur du domaine microapp.com
CREATE USER moi@'%' N'importe quel ordinateur

Notez que la table user est la liste des comptes utilisateurs autorisés à se connecter, et qu'il n'existe pas de « liste noire » des comptes interdits. De même, les comptes ne peuvent pas être suspendus, désactivés ou verrouillés, mais seulement détruits (ce qui n'empêche nullement leur recréation).

Pièges de vocabulaire

ATTENTION Le vocabulaire du contrôle d'accès n'est pas toujours limpide. Voici quelques précisions utiles :

  • Le mot-clé user ne doit pas vous induire en erreur : ce qui est créé n'est pas un utilisateur repéré par son simple nom, mais un compte caractérisé par le couple nom/hôte. De la même manière, la documentation MySQL parle le plus souvent d'un utilisateur là où il serait moins ambigu d'utiliser le terme de compte.
  • Le terme «hôte », combiné avec le nom d'utilisateur, désigne l'ordinateur de l'utilisateur, alors que dans un autre contexte il s'agirait plutôt de l'ordinateur qui héberge le serveur MySQL. Supposez que l'utilisateur toto souhaite se connecter avec le client texte, depuis un ordinateur sous Windows nommé client, à un serveur MySQL nommé serveur. Il utilisera la commande suivante :

C: > mysql –user=toto –host=serveur. Il sera connecté comme étant toto@client.

  • Enfin, il ne faut pas confondre le compte avec la session. L'utilisateur ouvre une session en se connectant, et la referme en utilisant la commande Quit. Toutes les informations propres à la session (comme les variables de session ou les tables temporaires) sont alors effacées, tandis que les informations relatives au compte (comme le mot de passe ou les privilèges) persistent.

Les comptes anonymes

Pour le nom d'utilisateur, vous ne pouvez pas utiliser de joker. Il vous est par contre possible de créer des comptes d'utilisateurs anonymes, en indiquant une chaîne vide comme nom d'utilisateur : Création de deux comptes d'utilisateurs anonymes, l'un en local, l'autre depuis n'importe quel poste

  • CREATE USER @localhost, @'%' ,

Un compte anonyme permet de se connecter sans nom d'utilisateur, mais aussi avec un nom inconnu. Ainsi, avec les comptes créés ci-dessus, les deux connexions suivantes deviennent possibles : Lancement du client texte sous Windows, avec une connexion anonyme en local

  • C:> mysql –host=localhost

Idem, avec un nom d'utilisateur inexistant, qui sera considéré comme utilisateur anonyme

  • C:> mysql –user=nimportequi –host=localhost

Notez que si aucun nom d'utilisateur n'est fourni, MySQL en attribuera automatiquement un : sous Linux, ce sera le nom de l'utilisateur Linux en cours, et sous Windows, ce sera toujours ODBC.

Limites sur les noms d'utilisateurs

ATTENTION La colonne user de la table user est un Char (16) , c'est-à-dire que le nom d'utilisateur est limité à 16 caractères et que les espaces finaux ne comptent pas :

  • 'moi'@localhost et 'moi '@localhost représentent le même compte ;
  • par contre, 'm oi'@localhost est un utilisateur différent.

En installation standard, cette colonne est sensible à la casse : moi et MOI sont deux utilisateurs différents.

Les mots de passe

Les comptes créés comportent une faille de sécurité béante : ils ne sont protégés par aucun mot de passe. Tout le monde peut essayer de se connecter au serveur sous n'importe quel nom, et il sera possible de se connecter si un nom d'utilisateur n'a pas de mot de passe.

Affecter ou supprimer un mot de passe

Pour affecter un mot de passe à un compte déjà existant (ou changer le mot de passe d'un compte), il faut utiliser l'instruction Set Password (2) : Attribution d'un mot de passe avec SET PASSWORD et la fonction de cryptage PASSWORD()

  • SET PASSWORD FOR moi@localhost = PASSWORD('secret') ;

Il est préférable d'attribuer le mot de passe dès la création du compte : Création d'un compte protégé par mot de passe

  • CREATE USER tartempion@'%' IDENTIFIED BY 'sesame' ;

Si vous souhaitez supprimer un mot de passe afin d'ôter la protection du compte, il suffit d'utiliser Set Password en fournissant une chaîne vide à la place du mot de passe. N'importe quel utilisateur nommé peut changer ou supprimer son propre mot de passe, auquel cas la clause For est facultative :

À l'inverse, un utilisateur anonyme ne peut pas changer le mot de passe de son compte. Pour changer le mot de passe d'un autre compte que celui avec lequel vous êtes connecté, il faut disposer du privilège Update sur la base mysql. Comme root@localhost dispose de tous les privilèges, vous n'avez pas de problème à attribuer des mots de passe.

Le cryptage des mots de passe

MySQL ne stocke pas les mots de passe en clair, mais sous forme cryptée, selon son propre algorithme de cryptage. La fonction de cryptage est déterministe mais irréversible. Autrement dit, le même mot de passe clair donnera toujours le même mot de passe crypté, mais il est impossible de retrouver le mot de passe clair à partir du mot de passe crypté.

En fait, MySQL ne connaît pas le mot de passe des utilisateurs, mais seulement sa version cryptée ! Les mots de passe cryptés sont, depuis MySQL 4.1, toujours constitués d'un astérisque suivi de 40 chiffres hexadécimaux. Ainsi, pour MySQL le mot de passe de moi@localhost n'est pas secret mais *14E65567ABDB5135DOCFD9A7083032C179A49EE7. Quand l'utilisateur tente de se connecter, MySQL crypte le mot de passe fourni et compare le résultat avec le mot de passe crypté stocké dans la table User. Si l'utilisateur a fourni secret, le cryptage donne à nouveau *14E65567ABDB5135DOCFD9A7083032C179A49EE7 et la connexion est acceptée. Sinon, elle est refusée. Si l'utilisateur perd son mot de passe, il n'existe aucun moyen de le retrouver. Il est par contre facile de lui en attribuer un nouveau.

Pour attribuer un mot de passe, vous pouvez toujours soit crypter un mot de passe en clair, soit fournir directement la version cryptée, mais avec des syntaxes différentes selon que vous utilisez Set Password ou Create User. Ainsi, les quatre instructions suivantes donnent le mot de passe secret à l'utilisateur lui@localhost : Avec la fonction de cryptage PASSWORD()

  • SET PASSWORD FOR lui@localhost = PASSWORD('secret')

En fournissant la version cryptée

  • SET PASSWORD FOR lui@localhost = '*14E65567ABDB5135DOCFD9A70B3032C179A49EE7';

La fonction PASSWORD() est implicite à la clause IDENTIFIED BY

  • CREATE USER lui@localhost IDENTIFIED BY 'secret' ;

Le mot-clé PASSWORD dans la clause IDENTIFIED BY permet de fournir directement la version cryptée

  • CREATE USER lui@localhost IDENTIFIED BY PASSWORD '*14E65567ABDB5135DOCFD9A7OB3032C179A49EE7' ;

Ces syntaxes peuvent être trompeuses, car la fonction Password( ) crypte, tandis que le mot-clé Password indique au contraire qu'il est inutile de crypter. Si l'administrateur peut attribuer un mot de passe déjà crypté à un utilisateur, l'utilisateur qui tente de se connecter ne peut par contre jamais indiquer qu'il fournit un mot de passe déjà crypté. S'il essaie malgré tout de se connecter avec le mot de passe crypté, celui-ci sera à nouveau crypté, et ne correspondra plus à celui qui est stocké dans la table User. Connaître un mot de passe crypté ne permet donc pas de se connecter à la place de l'utilisateur.

Ambiguïté des comptes

Les différents comptes créés coexistent, éventuellement avec des mots de passe ou des privilèges différents. Du fait des jokers et des connexions anonymes, il est fréquent qu'une tentative de connexion puisse correspondre à plusieurs comptes.

La préférence par spécificité

Voyez par exemple les comptes créés à ce jour par la lecture de la table des utilisateurs : Lecture de la table User :

SELECT User, Host, Password FROM mysql.User;

Résultat (vous pouvez avoir quelques comptes supplémentaires selon les options choisies lors de la configuration)

User Host Password
Root localhost
tartempion % *EE33294C97C42FFF14EA73AB81E428A6FC7B9A8B
Lui localhost *14E65567ABD85135DOCFD9A7083032C179A49EE7
%
Moi localhost *14E65567ABDB5135DOCFD9A70B3032C179A49EE7
Moi monordi
Moi 192.168.1.123
Moi 192.168.%
Moi %.microapp.com
Moi %
localhost

Si moi tente de se connecter en local, cela correspond non seulement à moi@localhost, mais aussi à moi@'%', @localhost, @'%'. Or, certains de ces comptes sont protégés par un mot de passe et d'autres non.

Comment MySQL choisit-il ?

  • MySQL choisit d'abord l'hôte exprimé de la façon la plus spécifique (donc localhost de préférence à %).
  • Il choisit ensuite le nom d'utilisateur le plus spécifique (donc moi plutôt qu'un compte anonyme).

En l'occurrence, ce sera donc bien moi@localhost qui l'emportera ; moi devra donc utiliser son mot de passe.

Que se passe-t-il si tartempion tente de se connecter en local avec son mot de passe ?

  • C:>mysql –user=tartempion –password=sesame –host=localhost
  • ERROR 1045 (28000): Access denied for user 'tartempion'@'localhost' (using password : YES)

En effet, en appliquant les règles ci-dessus, MySQL préfère un compte anonyme sur un hôte précis à un compte nommé sur un hôte générique. C'est donc ' '@localhost, sans mot de passe, qui l'emporte sur tartempion@'%'.

Les « privilèges » accordés aux utilisateurs.

On parle de privilèges et non pas de droits, octroyès (GRANT) par un administrateur, qui peuvent être révoqués (REVOKE) à tout moment. Cet administrateur ne peut exercer ce rôle d'octroi de privilèges que parce qu'il dispose lui-même des privilèges idoines qui lui ont été octroyés par le “superadministrateur” root@localhost.

Les privilèges globaux

Les privilèges globaux sont associés à un compte, sans considération de base de données ni de table.

Privilège Description
CREATE USER Permet de créer, de supprimer et de renommer (Rename User) des utilisateurs et également de révoquer tous les privilèges d'un utilisateur (Revoke All), mais pas de les rétablir
FILE Permet d'utiliser les commandes Select… Into Outfile et Load Data Infile etc.

Octroi du privilège CREATE USER au niveau global GRANT CREATE USER ON *.* TO tartempion@'%' ;

Les privilèges liés à des objets

Les autres privilèges sont liés à des objets : bases de données, tables, colonnes, routines, vues.

Privilège Description Objets privilégiés
SELECT Permet de lire les données des Base, table, vue, colonnes d'une table avec une requête colonne
UPDATE Permet de modifier les données des colonnes d'une table (requête Update)
INSERT Permet d'ajouter des lignes à une table (requête Insert)
DELETE Permet de supprimer des lignes d'une Base, table, vue table (Delete, Truncate)
etc.

La hiérarchie des autorisations

Un privilège change de portée selon le niveau auquel il est accordé. MySQL définit quatre niveaux de privilège :

  • niveau global (privilèges renseignés dans la table user de la base mysql) ;
  • niveau base de données (table db);
  • niveau table (table tables_priv) ou routine (procs_priv)
  • niveau colonne (table columns_priv)

Prenons l'exemple du privilège Select :

Syntaxe et portée de GRANT selon le niveau de privilège

Niveau Exemple Portée
Global Grant Select On *.* To tartempion@'%' Toutes les colonnes de toutes les tables de toutes les bases
Base Grant Select On Bibli.* To tartempion@'%' Toutes les colonnes de toutes les tables de la base Bibli
Table Grant Select On Bibli.Lecteurs To tartempion@'%' Toutes les colonnes de la table Lecteurs de la base Bibli
Colonne Grant Select (Nom, Prenom) On Bibli.Lecteurs To tartempion@'%' Les colonnes Nom et Prenom de la table Lecteurs de la base Bibli

Les différents niveaux de privilège sont amenés à entrer en conflit. Que se passe-t-il si, par exemple, tartempion@'%' dispose du privilège Select sur la table Lecteurs, mais pas sur les colonnes Nom et Prenom de cette table ? MySQL donne toujours la préférence à l'autorisation. Autrement dit, il suffit de posséder un privilège à n'importe quel niveau pour pouvoir l'exercer sur ce niveau et tous les niveaux inférieurs.

Nous venons de voir la création des comptes utilisateurs et l'octroi des privilèges via la console MySql. Les ajouts, suppressions, modifications des comptes utilisateurs ainsi que l'octroi, la révocation ou la modification des privilèges peuvent être effectués par PhpMyadmin via l'option Privilèges.(2)

Dans la plupart des cas et jusqu'à maintenant, vous avez, pour la plupart, implicitement utilisé le compte de « super administrateur root » (root@localhost), avec ou sans mot de passe selon les options choisies lors de la configuration. Ce « super administrateur » possède tous les privilèges possibles sur les bases de données, même la suppression totale des tables et bases quelles qu'elles soient, c'est pourquoi il faut éviter, même en utilisation locale et sauf cas très particuliers, de se connecter à MySql en tant que root@localhost. Il faut créer un ou plusieurs comptes utilisateurs, avec mot de passe, et ne possédant que les privilèges strictement nécessaires, par exemple seulement : SELECT, INSERT, UPDATE, DELETE

On ne peut pas, en une seule fois, créer un utilisateur et lui donner des privilèges sur une base de données. Il faut d'abord créer l'utilisateur (Page d'accueil PhpMyadmin puis lien Privilèges, Puis Ajouter un utilisateur) en ne lui donnant aucun privilège global. Ensuite, on pourra choisir sur quelle base et quels privilèges ou uniquement une ou plusieurs tables ou même sur un ou plusieurs champs d'une ou plusieurs tables.

Quand un utilisateur se connecte à phpMyAdmin, son nom d'utilisateur et son mot de passe sont passés directement à MySQL. phpMyAdmin ne fait pas de gestion d'utilisateurs par lui-même (autre que de permettre la manipulation de l'information du compte utilisateur MySQL) ; tous les utilisateurs doivent être des utilisateurs MySQL valides.

Architecture d'accès MySQL sur le WEB : 3-tier

Supposons que Tartempion soit chez lui et consulte le site web d'une bibliothèque depuis son navigateur. Les pages lui sont envoyées par le serveur web de la bibliothèque, qui en puise le contenu dans la base de données et le met en forme : c'est le principe d'une architecture 3-tier, appliqué au web (3-tier peut se traduire par « trois étages » ou « trois niveaux », mais certainement pas par « trois tiers » !).

Le modèle 3-tier se compose de :

  1. L'étage inférieur, appelé le « niveau présentation », représente l'ordinateur de l'internaute, qui affiche les pages avec son navigateur (et qui peut exécuter des scripts dits côté client comme du JavaScript, activant des menus déroulants ou divers effets graphiques).
  2. L'étage du milieu, appelé le « niveau application » ou parfois « niveau métier » (business level) est constitué d'un serveur web (géré par un logiciel comme Apache ou IIS) et doté d'un moteur PHP. Le serveur web s'occupe de l'interaction avec l'utilisateur (recevoir les clics et renvoyer les pages HTML correspondantes) et demande au moteur PHP d'exécuter ses scripts côté serveur afin de construire dynamiquement certaines pages ou parties de page. Pour cela, PHP va interroger l'étage suivant.
  3. L'étage supérieur, appelé le « niveau données », représente le serveur MySQL qui reçoit les requêtes du moteur PHP et y répond. Il ne s'occupe pas des pages web, mais simplement de la persistance des données et de leur exploitation.

Il n'y a donc aucune relation directe entre l'internaute et MySQL. Tout passe par l'intermédiaire du moteur PHP. À l'inverse, quand vous vous connectez à MySQL avec le client texte, vous êtes en architecture 2-tier client/serveur. Si de plus vous faites cela sur l'ordinateur où est installé MySQL (celui que MySQL considère comme localhost), les 2 niveaux sont hébergés par la même machine.

Dit autrement, le modèle 3-tier implique deux relations client/serveur :

  1. Le navigateur web est le client du serveur d'application.
  2. Le serveur d'application, à son tour, se connecte au serveur de données en tant que client.

Politiques d'accès au serveur MySQL

Comme MySQL vérifie le mot de passe et les privilèges selon la machine de son client, l'architecture 3-tier a pour conséquence que les internautes sont toujours considérés comme hébergés par le serveur d'application. Autrement dit, quand un lecteur consulte le catalogue de la bibliothèque de chez lui, MySQL le considère comme lecteur@serveurdappli et non lecteur@ordiperso, ni lecteur@fournisseurdacces.

Cela permet à MySQL de reconnaître les utilisateurs qui passent par l'interface web (ou du moins par le serveur web) de ceux qui tenteraient une connexion directe. L'administrateur peut ainsi accorder ou refuser les privilèges en connaissance de cause. Pour que PHP puisse se connecter à MySQL de manière sécurisée, le développeur PHP et l'administrateur MySQL doivent choisir entre deux méthodes d'accès :

  1. Si le site web ne demande pas aux internautes de s'identifier, ou s'ils doivent de toute façon avoir tous des privilèges identiques, on créera et on utilisera un compte générique comme siteweb@serveurdappli.
  2. Si les internautes doivent s'identifier, et s'ils reçoivent des privilèges différents selon cette identification, on pourra connecter le moteur PHP en relayant leur nom et mot de passe auprès de MySQL. Cela donnera des comptes individuels comme tartempion@serveurdappli.

La seconde méthode suppose une gestion plus lourde, utilisateur par utilisateur. Elle évite par contre de devoir conserver un mot de passe MySQL sur le serveur PHP, puisque ce sont les utilisateurs qui vont, à chaque fois, fournir leur mot de passe.

La première méthode, dite du compte applicatif, permet de ne gérer qu'un seul compte, mais demande des précautions particulières quand au stockage et à l'utilisation des informations de connexion (nom du compte, mot passe associé, nom du serveur de données et nom de la base de données). C'est cette méthode qui est utilisée par beaucoup d'hébergeurs en « mutualisé » où, en théorie pure, seul le mot de passe d'accès MySQL est indispensable, par exemple chez free.fr. Voir en (3) pourquoi il faut éviter de ne mettre que le mot de passe dans la configuration d'accès à MySQL.

Notes de renvoi

(1) Remarques sur les jeux de caractères entre le mode console MySql (Client texte) et le mode PhpMyAdmin (Client graphique) :

Par défaut, le client texte est configuré comme utilisant latin1. Or, sous Windows, le client texte est une application en ligne de commande, qui utilise un jeu de caractères cp850 des versions occidentales de Windows. Le fait que le client texte se déclare, à tort, comme Latin1 auprès de MySQL entraîne une erreur d'interprétation des caractères accentués ou spéciaux (ceux qui vous viennent de la base mais aussi ceux que vous frappez). En corrigeant les variables système afin qu'elles interprètent correctement le texte envoyé par MySQL, vous devriez corriger le problème :

SET NAMES cp850 ;

Doit-on faire un Set Names à chaque nouvelle session ? En théorie, il suffit de modifier l'option default-character-set de la section CLIENT du fichier my.ini. Toutefois, le cp850 n'étant pas un jeu compilé, tenter de l'utiliser comme option de départ empêche le client de démarrer. Il ne vous reste donc plus qu'à trouver une distribution de MySQL avec cp850 compilé. Le caractère compilé ou non d'un jeu de caractère se voit avec la commande Show Collation.

Les introducteurs

Une autre possibilité, surtout utilisée à titre de test ou pour résoudre certains cas difficiles, est d'indiquer à MySQL quel est le jeu de caractères d'une chaîne littérale, en la faisant précéder d'un introducteur :

SELECT latinl'été', utf8'été', cp850'été' ;

Une chaîne précédée d'un introducteur est envoyée telle quelle à MySQL, quelles que soient les variables @@character_set_client et @@character_set_connexion. MySQL l'interprète ensuite selon le jeu indiqué par l'introducteur, puis le renvoie. Vous ne verrez “été” écrit correctement que pour le jeu de caractère sous lequel vous êtes ; les autres cas vous donneront des affichages du genre Ä©tÄ© ou ?t? ou +®t+® ou ,t, Pour obtenir plus d'explications, voir l'article : MySQL : jeux de caractères (charset) et interclassement (collation)


(2) Les ajouts, modifications, suppressions d'utilisateurs et/ou de mots de passe peuvent être effectuées via PhpMyAdmin et l'onglet Privilèges en faisant attention que PhpMyAdmin prend en compte l'utilisateur éventuellement défini par le fichier phpmyadmin3.x.y/config.inc.php dont voici le contenu strictement indispensable :

<?php
//              Fichier config.inc.php pour PhpMyAdmin
// phpMyAdmin charge tout d'abord le fichier libraries/config.default.php
// puis écrase ces valeurs par celles du fichier config.inc.php.
// Il n'est donc pas nécessaire d'inclure toutes les valeurs dans ce fichier
// config.inc.php. N'y mettre que celle qui différent des valeurs par défaut.
/** Server(s) configuration */
$i = 0;
// Le tableau $cfg['Servers'] commence avec $cfg['Servers'][1]. Ne pas utiliser
// $cfg['Servers'][0]. Une entrée de configuration peut être désactivée en mettant
// host à ''. Pour obtenir plusieurs serveurs, il suffit de recopier ce qui suit
// en incluant l'incrémentation de $i.
$i++;
//Extension à utiliser (Par défaut mysql - peut être mysqli)
$cfg['Servers'][$i]['extension'] = 'mysql';
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 *  Type de connexion à PhpMyadmin                           *
 *  'http' : Nom utilisateur et mot de passe seront demandés *
 *           dans un formulaire lors de la connexion         *
 *  'config' : Nom utilisateur doit être mis dans 'user'     *
 *            et, si défini, mot de passe dans 'password'   */
$cfg['Servers'][$i]['auth_type'] = 'http';
$cfg['Servers'][$i]['user']      = ''; //Nom utilisateur
$cfg['Servers'][$i]['password']  = ''; //Mot de passe
 
//Formulaire de choix du "charset" aux exports/imports
$cfg['AllowAnywhereRecoding'] = TRUE;
 
// Supprime l'avertissement aux sujets des tables pmadb
$cfg['PmaNoRelation_DisableWarning'] = TRUE;
 
// Lien sur la documentation francophone
$cfg['MySQLManualBase'] = 'http://dev.mysql.com/doc/refman/5.0/fr/';
 
?>

(3) Les paramètres pour se connecter au serveur MySql afférent à un site http hébergé chez free.fr sont :

  • hôte : sql.free.fr
  • base : login_sql
  • user : login
  • password : mot_de_passe_sql (Qui peut être différent des mots de passe courriel et FTP)

Le login est le nom du site sans free.fr, par exemple si le site est “http://tartempion.free.fr/”, le login est “tartempion”. Si le login ne comporte pas de point (.) login_sql et login sont identiques. Dans le cas où le login comporte un point (.), par exemple “jean.tartempion”, ledit point DOIT être remplacé par un tiret bas (_) dans le login_sql, soit “jean_tartempion”.

Ceci pourrait se traduire, dans un fichier de configuration souvent nommé config.php par, entre autres, les lignes suivantes :

$db_host = 'sql.free.fr';
$db_name = 'login_sql';
$db_username = 'login';
$db_password = 'mot_de_passe_sql';

Chez free.fr (Et chez beaucoup dautres hébergeurs) on ne peut se connecter à la base de données ($db_name='login_sql') qu'à partir du site de même login ce qui fait que seul importe la validité du mot_de_passe_sql ; les noms $db_host, $db_name et $db_username n'ont aucune importance puisque le serveur MySql « sait » de quel login provient la demande de connexion. (C'est plutôt PHP qui le « sait », et qui force les valeurs). C'est pourquoi cette permissivité à vu fleurir tout et n'importe quoi dans les réponses aux paramètres de configuration d'accès à la base de données. Les « n'importe quoi » pour le nom de la base de données ($db_name) et d'hôte ($db_host) d'un fichier de configuration pour free.fr entrainera INÉVITABLEMENT des erreurs avec des scripts PHP qui iront vérifier l'existence ou l'état de tables. En effet, la requête : query('SHOW TABLE STATUS FROM `'.$db_name.'`') retournera une erreur si le nom de la base ($db_name) n'est pas “login_sql” puisque celle-ci ne sera pas trouvée.


Sources : Documentation MySql - Guide MySQL de Antoine Dinimant

 
mysql_gestion_utilisateurs.txt · Dernière modification: 2012/01/19 16:42 par Otomatic