Bonjours tout le monde.
 
Grâce notemment à l'aide de certains membres de ce forum, j'ai terminé la base d'un backoffice multiutilisateurs pour mes sites webs à venir. Merci déjà donc.
 
Je reviens vers vous, chers amis, cas le n00b que je suis se trouve façe à certaines interrogations quant à la sécurité de son script.
 
Voilà ce que j'ai fait :
 
- Les utilisateurs sont créés dans la bdd avec des droits bien définis suivant leurs status, et donc avec un accès restreint aux tables, ça évite déjà un drop malencontreux.
 
- Les utilisateurs sont stockés dans une table contenant toutes leurs infos sauf le password, qui lui est dans la base MySQL, crypté automatiquement donc (en tout cas je le vois crypté dans phpmyadmin), que personne sauf l'admin ne peut aller consulter.  
 
- Dans le script, une fois connecté, avant le header html de chaque page, je fais une connection à la base, si l'utilisateur est connecté, donc il existe (je n'oublie pas de fermer la connection) sinon retour à la page login, ça empêche la visualisation et l'acces aux pages, et même loggé si un utilisateur veut passer de pages en pages par l'intermédiaire de la barre d'addresse pour, admettons, acceder à des fonction admin, il est renvoyé au login.
 
- Pour éviter les injections j'utilise htmlentities pour toutes les variables transmises par champ texte.
 
- J'utilise POST au lieu de GET, donc rien dans la barre d'addresse.
 
Maintenant voilà ce qui m'embête :
 
Toutes les pages demandent une conenction à la base, que ce soit pour l'autentification ou non. Donc si je ne m'abuse, rien que pour exécuter une requète il me faut passer le password de page en page. J'utilise un input en hidden, donc rien n'est visible sur la page. MAIS dans le code on voit tout en clair. Et je ne crois pas que ce soit souhaitable. J'ai essayé de coller un "echo md5($pass)", dans ce cas c'est affiché en codé, très bien, mais il est envoyé codé dans la bdd et elle ne le reconnqît pas.
 
 
Quelle serait d'après vous la meilleur solution pour ne plus afficher le pass en clair  ?
 
Et dernière question, htmlentities, seul, est suffisant ou dois-je ajouter addslashes et autres ?
 
 
Si mes méthodes sont fausses, je ne vous demande pas de tout me refaire, mais si vous pouviez m'orienter, j'ai lu beaucoup de doc pour arriver au résultat final, et je ne sais plus trop où donner de la tête...
 
 
Merci d'avance pour votre temps.
 
MrNatas

utilises des variables de session si tu ne veux rien afficher dans les pages

pourquoi tu garde le mot de passe ?
tu pourrais garder juste le login, et enregistrer que cet utilisateur est loggé.
 
et à chaque fois que c'est nécessaire, (accés à des endroits particulier) éventuellement redemander le mot de passe.

Perso, dans la session, je garde l'ID (clé primaire) de l'utilisateur, + son nom, prénom, ID du profil et adresse e-mail. Comme ce sont des infos que j'utilise très souvent dans les pages de mon appli, je trouve que ça vaut le coup.

Une chose que je trouve crade à souhait : créer un utilisateur SQL pour chaque utilisateur qui s'enregistre sur ton site.
Le seul utilisateur SQL que tu devrais avoir c'est ton script lui-même.
 
Pour les utilisateurs du site, il faut que tu stockes leur login + md5(mdp) dans une table 'users' par exemple.
Ensuite, lorsque quelqu'un veut se connecter, il t'envoie par formulaire son login + son mdp. tu fait un SELECT count(*) du nombre de lignes qui ont ce login + md5(pass) et le tour est joué

Crade, ça dépend ce que tu cherches et l'application du truc
Ce qui est crade c'est de croire que ses propres besoins sont les mêmes pour tout le monde

