Catégorie : Développement

Nous avons déployé récemment notre première application métier sur une plateforme Linux / Apache / Mono / Postgresql sur un serveur tiers, et nous avons eu un problème pas très facile à diagnostiquer et dont je vais partager la solution au cas où cela serve à quelqu’un.

La base de données postgresql était bien configurée en UTF-8, le paramètre serveur « client_encoding » était bien configuré en UTF-8, mais le site persistait à nous afficher les accents de la base avec des « ? », et de même, à l’enregistrement, les accents se transformaient en « ? ». Nous avons regardé la documentation de Npgsql, le driver .NET Postgresql, où nous avons trouvé un paramètre « Encoding » mais déclaré obsolète et comme valant toujours unicode. Nous avons fait exécuter « SHOW client_encoding » qui doit renvoyer la valeur du paramètre pour la session, et avons reçu « UTF-8 ».

Finalement, nous avons trouvé une documentation Npgsql chez Mono qui conseillait d’utiliser le paramètre Encoding avec la valeur UNICODE si on avait des problèmes avec UTF-8 (attention, UNICODE en respectant les majuscules !). Et effectivement, en rajoutant Encoding=UNICODE dans la chaîne de connexion, les « ? » sont redevenus des caractères accentués.

Résumons : la base est en UTF-8, la valeur par défaut pour le codage de caractères de la connexion est UTF-8, la connexion est bien en UTF-8, mais le driver Npgsql embarqué par Mono s’embête à saloper toutes les chaînes avec une option déclarée comme obsolète par les développeurs de Npgsql eux-mêmes… Merci pour ce moment !

share this

Nous utilisons l’excellente bibliothèque native .NET SharpZipLib pour compresser et décompresser ; elle gère les formats tar, bzip2, gz et tar, fournit des implémentations bas niveau surchargeant Stream et plus haut niveau pour des tâches standards comme décompresser directement un zip dans un répertoire.

Dans le cadre de la mise en oeuvre d’un export xlsx pour notre contrôle tableau, j’ai naturellement utilisé SharpZipLib pour compresser les fichiers – xlsx est en ensemble de fichiers XML zippés. Après quelques erreurs venant du format du fichier XML inclus, qu’Excel me reportait clairement (erreur ligne x colonne y dans le fichier z), Excel continua à me dire qu’il avait du corriger mon fichier mais sans m’indiquer aucune erreur. Ouvert avec winrar, le fichier semblait parfaitement conforme ; pire, comparé à la version PHP, le contenu du zip était au caractère près le même, et pourtant Excel ne disait rien sur le fichier généré par la version PHP.

Je me suis donc naturellement tourné vers l’utilitaire de compression ; après quelques tripatouillages d’options, j’ai trouvé la bonne : UseZip64. SharpZipLib supporte Zip64, qui permet d’avoir des fichiers de plus de 4Go inclus dans le zip. Apparemment, il est connu que cette option est mal supportée par de vieilles versions de Winzip et par l’utilitaire de décompression inclus dans l’explorateur de fichiers de Windows XP ; j’ajoute à la liste au moins Excel, je n’ai pas testé avec Word ou PowerPoint mais j’imagine que ça doit être pareil. Pour que ça fonctionne, j’ai du modifier mon code de la façon suivante :

using(ZipOutputStream zos = new ZipOutpuStream(s)) {
  zos.UseZip64 = UseZip64.Off;
  ...
}

D’après la documentation, la valeur par défaut est Dynamic qui devrait déterminer si ça sert à quelque chose d’activer Zip64 ; dans mon cas, aucun fichier ne dépasse les 100ko, et pourtant il m’a activé Zip64, donc je ne sais pas trop quels sont les critères employés mais j’ai du désactiver complètement Zip64 pour qu’Excel soit content. Si ça peut servir à quelqu’un…

share this

Lors de mes recherches sur la proposition d’apprendre le code à l’école du Conseil National du Numérique, j’ai retrouvé plusieurs fois l’idée selon laquelle la programmation pouvait être une activité formatrice au sens où elle promouvait un processus de création par essai – erreur où l’erreur n’était pas considérée comme une sanction définitive mais comme une étape naturelle participant à la construction de la solution. Cette idée est également très régulièrement citée comme un des facteurs de la réussite de la Silicon Valley, où un échec n’est pas considéré comme rédhibitoire, mais comme une expérience valorisable comme une autre.

Encore faut-il que les programmeurs s’intéressent au fait que leur programme soit erroné, et d’après mon expérience, c’est souvent là que le bât blesse.

C’est ballot, mais la moindre modification du code doit être testée !

Je vais reprendre un exemple récent arrivé à un de mes développeurs – si il se reconnait, rien de personnel, c’est pour l’exemple – sur une fonction plpgsql ; ça, c’est la première version qui marche (simplifiée à l’extrême bien sûr) :

