Reprise du message précédent :
  Ben oui !
... J'ai fait une recherche sur le mot "Windev" dans cette section... Ok, les nobles codeurs d'HFR exècrent.
 
 Bon je m'en vais vers developpez.com qui me semble autrement plus ouvert...

C'est surtout que c'est un topic PHP, tu fait du php avec WindeV ??

Ah oui, zut, je ne suis pas sur le bon topic !

<?php $mention = 'excellent'; echo 'Tu fais un' . $mention . 'travail !' ?>

Quelle est la question ?

manque quelques whitespaces

Bonjour,
 
comment appelle-t-on ce format de donnees ?
 

Serialisation
 
C’est une sortie de la fonction serialize de PHP

merci beaucoup

echo $value; //20

$value a été casté en int

#drapdéguisé
edit: punaise, 1 page en 1 an

drap.
 
Quelqu'un a deja utilisé un CMS sous symfony ? J'en vois quelques un passer: Sulu, VictoireCMS etc... mais jamais testé.

Jamais vu ce topic.
 
Pour revenir sur la problématique des nombres à virgule flottante :

 
1,2 en double binaire s'écrit : 0 01111111111 0011001100110011001100110011001100110011001100110011
2,2 en double binaire s'écrit : 0 10000000000 0001100110011001100110011001100110011001100110011001
7,2 en double binaire s'écrit : 0 10000000001 1100110011001100110011001100110011001100110011001100
8,2 en double binaire s'écrit : 0 10000000010 0000011001100110011001100110011001100110011001100110
 
-1 en double binaire s'écrit :  1 01111111111 0000000000000000000000000000000000000000000000000000
-2 en double binaire s'écrit :  1 10000000000 0000000000000000000000000000000000000000000000000000
 
