Téléchargé 5 fois
Vote des utilisateurs
0 
0
Détails
Licence : Non renseignée
Mise en ligne le 5 avril 2020
Plate-forme :
Linux
Langue : Français
Référencé dans
Navigation
Walousql
Walousql
Walousql est un SGBD (système de gestion de base de données) en PHP qui ne nécessite aucun autre moteur ou logiciel. Les données sont directement stockées au même endroit que vos scripts.
Nos ressources disponibles
Toutes les informations sur : walousql.kaixo.fr
Bonjour,
Je vous propose un nouvel élément à utiliser : Walousql
Walousql est un SGBD (système de gestion de base de données) en PHP qui ne nécessite aucun autre moteur ou logiciel. Les données sont directement stockées au même endroit que vos scripts.
Qu'en pensez-vous ?
Je vous propose un nouvel élément à utiliser : Walousql
Walousql est un SGBD (système de gestion de base de données) en PHP qui ne nécessite aucun autre moteur ou logiciel. Les données sont directement stockées au même endroit que vos scripts.
Qu'en pensez-vous ?
D'un point de vue sécurité y'a intérêt d'être sacrément carré dans ce qu'on donne à ton système.
Y'a t'il des gardes fou qui éviterais l'injection de code ?
Y'a t'il des gardes fou qui éviterais l'injection de code ?
Bonjour Rawsrc,
Déjà, merci de t'être intéressé à ma source. Je me permets de préciser mes motivations pour la création d'une telle classe :
J'ai travaillé sur des transferts de sites Internet de serveur à serveur. Je me suis alors rendu compte qu'il y avait beaucoup de WordPress pour juste une douzaine de posts. Ce qui revient à utiliser la bombe H pour tuer un coléoptère. Et de manière générale, j'ai relevé un gros défaut des développeurs : ils se précipitent sur l'utilisation d'une base SQL pour stocker une poignée de données.
D'un autre côté, les hébergeurs ouvrent beaucoup plus facilement des accès aux scripts qu'aux bases de données. J'ai même vu un gros site se connecter à la base en root !
Enfin, j'ai récupéré des sites en PHP5 et pour les adapter à PHP7, ce qui veut dire changer tous les mysql_xxxxx en mysqli_xxxxx...
Je suis actuellement sur un projet créations de plusieurs petits sites pour des petits clients sur un serveur que je gère. Un client voulait avoir accès aux sources, quitte à changer d’hébergement. J'ai naturellement pensé à SQLite. Mais chez certains hébergeurs, on peut être amener à modifier le php.ini. Et l'édition des tables nécessitent un logiciel.
C'est pour ça que j'ai eu l'idée de créer une petite classe prête à l'emploi (sans rien modifier sur le serveur), compatible PHP5 et PHP7, qui permet de jouer avec des petites bases de données.
Walousql est SGDB et non un SGBDR. Il est plus dans l'esprit d'un NoSQL (d'où le nom : "walou" qui signifie "rien du tout" en argot). Donc il n'y a pas de notion native de jointure. Je t'avoue que ça m'a aussi gêné. Mais pour palier ce manque, il y a deux remèdes :
1/ Walousql peut stocker nativement des structures plus complexes qu'en SQL, comme des tableaux de tableaux.
2/ Par mon expérience, j'ai remarqué que les jointures appellent rarement plus de deux ou trois tables. L'équivalent en Walousql n'est pas non plus trop laid :
Pour la fonction search, j'ai voulu mettre des "vrais/faux morceaux" de SQL. J'aurais pu mettre "NOT NULL" à la place de "!null", comme il existe "and" à la place de "&&". Ta remarque est très judicieuse. Je te promets d'en tenir compte à la prochaine mise à jour !
Pour la gestion de la mémoire, je suis tout à fait d'accord avec toi. Plus que de charger toute la table en mémoire en lecture, c'est de réécrire toute la table qui me semble très gourmand. J'ai donc pensé à décomposer les tables en plusieurs fichiers PHP. Une telle gestion aurait eu deux inconvénients :
1/ Il aurait rendu la classe beaucoup plus compliquée et se serait éloigné de l'esprit "less is more" de départ
2/ L'édition des tables à la volée (pour ne pas dire à l'arrache) avec un éditeur de code aurait été moins aisée
Je peux me tromper, mais le var_export que j'utilise est en quelques sorte un mécanisme de sérialisation. Ou du moins, un cousin très proche. J'avais pensé stocker les données en JSON. Mais l'avantage du var_export est de pouvoir utiliser un simple include pour la lecture, sans aucune "dé-sérialisation". Je pense d'ailleurs ajouter pour une prochaine version une option permettant de stocker les données en JSON pour les rendre compatibles avec d'autres langages (comme mon chouchou Python).
Dans les conditions du réel, j'ai récupéré le site d'un restaurant existant depuis presque deux ans (avec suggestions du jour, réservations, avis, etc.) en MySQL que j'ai migré en Walousql. Le transfert de données s'est fait instantanément et le site ne souffre d'aucun ralentissement.
En revanche, j'ai essayé d'utiliser Walousql pour un autre projet en tentant d'exploiter toutes les transactions immobilières sur ces 5 dernières années (plus de 10 millions d'enregistrements). Je me suis vite rabattu sur MariaDB
En tout cas, je suis très heureux de voir que ma petite contribution suscite un peu de curiosité !
Déjà, merci de t'être intéressé à ma source. Je me permets de préciser mes motivations pour la création d'une telle classe :
J'ai travaillé sur des transferts de sites Internet de serveur à serveur. Je me suis alors rendu compte qu'il y avait beaucoup de WordPress pour juste une douzaine de posts. Ce qui revient à utiliser la bombe H pour tuer un coléoptère. Et de manière générale, j'ai relevé un gros défaut des développeurs : ils se précipitent sur l'utilisation d'une base SQL pour stocker une poignée de données.
D'un autre côté, les hébergeurs ouvrent beaucoup plus facilement des accès aux scripts qu'aux bases de données. J'ai même vu un gros site se connecter à la base en root !
Enfin, j'ai récupéré des sites en PHP5 et pour les adapter à PHP7, ce qui veut dire changer tous les mysql_xxxxx en mysqli_xxxxx...
Je suis actuellement sur un projet créations de plusieurs petits sites pour des petits clients sur un serveur que je gère. Un client voulait avoir accès aux sources, quitte à changer d’hébergement. J'ai naturellement pensé à SQLite. Mais chez certains hébergeurs, on peut être amener à modifier le php.ini. Et l'édition des tables nécessitent un logiciel.
C'est pour ça que j'ai eu l'idée de créer une petite classe prête à l'emploi (sans rien modifier sur le serveur), compatible PHP5 et PHP7, qui permet de jouer avec des petites bases de données.
Walousql est SGDB et non un SGBDR. Il est plus dans l'esprit d'un NoSQL (d'où le nom : "walou" qui signifie "rien du tout" en argot). Donc il n'y a pas de notion native de jointure. Je t'avoue que ça m'a aussi gêné. Mais pour palier ce manque, il y a deux remèdes :
1/ Walousql peut stocker nativement des structures plus complexes qu'en SQL, comme des tableaux de tableaux.
2/ Par mon expérience, j'ai remarqué que les jointures appellent rarement plus de deux ou trois tables. L'équivalent en Walousql n'est pas non plus trop laid :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 |
$walousql = new walousql();
$walousql->setTable('table1');
$table1 = $walousql->selectAll();
$walousql->setTable('table2');
foreach ($table1 as $key1 => $row1){
$rows2 = $walousql->selectByKey($row1['un_id_dans_la_table1']);
} |
Pour la gestion de la mémoire, je suis tout à fait d'accord avec toi. Plus que de charger toute la table en mémoire en lecture, c'est de réécrire toute la table qui me semble très gourmand. J'ai donc pensé à décomposer les tables en plusieurs fichiers PHP. Une telle gestion aurait eu deux inconvénients :
1/ Il aurait rendu la classe beaucoup plus compliquée et se serait éloigné de l'esprit "less is more" de départ
2/ L'édition des tables à la volée (pour ne pas dire à l'arrache) avec un éditeur de code aurait été moins aisée
Je peux me tromper, mais le var_export que j'utilise est en quelques sorte un mécanisme de sérialisation. Ou du moins, un cousin très proche. J'avais pensé stocker les données en JSON. Mais l'avantage du var_export est de pouvoir utiliser un simple include pour la lecture, sans aucune "dé-sérialisation". Je pense d'ailleurs ajouter pour une prochaine version une option permettant de stocker les données en JSON pour les rendre compatibles avec d'autres langages (comme mon chouchou Python).
Dans les conditions du réel, j'ai récupéré le site d'un restaurant existant depuis presque deux ans (avec suggestions du jour, réservations, avis, etc.) en MySQL que j'ai migré en Walousql. Le transfert de données s'est fait instantanément et le site ne souffre d'aucun ralentissement.
En revanche, j'ai essayé d'utiliser Walousql pour un autre projet en tentant d'exploiter toutes les transactions immobilières sur ces 5 dernières années (plus de 10 millions d'enregistrements). Je me suis vite rabattu sur MariaDB
En tout cas, je suis très heureux de voir que ma petite contribution suscite un peu de curiosité !
Bonjour Grunk,
Pour avoir été victime il y a quelques temps de très lourdes injections SQL, j'ai évidement pensé à la sécurité...
Si le serveur est bien configuré, c'est l'utilisateur "apache" qui exécute les scripts PHP. Donc il ne peut pas trop faire ce qu'il veut dans des dossiers sensibles.
Les noms de tables doivent répondre à une expression régulière assez stricte qui interdit les "/" et les "\".
Ainsi, il n'est pas possible de faire des :
C'est dommage, j'aurais bien aimé utiliser des tables dans des dossiers pour un meilleur classement, mais j'ai préféré privilégier la sécurité.
De plus, Walousql ne lit et n'écrit que dans des documents qui se terminent par ".table.php".
Enfin, je fais confiance à var_export pour sécuriser le contenu des tables. var_export gère tout seul les simples et doubles quotes, retours à la ligne, et autres caractères exotiques.
Pour avoir été victime il y a quelques temps de très lourdes injections SQL, j'ai évidement pensé à la sécurité...
Si le serveur est bien configuré, c'est l'utilisateur "apache" qui exécute les scripts PHP. Donc il ne peut pas trop faire ce qu'il veut dans des dossiers sensibles.
Les noms de tables doivent répondre à une expression régulière assez stricte qui interdit les "/" et les "\".
Ainsi, il n'est pas possible de faire des :
| Code : | Sélectionner tout |
1 2 3 |
$walousql->setTable('/etc/httpd')
$walousql->setTable('../../../') |
De plus, Walousql ne lit et n'écrit que dans des documents qui se terminent par ".table.php".
Enfin, je fais confiance à var_export pour sécuriser le contenu des tables. var_export gère tout seul les simples et doubles quotes, retours à la ligne, et autres caractères exotiques.
Pour moi c'est justement l'utilisation de var_export qui est le risque le plus important.
A mon avis en cherchant un petit peut il est relativement simple d'injecter du code PHP qui va s'executer, par exemple, en le plaçant au millieu du texte d'un article.
C'est le problème de stocker du code et non des chaines (comme dans une bdd classique). Si je veux enregistrer un article (par exemple) il est extrêmement difficile dans un texte de détecter que ce que je vais enregistrer est du code malicieux et non un simple texte.
Mais dans un environnement très contrôlé pourquoi pas
C'est surtout une question de rentabilité. Un wordpress ca se met en place en 5 min chrono. 2 plugins et un thème plus tard le client à son site prêt. C'est pas optimisé , c'est pas pro mais c'est rentable , c'est pour ca que quasi la totalité des agences web fonctionne comme ca.
Ca c'est la maladie des dév qui ne font que du web et ne font pas d'autre langage plus orienté client lourd , où généralement, la bdd est le dernier choix.
Ca c'est un problème de dev pas compétent/ pas à jour. Ça fait 15 ans que PDO existe , ca fait 15 ans que ca devrait être utilisé par tout le monde et ce genre de problème n'existerait pas.
Je pense que ta lib est un exercice intéressant, mais j'y vois trop de risque.
Toutes les solutions à base de fichiers plats fonctionnent en général sur des fichiers text (dokuwiki, picocms, grav cms ,etc ...)
A mon avis en cherchant un petit peut il est relativement simple d'injecter du code PHP qui va s'executer, par exemple, en le plaçant au millieu du texte d'un article.
C'est le problème de stocker du code et non des chaines (comme dans une bdd classique). Si je veux enregistrer un article (par exemple) il est extrêmement difficile dans un texte de détecter que ce que je vais enregistrer est du code malicieux et non un simple texte.
Mais dans un environnement très contrôlé pourquoi pas
Je me suis alors rendu compte qu'il y avait beaucoup de WordPress pour juste une douzaine de posts. Ce qui revient à utiliser la bombe H pour tuer un coléoptère.
j'ai relevé un gros défaut des développeurs : ils se précipitent sur l'utilisation d'une base SQL pour stocker une poignée de données.
Enfin, j'ai récupéré des sites en PHP5 et pour les adapter à PHP7, ce qui veut dire changer tous les mysql_xxxxx en mysqli_xxxxx...
Je pense que ta lib est un exercice intéressant, mais j'y vois trop de risque.
Toutes les solutions à base de fichiers plats fonctionnent en général sur des fichiers text (dokuwiki, picocms, grav cms ,etc ...)
Grunk,
Je surestime peut-être var_export, mais cette fonction ne me paraît pas plus exposée aux injections que les BindParam de PDO.
J'ai essayé en mettant un /* en plein milieu d'un texte par exemple : aucun problème à l'écriture, ni à la lecture.
Sincèrement, je serais le premier intéressé si tu trouves une faille qui pourrait faire "vaciller" var_export
Bien sûr, je ne parle pas de bidouille avec le HTML en mettant l'ouverture d'une balise qui ne se ferme pas (ou de <!--)... Comme avec SQL, c'est au développeur de gérer ça.
Je surestime peut-être var_export, mais cette fonction ne me paraît pas plus exposée aux injections que les BindParam de PDO.
J'ai essayé en mettant un /* en plein milieu d'un texte par exemple : aucun problème à l'écriture, ni à la lecture.
Sincèrement, je serais le premier intéressé si tu trouves une faille qui pourrait faire "vaciller" var_export
Bien sûr, je ne parle pas de bidouille avec le HTML en mettant l'ouverture d'une balise qui ne se ferme pas (ou de <!--)... Comme avec SQL, c'est au développeur de gérer ça.
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.