CREATE OR REPLACE FUNCTION MAFONCTION(V_ID INT, V_MONPARAMETRE BOOLEAN) RETURNS INT AS $$
DECLARE
 V_RESULT INT:=1;
BEGIN
 UPDATE MATABLE SET MAVALEUR=V_MONPARAMETRE WHERE ID=V_ID;
 RETURN V_RESULT;
END;
$$ LANGUAGE plpgsql;

En relisant les spécifications, le développeur s’aperçoit que j’avais demandé que le deuxième paramètre soit optionnel et ait comme valeur par défaut false, et connaissant mal la syntaxe plpgsql, écrit le code suivant – négligeant de le tester, se disant qu’il n’y avait pas de raison que cela ne fonctionne pas :

CREATE OR REPLACE FUNCTION MAFONCTION(V_ID INT, V_MONPARAMETRE BOOLEAN) RETURNS INT AS $$
DECLARE
 V_RESULT INT:=1;
 V_MONPARAMETRE BOOLEAN:=false;
BEGIN
 UPDATE MATABLE SET MAVALEUR=V_MONPARAMETRE WHERE ID=V_ID;
 RETURN V_RESULT;
END;
$$ LANGUAGE plpgsql;

Pas de bol, il se trouve que les paramètres d’une fonction plpgsql peuvent être nommés, mais que ce n’est qu’une sorte de macro ; posgtresql va remplacer toutes les occurrences du nom choisi dans la fonction par le numéro du paramètre précédé d’un $ ; dans notre cas, postgresql ne le fera pas, puisqu’on a défini une variable dans la clause DECLARE qui écrase le paramètre en entrée, et postgresql ne fera ni erreur ni avertissement. Du coup, la valeur de V_MONPARAMETRE sera toujours false, quoi qu’on passe à la fonction. Le développeur est venu une fois fini le reste du travail demandé me dire que tout était terminé ; mes tests d’intégration n’ont bien sûr pas fonctionné, pas plus que mes tests unitaires. Le développeur était pourtant certain d’avoir vu sa fonction marcher, sans doute avant sa dernière modification qu’il considérait comme tellement triviale qu’il n’y avait pas besoin de la tester.

Un exemple historique… et autrement plus coûteux

Le premier vol d’Ariane 5 s’est achevé au bout de quelques dizaines de secondes, détruisant pour 370 millions de dollars de satellites. La source du problème ? Un module de calcul de poussée de la fusée, repris tel quel d’Ariane 4, dans lequel la poussée était stockée sur une variable d’une taille trop petite pour la nouvelle fusée, munie de moteurs plus puissants ; habituellement, en programmation, quand une variable numérique reçoit une valeur trop grande pour sa capacité de stockage, et en l’absence de vérification, la valeur passe à 0 (cas non signé) ou à la plus petite valeur négative (cas signé), donc en tout état de cause une valeur anormalement basse.

Du coup, la fusée s’est crue dans une position nécessitant une intervention immédiate et radicale du pilote automatique pour rectifier la trajectoire, intervention qui a exercé des contraintes telles sur la fusée qu’elle a commencé à se disloquer, aboutissant à l’enclenchement du mécanisme d’auto-destruction, et à un joli mais très coûteux feu d’artifice. Tout ça pour une variable stockée sur 8 bits au lieu de 9 nécessaires, dans un module repris à l’identique, mais… non testé dans les nouvelles conditions.

De ces deux exemples, on peut déduire une première règle : ne jamais oublier que quelle que soit la petitesse de la modification effectuée sur le code, ce qui n’est pas testé ne fonctionne pas.

Et deux tests valent mieux qu’un…

Une autre de mes activités, récemment en croissance, est de débusquer des trous de sécurité, que ce soit sur des sites nous appartenant ou que nous hébergeons ; rien de très évolué, plutôt du très classique : injection SQL permettant de s’identifier avec n’importe quel compte ou de consulter toute une base de données payante sans l’acheter, cross-site scripting lors de la soumission de données pour intégrer du code actif envoyant discrètement des données du site attaqué vers un tiers ou pour faire du hameçonnage, ce genre de choses. Le point commun de ces défauts de sécurité, également commun avec les classiques attaques buffer overflow à la base de la plupart des failles des systèmes d’exploitation ? Le système définit des entrées – par exemple, le premier paramètre doit être un entier, et le deuxième une chaîne de caractères de moins de 256 octets de long – mais ne vérifie pas que les valeurs passées respectent cette définition.