Je vous laisse faire les additions et découvrir le résultat. (bon c'est galère les calculs en IEEE 754 alors je suis gentil je vous laisse un lien : http://weitz.de/ieee/ )
La conversion float --> integer va tronquer le nombre ce qui explique les premiers résultats.
Le résultat de 100 * 0.19999999999999999 s'explique par la capacité limité du double.
 
L'astuce est donc d'arrondir le résultat du calcul avant d'opérer la conversion de type.

Hello,
 
Cela vous arrive souvent que le lead dev de votre équipe commite directement du code sur le master en omettant de déclarer ses méthodes et tests, ce qui donne des erreurs 500 partout lors du déploiement en prod ?
 
Cela n'arrive t-il qu'à moi ou je rêve éveillé ? ..  

tester c'est douter
corriger c'est abdiquer

L'erreur est humaine, oublier de commiter des changements ou coder des conneries ça arrive

Ce qui est étonnant ici c'est que ce soit déployé. Vous avez pas de CI? Ou pas même un process de qualif basique, au pire manuel, avant de deployer ?

Qq'un a désactivé certains tests apparement, au lieu de les maintenir, return true cela ne s'invente pas ..  
 
En même temps il sort de sa super école, c'est son 1er poste est nous casse les pieds car il manque une étoile dans un docblock ..

Et il est lead dev !?  

 
+1000 Y'a un ptit soucis chez vos RH

Question du jour :
J'ai une appli web, avec plusieurs utilisateurs, chaque utilisateur peut stocker des fichiers dans l'appli, ces fichiers doivent être chiffrés sur le disque du serveur.
Pour chaque user j'ai donc généré une clé. Pour l'instant cette clé est stockée en clair dans la bdd (et par exemple pas chiffrée via le pass de l'utilisateur) car le risque de perte de mot de passe des utilisateurs est important et ils voudront absolument pouvoir récupérer leurs fichiers même s'ils ont perdu leur pass.
Du coup ça me fait un peu bizarre que l'appli chiffre direct les fichiers avec la clé qui est en clair dans la base de données, mais en même temps je ne vois pas trop l'intérêt d'aller plus loin :
- soit la bdd est compromise et du coup elle permet de récupérer la clé, ok mais on n'en fait pas grand chose, c'est juste une chaine qui ne permet d'accéder à rien (c'est pas un mot de passe permettant l'accès à l'appli par exemple)
- soit l'accès aux fichiers du serveur est compromis, ce qui veut dire que le "hacker" aura accès aux fichiers stockés (code + fichiers utilisateur), donc au mot de passe de la bdd (dans le fichier de config php), donc en fait à tout et donc rien de ce que je puisse faire par ailleurs n'apportera la moindre protection.
 
Je passe à côté de quelque chose ? Il y aurait mieux à faire ?
 
Les 2 autres approches auxquelles je pense :
- chiffrer la clé utilisateur via une fonction quelconque via l'appli avant de la stocker en bdd (et la déchiffrer avant de l'utiliser). Mais comme je disais plus haut, si quelqu'un à accès au système de fichier ça n'apporte pas grand chose.
- trouver une solution (un système avec 2 clés) pour par exemple chiffrer/déchiffrer les fichiers avec une clé (fixe) issue de l'appli et une autre issue de l'utilisateur (stockée dans la bdd). Esprit "banque" où il faut la clé de la banque et celle du client... en pratique je ne vois pas trop comment chiffrer un fichier (j'utilise sodium) avec 2 clés. En gros comment générer une 3è clé (qui sera toujours la même) à partir d'une fonction prenant en entrée 2 clés différentes. Une clé (après un bin2hex) c'est 64 caractères hexa, je ne me vois pas les additionner Après même chose qu'au dessus : si on a accès aux fichiers, on à accès aux 2 clés.
 
Bref je suis preneur d'idées sur le sujet qui apportent une amélioration de la sécurité générale, et pas juste de la complexité qui ne sert à rien

Autre question, cette fois sur les "prepared statements" pour les requêtes SQL.
 
Vous "préparez" toutes les variables, même celles dont vous êtes sûrs ou seulement celles qui proviennent de l'extérieur ?
 
Exemple :
J'ai un select qui requiert le passage d'une clé à tous les champs chiffrés en bdd (via AES_ENCRYPT et AES_DECRYPT), donc en gros, chaque select devient un truc du genre ;

 
Sachant que là j'ai juste mis quelques éléments, mais typiquement :
- $user_id est un truc totalement interne, absolument pas manipulable de l'extérieur (id de l'utilisateur courant, stocké en bdd/session...)
- $macle est le résultat d'une fonction qui va récupérer la clé de l'utilisateur $user_id
Bref, ces choses là sont "fixes", et je me vois mal polluer tous les bind_param avec ça car pour le moindre select ça va me faire style 10 ou 20 paramètres, auxquels il faut que j'ajoute le type, ... déjà qu'en temps normal c'est illisible, alors si je rajoute ça... En même temps ça fait un peu bricolage de passer des trucs en dur et d'autres en paramètres de statement...
 
Avis ?

Prepared statement. Le jour où ta méthode de récupération de $user_id ou $macle change ou si elle se révèle finalement vulnérable t'auras l'air malin avec tes trucs en dur à changer partout...

du coup des conseils particulier, on est obligé de se taper la ligne à la con avec  

?
J'arrive pas à comprendre que quelqu'un ait pu pondre un truc aussi illisible que de concaténer en une chaîne les types de paramètres.
Vous rajoutez une couche d'abstraction pour passer par exemple un tableau type/paramètre et que ça génère la fonction bind_param() tout seul ?
 
Il y a aussi un truc qui m'irrite un peu, parfois j'ai des parties de requêtes conditionnelles,  
genre si une case est cochée dans un formulaire de recherche alors ça ajoute carrément un bout de requête sql complet.
ex :

et dans la query, j'ai

 
Ca dépend de la complexite, là j'aurai aussi pu faire un  

 
Je ne vois pas trop comment passer ça en prepared statement sans doublonner la requête et la liste totalement.

Tu peux utiliser des paramètres nommés pour préparer ta requête, et peut-être mettre tes conditions dans un tableau que tu concatènes à la fin.
 

$and = [
    "x = :param_x"
];
 
$params = [
    ":param_x" => "y"
];
 
if(isset($_POST['macheckbox'])) { 
    $and[] = "machin = :param_machin";
    $params[":param_machin"] = $contenu_champ_texte_associe_a_la_checkbox;
} 
 
