Reprise du message précédent :
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.

Tu sais que t'es super lourd?

 
Quand est ce que tu tenteras d'apporter de l'information plutot que de polluer le topic avec des remarques non constructives ?

parce-que les tiennes c'est constructif? A part dire que tu ne ferais pas comme lui et que c'est pas comme ça que font les autres et que c'est donc forcément mal tu ne sers à rien, là.

 
je ne veux pas être méchant, mais pluzun... (qu'est ce que ton histoire de voiture à 5 pattes viens faire là).

C'est une analogie avec le problème actuel : pourquoi chercher à faire une solution plus compliquée qu'une solution déjà existante et qui a fait ses preuves ?

J'ai pas tout lu, mais ce que veut faire Natas (au fait, ton lecteur DVD va bien ? ) me semble particulièrement très bien.
 
Mais mieux : que ce soit sous Linux ou Windows, on peut mapper l'exécution du code de PHP à un compte local de la machine (ou même dans un domaine).
 
Ensuite, je suppose qu'il existe un connecteur pour MySQL étant capable de faire le lien entre des comptes locaux et les comptes de la base de données.
 
A ce moment, il suffit d'activer l'authentification intégrée dans Apache ou IIS afin de forcer l'utilisateur à être correctement identifié.
Ensuite, même pas besoin de passer le login ou l'utilisateur à la base de données, cette dernière doit être capable de retrouver ces infos de la façon la plus sûre possible : l'identité du process PHP.
 
C'est en tout cas de cette façon que marchent la plupart des outils Microsoft qui ont une interface web (Frontpage Extensions, Sharepoint, etc.)
 
Via ce système, c'est le système d'exploitation qui gère la session utilisateur ainsi que l'authentification. Cela permet en outre :
- Une protection totale contre les tentatives d'attaque (avec lock du compte attaqué, etc.)
- Stocker dans un annuaire ldap local ou sur le domaine toutes les infos désirées (mail, etc.)
- Gérer des droits au niveau groupes, etc. (ACL)
 
Bref, en tout cas, avec le trio Windows / IIS / SQL Server, on peut faire ça extrêment simplement, et c'est réellement un gage de sécurité, largement suppérieur à une authentification à la main avec un mdp en md5 tout pourri : c'est l'ouverture à toutes les failles, aux injections SQL et autre lacunes de conception.
 
J'espère bien que le trio Linux / Apache / MySQL en est capable aussi...

 
Pour exporter tes données sur le serveur final: http://dev.mysql.com/doc/refman/5.0/fr/mysqldump.html
 
Pour limiter les droits à une machine, dans la base mysql, dans la table user, t'as un champ host qui permet de restreindre le host depuis lequel un utilisateur peut se connecter De façon plus générale tu as une table host
http://dev.mysql.com/doc/refman/5.0/fr/privileges.html
 

Comme on l'a déjà dit et exposé, les deux méthodes sont utilisées, ont leur avantages et inconvéniants, et surtout leur domaine d'application
 
De plus ton analogie est pas la meilleure si je puis me permettre J'aurais dit: pourquoi utiliser tracteur pour aller acheter ta baguette, plutot
 

oui ton analogie est surement meilleure

avec autrechose que des outils de merde, ça va pourtant tout seul

De quoi parle tu
 
J'ai comme l'impression d'avoir à faire à quelqu'un qui préfère payer des centaines de milliers d'€ pour moins adpaté  

Wow, merci du compliment !  Je me sent un peu moin glon sur le coup. Mais pour autant, et pour avoir suivi les débats, je me rend compte que ce n'est pas la solution désirée au niveau de la portabilité. Mon but serait de faire une application uniquement en interne, les solutions que tu apporte, même si elle demandent certainement un certain temps passé à se documenter, m'auraient semblées les meilleures.

Mais ce que j'envisage c'est de partager mon travail une fois finalisé. [maviepoincom] Le Backoffice que je suis en train de réaliser et de mon point de vue un peu spécial en ça que contraîrement à la mode du moment il ne va pas toucher au design du site mais simplement constituer une interface avec certaines options d'organisation, hiérarchie des rédacteurs et des membres, catégories et sous catégories, multilangages etc... [/maviepoincom]. Je cherche donc à le créer avec un code simple et des méthodes simples, de façon à ce qu'il soit facilement modifiable et surtout portable.

Je choisis donc au final la méthode la plus simple, je vais stocker tous les users dans une table avec leurs pass.
Si d'aventure un admin veut renforcer la sécurité via les droits sql, je pense que deux utilisateurs seront suffisants, un pour connecter les membres avec des droits en lecture uniquement sur certains champs, et un pour les rédacteurs avec les droits en lectures et écritures sur les tables concernées.
Aprés tout je me dis aussi que la premiére des sécurités, c'est de ne pas engager un gar susceptible de nous coller le boxon, et puis choisir un hébergeur qui gère sql correctement, dans le cadre d'une utilisation professionnelle, c'est aussi une bonne chose.

Mais dans tous les cas si un jour j'ai un peu plus le temps de me pencher sur l'administration serveur (pour l'instant ubuntu serveur et samba c'est mon maximum   ) je suivrais tes conseils et me documenterai.

Quant à mon lecteur dvd, si tu fais un tour sur le topic sache que j'ai entre temps grillé encore plus de choses, dont une énorme imprimante de chez rex-rotary   et que l'aventure continue au pays des merveilles.

[hs]
Je suis en train de penser que je suis sur ce forum depuis déjà 7 ans...  et que quant je suis arrivé je faisais joujou avec la balise <marquee> en croyant que ça faisait classe...
[/hs]

Merci tout le monde pour vos conseils. J'ai encore des questions au fait.

- Pour le stockage des mots de passes, j'utilise md5, mais est ce suffisant ?
- Pour les injections, je protège avec htmlentities, si j'ajoute addslashes, c'est redondant non ?

Oilààà sorry pout le squattage d'écran.

Pour les injections, utilise ce qui est prévu pour ton sgbd.
mysql_real_ecape_string pour mysql, par exemple.

Windows 2003 Server Standard Edition : 800 € (500 € pour la Web Edition qui est suffisante)
SQL Server 2005 Express : 0 €
IIS 6.1 : 0 €
 
C'est ça que t'appelle des millions d'euros ?
 
Le temps gagné en n'ayant pas à redévelopper la gestion des autorisations suffit à économiser l'investissement.
Parle de choses que tu connais, merci.

et proprement, t'as déjà pensé à travailler proprement ?
 
faire de l'échappement de chaînes de caractères sans même chercher à contrôler la validité des types des données passées à la requête, tu trouves ça propre ?
 
en php y'a l'intégralité des objets nécessaires pour travailler proprement avec des objets command et des paramètres typés.
vous allez vous mettre à bosser proprement à quelle date bordel ?

 

 
On ne sait même pas quelle version de php il utilise, ni quel sgbd il utilise, etc. Donc on n'a franchement aucune idée de ce qu'il a à disposition qui corresponde à ses besoins.
Il y a de bonnes chances que ce soit mysql, auquel cas le truc disponible dans le maximum des configs installées actuelles est mysql_real_escape_string.
Après s'il est en php5 il a mysqli qui propose un tas de choses supplémentaires, mais ça on ne sait pas...et idem s'il est sous un autre sgbd, il y a des choses utilisables pour faire plus propre, mais sans plus d'infos on ne peut pas deviner.

chuis pas un dieu du PHP, mais je sais deux choses :
- depuis longtemps il existe une interface oledb (qui marche aussi bien sous lunix que windows) dans php, et mysql dispose d'un drivers oledb. ces connecteurs oledb disposent à leur tout de tous les objets dont je parle
- on m'a déjà dit que ces mêmes objets étaient directement utilisables depuis php (quelle version, je sais pas, je te rejoins sur le coup) sans passer par une couche oledb
 
dans tous les cas, mieux vaut proposer selon moins une solution qui peut le plus, mais qui nécessite une version récente, qu'un truc goret qui passe partout alors que le demandeur à la toute dernière version

oledb?
odbc, tu veux dire, p-e?
 
Je lui ai apporté une solution plus propre tout en restant proche de l'approche qu'il a actuellement.
Après tout dépend de ce qu'il veut faire et de ce qu'il a déjà fait...

y'a aussi un connecteur oledb logiquement. anyway, de toute façon c'est le même fonctionnement (y'à que les traîtements internes qui changent)

Travailler proprement, c'est incompatible avec PHP, tout comme travailler efficacement est incompatible avec Java

* "autant faire se peut" alors

Mais non, tu vois le mal partout.
C'est possible, mais c'est pas l'option par défaut, juste.

bon vous exposer des idées.. concrétisont svp...
 
Imaginons, j'ais un serveur avec PHP5, mysql (5 pour le coups). Comment faire pour faire propre.
 
Pourquoi mysql_real_ecape_string c'est pas propre ?

parce que si t'attends un nombre, rien ne te dis que ça va pas être une chaîne de caractères.
parce que si tu veux passer NULL, tu peux pas.
parce que ça te force à bosser avec des paramètres non typés et c'est le mal.

mysqli.
http://fr3.php.net/manual/fr/ref.mysqli.php

quand on travaille proprement, c'est à la couche précédent l'appel de la base qui doit se rendre compte de ce genre d'erreurs.
 
genre tu veux faire un IN qui porte sur des flottants. tu fais quoi pour t'assurer que le gars tapes pas "10,5" qui sera interprété comme "10 ou 5" ? tu passes une chaîne de caractères ? ça va pas marcher des masses...

avec un real_escape_string ça marcherait.
 
Bon sinon, pour faire ça proprement, http://fr3.php.net/manual/fr/funct [...] repare.php

ça semble pas trop pourri mais...
je ne vois toujours pas de notion de type
 
pkoi ils s'obstinent à pas vouloir typer les paramètres des requêtes ?
 
Genre ça :

 
genre...
 
là je passe une chaîne de caractères, je plante avant de faire quoi que ce soit à la base : moi j'attends un number(38) et pas autrechose.
si j'envoie un float aussi je vais planter, parceque j'ai pas de scale (donc à 0), donc je n'attends qu'un entier.
 
bref, c'est quand même pas compliqué !
 
en plus ça permet d'utiliser des paramètres nommés, autrement plus lisibles que des ? dans tous les sens (et surtout, ça permet de passer les paramètres dans le désordre et retrouver ceux qui manquent, mais aussi de passer plusieurs fois le même paramètre dans la même requête, sans devoir l'écrire 25 fois).
 
genre dans mon cas parameterName = ":codsoc"
 
ce qui veut dire que dans ma requête j'ai :
 
select trucmuche from matable where monchamp = :codsoc
 

Bah là ça plante lorsque tu bindes et que le type est pas compatible.

(faut pas oublier non plus que la notion de type, dans php, c'est "un peu" inexistant, en fait...)

ben c'est mysql qui va planter. c'est à dire qu'il est déjà trop tard. c'est la porte ouverte aux tentatives d'intrusion, et dans une application transactionnelle, ça allourdit très grandement les traîtements.
 
sinon, en VBS non plus y'a pas de notion de types, et pourant la syntaxe est quasiment la même.
 
dans l'exemple que j'ai fourni (C# qui utilise les libs d'Oracle -clone des libs standard .NET-) on parle ici de "OracleType.Number" ainsi que de "DBType.Decimal", choses qui n'ont absolument rien à voir avec les types de .NET.
 
c'est la lib par contre qui va vérifier que la variable reçue est bien castable dans le type demandé.

ah tiens en vérifiant il y a le type, dans le bind...
 
 

par contre c'est pas exhaustif, comme truc...
 

ah, c'est déjà pas trop pire
 
y'a encore au boulot, mais au moins ça montre qu'il y a au moins dev de php qui s'est dit que ça pouvait être intéressant

pour ça l'extension pour oracle le fait depuis bien longtemps...il était temps que ça arrive pour mysql, qui reste vachement utilisé...

ce serait d'ailleurs bien qu'ils pense un jour à unifier le connecter comme on fait avec OLEDB (ou ODBC) sur les plateformes Microsoft, d'autant que les versions X-like supportent maintenant ces deux normes la plupart du temps.
 
niveau perfs ça change quasiment rien, et ça permet simplement de faire abstraction du SGBD sans devoir tout changer le code à chaque fois...

Il y a PDO, pour ça, si tout est installé...

mais comme c'est encore plus compliqué de savoir s'il y a tout ce qu'il faut d'installé j'en avais pas parlé avant...

bon, ben alors pkoi tout le monde utilise les fonctions proprio mysql ou autre ?

phpinfo.php

l'habitude.
 
Puis bon t'as pas toujours la main sur le serveur...