Pour une appli, je parle pas de site, mieux vaut utiliser le système de droits du sgbd plutot que croire qu'on fera mieux tout seul Après suffit d'interfacer et éventuellement rajouter ton système de droit logique mais au moins t'as un garde fou "physique" sur ta base

Edit: pour le coup ta solution pour le login est vraiment crade, explique moi en quoi tu as besoin d'aller vérifier le mot de passe dans ta requête

Je tiens fermement à garder les utilisateurs sql, pour moi c'est une option de sécurité en plus. J'ai bien un système de droits logiques sur le backoffice, mais j'ai pas envie du tout que sur un site pour lequel j'ai fourni l'appli un crétin un peu doué en sql s'en aille tester les dernières méthodes d'injection de HaK0Rz mag' et me vider ma base de users ou aller me chercher les pass admins...
 
Je suis en train de plancher sur les variables de sessions. Il faut encore que j'allège mon code, et ensuite je le diffuse en GPL, na.

 
Ce qui est crade surtout c'est de ne pas tenir compte des expériences précédentes. Il suffit de voir comment tous les CMS gèrent les utilisateurs pour comprendre que la solution que j'expose est de loin la plus propre.
Et si tu dois migrer ton site sur un autre serveur, amuse toi bien à recréer tout tes utilisateurs SQL sur l'autre serveur !

 
 
T'as l'air d'en avoir de l'expérience dis-moi pour te permettre de dire que si une solution est utiliée quelquepart c'est forcément la meilleure.
La création d'utilisateurs de la base est une solution tout à fait valide, et aux dernières nouvelles c'est absolument pas un problème de générer un script sql qui va te les recréer sur ton nouveau serveur si tu changes.

Dans tous les cas comment restreindre l'acces aux tables si les utilisateurs ne sont pas des utilisateurs sql ?

C'est impossible, tu dois te les taper dans l'appli, les droits d'accès.

C'est bien ce que je pensais, et ça fait un moment que c'est fait d'ailleurs.
 
Donc c'est quoi finallement le plus sain ? De stocker les mots de passes dans la table des users ou de créer des users MySQL ?

Il n'y a pas de solution plus saine que l'autre...ta solution a l'avantage d'ajouter un niveau de sécurité supplémentaire, le '100% logique' sera par contre probablement plus simple à mettre en place et à maintenir...

Un utilisateur DB par utilisateur du site, cai malle.
 
- Comment obtenir un connexion pooling efficace si pour chaque visiteur, il faut une connexion DB qui lui est propre?
 
- Pq scinder les informations d'un visiteur d'une part en login DB (uid/pwd) et d'autre part en data (email, adresse, ...), alors que toutes les infos pourraient être accessibles de manière unifiée (data uniquement)?
 
- Les utilisateurs accèdent à une application, pas à la DB. Pq leur donner la granularité du login DB s'ils n'y accèdent pas directement?
 
Attention: je parle bien de "créer un utilisateur SQL pour chaque utilisateur qui s'enregistre sur ton site" comme le dit vanadium, PAS d'une "application" comme l'entend leflo.
 
Dans le premier cas, c'est cra-cra...
 
Mais même dans le deuxième, l'utilisation de logins distincts ne servira que de cache-misère Il est difficile de faire l'économie d'un FAP / DAP en harmonie avec l'interface utilisateur! Sauf à donner dans l'appli "quick & dirty" pour des power-userz.  
 
Natas> Stocker les MDP, cai malle.

 
c'est le principal soucis, oui...mais d'un autre coté il cause de backoffice, là, si j'ai bien lu...va pas y en avoir 36000 en même temps, des users...
 

 
Tu chipotes, là.
 
La DB peut contenir de la logique métier, via des procédures stockées par exemple...je vois pas en quoi utiliser la gestion d'utilisateurs existante comme base pour celle de ton appli est gênant.
 
 
'fin bref, c'est quelque chose qui se faisait pas mal il y a quelques années, et qu'on voit de moins en moins, mais ça ne veut pas dire que c'est forcément à jeter...

Bah en fait, je crois que je vais faire les deux.
 