$query = "SELECT * FROM table WHERE " . join(" AND ", $and) . " ORDER BY foo ASC";
 
$stmt = $db->prepare($query);
$stmt->execute($params);

 
Toutes
 
Je ne vois pas l'intérêt de mixer les deux usages, d'autant que l'un est à proscrire (cf la réponse de skeye)

variables nommées, oui, et ça devient tout de suite largement lisible.

ha les paramètres nommés, visiblement c'est un truc spécifique à PDO, je passe par mysqli

Tu peux utiliser un query builder pour abstraire tout ça.

Des suggestions ? (recommandé par l'expérience de l'usage hein, pas juste des noms).
 
J'ai toujours une certaine apréhension vis à vis de ce genre de chose.
Je me traine par exemple dans pas mal de mes projets 2 outils un peu pénibles :
- une vieille couche d'abstraction d'accès à la bdd issue de... phpBB des années 2000. Il manquait plein de trucs, c'était plus mis à jour (ça a trop changé pour être compatible)...
- un vieux smarty 2, plus trop mis à jour, un miracle que ça fonctionne encore sur php 7.2 par exemple
 
La couche d'abstraction à la base de données par exemple elle fait beaucoup de passe plat sans grand intérêt, elle permet certes une bascule plus facile d'un système à l'autre mais n'améliore pas la facilité d'utilisation. Par contre une fois utilisée, tu deviens dépendant de cette couche, là par exemple pour switcher sur pdo (non prévu dans la librairie) ça veut dire soit dégager la couche d'abstraction et tout réécrire, soit créer un nouveau type de base pour la couche d'abstraction à la main (vla le boulot) et malgré tout se taper une bonne dose de réécriture du code de l'application car par exemple rien n'est pris en compte pour les "named parameters".
 
Smarty, marrant au début, ça impose un peu de rigueur de séparation de code, mais devenir dépendant d'une couche supplémentaire alors qu'on pourrait le faire nativement d'une manière très proche directement en php c'est pas forcément si futé que ça.

Tu bosses avec quel SGBD ?

Mysql

La référence actuelle c'est Doctrine DBAL : https://www.doctrine-project.org/projects/dbal.html

Je poursuis mes recherches sur l'aspect sécurisation des saisies/stockage bdd/réaffichage.
 
En fait le net pullule de morceaux de tutos ou de conseils généraux*, mais j'ai du mal à mettre la main sur un ensemble de code cohérent qui gère le processus global.
 
Mes questions en suspens :
1/ la meilleure manière de gérer les "input text" généraux (type nom, prénom, adresse postale...) à la saisie : en gros on filtre comment (regex ?) OU alors aucune vérification vu que c'est fait automatiquement par les prepared statements de la bdd ? Genre avant de faire un insert en bdd on fait une étape isset($_POST['nom']) ? un is_numeric($_POST['montant_euros_ht']) ou tout autre type de is_valid() ou ce genre de chose ?  
2/ idem pour des inputs pouvant contenir du html (champ libre avec un tinymce ou équivalent) ???
3/ en cas de non conformité on rejette comment ? un die("allez vous faire..." ) barbare ? parce que comme on a filtré en JS en amont, si on tombe sur l'erreur en php c'est très probablement une tentative de hack donc on s'en fout de faire un joli message d'erreur ; ou alors à l'opposé on se fait des try/catch ou que sais-je ? comment retourner proprement l'erreur, ne pas risquer d’exécuter du code "suivant" en cas de saisie incorrecte en amont ?  
4/ insertion en BDD je commence à voir (on en a parlé pas mal plus haut)
5/ réaffichage html de ces données (stockées en bdd) : un des 2 tutos plus bas évoque le fait qu'il faut systématiquement échapper tout ce qui vient de la bdd sur le principe du "si la bdd est hackée, on peut ajouter n'importe quoi dedans et donc c'est des données potentiellement dangereuses (code php, javascript...)" donc en gros tout echo $row['nom'] devrait devenir un echo htmlentities($row['nom']). Vous faites vraiment ça ? Si oui vous le faites pour chaque affichage (au plus près du html, via echo) ou en amont lorsque vous récupérez les données de la bdd et stockez les données "échappées" dans un tableau en attendant leur utilisation (via moteur de template par ex) ?
 
 
* 2 url sympa :
https://paragonie.com/blog/2017/12/ [...] p-software -> bon guide sur la sécurisation
https://phptherightway.com/#code_style_guide -> guide complet sur pas mal de bonnes pratiques php

