rend plus lisible

CONTRIBUTING.md

@@ -25,6 +25,125 @@ Contribuer
 
 - branche sur laquelle hawkspar développait la version "orienté objet" de ldap_data.js
 
+
+
+## Structure
+
+La structure générale du projet est détaillée ci-dessous ; pas d'inquiétude, la plupart des fichiers .js sont aussi extensivement documentés plus bas.
+
+* Racine du projet : fichiers de configuration ;
+  * config.json : données "sensibles" spécifique au projet à priori non partageable (adresse du LDAP, mots de passe),
+  * configfile_doc.json : JSDoc, l'outil de génération automatique de documentation,
+  * autres fichiers relatifs à des modules particuliers ou à la gestion de paquets,
+  * [`assets`](../assets) : ressources ;
+    * images et divers (dont l'essentiel flavicon)
+  * [`build`](../build) : dépendances gérées automatiquement ;
+    * bundle.js est un monstrueux fichier généré automatiquement qui gère nos dépendances.
+  * [`db`](../db) : base de donnée sigma ;
+  * knex_router.js charge la configuration précisée dans knexfile.js,
+    * [`migrations`](../db/migrations) stocke l'ensemble des migrations knex ; c'est un équivalent d'un répertoire git pour la BDD sigma (du coup seulement les groupes pas les individus),
+    * [`seeds`](../db/seeds) : stocke les éléments de générations des BDD ; c'est un ensemble de scripts.
+  * [`doc`](.) : documentation ;
+    * ensemble de pages html et fichiers associés ; index.html permet de naviguer sereinement sur toute la doc JSDoc.
+  * [`node_modules`](../node_modules) : gestion automatique des modules.
+  * [`src`](../src) : code source
+    * [`admin_view`](../src/admin_view) : gestion d'une interface administrateur de la base de donnée, s'appuie sur *css* et *views*
+    * [`ldap`](../src/ldap) : gestion des requêtes LDAP
+
+La syntaxe adoptée est JavaScript ES6, un standard moderne (2015) de JavaScript. Il permet d'importer des dépendances en utilisant le mot-clé `import`, ce que le serveur Node.js ne comprend pas puisque la version 8 de Node ne comprend que le standard ES5 (2009), qui gère les imports avec `require()`.
+
+
+
+## Base de données
+
+Sigma s'appuie sur deux bases de données :
+
+* La BDD frankiz accessible par LDAP hébergée sur un serveur de l'école, qui contient identifiants, mots de passe, et toutes les informations sur les utilisateurs et groupes spécifiques X.
+  * On y accède par des requêtes LDAP, d'où la nécessité de ldap.js.
+* La BDD de sigma propre est en [PostgreSQL](https://www.postgresql.fr/), hébergée en propre BR, qui contient les groupes et leurs niveaux de visibilité mais peu d'information sur les utilisateurs (seulement son école).
+  * Les requêtes à cette base de données sont gérées par [Knex.js](http://knexjs.org).
+
+Cette structure peut sembler lourde et redondante mais s'explique par plusieurs raisons :
+
+* Volonté d'intégrer d'autres écoles simplement
+  * Rajouter leurs groupes sur la BDD sigma
+  * Pas les obliger à rejoindre notre LDAP avec notre structure
+* Garder le LDAP X et le mettre à jour ; il est utilisé par beaucoup d'autres sites X
+* Enjeu de sécurité
+  * La BDD de sigma est public et ne comporte rien de compromettant
+  * La BDD accessible par LDAP de l'X qui contient des informations plus sensibles et qui doit être plus protégée
+
+Les deux sections suivantes détaillent les opérations possibles grâce au back directement sur les bases de données via sigma.
+
+### Guide: Knex.js
+
+L'interface en ligne de commande de [Knex.js](http://knexjs.org) contient les commandes suivantes :
+
+* `knex migrate:make migration_name` crée une migration dans `db/migrations/`
+* `knex migrate:latest` met à jour le schéma de la BDD
+* `knex seed:make filename` crée un _seed_ `seeds/filename`
+* `knex seed:run` insère les _seeds_ dans la BDD
+
+Un fichier _seed_ permet d'insérer des données dans la BDD. Ils sont stockés dans [`seeds`](../db/seeds).
+
+#### Comment faire une migration
+
+On utilisera l'interface en ligne de commande de Knex.js.
+
+Les migrations servent à **mettre à jour le schéma de la base de données**. Pour créer une migration, on lance la commande `knex migrate:make <nom_migration>`, qui crée un fichier `db/migrations/[hash]_nom_migration.js` où le hash est la date et l'heure.
+
+Maintenant, on édite le fichier de migration. Il fait deux exports, `exports.up` et `exports.down`, qui définissent respectivement comment mettre à jour le schéma de la BDD et comment annuler la modification si `knex migrate:rollback` est invoqué.
+
+Il faut se référer à la documentation de Knex.js pour comprendre comment écrire les requêtes. Voici un [cheatsheet](https://devhints.io/knex).
+
+### Fonctions LDAP
+
+On peut facilement explorer et modifier des éléments du LDAP de l'école depuis le réseau de l'X avec [JXplorer](http://jxplorer.org/) en entrant `frankiz` dans nouvelle connexion et en allant dans `net`.
+
+### Accéder à la BDD de sigma propre
+
+Pour accéder à la "vraie" BDD, sur roued (le serveur qui héberge sigma), il faut
+* se connecter dessus en `ssh roued`
+* passer en `sudo`
+* faire un `su postgres` pour se faire passer pour l'utilisateur unix postgres
+* se connecter à la BDD via la commande `psql`
+* faire les requetes en SQL par l'interface de postgreSQL.
+
+## Panneau d'administration
+
+### Authentification
+
+L'authentification se fait contre le LDAP en envoyant un requête HTTP POST à '/adminview/avlogin'. C'est une page distincte de '/login' qui est utilisé pour les requetes d'authentification à partir du client front, pour pouvoir facilement distinguer les deux comportements :
+- login depuis le panneau d'administration (POST à '/adminview/avlogin') : `passport.authenticate(...)` puis redirection vers GET '/adminview/admin'
+- login depuis le client front (requête POST à '/login']) : `passport.authenticate(...)` puis renvoyer une reponse au client
+
+### Accès direct à la BDD via knex
+
+Le panneau d'administration sert (ou plutôt, servira à terme) à accéder directement à la BDD propre de sigma. On accède à la table `table_name` par une requête GET à '/adminview/db/`table_name`' et aux colonnes `columns` de cette table par une requête GET à '/adminview/db/`table_name`?columns=`columns`.
+Ces pages sont protégées pour n'être accessibles qu'en étant authentifé.
+
+### GraphiQL et Voyager
+
+A partir du panneau d'admin, en faisant des requêtes GET à '/graphiql' et '/voyager' respectivement, on accède à GraphiQL et à GraphQL Voyager. Ces pages sont protégées pour n'être accessibles qu'en étant authentifé.
+
+
+## Appendixes
+
+### ESLint
+
+On utilisera ESLint pour standardiser le code : un ensemble de règles de style pour le code sont appliquées, et quelques-unes d'entre elles sont dans le fichier `.eslintrc.json`. Pour l'instant, la config ESLint impose d'utiliser quatre espaces pour les indentations et d'utiliser des points-virgule en fin de ligne.
+
+Il est préférable de l'installer **globalement** avec `npm install -g eslint`. Pour faire valider les fichiers source par ESLint, utilisez `npm run lint`.
+
+qui fait appel au script `eslint src/` défini dans le [`package.json`](../package.json). L'option `--fix` permet de corriger les fichiers.
+
+Sinon, si vous utilisez Atom ou Visual Studio Code pour éditer votre code, il existe des plugins qui font tourner ESLint en _live_ sur le code et vérifient que tout est en ordre.
+
+Pour mieux comprendre ESLint, référez-vous à la [doc](https://eslint.org/docs/user-guide/getting-started).
+
+
 ## Contact
 
 le BR 2016
+
+

README.md

@@ -35,93 +35,9 @@ Les dépendances les plus importantes sont knex.js, notre outil de gestion de BD
 
 Le serveur utilisé est [express.js](https://expressjs.com/) ; il est configuré dans [`server.js`](../src/server.js) puis lancé sur le port 3000 dans [`index.js`](../src/index.js).
 
-## Structure
-
-La structure générale du projet est détaillée ci-dessous ; pas d'inquiétude, la plupart des fichiers .js sont aussi extensivement documentés plus bas.
-
-* Racine du projet : fichiers de configuration ;
-  * config.json : données "sensibles" spécifique au projet à priori non partageable (adresse du LDAP, mots de passe),
-  * configfile_doc.json : JSDoc, l'outil de génération automatique de documentation,
-  * autres fichiers relatifs à des modules particuliers ou à la gestion de paquets,
-  * [`assets`](../assets) : ressources ;
-    * images et divers (dont l'essentiel flavicon)
-  * [`build`](../build) : dépendances gérées automatiquement ;
-    * bundle.js est un monstrueux fichier généré automatiquement qui gère nos dépendances.
-  * [`db`](../db) : base de donnée sigma ;
-  * knex_router.js charge la configuration précisée dans knexfile.js,
-    * [`migrations`](../db/migrations) stocke l'ensemble des migrations knex ; c'est un équivalent d'un répertoire git pour la BDD sigma (du coup seulement les groupes pas les individus),
-    * [`seeds`](../db/seeds) : stocke les éléments de générations des BDD ; c'est un ensemble de scripts.
-  * [`doc`](.) : documentation ;
-    * ensemble de pages html et fichiers associés ; index.html permet de naviguer sereinement sur toute la doc JSDoc.
-  * [`node_modules`](../node_modules) : gestion automatique des modules.
-  * [`src`](../src) : code source
-    * [`admin_view`](../src/admin_view) : gestion d'une interface administrateur de la base de donnée, s'appuie sur *css* et *views*
-    * [`ldap`](../src/ldap) : gestion des requêtes LDAP
-
-La syntaxe adoptée est JavaScript ES6, un standard moderne (2015) de JavaScript. Il permet d'importer des dépendances en utilisant le mot-clé `import`, ce que le serveur Node.js ne comprend pas puisque la version 8 de Node ne comprend que le standard ES5 (2009), qui gère les imports avec `require()`.
-
-## Base de données
-
-Sigma s'appuie sur deux bases de données :
-
-* La BDD frankiz accessible par LDAP hébergée sur un serveur de l'école, qui contient identifiants, mots de passe, et toutes les informations sur les utilisateurs et groupes spécifiques X.
-  * On y accède par des requêtes LDAP, d'où la nécessité de ldap.js.
-* La BDD de sigma propre est en [PostgreSQL](https://www.postgresql.fr/), hébergée en propre BR, qui contient les groupes et leurs niveaux de visibilité mais peu d'information sur les utilisateurs (seulement son école).
-  * Les requêtes à cette base de données sont gérées par [Knex.js](http://knexjs.org).
-
-Cette structure peut sembler lourde et redondante mais s'explique par plusieurs raisons :
-
-* Volonté d'intégrer d'autres écoles simplement
-  * Rajouter leurs groupes sur la BDD sigma
-  * Pas les obliger à rejoindre notre LDAP avec notre structure
-* Garder le LDAP X et le mettre à jour ; il est utilisé par beaucoup d'autres sites X
-* Enjeu de sécurité
-  * La BDD de sigma est public et ne comporte rien de compromettant
-  * La BDD accessible par LDAP de l'X qui contient des informations plus sensibles et qui doit être plus protégée
-
-Les deux sections suivantes détaillent les opérations possibles grâce au back directement sur les bases de données via sigma.
-
-### Guide: Knex.js
-
-L'interface en ligne de commande de [Knex.js](http://knexjs.org) contient les commandes suivantes :
-
-* `knex migrate:make migration_name` crée une migration dans `db/migrations/`
-* `knex migrate:latest` met à jour le schéma de la BDD
-* `knex seed:make filename` crée un _seed_ `seeds/filename`
-* `knex seed:run` insère les _seeds_ dans la BDD
-
-Un fichier _seed_ permet d'insérer des données dans la BDD. Ils sont stockés dans [`seeds`](../db/seeds).
-
-#### Comment faire une migration
-
-On utilisera l'interface en ligne de commande de Knex.js.
-
-Les migrations servent à **mettre à jour le schéma de la base de données**. Pour créer une migration, on lance la commande `knex migrate:make <nom_migration>`, qui crée un fichier `db/migrations/[hash]_nom_migration.js` où le hash est la date et l'heure.
-
-Maintenant, on édite le fichier de migration. Il fait deux exports, `exports.up` et `exports.down`, qui définissent respectivement comment mettre à jour le schéma de la BDD et comment annuler la modification si `knex migrate:rollback` est invoqué.
-
-Il faut se référer à la documentation de Knex.js pour comprendre comment écrire les requêtes. Voici un [cheatsheet](https://devhints.io/knex).
-
-### Fonctions LDAP
-
-On peut facilement explorer et modifier des éléments du LDAP de l'école depuis le réseau de l'X avec [JXplorer](http://jxplorer.org/) en entrant `frankiz` dans nouvelle connexion et en allant dans `net`.
-
-### Accéder à la BDD de sigma propre
-
-Pour accéder à la "vraie" BDD, sur roued (le serveur qui héberge sigma), il faut
-* se connecter dessus en `ssh roued`
-* passer en `sudo`
-* faire un `su postgres` pour se faire passer pour l'utilisateur unix postgres
-* se connecter à la BDD via la commande `psql`
-* faire les requetes en SQL par l'interface de postgreSQL.
-
 ## Panneau d'administration
 
-### Authentification
-
-L'authentification se fait contre le LDAP en envoyant un requête HTTP POST à '/adminview/avlogin'. C'est une page distincte de '/login' qui est utilisé pour les requetes d'authentification à partir du client front, pour pouvoir facilement distinguer les deux comportements :
-- login depuis le panneau d'administration (POST à '/adminview/avlogin') : `passport.authenticate(...)` puis redirection vers GET '/adminview/admin'
-- login depuis le client front (requête POST à '/login']) : `passport.authenticate(...)` puis renvoyer une reponse au client
+Il est accessible au path /adminview/admin ; n'importe quel path devrait rediriger dessus, ou alors vers /adminview/login. Les identifiants à utiliser sont ceux de Frankiz. L'authentification se fait par le LDAP Frankiz.
 
 ### Accès direct à la BDD via knex
 
@@ -132,6 +48,7 @@ Ces pages sont protégées pour n'être accessibles qu'en étant authentifé.
 
 A partir du panneau d'admin, en faisant des requêtes GET à '/graphiql' et '/voyager' respectivement, on accède à GraphiQL et à GraphQL Voyager. Ces pages sont protégées pour n'être accessibles qu'en étant authentifé.
 
+
 ## Scripts
 
 Les scripts sont des instructions en ligne de commande que l'on peut faire tourner avec la commande `npm run`. Ce sont des raccourcis pour gagner du temps sur des opérations un peu longues. Ils sont définis dans [`package.json`](../package.json).
@@ -159,17 +76,3 @@ La documentation détaillée du projet est [ici](./doc/index.html). Elle a été
 Les fichiers compilés se situent dans [`doc`](.) avec leurs fichiers image. Par nature de l'outil JSDoc il est facile de documenter en détail des fonctions .js mais plus compliqué de documenter un fichier.
 
 A la fin de ce fichier JSDoc rajjoute les commentaires placés dans chacun des fichiers et des hyperliens pour y accéder.
-
-## Appendixes
-
-### ESLint
-
-On utilisera ESLint pour standardiser le code : un ensemble de règles de style pour le code sont appliquées, et quelques-unes d'entre elles sont dans le fichier `.eslintrc.json`. Pour l'instant, la config ESLint impose d'utiliser quatre espaces pour les indentations et d'utiliser des points-virgule en fin de ligne.
-
-Il est préférable de l'installer **globalement** avec `npm install -g eslint`. Pour faire valider les fichiers source par ESLint, utilisez `npm run lint`.
-
-qui fait appel au script `eslint src/` défini dans le [`package.json`](../package.json). L'option `--fix` permet de corriger les fichiers.
-
-Sinon, si vous utilisez Atom ou Visual Studio Code pour éditer votre code, il existe des plugins qui font tourner ESLint en _live_ sur le code et vérifient que tout est en ordre.
-
-Pour mieux comprendre ESLint, référez-vous à la [doc](https://eslint.org/docs/user-guide/getting-started).

package.json

@@ -2,7 +2,21 @@
   "name": "sigma-backend",
   "version": "0.0.1",
   "description": "Backend of sigma, the new Frankiz",
-  "main": "index.js",
+  "scripts": {
+    "build": "webpack --mode production",
+    "serve": "node build/bundle.js",
+    "dev": "webpack --mode development",
+    "watch": "webpack --watch --mode development",
+    "start": "nodemon --watch build build/bundle.js",
+    "doc": "jsdoc -c configfile_doc.json",
+    "lint": "eslint src/"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git@gitlab.binets.fr:br/sigma-backend"
+  },
+  "author": "Binet Réseau",
+  "license": "ISC",
   "dependencies": {
     "body-parser": "^1.18.2",
     "colors": "^1.2.3",
@@ -48,19 +62,5 @@
     "webpack": "^4.6.0",
     "webpack-cli": "^2.1.2",
     "webpack-node-externals": "^1.7.2"
-  },
-  "scripts": {
-    "start": "nodemon --watch build build/bundle.js",
-    "serve": "node build/bundle.js",
-    "lint": "eslint src/",
-    "build": "webpack --mode development",
-    "watch": "webpack --watch --mode development",
-    "doc": "jsdoc -c configfile_doc.json"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git@gitlab.binets.fr:br/sigma-backend"
-  },
-  "author": "Binet Réseau",
-  "license": "ISC"
+  }
 }