J'ai rajouté un fonction membre pour personnaliser le contenu du site, et ceux là ne modifient pas la base, juste un select. Donc eux, je vais stocker leurs pass dans la table users vu qu'il y à tout de même moins de risques.
 
Sircam, si je ne stocke pas les mdp dans la base je fais comment pour identifier mes users ?
 
Encore une chose, j'ai bien implémenté les sessions, et ça a fait disparaître les info sensibles des sources, en même temps qu'alleger mon code, je suis ravi.  
Mais je voudrais en savoir plus, genre comment gerer la durée d'une session et renvoyer les messages d'erreur adéquats, quelqu'un à un lien sur un tuto complet ? J'ai des bribes de ça de là mais c'est pas encore ce que je veux...
 
Merci encore, je prend plaisir à discuter.

Gères toi même les durées, comme ça pas de surprise
 
Sinon y'a rien de bien sorcier, doc php sur les sessions
 
Pour les messages c'est à toi de gérer, que ça soit toi ou la config de la session, si t'as passé le temps ou plus de session, tu balances une erreur

Mais les sessions n'ont pas une duree par defaut ?
 
J'avoue que je commence a saturer un peu a cracher du code, et je commence a deccrocher un peu...

Si les sessions ont une durée maximum de vie par défaut... mais elle dépend de ton serveur. (dans le fichier ini, sessionmaxlifetime il me semble.. ou quelque chose dans le gout la) donc il vaut mieux le gérer dans ton code afin d'avoir sa de moins comme soucis quand tu exporteras ton site.
 
et puis pour les erreurs de dépassement de temps.. c'est juste afficher un message et délogguer automatiquement l'utilisateur en cas de dépassement.. c'est faisable en 3 lignes

Et dans le cas ou la session se termine sur le serveur avant qu'elle ne se termine dans mon script, je fais comment  ? O.O

cette question est une hérésie.

8.117.17 session_get_cookie_params() : Lit la configuration du cookie
de session
array session_get_cookie_params ( void )
session_get_cookie_params retourne la configuration courante du cookie de session. Cette fonction
retourne un tableau, qui contient les éléments suivants :
· " lifetime " - Durée de vie du cookie.
· " path " - Le chemin où les informations sont stockées.
· " domain " - Le domaine du cookie.
" secure " - Le cookie ne doit être envoyé que sur des connexions sécurisées (cet élément a
été ajouté en PHP 4.0.4).
 
et
 
8.117.25 session_set_cookie_params() : Modifie les paramètres du
cookie de session
void session_set_cookie_params ( int lifetime , string path , string domain , bool secure )
session_set_cookie_params modifie les paramètres de configuration du cookie de session, qui a
été configuré dans le fichier php.ini . L'effet de cette fonction ne dure que pendant l'exécution du
script courant. De ce fait, vous devez appeler session_set_cookie_params pour chaque script et
avant l'appel à session_start
 
vla... donc temporairement tu peux modifier la configuration des sessions

Oué, ça n'est vraiment un pb que si la charge est importante. Ceci dit, un "gros" back-office, ça peut comprendre pas mal de clients aussi...
 

 
J'chipote pas
 
C'est tout de même plus facile de repêcher les infos de ton utilisateur de manière unifiée que de devoir agréger un hybride data/login. Que tu utilises une datawindow powerbuilder ou hibernate ou que sais-je. J'dis pas, c'est pas la mort, mais c'est par définition par super portable, un login DB. Au lieu de tout traiter d'une seule manière (client, utilisateur, ...), tu ajoutes une deuxième méthode, qui demande un supplément de travail, en tant que tel et pour l'agréger avec le reste.
 
'fin bon, faut juger sur pièce. Tu évoques la logique métier dans des stored procedures. Sans doute du "good old client-server". Ca me rappelle ma jeunesse De ce temps là, travailler comme tu dis n'était pas choquant. Maintenant, avec J2EE et toussa, c'est tellement bloatware & co qu'on évitera d'en rajouter la moindre couche    
 
