Je débute en php et je voudrai réaliser un contrôle d'entrée sur un site web
(espace réservé) pour une cinquantaine d'utilisateurs différents. Le tout
couplé à une base de donné Mysql. Un identifiant + un mot de passe par
utilisateur me permettrait de pouvoir vérifier si les pages web mises dans
cet espace réservé ont été visitées et par qui.
J'imagine assez bien une table du genre :
id
nom
password
date de connexion
Requête du type: id, nom, connecté depuis ...
Question : Existe-t-il ce type d'application toute faite ? (inutile de
réinventer la roue..)
Question : Existe-t-il ce type d'application toute faite ? (inutile de réinventer la roue..)
htaccess te permet d'obtenir le nom du consultant dans $HTTP_SERVER_VARS["REMOTE_USER"] Un script de gestion d'htaccess/htpasswd, ça doit exister...
CrazyCat
Marc wrote:
Question : Existe-t-il ce type d'application toute faite ? (inutile de réinventer la roue..)
Très franchement, même si ça existe, il vaut mieux le faire toi même, ça prends environ 1h pour un débutant et au moins tu sais ce que tu as. Si tu veux quelques indications pour le développement: page d'accueil => un formulaire login/password page de traitement => recherche en DB si le couple correspond OUI => session ou cookie contenant le login (surtout pas le password) NON => retour à l'accueil le OUI renvoit sur l'accueil protégé.
Toutes les pages de la section protégées doivent checker la session ou le cookie, si celle(celui)-ci n'est plus présent, tu repars sur l'accueil initial.
-- CrazyCat from C-P-F.org
Marc wrote:
Question : Existe-t-il ce type d'application toute faite ? (inutile de
réinventer la roue..)
Très franchement, même si ça existe, il vaut mieux le faire toi même, ça prends environ 1h pour un débutant et au moins tu sais ce que tu as.
Si tu veux quelques indications pour le développement:
page d'accueil => un formulaire login/password
page de traitement => recherche en DB si le couple correspond
OUI => session ou cookie contenant le login (surtout pas le password)
NON => retour à l'accueil
le OUI renvoit sur l'accueil protégé.
Toutes les pages de la section protégées doivent checker la session ou le cookie, si celle(celui)-ci n'est plus présent, tu repars sur l'accueil initial.
Question : Existe-t-il ce type d'application toute faite ? (inutile de réinventer la roue..)
Très franchement, même si ça existe, il vaut mieux le faire toi même, ça prends environ 1h pour un débutant et au moins tu sais ce que tu as. Si tu veux quelques indications pour le développement: page d'accueil => un formulaire login/password page de traitement => recherche en DB si le couple correspond OUI => session ou cookie contenant le login (surtout pas le password) NON => retour à l'accueil le OUI renvoit sur l'accueil protégé.
Toutes les pages de la section protégées doivent checker la session ou le cookie, si celle(celui)-ci n'est plus présent, tu repars sur l'accueil initial.
-- CrazyCat from C-P-F.org
philippe.rebouillat
Il existe aussi ce script, c'est très pratique car ca affiche une boite de log classique. Il suffit d'aller chercher dynamiquement dans ta base le $login et le $motdepasse pour en faire un acces multi-utilisateur
Philippe REBOUILLAT
// if we are using IIS, we need to set $PHP_AUTH_USER and $PHP_AUTH_PW if (substr($SERVER_SOFTWARE, 0, 9) == "Microsoft" && !isset($PHP_AUTH_USER) && !isset($PHP_AUTH_PW) && substr($HTTP_AUTHORIZATION, 0, 6) == "Basic " ) { list($PHP_AUTH_USER, $PHP_AUTH_PW) explode(":", base64_decode(substr($HTTP_AUTHORIZATION, 6))); }
// Replace this if statement with a database query or similar if ($PHP_AUTH_USER != "user" || $PHP_AUTH_PW != "motdepasse") { // visitor has not yet given details, or their // name and password combination are not correct
echo "<h1>Go Away!</h1>"; echo "You are not authorized to view this resource."; exit(); }
"Marc" a écrit dans le message de news: bdo16c$td4$
Bonjour,
Je débute en php et je voudrai réaliser un contrôle d'entrée sur un site web
(espace réservé) pour une cinquantaine d'utilisateurs différents. Le tout couplé à une base de donné Mysql. Un identifiant + un mot de passe par utilisateur me permettrait de pouvoir vérifier si les pages web mises dans cet espace réservé ont été visitées et par qui.
J'imagine assez bien une table du genre : id nom password date de connexion
Requête du type: id, nom, connecté depuis ...
Question : Existe-t-il ce type d'application toute faite ? (inutile de réinventer la roue..)
Merci Marc
Il existe aussi ce script, c'est très pratique car ca affiche une boite de
log classique. Il suffit d'aller chercher dynamiquement dans ta base le
$login et le $motdepasse pour en faire un acces multi-utilisateur
Philippe REBOUILLAT
// if we are using IIS, we need to set $PHP_AUTH_USER and $PHP_AUTH_PW
if (substr($SERVER_SOFTWARE, 0, 9) == "Microsoft" &&
!isset($PHP_AUTH_USER) &&
!isset($PHP_AUTH_PW) &&
substr($HTTP_AUTHORIZATION, 0, 6) == "Basic "
)
{
list($PHP_AUTH_USER, $PHP_AUTH_PW) explode(":", base64_decode(substr($HTTP_AUTHORIZATION, 6)));
}
// Replace this if statement with a database query or similar
if ($PHP_AUTH_USER != "user" || $PHP_AUTH_PW != "motdepasse")
{
// visitor has not yet given details, or their
// name and password combination are not correct
echo "<h1>Go Away!</h1>";
echo "You are not authorized to view this resource.";
exit();
}
"Marc" <mb59@free.fr> a écrit dans le message de news:
bdo16c$td4$1@news-reader2.wanadoo.fr...
Bonjour,
Je débute en php et je voudrai réaliser un contrôle d'entrée sur un site
web
(espace réservé) pour une cinquantaine d'utilisateurs différents. Le tout
couplé à une base de donné Mysql. Un identifiant + un mot de passe par
utilisateur me permettrait de pouvoir vérifier si les pages web mises dans
cet espace réservé ont été visitées et par qui.
J'imagine assez bien une table du genre :
id
nom
password
date de connexion
Requête du type: id, nom, connecté depuis ...
Question : Existe-t-il ce type d'application toute faite ? (inutile de
réinventer la roue..)
Il existe aussi ce script, c'est très pratique car ca affiche une boite de log classique. Il suffit d'aller chercher dynamiquement dans ta base le $login et le $motdepasse pour en faire un acces multi-utilisateur
Philippe REBOUILLAT
// if we are using IIS, we need to set $PHP_AUTH_USER and $PHP_AUTH_PW if (substr($SERVER_SOFTWARE, 0, 9) == "Microsoft" && !isset($PHP_AUTH_USER) && !isset($PHP_AUTH_PW) && substr($HTTP_AUTHORIZATION, 0, 6) == "Basic " ) { list($PHP_AUTH_USER, $PHP_AUTH_PW) explode(":", base64_decode(substr($HTTP_AUTHORIZATION, 6))); }
// Replace this if statement with a database query or similar if ($PHP_AUTH_USER != "user" || $PHP_AUTH_PW != "motdepasse") { // visitor has not yet given details, or their // name and password combination are not correct
echo "<h1>Go Away!</h1>"; echo "You are not authorized to view this resource."; exit(); }
"Marc" a écrit dans le message de news: bdo16c$td4$
Bonjour,
Je débute en php et je voudrai réaliser un contrôle d'entrée sur un site web
(espace réservé) pour une cinquantaine d'utilisateurs différents. Le tout couplé à une base de donné Mysql. Un identifiant + un mot de passe par utilisateur me permettrait de pouvoir vérifier si les pages web mises dans cet espace réservé ont été visitées et par qui.
J'imagine assez bien une table du genre : id nom password date de connexion
Requête du type: id, nom, connecté depuis ...
Question : Existe-t-il ce type d'application toute faite ? (inutile de réinventer la roue..)
Merci Marc
Marc
Très franchement, même si ça existe, il vaut mieux le faire toi même, ça prends environ 1h pour un débutant et au moins tu sais ce que tu as. Si tu veux quelques indications pour le développement: page d'accueil => un formulaire login/password page de traitement => recherche en DB si le couple correspond OUI => session ou cookie contenant le login (surtout pas le password) NON => retour à l'accueil le OUI renvoit sur l'accueil protégé.
oui, mais moi je suis un petit rusé et j'ai un moyen de poser
manuellement des variables de session, ou plutot des cookies. Et comme j'ai pu voir le contenu du cookie j'ai vu qu'un simple login suffisait a obtenir un acces au systeme. Je me dis, que si a la place de mon login je mets un autre ca va peut-etre marcher et youpiii, ca marche.
conclusion, il ne faut pas bricoler soit meme un systeme de login sauf si on a de la bouteille.
il existe des classes Pear qui font ce travail.
Très franchement, même si ça existe, il vaut mieux le faire toi même, ça prends environ 1h pour un débutant et au moins tu sais ce que tu as.
Si tu veux quelques indications pour le développement:
page d'accueil => un formulaire login/password
page de traitement => recherche en DB si le couple correspond
OUI => session ou cookie contenant le login (surtout pas le password)
NON => retour à l'accueil
le OUI renvoit sur l'accueil protégé.
oui, mais moi je suis un petit rusé et j'ai un moyen de poser
manuellement des variables de session, ou plutot des cookies.
Et comme j'ai pu voir le contenu du cookie j'ai vu qu'un simple
login suffisait a obtenir un acces au systeme. Je me dis, que
si a la place de mon login je mets un autre ca va peut-etre marcher
et youpiii, ca marche.
conclusion, il ne faut pas bricoler soit meme un systeme de login
sauf si on a de la bouteille.
Très franchement, même si ça existe, il vaut mieux le faire toi même, ça prends environ 1h pour un débutant et au moins tu sais ce que tu as. Si tu veux quelques indications pour le développement: page d'accueil => un formulaire login/password page de traitement => recherche en DB si le couple correspond OUI => session ou cookie contenant le login (surtout pas le password) NON => retour à l'accueil le OUI renvoit sur l'accueil protégé.
oui, mais moi je suis un petit rusé et j'ai un moyen de poser
manuellement des variables de session, ou plutot des cookies. Et comme j'ai pu voir le contenu du cookie j'ai vu qu'un simple login suffisait a obtenir un acces au systeme. Je me dis, que si a la place de mon login je mets un autre ca va peut-etre marcher et youpiii, ca marche.
conclusion, il ne faut pas bricoler soit meme un systeme de login sauf si on a de la bouteille.
Noter que d'après la doc PHP, le choix entre les syntaxes (1) et (2) ne semble pas dépendre que du type du serveur (Microsoft ou autre).
http://www.php.net/manual/fr/function.header.php
CrazyCat
Marc wrote:
OUI => session ou cookie contenant le login (surtout pas le password) oui, mais moi je suis un petit rusé et j'ai un moyen de poser
manuellement des variables de session, ou plutot des cookies. Et comme j'ai pu voir le contenu du cookie j'ai vu qu'un simple login suffisait a obtenir un acces au systeme. Je me dis, que si a la place de mon login je mets un autre ca va peut-etre marcher et youpiii, ca marche.
Ou est la partie signalant qu'il faut UNIQUEMENT le login? De plus, lorsqu'on est si malin, ou qu'on a de la bouteille comme moi, on sait que pour une partie protégée, on utilise une limitation dans le temps, genre 1/2h, et pourquoi pas un petit md5... Très franchement, c'est plus simple de perforer un htaccess que de passer à travers une de mes protections php, toute modestie mise a part :) -- CrazyCat from C-P-F.org
Marc wrote:
OUI => session ou cookie contenant le login (surtout pas le password)
oui, mais moi je suis un petit rusé et j'ai un moyen de poser
manuellement des variables de session, ou plutot des cookies.
Et comme j'ai pu voir le contenu du cookie j'ai vu qu'un simple
login suffisait a obtenir un acces au systeme. Je me dis, que
si a la place de mon login je mets un autre ca va peut-etre marcher
et youpiii, ca marche.
Ou est la partie signalant qu'il faut UNIQUEMENT le login?
De plus, lorsqu'on est si malin, ou qu'on a de la bouteille comme moi, on sait que pour une partie protégée, on utilise une limitation dans le temps, genre 1/2h, et pourquoi pas un petit md5...
Très franchement, c'est plus simple de perforer un htaccess que de passer à travers une de mes protections php, toute modestie mise a part :)
--
CrazyCat from C-P-F.org
OUI => session ou cookie contenant le login (surtout pas le password) oui, mais moi je suis un petit rusé et j'ai un moyen de poser
manuellement des variables de session, ou plutot des cookies. Et comme j'ai pu voir le contenu du cookie j'ai vu qu'un simple login suffisait a obtenir un acces au systeme. Je me dis, que si a la place de mon login je mets un autre ca va peut-etre marcher et youpiii, ca marche.
Ou est la partie signalant qu'il faut UNIQUEMENT le login? De plus, lorsqu'on est si malin, ou qu'on a de la bouteille comme moi, on sait que pour une partie protégée, on utilise une limitation dans le temps, genre 1/2h, et pourquoi pas un petit md5... Très franchement, c'est plus simple de perforer un htaccess que de passer à travers une de mes protections php, toute modestie mise a part :) -- CrazyCat from C-P-F.org
Marc
Ou est la partie signalant qu'il faut UNIQUEMENT le login? De plus, lorsqu'on est si malin, ou qu'on a de la bouteille comme moi, on sait que pour une partie protégée, on utilise une limitation dans le temps, genre 1/2h, et pourquoi pas un petit md5... Très franchement, c'est plus simple de perforer un htaccess que de passer à travers une de mes protections php, toute modestie mise a part :)
tres certainement,
tu es le seul a travail sur tes protections, et pour .htaccess, il s'agit d'une protection native au serveur Apache, serveur open source dont une equipe travaille dessus depuis des années. Je crois qu'on peut difficillement etre a la hauteur.
tu as a ton avantange le fait que tes sources ne sont peut-etre pas publics.
Ou est la partie signalant qu'il faut UNIQUEMENT le login?
De plus, lorsqu'on est si malin, ou qu'on a de la bouteille comme moi, on sait que pour une partie protégée, on utilise une limitation dans le temps, genre 1/2h, et pourquoi pas un petit md5...
Très franchement, c'est plus simple de perforer un htaccess que de passer à travers une de mes protections php, toute modestie mise a part :)
tres certainement,
tu es le seul a travail sur tes protections, et pour .htaccess, il s'agit d'une
protection native au serveur Apache, serveur open source dont une equipe travaille
dessus depuis des années. Je crois qu'on peut difficillement etre a la hauteur.
tu as a ton avantange le fait que tes sources ne sont peut-etre pas publics.
Ou est la partie signalant qu'il faut UNIQUEMENT le login? De plus, lorsqu'on est si malin, ou qu'on a de la bouteille comme moi, on sait que pour une partie protégée, on utilise une limitation dans le temps, genre 1/2h, et pourquoi pas un petit md5... Très franchement, c'est plus simple de perforer un htaccess que de passer à travers une de mes protections php, toute modestie mise a part :)
tres certainement,
tu es le seul a travail sur tes protections, et pour .htaccess, il s'agit d'une protection native au serveur Apache, serveur open source dont une equipe travaille dessus depuis des années. Je crois qu'on peut difficillement etre a la hauteur.
tu as a ton avantange le fait que tes sources ne sont peut-etre pas publics.
CrazyCat
Marc wrote:
tu es le seul a travail sur tes protections, et pour .htaccess, il s'agit d'une protection native au serveur Apache, serveur open source dont une equipe travaille dessus depuis des années. Je crois qu'on peut difficillement etre a la hauteur.
tu as a ton avantange le fait que tes sources ne sont peut-etre pas publics.
le .htaccess est avant tout fait pour protéger un répertoire, lorsqu'on veut protéger des accès à des pages bien particulières, et ce de manière variable (ajout de collaborateur dans un site), je reste persuadé qu'un système fait maison reste le plus simple, car il permet a l'administrateur du site de récupérer les mots de passes, ou de les changer. Bien entendu, certains systèmes tels que SPIP n'hésitent pas a créer et modifier un .htaccess, mais c'est pour donner accès a tout un répertoire. Dans MA logique, si un site est assez complexe, les "opérateurs" doivent pouvoir effectuer des actions particulières ailleurs que dans un seul répertoire, la solution de la session permet donc de garder pour un temps donné le statut de la personne, ce qui lui permet de modifier une partie du site sans accèder à une interface particulière. Les habitués de PHPNuke et consorts savent bien qu'un ayant droit peut modifier ou détruire un article en ligne, sans avoir a passer par l'interface d'admin. En bref et pour résumer, la protection doit être adaptée à son utilisation, chaque système ayant ses avantages et ses limites.
-- CrazyCat from C-P-F.org
Marc wrote:
tu es le seul a travail sur tes protections, et pour .htaccess, il
s'agit d'une
protection native au serveur Apache, serveur open source dont une
equipe travaille
dessus depuis des années. Je crois qu'on peut difficillement etre a
la hauteur.
tu as a ton avantange le fait que tes sources ne sont peut-etre pas
publics.
le .htaccess est avant tout fait pour protéger un répertoire, lorsqu'on veut protéger des accès à des pages bien particulières, et ce de manière variable (ajout de collaborateur dans un site), je reste persuadé qu'un système fait maison reste le plus simple, car il permet a l'administrateur du site de récupérer les mots de passes, ou de les changer.
Bien entendu, certains systèmes tels que SPIP n'hésitent pas a créer et modifier un .htaccess, mais c'est pour donner accès a tout un répertoire.
Dans MA logique, si un site est assez complexe, les "opérateurs" doivent pouvoir effectuer des actions particulières ailleurs que dans un seul répertoire, la solution de la session permet donc de garder pour un temps donné le statut de la personne, ce qui lui permet de modifier une partie du site sans accèder à une interface particulière.
Les habitués de PHPNuke et consorts savent bien qu'un ayant droit peut modifier ou détruire un article en ligne, sans avoir a passer par l'interface d'admin.
En bref et pour résumer, la protection doit être adaptée à son utilisation, chaque système ayant ses avantages et ses limites.
tu es le seul a travail sur tes protections, et pour .htaccess, il s'agit d'une protection native au serveur Apache, serveur open source dont une equipe travaille dessus depuis des années. Je crois qu'on peut difficillement etre a la hauteur.
tu as a ton avantange le fait que tes sources ne sont peut-etre pas publics.
le .htaccess est avant tout fait pour protéger un répertoire, lorsqu'on veut protéger des accès à des pages bien particulières, et ce de manière variable (ajout de collaborateur dans un site), je reste persuadé qu'un système fait maison reste le plus simple, car il permet a l'administrateur du site de récupérer les mots de passes, ou de les changer. Bien entendu, certains systèmes tels que SPIP n'hésitent pas a créer et modifier un .htaccess, mais c'est pour donner accès a tout un répertoire. Dans MA logique, si un site est assez complexe, les "opérateurs" doivent pouvoir effectuer des actions particulières ailleurs que dans un seul répertoire, la solution de la session permet donc de garder pour un temps donné le statut de la personne, ce qui lui permet de modifier une partie du site sans accèder à une interface particulière. Les habitués de PHPNuke et consorts savent bien qu'un ayant droit peut modifier ou détruire un article en ligne, sans avoir a passer par l'interface d'admin. En bref et pour résumer, la protection doit être adaptée à son utilisation, chaque système ayant ses avantages et ses limites.
