egxtech Posted January 23, 2015 Share Posted January 23, 2015 (edited) Bonjour à tous J'ai développé un module et dans celui ci je me connecte à une base de donnée externe (celle de mon entreprise) (pour récupérer, mettre à jour, insérer ou encore supprimer des données). La connection se fait avec PDO (du type new PDO($host,$dbname,$user,$pass) Ensuite un tas de fonctions avec des reqûetes, etc J'ai 2 questions: - Ce module étant destiné à être distribué à plusieurs entreprises comment faire pour ne pas avoir le mot de passe de connection à la BDD en clair ? - Comment faire pour empêcher quelqu'un de mal intentionné à faire des requêtes non prévues ? Merci d'avance ! bonne journée Edited January 23, 2015 by egxtech (see edit history) Link to comment Share on other sites More sharing options...
J. Danse Posted January 23, 2015 Share Posted January 23, 2015 La seule solution est de ne pas faire vos appels à la DB dans le module lui-même. Vous pourriez très bien stocker le mot de passe dans un fichier distant, mais il doit être récupérer: il sera possible de le faire également de la même manière que si en dur dans le module... Pour moi, la solution est d'avoir une API externe. C'est non seulement plus sécurisé mais aussi plus pratique. Pour ma part, j'utilise dans l'ensemble de mes modules un appel à une "api" très light (c'est quasi qu'un switch en php) me permettant par exemple de créer un ticket dans mon système externe. Link to comment Share on other sites More sharing options...
egxtech Posted January 23, 2015 Author Share Posted January 23, 2015 Merci pour la réponse, oui pour l'api forcément ça serait une bonne solution mais pour l'instant comme celle ci n'est pas finalisée on voulait faire sans.Quid d"un cryptage du code php ? genre obfuscation ? Link to comment Share on other sites More sharing options...
J. Danse Posted January 23, 2015 Share Posted January 23, 2015 Il n'existe pas de réelle obfuscation en PHP. Encore une fois, si le module est "publié" et que quelqu'un est mal intentionné, il lui sera simple de faire une marche arrière du code obfusqué et donc d'obtenir le mot de passe. Honnêtement, que le mot de passe soit en clair ou dans un faux semblant d'obfucation, l'utilisateur lambda ne le verra pas. Quant à un utilisateur mal intentionné, peu importe la manière. 1 Link to comment Share on other sites More sharing options...
Whoami Posted January 23, 2015 Share Posted January 23, 2015 Bonjour, J'appuie les dires de PrestaEdit pour insister sur l'API, y compris pour répondre à ta deuxième question. L'avantage étant que tu peux totalement cloisonner ton module sur les opérations possibles sur ton serveur et ta DB. Je passe systématiquement par l'étape de création d'un mini-API/mini-WebService dès que les clients ont besoin d'intervenir sur les données de modules personnalisés (généralement pour la récupération de données collectées, statistiques, etc.). Si tu fais les requêtes directement dans le module, il suffit au client qui le reçoit de modifier le code du module (obfuscation ou pas, c'est juste "un peu" plus long pour qui s'y connait un minimum) pour trouer littéralement la sécurité de la base distante. Ou alors tu as prévu tous les cas invraisemblables, chose qui en général n'est pas possible Link to comment Share on other sites More sharing options...
egxtech Posted January 23, 2015 Author Share Posted January 23, 2015 Oui c'est sûr que quelqu'un de mal intentionné pourra toujours agir s'il le souhaite. Bon bah va falloir passer par la case API alors ^^, histoire de ne prendre aucun risque . Merci de m'avoir répondu en tout cas je vais mettre en résolu. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now