Version imprimable
Bonsoir,
je me connecte à ma bdd MySQL via les variables superglobales $_SERVER["PHP_AUTH_USER"] et $_SERVER["PHP_AUTH_PW"] (mysql_connect("localhost",$_SERVER["PHP_AUTH_USER"],$_SERVER["PHP_AUTH_PW"] )). Or dans ma fonction, ces variables superglobales sont vides (alors qu'elles sont bien affectées à un autre endroit) : une fois, l'authentification effectuée, ne sont-elles pas disponibles partout ?
Tu veux dire que tu les définis toi-même ? Ces variables sont censées être créées par le serveur.Citation:
Envoyé par laurentSc
http://fr2.php.net/reserved.variables.server.php
Si tu les redéfinis, leur valeur ne sera pas conservée d'un script à l'autre. $_SERVER ne fonctionne pas comme une session.
Peux-tu me dire en quelques mots comment tu as mis en œuvre ton authentification ? Est-ce que ta méthode ressemble à celle-ci ?
Désolé de t'avoir enduit d'horreur (j'aime bien ce jeu de mots :mouarf:)
Quand je disais "affectées", je pensais "le serveur les a positionnées" (donc affectées pour moi).
Voici l'authentification :et ailleurs :Code:
2
3
4
5
Code:
2
3
Sur la même page ?
Désolé si j'enfonce des portes ouvertes, mais voilà :roll: : les informations d'authentification sont envoyées par le client, comme s'il soumettait un formulaire HTML. Ça se fait en deux étapes :
1a. Le client non authentifié accède à ton script
1b. Ton script répond avec les header 401, etc.
2a. Le client envoie les informations d'authentification
2b. Là, ton script peut utiliser les variables PHP_AUTH_*
Dans les étapes 1a et 1b, les informations sont absentes, donc si tu fais tout dans le même script, et si tu ne l'as pas déjà fait, tu dois rajouter un test isset($_SERVER['PHP_AUTH_USER']) pour la partie qui gère 2a et 2b, comme dans cet exemple.
Sur la page que je viens de lier il y a également un passage un peu plus haut à propos du safe mode, qui pourrait poser problème. Jette un œil ;)
Je vais encore jouer sur les mots : jeter un oeil, OK mais le droit ou le gauche ? :mouarf:
Tu n'enfonces pas des portes ouvertes car je ne suis pas l'auteur de ce script, que je récupère donc, et je ne connaissais pas du tout la question. Donc le cours php avec les points 1a, 1b, 2a et 2b n'est pas inutile.
Je te pose donc des questions : les points 1a et 1b, OK, c'est le premier bout de code que j'ai donné, mais le point 2a, c'est quoi ? Le point 2b, OK ; chez moi, c'est le code que le client appelle. Et qui ne marchera que si les variables $_SERVER["PHP_AUTH_*"] existent, d'où le test du isset, mais si elles n'existent pas (ce qui est visiblement le cas vu qu'elles sont normalement utilisées et que le script échoue), on fait quoi ?
Et j'avoue ne pas avoir capté le couplet sur le safe mode...:(
Le serveur c'est la machine qui fait tourner PHP. Le client c'est le navigateur.
Au point 1b le navigateur reçoit un code HTTP 401. Il est programmé pour afficher dans ce cas une fenêtre à l'utilisateur, lui demandant des informations d'authentification. Une fois que l'utilisateur clique sur « Ok », ce sont ces informations que le navigateur envoie, dans une nouvelle requête au serveur, et c'est le point 2a.
Voici une page de test que j'ai nommée authentification.php. Dans un nouvel onglet, ouvre la console de ton navigateur (F12) et sélectionne l'onglet réseau, puis va sur la page de test en passant par ton localhost.
En ouvrant la page tu verras apparaître la fenêtre d'authentification, ainsi qu'une ligne GET dans la console. Cett ligne représente la requête que ton navigateur a adressée au serveur (étape 1a), ainsi que la réponse du server (étape 1b).Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Si tu fais « Annuler » à ce moment-là, le navigateur se contente de fermer la fenêtre, rien n'est envoyé au serveur.
Si tu remplis les champs et cliques sur « Ok », le navigateur envoie les informations (2a).
Le serveur le reçoit et c'est alors la partie restreinte du script PHP qui est exécutée : le serveur renvoie ce qui est produit par le var_dump (2b).
Une seconde ligne GET apparaît dans la console ; clique dessus et regarde les informations « en-têtes de la requête », il y a un nouvel en-tête par rapport à la requête précédente. Il s'agit de l'en-tête Authorization et il contient les informations d'authentifications encodées avec l'algorithme uuencode. NB : ce n'est pas un algorithme de chiffrage, les données ne sont pas protégées !
Le safe mode, je ne pourrais pas t'expliquer ce que c'est (ou plutôt ce que c'était) mieux que le manuel : safe mode. Il est probablement activé sur ton serveur si celui-ci est mutualisé et fait tourner une version de PHP pas à jour. Pour le savoir, regarde le phpinfo et recherche la chaîne « safe_mode ». Si elle est présente et que la valeur est « On » ça signifie que le safe mode est activé.
Si en plus d'avoir le safe mode activé, tu as un mécanisme d'authentification non PHP déjà en place (par exemple avec un .htaccess), alors PHP ne remplit pas les variables PHP_AUTH. C'est une malchance assez rare mais ça pourrait expliquer les symptômes. Pour vérifier s'il y a une authentification non PHP, fais var_dump($_SERVER['REMOTE_USER']);.
Bonsoir, je reviens vers toi (merci de m'aider). Bon ce n'est pas encore au point mais je suis en train de penser à un truc : si au lieu de ça, on faisait un formulaire html standard, puis que dans l'action le serveur comparait les données utilisateur/mot de passe entrées par l'utilisateur à des données stockées dans une bdd MySQL ? Ca ne reviendrait pas au même ?
Il y aurait des points communs, mais je pense que la solution formulaire + base de données est plus souple.
- Tu peux styler le formulaire comme tu veux ;
- c'est le serveur qui contrôle la session ;
- tu peux utiliser des données supplémentaires pour l'authentification, par exemple un token de sécurité.
Ce qui ne change pas en revanche, c'est que les données transitent toujours en clair. Dans une requête de formulaire, POST ou GET, il n'y a même pas de codage uuencode donc elles sont encore plus faciles à lire (*). Pour éviter ça, tu as deux solutions :
- te payer un certificat pour servir tes pages en https ;
- utiliser un certificat gratuit
Il existe des CA (Certificate Authority) gratuits mais ils sont marginalisés : les navigateurs n'incluent pas leurs certificats dans leur liste de confiance. Les visiteurs reçoivent alors une alerte de sécurité, hautement décourageante, alors que le certificat est parfaitement fonctionnel. Le site CAcert est, à juste titre, un bon exemple.- utiliser une bibliothèque de chiffrement côté client.
Pour être honnête je ne sais pas si ça existe, ni même si c'est raisonnable, car il s'agit en gros de reproduire le mécanisme https « à la main »...
(*) C'est aussi valable pour le cookie qui contient l'identifiant de session (SESSID), qui est envoyé à chaque requête.
Vu tes réponses, j'ai visiblement à faire à un connaisseur...
Que les identifiants soient visibles dans les en-têtes http ne me semble pas gênant vu que ça concerne un site intranet et non internet...
J'en suis finalement resté au script d'identification et non passé à un formulaire html et après avoir tenté sans succès ce code :j'ai pu corriger mon script pour qu'il n'utilise pas les variables $_SERVER['PHP_AUTH_*'].Code:
2
3
Ok !
Quelques mots à propos de ton sleep (pas de jeu de mots hein, je te vois venir) : il n'avait aucune chance de fonctionner.
D'abord, ce n'est pas exactement de l'attente active mais ça a les mêmes inconvénients : le thread alloué à ton script n'est pas réutilisable pendant la durée du sleep, et comme le nombre de threads est limité (20 en général), ton site peut devenir inaccessible pendant un pic de fréquentation. Voir ce commentaire.
Ensuite, les variables de $_SERVER ne peuvent pas changer toutes seules pendant l'exécuction d'un script (sauf si ton script les modifie lui-même). Mettons que ton logiciel serveur est Apache par exemple. Quand il reçoit une requête concernant un fichier php, il est configuré pour appeler l'interpréteur PHP, et il lui passe en paramètre les caractéristiques de la requête. Entre autres, le tableau $_SERVER est construit à ce moment-là. L'interpréteur continue de tourner tant que la fin du script (ou une instruction exit) n'est pas atteinte. Et si le serveur reçoit une autre requête, il lance une nouvelle instance de l'interpréteur, dans un autre thread, avec un autre tableau $_SERVER.
Pour résumer : chaque instance d'exécution de ton script a son propre tableau $_SERVER.