18041 sujets

Questions générales et questions de débutants

Protection par mot de passe

Bonjour à tous
Cela fait maintenant 15 ans que j'ai installé une protection par mot de passe sur une partie d'un site. C'est un sous-répertoire "private" du site, avec un un .htaccess qui contient

AuthUserFile ....
AuthType Basic
Require valid-user
ErrorDocument  401  /html/lostpw.html

Toute personne qui veut accéder à un fichier contenu contenu dans l'arborescence de ce sous-répertoire.
L'ennui essentiel, c'est qu'il faut entrer son nom et son mot de passe à chaque accès, alors que les sites "modernes" permettent d'enregistrer ces informations "quelque part" (dans un cookie, je présume) pour ne pas avoir à faire cette opération à chaque fois. C'est par exemple le cas du site Alsacreations.
J'aimerais pouvoir ajouter ce genre de protection sans pour autant devoir réorganiser tout le site.
Un point en particulier est important: la possibilité d'accéder à un fichier de la zone protégée par un lien vers ce fichier transmis par exemple par courriel.
Merci de vos conseils
Je sais que tu maîtrise bien des choses et donc je vais te donner la formule sans soucis et imparable à ton problème.
Lorsqu'un visiteur clic sur un lien allant dans "prive_a_toi/" tu lui demandes de se loguer à moins qu'il ait un cookies permanent et que tu trouves qu'il a le droit !
DE TOUTE FAÇON qu'il soit connu valide par cookies ou par formulaire, alors tu lui donnes une variable de session par exemple "mdp"="x!_32azoule"

Alors surtout fait bien ceci:
DANS TON RÉPERTOIRE "prive_a_toi/"
1) tu mets un index.php contenant:

<?php
 header('Location:http://TONSITE/index.php');
 exit;
?>

interdisant le parcours du répertoire

2) dans Tout tes PHP tu mets:

<?PHP 
session_start();
header('Content-Type: text/html; charset=utf-8');  
$LeMDP = (isset($_SESSION['mdp'])) ? $_SESSION['mdp'] : 'REFUS'; 
if ($LeMDP !="x!_32azoule" )  header('Location:http://TONSITE/index.php');)


Ainsi aucun appel directe ne peux exister Smiley cligne
Bien sur vires tes .htaccess !
Merci de ta réponse.
Christele a écrit :

Lorsqu'un visiteur clic sur un lien allant dans "prive_a_toi/" tu lui demandes de se loguer à moins qu'il ait un cookies permanent et que tu trouves qu'il a le droit !

C'est exactement ce que fait mon .htaccess
Mon répertoire "privé" s'appelle /html/private et c'est dans ce répertoire que se trouve le .htaccess en question.

Actuellement, le mécanisme est le suivant:
lorsqu'un membre de l'ensemble vocal se connecte pour la première fois dans la partie privée du site, Apache lui demande de se logger par les infos du fichier /html/private/.htaccess
Je crée alors un cookie valable un an et qui se rafraichit à chaque connexion, ce qui permet de mémoriser sur son appareil son code d'accès mais pas son mot de passe.
Grâce à ce cookie, chaque fois qu'il se connecte au site, je sais qui sait, et je génère les pages en fonction de cette information, ce qui peut lui montrer des choses que l'utilisateur non enregistré ne voit pas. Par contre s'il appuie sur un lien qui va vers la partie privée du site, Apache lui demande automatiquement de se logger.

De même, quand je transmets par courriel l'adresse d'un fichier de partition aux membres de l'ensemble vocal, par exemple
https://www.alma-musica.net/html/private/partitions/Kodaly/Hegyi-ejszakak.pdf
le seul fait de vouloir accéder à ce fichier provoque la vérification par Apache du mot de passe de l'utilisateur. S'il a déjà été donné, ça affiche la partition en question, sinon ça lui demande son mot de passe.

Si je supprime les infos du .htaccess, comment vais-je "trapper" l'essai d'accéder un fichier du domaine protégé et lui demander de se logger?
Modifié par PapyJP (23 Oct 2017 - 11:04)
je reviens sur ton premier poste.
Les cookies c'est la vie (avec des pépites de caramel beurre salée surtout!)

Sinon, tu peux stocker tout ce que tu veux dans tes cookies
et une fois arrivée sur la page, si la personne a le fameux cookie chez lui, il suffit de le lire et alors tu peux tout a faire réécrire tel que les infos et ça de manière transparente et automatiquement, sinon faire une redirection Smiley smile
Modifié par JENCAL (23 Oct 2017 - 11:24)
Modérateur
PapyJP a écrit :

Si je supprime les infos du .htaccess, comment vais-je "trapper" l'essai d'accéder un fichier du domaine protégé et lui demander de se logger?


C'est la grosse complexité de l'affaire. Et sans framework/CMS qui gère ces choses là c'est un gros morceau à faire, en sus de la gestion de la session et du login, il faudra:

