diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c1f7320a9aea14f3336e13b1e9f5502abcba9745..f792b91f7c728d15a1792c49f0d6f90f20cd8da1 100644
--- a/CONTRIBUTING.md
+++ b/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
+
+
diff --git a/README.md b/README.md
index 5462b36b3f7abd1d65f2796f90feb8ae66b178c2..6f61af13f678faa588d2d893c100f5272c661b80 100644
--- a/README.md
+++ b/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).
diff --git a/package.json b/package.json
index c2b626545e4862818fbaf580c322371eb13a8216..5f61029d8a1e344318dc9b15e677893634906026 100644
--- a/package.json
+++ b/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"
+ }
}