Protéger une page avec les sessions.

[invite7e9df035]

Salut a tous et bonné en retard!!!
Je suis en train de réaliser un site et je souhaite protéger les pages à l'aide des sessions. J'ai trouvé un site sur internet (http://www.graphiks.net/cours/php/26...sions-php.html) qui explique bien sauf qu'il y a un passage que je ne comprend pas :

 <?php
$_admin_pass = md5('motdepasse'); // on crypt pour pouvoir comparer - plus securisé
$_admin_login = 'login';
?>  

D'où sort le ('motdepasse') et le 'login'. A quoi ils correspondent ?

Une autre question sur ce site : Des fois, ils met comme include

 include("./form.html") 
  

et d'autre fois

 include("form.html") 
  

. Y a t'il une différence entre les 2 ?

Merci d'avance.
-----

[invite4ad25ccf]

D'où sort le ('motdepasse') et le 'login'. A quoi ils correspondent ?

A vue de nez, ils viennent de la ou tu les as récupérés (généralement de $_POST['password'] et $_POST['username']), enfin tout dépend de ton code / type d'authentification (faite toi même, via une demande d'authentification (me suivient plus du http_header() qu'il faut envoyer pour cela) ...)

. Y a t'il une différence entre les 2 ?

Aucune. ./ désigne le répertoire courant, et s'il n'y a rien, c'est à partir du répertoire courant
Par contre, en général, on essaye de toujours garder une même facon de nommer les choses (variables, chemin d'accès), ca fait toujours plus propre dans le code

[invite770d9cfe]

<?php
$_admin_pass = md5('motdepasse'); // on crypt pour pouvoir comparer - plus securisé
$_admin_login = 'login';
?>

A mon avis, l'auteur a fait une erreur de ne pas expliciter ce qui aurait du l'être : 'motdepasse' et 'login' sont des chaînes au pif ; avec

<?php
$_admin_pass = md5('toto'); // on crypt pour pouvoir comparer - plus securisé
$_admin_login = 'Ginette';
?>

...ça marcherait aussi bien. En fait à l'ouverture de la session, tu dois créer tes propres clés (un mot de passe que tu vas crypter et un login) qui vont aller se stocker au départ dans le dossier des sessions du serveur. Ensuite, toutes tes pages protégées devront commencer par vérifier le contenu de la session. S'il n'y a rien ou si ça ne correspond pas, c'est que l'utilisateur a attaqué directement une de tes pages protégées.