1) Mettre les fichier dans un dossier non servi par apache
2) Dans ta partie admin, rediriger toutes les requêtes vers un contrôleur unique (par rewrite), par exemple monsite.fr/admin/fichier/truc.pdf se réecrira vers monsite.fr/admin/index.php?q=fichier/truc.pdf
3) Analiser les requêtes et rediriger vers les actions adaptées:
- Fournir le fichier si les droits sont bons (et le streamer par php)
- Afficher un acces denied si ils ne sont pas bons,
- Rediriger vers le login si nécessaire de se logguer
Merci de vos réponses

@kustolovic
C'est bien le genre de chose que je craignais.
Pour un site qui n'a que 25 utilisateurs réguliers, pas la peine de se lancer dans une telle opération.
Déjà utiliser un dossier non servi par Apache, je ne vois pas très bien comment faire ça sur un site hébergé en "mutualisé". Je pense que ça n'est tout simplement pas faisable.
Let's forget it!!

Pour le reste, oui, bien sûr, j'utilise des cookies, et surtout un qui s'appelle "user" et qui contient l'identifieur de l'utilisateur. C'est à partir de cet identifieur que les pages calculent ce que l'utilisateur est sensé voir. Par exemple les membres du conseil d’administration voient apparaitre dans le calendrier les réunions qui les concernent.
Modifié par PapyJP (23 Oct 2017 - 20:47)
Modérateur
PapyJP a écrit :

Déjà utiliser un dossier non servi par Apache, je ne vois pas très bien comment faire ça sur un site hébergé en "mutualisé". Je pense que ça n'est tout simplement pas faisable.
Let's forget it!!

En mutualisé on a souvent accès à des dossiers en dehors du root (httpdocs/www/etc.). Si ce n'est pas le cas il suffit de créer un dossier avec un .htaccess contenant "deny from all".

Mais je t'accorde que sans CMS et/ou framework pour gérer cela c'est fastidieux et ne vaut probablement pas la peine.

Sinon il existe aussi des mods apache pour aller plus loin dans ces mécanisme d'authentification, mais c'est à nouveau complexe, et sur un serveur mutualisé c'est pas glop.
Je ne comprends riens, ce que je proposes n'a pas besoins d'.htaccess et est inviolable, mis en place en qq minute !!! Smiley eek
Modérateur
Christele, sécuriser des pages php n'est en effet pas très compliqué, bien qu'on puisse le faire de manière plus propre.

Par contre cela ne sécurise que les fichiers php, comment mettre ton code dans un fichier pdf ou zip ?
Après avoir dormi dessus, et en m'inspirant de ce que vous dites, est-ce qu'à votre avis l'approche suivante serait envisageable:
1) mettre la zone privée en "deny from all"
2) faire un rewrite pour tout appel de fichier de la zone privée qui renvoie vers un programme php qui fait ce qu'il faut, à savoir
- regarder dans session si l'utilisateur est déjà loggé
- sinon lui demander de se logger
- afficher le fichier par readfile
De toute façon, si je décide de faire ça, ça ne sera pas avant longtemps, car j'ai plein d'autres choses à faire, le site satisfait actuellement ses utilisateurs, faire des changements de cet ordre va le déstabiliser.
Donc je peux éventuellement travailler là dessus à temps perdu sur un site de test et faire éventuellement une migration durant une longue période de congés, où personne ne se sert du site.

Une autre approche pourrait être de migrer le site sous un CMS.
Comme j'ai commencé à faire ce site en 1999, avant qu'il existe le moindre CMS, ça voudrait dire revoir le fonctionnement de fond en comble, ce qui ne me fait pas peur, ce ne serait pas la première fois que je fais une telle modification. Le capital de ce site n'est pas tant dans le code que dans des fichiers pdf qui peuvent rester tels qu'ils sont.
On peut penser que cela faciliterait la transmission du site à quelqu'un d'autre, car mon âge et mon état de santé me forcent à penser à la suite, ce qui n'est pas très plaisant, mais la réalité est ce qu'elle est.
Votre avis?
Christele a écrit :
Je note que tu rejettes ma solution, en attendant quel rapport avec un CMS ? Smiley confused

Je ne rejette pas: je ne comprends pas comment ça pourrait avoir une chance de marcher avec un fichier qui ne soit pas du html ou du php, explique moi.

Le CMS (encore faudrait il savoir lequel) est supposé être la façon de faire fonctionner un site avec des gens qui ne comprennent pas grand chose à la programmation.
Si je veux transmettre le site à un successeur, il pourrait être plus simple de le mettre dans un cadre sensé être connu et documenté, alors que mon code, c'est le mien, avec mes trucs de programmation dont certains remontent à la fin des années 1960. Pas très simple d'expliquer ça à des jeunes gens qui se croient experts en informatique parce qu'ils savent un peu utiliser quelques produits.
Personnellement je ne connais rien aux CMS, et mes rares incursions dans ce domaine m'ont fait fuir, de même que les packages du genre jQuery, qui t'obligent à apprendre un nouveau langage, alors que l'on peut très bien faire ça tout seul en JS, sauf bien entendu si on tient à supporter les navigateurs obsolètes, car ils ont au moins l'intérêt -- du moins sur le papier -- d'éviter à faire les pieds au mur pour adapter son code aux différents navigateurs.
C'est pour toutes ces raisons que je demande des conseils.
Sujet clos
Aller à