Systèmes d'identification : avantages et inconvénients

Bonjour à tous.

Jusqu'à aujourd'hui je n'avais jamais été confronté à la construction d'un site en entier et en particulier aux systèmes d'identifications.

J'ai entendu parler des sessions PHP, des cookies, des .htaccess mais quels sont les avantages et les inconvénients de ces différents systèmes ?

Nota : je suppose que je pourrais trouver de nombreux avis sur Internet mais je fais confiance aux personnes de ce forum.

Merci d'avance.

Bonsoir,

Je ne te serai pas d' une grande aide mais je te répond quand même.
Je ne connais ni les cookies ni htaccess, je suis débutante en programmation et j' ai compris rapidement les sessions en php.
Donc avantage: simplicité si tu connais un peu de php.

Par contre je crois que les sessions en php se ferment automatiquement quand on ferme la fenêtre du navigateur (et aussi toutes seules au bout de 30 mns) ce n' est pas le cas des cookies, avec lesquels tu peux " reconnaitre " un internaute quand il revient sur ton site.

Bonsoir.

Disons que je connais a peu près le principe de chacune de ces méthodes mais ce que je voudrais c'est l'avis de personnes qui utilisent ces solutions pour qu'elles me fassent part de leur expérience.

Merci quand même, c'est l'intention qui compte.

Voici mon avis :

Cookies
- Temps de vie ajustable, presque permanant à vie si nécessaire
- Utilisation facile également en javascript
- Facilement crackable = facilité à récupérer/usurper des informations potentiellement confidentielles
- Peut être supprimé par l'utilisateur à volonté, permanence pas forcément assurée aussi longtemps qu'on le voudrait parfois
- Impossible de stocker des informations complexes (tableaux, objets, etc.) non ou difficilement convertibles en chaîne... quoique, avec la sérialisation... mais ça complique beaucoup les choses.