up
 
j'ai poursuivi mes recherches sans jamais vraiment avoir de conseils clairs.
Tout le monde dit "c'est idiot de tenter de filtrer avant l'insertion en bdd", c'est le rôle des prepared statement et compagnie, mais je trouve que si oui ça protège de l'injection SQL, ça ne protège pas de problèmes d'insertion du type "valeur saisie trop longue" (ex : champ prénom varchar(255) en bdd -> quelqu'un saisait 500 caractères... ben ça va faire planter la requête SQL. Même chose pour les champs numériques non integer, gérés en tant que "string" par PDO. Donc si quelqu'un saisit "toto" là où un décimal est attendu, ça va aller direct en bdd et péter la requête.
Bref, vous faite quoi vous ?

et bien tu regardes si la requetes s'est bien passée. Quel que soient les contrôles que tu fais ça pourra péter au niveau du serveur de base de données ( disque plein , coupure réseau, mise à jour de la base en cours, ...)-

Je ne suis pas pro, et je suis partisan du filtrage en amont, ce qui n'empêche pas de vérifier le statut de la requête.

Après statistiquement parlant, tu vas en quelque sorte double check toutes tes données alors qu'une infime partie ne seront pas bonnes, tu vas donc économiser le coût de quelques requêtes erronées. Mieux vaut donc faire un simple check au niveau de la requête afin d'économiser un check et de payer dans de rares cas le coût des requêtes erronées.
Sachant que tu pars du fait que les données sont déjà vérifiées en amont par JS, et que si ce n'est pas le cas, l'utilisateur sait ce qu'il fait.

Le mec qui met 500 caractère au lieu de 255 dans le champs "nom" ça me fait un peu penser à Zezette épouse X.
 
Ta requête ne vas pas planter (encore je suppose que ça doit dépendre des BDD), sur Mysql en tout cas elle vas juste être couper pour ne garder que les 255 premiers.
Du coups la solution de prévenir en JS en amont que le champs ne doit pas excéder 255 caractère me semble aussi la meilleur...

Après, à voir si le script peut être utilisé de manière ouverte, par exemple tu proposes à des utilisateurs de pouvoir raccorder leur appli à ton script, dans ce cas là mieux vaut inclure une vérification dans le script avant d'effectuer les requêtes.

Ca réonds pas vraiment à la question, mais c'est lié : pour des APIs, je laisse ce boulot à une couche de validation des I/O à base par exemple de JSON Schema qui va valider (ou pas) chaque objets/propriétés en fonction du schéma defini.

Merci des retours.
En fait sur un champ "'nom" par exemple on pourrait facilement rejeter un paquet de caractères histoire de s'éviter de stocker <script>alert("toto" )</script> (ou plus méchant) en bdd (ce qui est une chaine parfaitement valide d'un point de vue sgbd/injection sql.
Certes je suis censé l'échapper systématiquement si je l'affiche, mais c'est quand même un peu risqué non ?
 
On peut aussi se poser la question : si ce que je demande à saisir est dans un formulaire html (une page web quoi), ne suis-je pas censé stocker les données saisies au format html, c'est-à-dire en encodant les caractères avec leurs valeurs html (genre "<" devient &lt; en base de données) ?

1/ nom, si tu l'échappes correctement, tu ne prends pas de risque  
 
2/ non, car si tu utilises les données pour un autre usage, tu vas devoir repartir à la peche aux entités html pour refaire la mécanique inverse ( par exemple un publipostage, un mail en text)

Donc de votre côté vous passez directement les var du type $_POST['nom'], $_POST['adresse'], $_POST['commentaire'], ... aux "prepared statements" d'une requête SQL ?