Ceci dit, je ne vois toujours pas en quoi ça simplifie vraiment les choses. Si tu dois par exemple griser un bouton sur la toolbar en fonction du profil de l'utilisateur, tu n'es pas plus avancé avec ton login DB. Tout au plus, ça te permet de torcher une appli sans contrôle d'accès, dans laquelle l'utilisateur qui tente d'accéder à des données qu'il ne peut pas voir se fait jeter par le DBMS, comme par un sorteur en boîte. Dès que tu veux qq chose de friendly, tu devras implémenter la logique FAP ou DAP dans l'appli, et le login DB ne te sera d'aucune utilité.
 
En dehors d'un "garde-fou", je ne vois pas le bénéfice au login DB. Par contre, j'en vois clairement le coût.  
 
Si tu as un exemple sur ce point, je t'écoute volontier.

ok, lol.
Au lieu d'aller chercher ton login/mdp pour la connexion db tu prends le login/mdp saisi par ton utilisateur, c'est tout ce que ça change.
On est en cat' php, hein.

Mouhahaahahahahahaha il parle de J2EE et traite autre chose de bloatware dans la même phrase...

J'ai jamais dit qu'il fallait se passer d'une gestion de droits d'accès propre à l'appli. Ca fait juste un garde-fou supplémentaire.

p'tain... c'est grave.. pas moyen de comprendre de quoi tu parle...:D... comprend les noob comme moi qui ne parle pas l'informaticien ... il va falloir que je squatte google pour décoder ce que tu raconte... je ne pense pas que le créateur du topic suive ce que tu raconte... (enfin en tout cas, moi je ne suis pas )

'k, j'croyais qu'on pouvait malgré tout parler sérieusement, BUT I WAS TEH WRONG
 

Relis bien, je parlais de J2EE comme étant du bloatware. D'où la nécessité de ne pas en rajouter
 

Bah voilà alors, stout. On parle de la même chose.  

 
Bah je suis sérieux...mais dans le contexte.
A l'utilisation ça change quasiment rien, là.
 

 
C'était pas hyper clair.
Et d'ailleurs les procédures stockées c'est le bien.
Si t'as plusieurs applis qui utilisent la même base c'est le seul moyen de rester cohérent à coup sûr.
 

 
bah c'est ce que je dis depuis le début, hein...

Le pire, c'est que tu n'as pas tort. T'as même sans doute raison.
 

J2EE cai le malle. Et je resterai contaminé à vie. Pire qu'une exposition prolongée au BASIC.
 

Sauf si tu as un serveur applicatif entre les deux. Tu y déploies la buzinezz logique et hop! Write once, run anywhere
 
Oui, je sais, en client-serveur, etc, ... je n'ai pas renié ma jeunesse. Je t'ai dit que j'étais contaminé, remember?
 

I AM TEH MALCOMPRENANT

Le fait de créer des utilisateurs SQL à chaque utilisateur du site, je me trompe ou ça me permettrait de me connecter au serveur sql avec mon user et pass et faire tous les selects que je veux sur les tables auxquelles je suis autorisé d'accéder ?
si en plus je suis autorisé à faire des insert, je n'imagine meme pas comment on peut vite faire tomber le site en saturant la bdd !
 
enfin tout ça suppose tout de meme que le serveur sql accepte des connexions d'un autre site que localhost, mais je pense que cette solution c'est s'exposer inutilement à des problèmes de sécurité.

Tu restreins l'accès à la base à la machine qui héberge le site, je vois pas le soucis.
Au contraire tu renforces la sécurité en réduisant l'impact des failles qui pourraient se retrouver dans ton site.

Ba si vraiment c'est nécessaire de scinder les autorisations, pourquoi ne pas créer un user/pass par type de user.. et donc en fonction de ce type enregistrer en dure les log/mdp dans un fichiers. auquel cas le log se ferais de manière transparente avec le login du site...

