Bonjour Spols,

On a tout vérifié et testé 2 fois!
Le fichier qui génère les PW hashés n'a pas de relation avec sha1 (le code de la ligne avec sha1 est désactivé).
Oui nous partons des PW en clair avant de procéder avec le fichier de hachage sécur.
Les PW hashés changent à chaque fois que nous activons ce fichier (pas si sha1) et donc tous les PW hashés sont changés
en remplaçant les précédents dans le fichier fichieravecIDtabPWhashtabdate.txt qui est vérifié avant d'accès à l'espace membre.
Est-cela la raison? Faut-il changer le code de l'accès membre? Faut-il abandonner ce hachage sûr et rester à sha1?

Je n'en sais rien. Mais pour nous c'est le blocage total.

A te lire!

Merci, Seb

J'ai jamais utilisé ces fonctions, commence par la base comme le script demo de naroth pour t'assurer que tout fonctionne.

ensuite ajoute la complexité étape par étape.

Bonjour et merci vivement à vous Naroth et Spols,

Le fil s'arrêtera là si personne de pointu sur ce sujet ne vient à la rescousse!

En effet c'était une question de débutant pur mais la question qui paraissait facile pour des connaisseurs et n'étre qu'une transformation de sha1 à password_hash est bien plus compliquée que cela.

C'est la vie!

Re-merci à tous les 2 de votre intérêt!

Cordialement,

Seb

Salut, il y a une erreur dans le test :

if (!password_verify($champ[1],$passe1)) continue;

$champ[1] n'est pas le mot de passe en clair mais le hash sauvegardé dans le fichier. $champ[1] étant un hash et $passe1 également, ça ne peut pas fonctionner. Il faut vérifier le mot de passe en clair qui provient de $_POST avec le hash stocké dans le fichier. Soit :

if (!password_verify($_POST['password'], $champ[1])) continue;

EDIT :

// avec fichier de la forme
// login1\thash1\tdate1
// login2\thash2\tdate2
// ...

// et formulaire avec inputs login et password en post

foreach (file('fichieravecIDtabPWhashtabdate.txt') as $line) {
  list($login, $passwordHash, $date) = explode("\t", $line);
  
  if ($login == $_POST['login'] && password_verify($_POST['password'], $passwordHash)) {
    // connecter l'utilisateur
    // ...

    break ;
  }
}

Bonjour Saian,

Désolé de ne pas avoir répondu plus tôt, mais j'étais en voyage pendant les vacances scolaires.