Tendance bien naturelle : quand on programme la fonction et les appels à la fonction puis que dans la foulée, on effectue les tests, il est assez logique de mettre en oeuvre des tests respectant les contraintes qu’on a soit même définies, elles sont assez fraîches dans notre esprit. De nombreuses façons d’éviter ces erreurs existent : faire écrire les tests par une autre équipe que l’équipe de développement est une parade classique, certains langages de programmation incluent ce type de contraintes dans la signature des fonctions comme Ada par exemple, etc. Mais aucune n’est plus efficace que d’être conscient de la problématique et de la mettre au cœur de ses pratiques !

Ces exemples nous permettent d’énoncer une deuxième règle : ne jamais faire confiance aux données envoyées par le client.

Si vous gardez ces deux règles présentes à l’esprit tout au long de vos développements, quels que soient les outils que vous utilisez, aussi protecteurs que vous pensiez qu’ils soient contre les fautes de programmation, vous aurez fait un grand pas vers la production de programmes conformes et sûrs.

share this

Pour le meilleur et pour le pire, SQLite est l’unique sgbd embarqué sur les principales plateformes mobiles du marché – au moins, il est présent sur toutes, c’est déjà ça.

Pour quelqu’un d’habitué à un sgbdr comme Oracle ou Postgresql, le système de typage de SQLite peut être très déroutant et entraîner des bogues très difficiles à débusquer. Cet article va vous donner quelques trucs pour éviter les plus vicieux.

La documentation ne vous prend pas en traître : les colonnes en SQLite ne sont pas typées statiquement (cf https://www.sqlite.org/datatype3.html). Eux ont l’air de trouver ça génial, vous allez voir que ce n’est pas vraiment mon avis.

Concrètement, qu’est-ce-que ça change ? Quand vous insérez une valeur dans une colonne SQLite, SQLite décide de lui-même d’une « classe de stockage » (storage class) qui peut être NULL, INTEGER, REAL (en virgule flottante), TEXT et BLOB suivant les caractéristiques qu’il perçoit de la donnée que vous lui transmettez.

Mais alors, si SQLite décide du stockage lui-même, à quoi servent les types qui sont données dans les instructions CREATE TABLE ? La réponse est que ce ne sont pas des types, mais des « affinités de types » (type affinities), une sorte de préférence pour le stockage. Pour les exemples ci-dessous, j’emploierai la table suivante :

CREATE TABLE TEST_CRAPPY_TYPING_SYSTEM(
  t text,
  not_quite_float float
);

La première conséquence est que de ligne en ligne, la classe de stockage pour une même colonne peut varier ; par exemple :

INSERT INTO TEST_CRAPPY_TYPING_SYSTEM VALUES('test',500); -- 500 est stocké en INTEGER
INSERT INTO TEST_CRAPPY_TYPING_SYSTEM VALUES('test 2',500.5); -- 500.5 est stocké en REAL

La deuxième conséquence, encore plus rigolote, est que contrairement à l’exemple ci-dessus, la classe peut sembler complètement incompatible :

INSERT INTO TEST_CRAPPY_TYPING_SYSTEM VALUES('test 3','tralala'); -- ne fait pas d'erreur et est stocké en TEXT

Ce qui peut amener si on ne fait pas attention à des cas très vicieux :

INSERT INTO TEST_CRAPPY_TYPING_SYSTEM VALUES('test 4','4,567'); -- stocké sous forme de chaîne, car SQLite ne reconnait pas 4,567 comme un REAL !

Cas particulièrement vicieux car si vous faites :

SELECT not_quite_float * 100 FROM TEST_CRAPPY_TYPING_SYSTEM WHERE t='test 4';

Vous recevez un joli 400 – car SQLite fait un gros effort pour tenter de faire de votre chaîne un nombre, qui s’arrête lamentablement à la virgule ; du coup, vous avez l’impression qu’il y a bien quelque chose comme un nombre dans votre valeur, sauf que non. Ca fait un peu penser à MySQL et son absence d’erreurs sur les débordements numériques, sauf que SQLite a l’excuse de le faire exprès et de le documenter.

Maintenant, si vous exécutez le code C# suivant (j’omets la création de la connexion et toutes les fermetures propres de ressources) :

IDdCommand cmd = conn.CreateCommand();
cmd.CommandText = "SELECT not_quite_float FROM TEST_CRAPPY_TYPING_SYSTEM";
IDataReader rs = cmd.ExecuteReader();
while(rs.Read()) {
  Console.WriteLine(rs.GetValue(0).GetType().FullName);
}

Vous récupérez Int32, Decimal, String, String. C’est un peu mieux que le driver OleDb Excel qui devine le type sur les premières lignes, puis renvoie NULL si il rencontre une valeur qui ne se conforme pas au type qu’il a décidé, mais il vaut mieux être prévenu.

Conclusion : si vous voulez de la cohérence de typage avec SQLite, do it yourself, et si vous avez des résultats étranges avec les types numériques, vérifiez bien ce que vous avez donné à manger à SQLite en insertion.

share this