Discussion :

[feelwatt]

Bonjour,
Dans mes développements, j'ai l'habitude (idiote ?) de charger les données à chaque rafraîchissement ou changement de page.
Même lorsqu'il n'y a pas eu de modifications de la BD.
>>> Et ca fait travailler les serveurs et ils chauffent et ce n'est pas ce qui est préconisé pour notre belle planète

Généralement, on a deux types de pages:
Pages de listes: ex liste de tous les adhérents avec peu d'infos (nom, prénom,ville, tel, mail)
Page type 'fiche': La fiche d'un adhérent avec cette fois ci tous ces infos.

Alors je me posais cette question,
Est-il judicieux de:

1. Charger tous les listes dans des Array sessions dès l'arrivée du visiteur
   (comme ca plus d'appel à la BD lorsque l'on change de page)
2. Pour les pages 'fiche': Cette fois-çi, charger toutes les infos à partir de la BD en variables normales
   et de recharger uniquement la session de cet adhérent lors d'un Update

• Mais pour les listes ca risque de faire volumineux pour le client,
• il y a-t'il une limites de stockage en ko pour les sessions (notamment pour les Smartphones) ?
• Est que des Cookies seraient mieux ?

Qu'en pensez-vous ?

[rawsrc]

Salut,

la meilleure soluce c'est de faire appel à un serveur de cache de type Memcached.
Laisse tomber le stockage local.
Je préfère de loin réserver le stockage local pour les formulaires multipages par exemple. Ce qui te permet de réafficher les données déjà saisies et ne soumettre le tout une fois la saisie finie.

[feelwatt]

Ah Ok, Memcached.
je vais regarder ca.

[feelwatt]

Salut,
j'ai regardé Memcached,
apparemment il faut l'installer,
aussi, comme je ne sais pas encore sur quel hébergeur, je vais posé mon développement,
je crains de devoir galérer avec l'installation sur l'hébergeur que j'aurais choisi.

Comment fonctionne d'ailleurs ce site developpez.net/
(qui est foisonnant en BD) notamment en forums.

Ils ne doivent pas charger tous les messages de toutes les discutions, si ?

[rawsrc]

Salut,

DVP s'étale (je pense) sur au moins une dizaine de serveurs dédiés (vu le nombre de pages affichées tous les jours et les temps de réponse). Et doit utiliser un gestionnaire de cache performant pour soulager les serveurs BDD.
Après, savoir quels sont précisément les données techniques, c'est confidentiel ne serait-ce que pour des raisons de sécurité (moins tu exposes de surface d'attaque et mieux c'est)

[feelwatt]

Au sujet de la sécurité Mysql et des injections néfastes,
Il y a html specialchars...

Mais je trouve que ca permet à une personne d'essayer plusieurs fois d'attaquer les BD.

J'ai pensé à un truc cette nuit.

1. Faire un array avec tous les termes MySql dangereux (DELETE, TRUNC, DROP, <script ...)
2. Sur les submit, vérifier chacun des POST s'ils contiennent un de ces termes
3. Si c'est le cas: Blacklister l'adresse ip et bloquer le compte en changeant le Mdp

Il y a aussi des requetes utilisant GET,
du type: (SELECT * Form table WHERE id=:id) puis execute(array('id'=>$_GET['id']))
là aussi on peut checker la valeur des GET.

L'idée c'est de virer direct un user qui cherche des noises.
Sans le laisser essayer d'autres choses.

Qu'en pensez-vous ?

[armel18]

Une lib comme phpfastcache propose de mettre en cache les données. phpfastcache te laisse le choix du support de cache(Memcache, redis, Files ...) à utiliser. En choisissant le support de cache Files, phpfastcache va stocker les données de cache dans un fichier plat(le stockage par fichier fonctionne avec n'importe quel hébergeur).
Après il faut définir une politique de mise en cache. quand est-ce que tu décides de mettre les données en cache ? par exemple pendant la mise à jour de la BD tu peux alimenter le cache (vider l'ancien cache au préalable) ou encore alimenter le cache toutes x minutes.
L’intérêt du cache ici c'est d'éviter que l'internaute envoie un ordre SQL tant que les données n'ont pas changés.

Le cache client (côté navigateur) est aussi indispensable pour les besoins d'optimisations.Grace aux entetes http il est possible mettre dans le cache du navigateur du client des ressources(images,css, page html...).

Pour se prémunir des attaques par injections SQL, il faut:
-Filtrer et protéger toutes les données envoyées à MySQL en utilisant soit la fonction mysqli_real_escape_string() soit utiliser des requêtes préparées.
Dans tous les cas il faut systématiquement vérifier les données reçues de l'utilisateur avant de les envoyer à MySQL.

Sur les submit, vérifier chacun des POST s'ils contiennent un de ces termes
Si c'est le cas: Blacklister l'adresse ip et bloquer le compte en changeant le Mdp

En général ce type de blocage se fait du côté du serveur avec l'installation d'un outil comme fail2ban qui permet bannir les IP ayant effectuées plusieurs tentatives de connexion infructieuses ssh, bannir des IP responsables de plusieurs errors apache ou nginx( error 403,404 ...), bannir ceux qui ont saisis des urls interdits .... fail2ban s'appuie sur le parefeu seulement voilà ça ne nécessite une bonne maîtrise de linux.

[feelwatt]

Oulala, ca va être chaud pour moi..

Elle serait comme même bonne, cette idée:
Comparer les POST avec un array de tous les termes dangereux pour MySql ?

[armel18]

Oulala, ca va être chaud pour moi..

Elle serait comme même bonne, cette idée:
Comparer les POST avec un array de tous les termes dangereux pour MySql ?

si toutes les mesures destinées à contrer les attaques de type injections SQL, XSS, CSRF, Middleman ... ont été mises en place du côté applicatif et que les données entrantes ont été filtrées, validées ( ex: tu as attends une date au format dd-mm-yyyy assures toi que la date est bien valide) il n y a aucune raison de contrôler tous les termes dangereux pour mysql.En revanche tu peux faire un journal de logs qui tracent les authentifications( réussies et échouées) pour pouvoir bannir des internautes qui ont essayé de forcer le système.

[feelwatt]

Ok, merci pour les réponses.
> Bien controler le type de données reçues.

Avant de clore le sujet,
une dernière question pour confirmation, ceci est-il bien une requête préparée ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$req_modif = $bdd->prepare("INSERT INTO docs SET comment=:comment"); 
$req_modif->execute(array('comment' => $_POST['comment']));

> Faut-il tout de même utiliser real_escape_string ?

[armel18]

oui bien sûr que c'est une requête préparée faite avec PDO.

par contre la fonction mysqli_real_escape_string est propre à mysqli.Tu utilises déjà PDO tu n'en a pas besoin car elle propre à l'interface mysqli.

[feelwatt]

Ok,
merci Armel

Résolu.

[feelwatt]

Je ré-ouvre le temps de cette question:
Que pensez-vous du window.sessionStorage ?
Cela peut-il soulager les reqêtes ?
debray-jerome.developpez.com/articles/comprendre-le-storage-en-html5/
Merci