Sessions
- Simplicité d'utilisation avec la variable $_SESSION (ne pas oublier le session_start !)
- Beaucoup plus difficilement crackable que les cookies (ce n'est cependant pas impossible)
- Informations non persistantes perdues lors de la fermeture du navigateur ou après plus d'une certaine durée d'inactivité (généralement entre 15 et 180 minutes selon php.ini)

identification par .htaccess
- Pratiquement impossible à cracker
- Impossible de stocker des variables, utile juste pour l'identification et ensuite, inutilisable.
- Certains trouvent que la fenêtre par défaut permettant l'identification est moche.

Verdict personnel
Les sessions et les cookies sont le duo idéal dans la majorité des cas.
Pour les scripts sensibles nécéssitant une sécurité meilleure (p.ex. panel d'admin), le duo sessions et .htaccess est idéal.

OK. Merci. D'autres avis ?

Après réflexion je me pose une question. Le problème des .htaccess c'est que PHP ne sait pas quelle personne se connecte mais ne serait-il pas possible que ce soit PHP qui récupère les valeurs dans un formulaire et qu'ils les envoie à Apache donc sans que la fenêtre "moche" apparaissent ?

CNeo a écrit :
Après réflexion je me pose une question. Le problème des .htaccess c'est que PHP ne sait pas quelle personne se connecte

Ca c'est faux : il y a des variables dans $_SERVER qui contiennent ces valeurs. Je n'ai plus les noms en tête mais je sais qu'elles y sont.

CNeo a écrit :

mais ne serait-il pas possible que ce soit PHP qui récupère les valeurs dans un formulaire et qu'ils les envoie à Apache donc sans que la fenêtre "moche" apparaissent ?

Par contre ça, je ne sais pas si c'est possible. J'aurais tendance plutôt à dire non...

QuentinC a écrit :

Ca c'est faux : il y a des variables dans $_SERVER qui contiennent ces valeurs. Je n'ai plus les noms en tête mais je sais qu'elles y sont.

Ok, c'est pas ce que j'avais compris.

QuentinC a écrit :

Par contre ça, je ne sais pas si c'est possible. J'aurais tendance plutôt à dire non...

À mon avis c'est possible mais pour ça il faudrait connaître les requêtes HTTP qui sont transmises pour pouvoir envoyer les mêmes avec PHP puisque j'ai cru comprendre qu'il a de bons outils pour ça.
Enfin de toute façon ce n'est pas grave la fenêtre "moche" je m'en fous un peu.

Théoriquement, on peut, oui. Mais il faut envoyer une requête HTTP sur son propre serveur, et ce n'est pas si simple. En effet, il est impossible d'utiliser les habituels sockets même en indiquant $_SERVER['SERVER_ADDR'] comme cible : l'iP du client ne serait pas la même (le client serait en fait dans un tel cas le serveur !!).

Par contre, on peut le faire avec de l'AJAX en envoyant les en-têtes HTTP adéquats ... reste à prouver l'utilité de la mise en place d'un tel système.

Bon je viens enfin de commencer à lire la doc et à réfléchir à mon système d'identification et il y a un truc que je ne comprends pas : à quoi sert session_name() ?

Salut

session_name("nouveaunom") sert à modifier le nom de session par défaut PHPSESSID

D'accord mais ça j'avais compris c'est écrit dans le manuel. Ce que je veux dire c'est doit-on utiliser cette fonction et quelle valeur doit-on lui donner ?

salut,
disons que, majoritairement, il vaut mieux laisser php se charger du nom de session (phpsessid par défaut), à moins d'avoir vraiment envie de te lancer dans la génération d'id de session mais, dans ce cas-là, veille à les rendre aussi aléatoires et difficiles à mémoriser et à doublonner que ceux de php

En revanche, session_name() peut te servir à récupérer le nom actuel de la session pour des manips côté base de données par exemple, genre association d'une session avec un utilisateur pour une date donnée, etc, etc

have swing

salut ,

Dans le même cas que Cneo , j'ai commencé à me documenter sur les session et voilà ce que dit mon bouquin sur les identifiants de session :

fournir soi-même un identifiant de session sans précaution peut permettre à quelqu'un d'usurper la session d'un autre.

Il précise un peu plus loin d'eviter de définir soi-même un identifiant de session, et de faire confiance au développerur PHP pour cette identifiant

J'ai trouvé par ailleurs concernant la sécurité lors de la vérification de mot de passe et identifiant utilisateur , un changement d'identifiant session avec
'session_regenerate_id()' lorsque l'utilisateur avait passé avec succès la vérification de son 'pseudo' et mot de passe

Par la suite seul le nom de l'utilisateur est mis dans une varaible $_session et est vérifié (son existence) sur toutes les pages utilisant les session :
Si la varaible $_SESSION['nom'] existe (if(isset($_SESSION['nom']) c'est que le visiteur s'est authentifié correctement donc peut accéder à cette page

Personnellement je pense que mon choix va se porter sur les .htaccess même si mon site ne requiert pas une sécurité optimale. Par contre pour ajouter des utilisateurs il vaut mieux encoder les mots de passe, je pense que ça doit être possible donc si vous avez des bon liens je veux bien sinon je chercherais plus tard.

re,

ben tu en trouveras partout, c'est relativement facile à faire. Pour le moment sur mon site il n'y a pas de contenu (trop feignant ) sauf, justement un petit utilitaire que je me suis fait pour ça

have swing

Oui mais j'aurais préféré un lien qui explique comment ça fonctionne. Il n'y a pas une histoire de clé de cryptage aussi à un moment ?

re,

alors, accroche-toi, ça va aller vite tu récupères ta valeur postée par le formulaire ou n'importe quel autre moyen et tu fais

//donc soit
$pass=$_POST['pass'];
//soit carrément en dur dans la page si tu n'en as pas 2000 à crypter
$pass="toto";
//suivi de
$cryptpass=crypt($pass); //et voilou

hop, tu as vu, c'est vite fait et pour htaccess, pas besoin de stipuler de salt (la fameuse clef dont tu parles). En revanche, pense à stocker tes mots de passe en clair dans un coin (pas sur le serveur hein ) parce qu'une fois crypté il n'y a pas de fonction de décryptage

Have swing

Je me pose aussi la même question... et après quelques recherches:

a écrit :
Par contre je crois que les sessions en php se ferment automatiquement quand on ferme la fenêtre du navigateur (et aussi toutes seules au bout de 30 mns) ce n' est pas le cas des cookies, avec lesquels tu peux " reconnaitre " un internaute quand il revient sur ton site.

Apparemment, c'est faux. C'est ce que je pensais aussi au début, mais en redéfinissant cookie_lifetime avec session_set_cookie_params, on peut apparemment définir une date d'expiration, comme on le ferait directement avec les cookies (et de toutes façons, les sessions serveur utilisent aussi les cookies, la seule différence étant que l'association internaute <> données sauvegardées est automatique).

a écrit :
Informations non persistantes perdues lors de la fermeture du navigateur ou après plus d'une certaine durée d'inactivité (généralement entre 15 et 180 minutes selon php.ini)

180 minutes ? Ca serait un délai maximum? Du moins ce n'est pas indiqué dans la doc PHP donc je suppose que ce sont les mêmes limites que pour un cookie classique... ?!

----------------

Bref je ne vois toujours pas l'intérêt de préférer les cookies aux sessions PHP (c'est pourtant le cas de PHPBB: les scripts fonctionnent visiblement comme les sessions serveur: un identifiant en cookie et sauvegardé en BDD avec les autres infos).

Perso je couple cookies et sessions.

La session pour "suivre" l'utilisateur sur le site et lui attribuer les droits qui lui correspondent.
J'utilise le cookie pour savoir si la personne est déjà venue sur le site et si elle veut être reconnue automatiquement.

Je n'utilise le .htaccess que pour le rewritting d'url.