Il reste que je n'ais jamais vu aucun projet php faire de la sorte et que je m'interroge sur la véritable utilité d'un tel renforcement.
Après tout, si tu codes correctement et que tu prêtes une attention particulière à la phase de tests, il n'y a pas de raison qu'une authentification entièrement php soit synonyme de faille de sécurité.

Je n'ai jamais dit que c'était synonyme de faille.
J'ai dit que c'était un filet de plus pour te rattraper en cas de soucis, et en aucun cas une erreur rédhibitoire.

Et? Apprends le français.
Le conditionnel n'indique pas une certitude.

Je comprends pas bien pourquoi le débat a lieu Mon point de vue: les données ce sont les données Donc on est tous d'accord qu'un utilisateur donné ne doit pouvoir manipuler que les données qui l'intéressent, et faire que ce qu'il a le droit de faire (genre select, insert mais pas delete et encore moins drop ). Partant de là, je vois pas bien comment faire autrement qu'avoir ne serait ce qu'au moins un utilisateur par type d'utilisateur à défaut de personnaliser chaque utilisateur
 
Parce qu'avec un seul et unique utilisateur qui a tous les droits, utilisé par l'admin ou par l'utilisateur de base avec des restrictions logicielles, c'est la porte ouverte à toutes... les fenêtres
 
Vous me direz que sans faille y'a aucun risque, mais qui peut se vanter d'être sur à 100% que y'a aucune faille, ne serait ce que sur le serveur hébergeant le site/appli
 
Je suis pas partisant du masquage qui comme chacun sait sert à rien, mais je suis partisant du verrouillage à tous les niveaux pour garantir un ensemble cohérant si par malheur y'avait un trou quelque part

Bon, fort de ce prenant débat j'ai révisé ma politique de sécurité.
 
Comme le site possède un espace membre, je ne pense pas que je vais m'amuser à créer un user SQL par membre.
En revanche les utilisateurs du backoffice, eux, ont besoin de manipuler la base en faisant autre chose que des select, donc je leur donne juste les droits sur les tables concernées. C'est un peu la mouise pour l'identification mais ça passe.
 
Le fait de restreindre la connection directe à la base uniquement au serveur, on fait ça comment ? Si c'est un paramètre du serveur c'est dommage vu que l'appli va être hébergée ailleurs que chez nous.
 
Encore une chose, je commence à avoir des doutes sur l'export de la base. C'est une chose que je n'ai jamais faite, je n'ai utilisé jusqu'à présent que des app en local. Donc j'e copie quoi et ou ? Et quid des users SQL ? Ca va me les garder ?
 
Je suis désolé, je suis sûr que ces questions irritent, mais quand je vais publier le site avec le backoffice, il ne s'agit plus de faire de l'apprentissage par l'erreur, j'ai pas envie que le web de la boîte soit en vrac pendant que je bidouille...
 
En tout cas merci encore pour les conseils et le débat, j'aime bien ça

pour l'export de ta base, en ce qui concerne la structure et les données, en fait tu peux exporter tout ça en fichier texte (qui regroupera alors les requêtes à effectuer pour recréer ta base). (voir dans phpmyadmin si c'est une bdd mysql, onglet exportation).
 
Pour les users, j'aurais tendance à dire qu'il faut que tu les recré. Attention cependant, je ne suis pas sur que tous les hébergeurs te permette d'en créer autant que tu veux... à vérifier

ah si c'est chez un hébergeur c'est pas gagné la création d'utilisateurs, en effet...

2 réflexions analogues :
- Pourquoi ne pas gérer les utilisateurs comme tout le monde le fait, çad en php avec une table contenant login + md5(mdp) + ... ?
- Pourquoi vouloir faire une voiture à 5 roues alors que tout le monde roule en voiture à 4 roues ?
 
Il y a toujours plusieurs façons d'aborder un même problème et plusieurs solutions. Les solutions ne diffèrent que par leur practicité et leur élégance.