Merci beaucoup d'avoir corrigé l'erreur de conception dans le code précédent, pas dans la codification.
Cela fait sens... mais cela ne marche pas encore.
Pour éviter de se prendre la tête, je vais mettre le dernier code sur lequel je travaille après ces commentaires (par rapport au précédent j'ai juste renommé les 2 variables en $nom2 et $passe2 pour les distinguer de $nom1 et $passe1 qui correspond au fichier en sha1 qui est toujours actif sur le site) et aussi, de même, en $membre2 et $id_mem2.
Avec ce code, sur Internet, si je tape ID et PW, il y a une page blanche qui apparaît (ni login_failed.php ni l'espace membre)
Avec ce code, sur Localhost de Wampserver, çà marche, j'accède à l'espace membres avec bon ID et PW, mais encore une fois c'est un trompe l'oeil car çà marche même avec un faux PW et un vrai ID (on accède au login_failed.php avec un faux ID et un vrai PW, ou avec avec un faux ID et un faux PW)
Donc il ya un os.
Voici le code (désolé je ne trouve pas sur le site comment le singulariser comme code php ce qui seriat mieux lisible)
if ((isset($_POST)) && (!empty($_POST)))
{
$redirect = "xxx.php";
$members_area = "espacemembre/acces.php";
$error = "login_failed.php";

// les codes sont-ils fournis ?
if ((!isset($_POST["ID"])) or (!isset($_POST["password"])))
{

header('Location: $error');
// include "$error";
die(""); //pour arrêter le script et l'empêcher d'afficher la page de partenariat
}

// les mettre en variable
$nom2=$_POST["ID"];
$passe2= password_hash($_POST["password"], PASSWORD_DEFAULT); //cryptage en password_hash

// les codes sont-ils vides ?
if (($nom2=="") or ($passe2==""))
{
header("Location: $error");
}
else
{

// verification des codes
$lignes=file("IDtabPWtabdate.txt");
/* membre = 0 => non membre
* membre = 1 => membre
* il faut ensuite vérifier la validité de l'abonnement
*/
$membre2=0;
$regex="#$nom2#";
foreach ($lignes as $lgn)
{
if(preg_match($regex,$lgn,$tab))
{
$champ = preg_split('#\t#',$lgn);
if (!password_verify($_POST['password'],$passe2)) continue;//Si le mot de passe n'est pas vérifié, on passe à la ligne suivante en cas de double login sinon un break marche aussi
$date = $champ[2];

if($date!== false)
{
$now = new Datetime();
$now = $now->format('Y-m-d');
$next = new DateTime($date);
if( $now < $date ) //si la date enregistrée est plus récente que la date actuelle
{
$membre2=1;
$id_mem2=$tab[1];
}
}


}// fin if(preg_match)
}//fin foreach

Merci encore,
A+
Seb

Salut, tu fais un password_verify avec le mot de passe fournis dans le formulaire de connexion ($_POST['password'], ça ok) et un hash généré à partir de ce même mot de passe, donc forcément c'est valide à chaque fois... tu dois utiliser le hash présent dans le fichier !

Comme je te le disais dans mon message précédent : Il faut vérifier le mot de passe en clair qui provient de $_POST avec le hash stocké dans le fichier.

La fonction password_hash n'est pas sensée être utilisée lors de la connexion.

Appuis toi sur le code que je t'ai mis en EDIT de mon message précédent, tu verras ça devrait aller beaucoup mieux si tu ne t'emmêles pas encore les pinceaux.

PS : il y a un bouton PHP dans la barre d'outils au dessus du champ d'édition pour mettre ton code dans la balise PHP afin qu'il s'affiche de manière lisible.

PPS : break et continue c'est pas la même chose. Le break sort de la boucle alors que le continue passe à l'index suivant.

Bonjour Saian,

Merci beaucoup de te mettre à mon niveau.

Tu m'as convaincu, c'est un souci de logique plus que de code, mais comme je ne suis pas l'auteur du code en sha1 j'ai bien du mal à en discerner la logique.

Mais essayons.

1- le membre tape son ID et PW
2- on les renomme en variables resp. nom2 et passe2 préalablement hashé en mode défaut (donc nom2 est inchangé et passe2 est, sauf erreur, une suite de chiffres et lettres commençant par $2y$10$)
3- on vérifie qu'ils ne sont pas vides
4- on appelle le fichier texte où sont stockés ID (= nom2) et PW comme une suite de chiffres et lettres commençant par $2y$10$ (là j'en suis sûr)
5- on teste sur le PW par if (!password_verify($_POST['password'],$passe2))
Et c'est peut-être là si je te suis bien qu'il y a une erreur puisque l'on compare des carottes et des poireaux.
Donc j'essaie if (!password_verify($champ[1],$passe2)) qui compare 2 suites de chiffres et lettres commençant sans doute par $2y$10$...
mais si je fais le test en local avec de bons ID et PW je suis renvoyé à login-failed
Mais tu écris qu'il faut comparer le mot de passe en clair qui provient de $_POST avec le hash stocké dans le fichier donc je suis obéissant (!!) et cela donne:
if (!password_verify($_POST['password'], $champ[1])) continue;
Et... tout baigne dans tous les cas de test!
Donc c'est bon (bravo), mais
je bloque, car je ne comprend pas... c'est peut-être dans la logique de la fonction password_verify (mais je regarde le manuel en Anglais et cela me dépasse!)
Bon donc c'est OK en local... mais, mais, sur Internet cela bloque!
Si je tape de bons ID et PW, il m'envoie sur une page totalement blanche (aucun texte, rien) avec comme URL celle du départ (pagededepart.php)!
Donc il y a encore un os (j'ai essayé de 2 manières dans le code de pagededepart.php avec les chemins http://wwww.xx.com/pagededepart.php ou simplement pagededepart.php et c'est pareil!
Peut-être une étourderie?

A+ donc

PS: merci pour le bouton 'code' (pas utile cette fois) la barre ne s'affichait pas sur l'ordi avant, maintenant c'est OK

Seb

Rebonjour Séb,

Sur le point 2, tu n'as pas besoin de hasher le mot de passe saisi par l'utilisateur car tu dois juste comparer le mot de passe en clair avec le hash trouvé dans le fichier, grâce à la fonction password_verify. Apparemment tu as bel et bien réussi à solutionner ce problème une fois cette logique comprise.

Maintenant il semble que tu ais un problème lors du passage en production... tu parles d'une page blanche, j'imagine donc que en production la page est en erreur. Le tout est donc de savoir quelle est cette erreur ? D'ailleurs si ça ne redirige pas vers la bonne page, peut être as tu simplement un problème avec le fichier des mots de passe qui ne contiendrait pas les bons hashs et donc le login ne fonctionnerait pas ?

EDIT

Oui j'imagine que tu ne dois pas bien comprendre le fonctionnement de password_hash et password_verify.

Le problème avec la fonction password_hash est qu'elle va te sortir à chaque fois que tu l'utilises un hash différent pour la même chaine de caractère en entrée. Tu ne peux donc pas hasher le mot de passe et le comparer à un autre hash généré auparavant car il seront différents. C'est la qu'entre en jeu la fonction password_verify qui permet justement de vérifier que le mot de passe en clair est valide pour le hash fourni (celui qui est stocké dans le fichier).

Si tu lis bien la documentation de password_verify c'est pourtant clair : password_verify — Vérifie qu'un mot de passe correspond à un hachage. Il n'est dit nul part que le mot de passe doit être haché avant d'être passé à la fonction et le premier exemple est simple et clair. Il faut juste que tu comprennes que le hash définit en dur dans l'exemple a été préalablement généré à l'aide de la fonction password_hash comme l'indique le commentaire en début de code. En l’occurrence dans ton cas, tu as généré ces hashs lorsque tu as rempli le fichier des comptes.

<?php
// Voir l'exemple fourni sur la page de la fonction password_hash()
// pour savoir d'où cela provient.
$hash = '$2y$07$BCryptRequires22Chrcte/VlQH0piJtjXl.0t1XkA8pw9dMXTpOq';

if (password_verify('rasmuslerdorf', $hash)) {
    echo 'Le mot de passe est valide !';
} else {
    echo 'Le mot de passe est invalide.';
}

La fonction sha1 elle fonctionne différemment, pour une même chaine en clair elle te sortira toujours le même hash et c'est pour cela que la logique est différente. Le hash généré étant tjrs le même pour une même chaine en entrée, dans ce cas tu peux hasher le mot de passe avec sha1 et comparer les hashs avec un simple ==.

Bonjour Saian,

Merci, tout est clair, sauf le souci, hélas...

J'avais bien vérifié la parfaite identité entre le fichier fichieravecIDtabPWhashtabdate.txt en local et sur le serveur Internet (ce que tu appelles 'production').
Pour chaque ligne dans ce fichier j'ai qqchose comme:
Identifiant-en-clair $2y$10$XdTIG0akikThAMADyblaY.5NF2c3MKfJtZQTY8MfuNpuDC29iVaxq 2020-01-31
Et quand le membre essaie de rentrer dans l'espace membre il tape
Identifiant-en-clair et Mot-de-passe-en-clair

Le souci c'est qu'en production j'arrive sur une page blanche et que tout est figé.
Cette page blanche est appelée http://www.xxx.com/pagededepart.php dnas l'URL du navigateur.

or je pars précisément de cette page et, au départ elle s'affiche bien avec les 2 cases de textes à remplir pour ID et PW, mais quand j'ai tapé les bons ID et PW j'atterris sur une page blanche avec la même URL et cela ne change rien si j'actualise la page!

Dans l'instruction du code j'ai en production (en local, idem mais en relatif, sans le http://www.xxx.com/)

$redirect = "http://www.xxx.com/pagededepart.php";
$members_area = "ttp://www.xxx.com/espacemembre/access.php";
$error = "ttp://www.xxx.com/login_failed.php";

donc tout se passe, en production, comme si je n'accédais pas à la variable members_area mais à redirect et qu'il ne sait plus afficher la pagededepart en redirection.

je ne vois pas plus...

une question (peut-être stupide) quand en production il procède la ligne de code:
$passe2= password_hash($_POST["password"], PASSWORD_DEFAULT);
est-ce que, si le PW en clair est bon, le résultat hashé va être identique à celui du fichier txt qui a été généré et figé par exemple 3 semaines plus tôt???
(en sha1 la question ne se posait pas car le PW en sha1 est invariable).

c'est vraiment compliqué... encore merci à toi!

Ah au fait si je teste en local avec les redirections complètes (http://etc) avec connexion à Internet, eh bien le local ne marche plus: avec un bon ID/PW j'atterris à la page d'index du site www.xxx.com et pas sur la pageditededepart!

A+
Seb

Salut, à mon sens tu as une erreur sur la production qui ne se produit pas sur le local. Comme tu as cette erreur, la page est blanche mais l'erreur n'est pas affichée car le php est configuré pour ne pas afficher les erreurs. Quelle est cette erreur ?

Ton formulaire étant sur pagededepart.php, quand tu soumets le formulaires je suppose que tu rappelles pagededepart.php qui lors de la soumission exécute le code du formulaire soumis, qui n'est pas exécuté lors du premier affichage de la page. Tu dois avoir une ligne dans ce bloc qui pète une erreur sur la prod.

Page blanche et script PHP : Comment résoudre le problème ?
faq-tutoriels/page-blanche-script-php-c ... 73178.html

EDIT

une question (peut-être stupide) quand en production il procède la ligne de code:
$passe2= password_hash($_POST["password"], PASSWORD_DEFAULT);
est-ce que, si le PW en clair est bon, le résultat hashé va être identique à celui du fichier txt qui a été généré et figé par exemple 3 semaines plus tôt???

Le hash sera toujours différent comme déjà dit et c'est bien pour ça qu'on ne compare pas les hashs mais qu'on utilise la fonction password_verify avec le passe en clair et le hash généré lors de la définition du mot de passe. La fonction est capable de déterminer si le mot de passe fourni est valide pour le hash fourni.

PS : je dis toujours différent mais en vrai j'en sais rien car je n'ai pas étudié l’algorithme derrière la fonction ni ne me suis penché plus en profondeur dessus. Peut être que le nombre de hashs est limité pour une même chaine et qu'un même hash peut ressortir ? la comme ça instinctivement j'en doute, en tout cas parts du principe qu'il sera toujours différent et que tu ne peux pas comparer les hashs.

Bonjour Saian,

Merci, tu as vu juste, j'ai ajouté le code de détection d'erreur php dans pagededepart.php en ligne 5 (j'en ai déjà un similaire dans mes pages de l'espace membres, mais curieusement pas dans les pages publiques où il y a surtout du code html 5).

En localhost, toujours pas d'erreur.
Mais en production, j'ai:

Notice: Undefined offset: 1 in /homepages/pagededepart.php on line 63

la ligne 63 est:
$id_mem2=$tab[1];
C'est dans la partie suivante (au code que tu as contrôlé) qui concerne la date de validité (voir ci-après).
Je ne sais pas ce que $tab[1] signifie mais la variable $id_mem2 sert un peu plus loin dans le code, indépendamment du controle ID/PW/date (j'ai essayé aussi de la désactiver ici et plus loin mais cela ne change rien... OK en local, même erreur en production seulement en ligne 83)

j'ai aussi:
Warning: Cannot modify header information - headers already sent by (output started at /homepages/pagededepart.php:1) in /homepages/pagededepart.php on line 83

la ligne 83 est:
header("Location: $members_area");

et comme $members_area est la variable de redirection vers l'espace membre cela explique pourquoi cela bloque.

Après cela comment régler le souci, aucune idée!

Au hazard j'ai essayé (bêtement):
$id_mem2=$tab[0];

mais çà bloque toujours
Warning: Cannot modify header information - headers already sent by (output started at /homepages/pagededepart.php:1) in /homepages/pagededepart.php on line 83

cette partie qui contrôle la date de validité est inchangée par rapport au code avec sha1 (qui est toujours active en production, en PHP 7) et donc je conclus que la modification avec hash destabilise la suite, seulement en production... peut-être suite à la modification du code avant pregmatch car $passe2 a disparu et on le retrouve à $_SESSION["passe"]=$passe2;
avec hash: J'ai essayé de changer $_SESSION["passe"]=$passe2; en $_SESSION["passe"]=$_POST['password']; ou bien en $_SESSION["passe"]=$password ou bien, en désespoir de cause, en $_SESSION["passe"]=$champ[1]; , mais j'ai les mêmes erreurs.

Ma logique est en défaut!

A+

Seb

EDIT : si j'ai bien compris pour la date c'est vérifier que la date du jour est inférieur à la date du membre qui doit être la date de fin de son abonnement ? et si la date est bien de la forme Y-m-d, le teste devrait être bon.

session_start();

if ($_SERVER['REQUEST_METHOD'] == 'POST')
{
  // stocke les données du formulaire dans 2 variables
  $login = isset($_POST['ID']) ? trim($_POST['ID']) : null;
  $password = isset($_POST['password']) ? trim($_POST['password']) : null;

  // si l'une ou l'autre des variables est vide => erreur
  if (!$login || !$password) {
    header('Location: login_failed.php');
    exit ;
  }

  // boucle sur le fichier membres
  foreach (file('IDtabPWtabdate.txt') as $line) {
    // converti la ligne en tableau
    $data = explode("\t", $line);

    // si il n'y a pas 3 colonnes dans le tableau => saute la ligne
    if (count($data) != 3)
      continue ;

    // converti les données du tableau en forme objet
    $member = (object) array_combine(['login', 'passwordHash', 'date'], $data);

    // compare le login, vérifie le mot de passe et la date
    if ($login == $member->login && password_verify($password, $member->passwordHash)
      && (new DateTime())->format('Y-m-d') < $member->date) {
      // connecte l'utilisateur
      $_SESSION["MEMBRE"] = "oui";
      $_SESSION["login"] = $member->login;
      $_SESSION["passe"] = $password;// je vois pas l'intérêt de stocker le mot de passe dans la session...? je dirais même que c'est dangereux

      header("Location: espacemembre/acces.php");
      exit ;
    }
  }
  
  // éventuellement ici => compte inexistant ou abonnement terminé
}

Bonjour ,

C'est vraiment super gentil à toi de proposer autre chose mais, vraiment désolé, avec mon niveau débutant je n'arrive pas à adapter ton nouveau code au mien notamment le code fermé utilisant $id_mem2 et cette curiosité de <?php } ?> après la balise </html> que j'avais simplement oublié de mentionner car tout à la fin de la page (je ne sais pas à quoi çà sert)

Je viens de passer 20 heures à essayer mais j'ai bcp d'erreurs mais je continue.

Donc en parallèle si je met le code complet qui marche en local mais pas en production est-ce que tu peux y voir plus clair???

J'ai essayé d'autres trucs avant ton message:

si je remonte le code <?php } ?> après la balise </html> juste avant <doctype> en local cela continue à marcher et en production cela ne marche toujours pas avec bons ID et PW mais au moins en retour je n'ai plus une page blanche mais la page de départ avec en haut les mêmes lignes d'erreur qu'avant.
Enfin si je désactive $id_mem2=$tab[1} cela continue à marcher en local c'est juste le résultat du fichier de connexion de page qui est affecté, donc a priori c'est pas çà!

Au total dans mon code passé en hash il ne doit plus y avoir grand chose de mauvais, peut-être ce fameux code après la balise </html>???

Voici le total hors code de compte de connexion
A+
Seb

Bonjour Saian, Naroth, et Spols,

Encore merci à chacun pour l'aide,

Je reviens vers vous et le forum pour vous informer de mes progrès périlleux sur ce fil.

Comme je ne m'explique toujours pas pourquoi notre fichier en sha1 marche en local et en production et notre nouveau fichier en hash ne marche qu'en local.

J'ai ajouté le code d'erreur en sha1 aussi.
error_reporting(E_ALL);
ini_set("display_errors", 1);

Et là surprise, en production, j'ai les même erreurs en sha1 avec la page blanche!!!

Donc d'abord je bloque, puis je me dis que pourquoi ne pas revenir en arrière dans le fichier hash sans le code d'erreur???

Et là çà marche... incompréhensible.
Cela voudrait dire que comme rien n'a changé dans le fichier en sha1, une intervention extérieure (l'hébergeur?) a changé la donne pour le fichier hash (et comme on est plusieurs à tester, ce n'est pas moi qui ai perdu la tête).

Comme je ne sais pas si les droits d'accès ont changé (les 2 fichiers sont maintenant en 604), je ne peux en dire plus sur ce mystère.

Peut-être un expert a-t'il une piste ???

En tout cas merci à vous 3 de votre aide et de votre coopération patiente.

Je ne marque pas le fil comme résolu, car l'erreur subsiste même en 604 avec sha1 et hash donc il est possible qu'un jour nous soyons piégés avec une évolution de php (ou autre) moins souple.

A+ peut-être, Seb

Ca me fait penser à un hebergeur qui ne te permet pas de modifier la config via error_reporting et/ou ini_set
du coup tu obtiens une erreur sur ces lignes mais comme elles ne s'affichent pas => page blanche.