custom for poc and simpler

.dockerignore

-node_modules/
-src/
-test/
\ No newline at end of file

.gitlab-ci.yml

-# Official framework image. Look for the different tagged releases at:
-# https://hub.docker.com/r/library/node/tags/
-image: node:10-stretch
-
-#global variables
-variables:
-  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
-
-
-# This folder is cached between builds
-cache:
-  paths:
-  - node_modules/
-
-stages:
-  - build
-  - tests
-  - docker
-  - deploy
-
-### Jobs ###
-
-# Install dependencies, compile the bundle.js,
-build:transpile:
-  stage: build
-  script:
-    - npm ci 
-    - npm run build
-  artifacts:
-    paths:
-      - build/
-
-# Run all unit tests
-tests:mocha:
-  stage: tests
-
-  # Only needed when using a docker container to run your tests in.
-  # Check out: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html#what-is-a-service
-  services:
-    - postgres
-  variables:
-    POSTGRES_DB: sigma_staging
-    POSTGRES_USER: sigma
-    POSTGRES_PASSWORD: sigmapw
-    TARGET_ENV: staging
-    # set up to use ldap, not ldaps 
-    LDAP_URI: ldap://ldapdev.eleves.polytechnique.fr:389
-    LDAP_DN: uid=sigma,ou=services,dc=frankiz,dc=net
-    # in Kubernetes executor, hostname postgres is broken
-    # in Docker executor, it is postgres
-    DB_HOST: postgres
-  script:
-    - npm ci && npm i -g knex
-    - cd db
-    - knex migrate:latest --env staging
-    - knex seed:run --env staging
-    - cd ..
-    - npm run test
-
-# Build docker image and upload to registry
-docker:build:
-  stage: docker
-  only:
-    - master
-    - stable
-  image: docker:stable
-  services:
-    - docker:dind
-  variables:
-    DOCKER_HOST: tcp://docker:2375/
-    DOCKER_DRIVER: overlay2
-  script:
-    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
-    - docker build --pull -t $IMAGE_TAG .
-    - docker push $IMAGE_TAG
-
-# Deploy the docker image to docker host
-deploy:docker:
-  stage: deploy
-  # tag is needed to use the deploy runner instead of the standard runner
-  tags:
-    - deploy
-  only:
-    - master
-    - stable
-  when: manual
-  # need to overwrite entrypoint because default entrypoint is "docker-compose" https://stackoverflow.com/a/52734017
-  image: 
-    name: docker/compose:1.24.0
-    entrypoint: ["/bin/sh", "-c"]
-  # "DOCKER_IMAGE" variable cannot be defined here and has to be exported in script
-  # because recursive variable substitution doesn't work https://gitlab.com/gitlab-org/gitlab-runner/issues/2007
-  variables:
-    HOST: $SIGMABACK_HOST
-    PORT: $SIGMABACK_PORT
-    FRONTEND_SERVER_URL: http://$SIGMAFRONT_HOST:$SIGMAFRONT_PORT
-  script:
-    - export DOCKER_IMAGE=$IMAGE_TAG
-    - docker-compose -f docker-compose.production.yml stop
-    - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}
-    - docker-compose -f docker-compose.production.yml pull
-    - docker-compose -f docker-compose.production.yml up -d
\ No newline at end of file

Dockerfile

-FROM node:10-alpine
-
-WORKDIR /app
-
-# Set up dependencies
-COPY package*.json ./
-
-# Install app dependencies
-ENV NODE_ENV=production
-RUN npm ci --only=production
-
-# Copy application
-COPY . .
-
-EXPOSE 3000
-CMD [ "sh", "-c", "npm run migrate && node build/bundle.js" ]
\ No newline at end of file

README.md

-[![pipeline status](https://gitlab.binets.fr/br/sigma-backend/badges/master/pipeline.svg)](https://gitlab.binets.fr/br/sigma-backend/commits/master)
-
-Sigma - serveur backend 
+Proof Of Concept pour gestion des droits Sigma
 ===
 
-Ce dépôt contient le _backend_ de Sigma, le successeur de Frankiz, un site étudiant permettant de gérer les groupes et les étudiants du plateau de Saclay.
+Une implémentation la plus simple possible illustrant la gestion des droits de Sigma.
 
-À terme, ce projet doit tourner sur un serveur du BR et servir d'API à un _frontend_ React *au code séparé et documenté séparément* toutes les données nécessaires à son bon fonctionnement (authentification, appartenance à un groupe, droits de visibilité...). Le dépôt pour le serveur front se trouve ici : <https://gitlab.binets.fr/br/sigma-frontend> (on l'appellera indifféremment serveur front, front ou frontend...)
+Elle illustre le framework d'autorisation décrit ici : https://gitlab.binets.fr/guillaume.wang/gestion-des-droits-sigma/. Elle lui sert autant de POC que de terrain d'expérimentation.
 
-**Le but des lignes qui suivent est de permettre au lecteur de rapidement mettre en place et lancer un sigma en local et se familiariser avec son administration.** Comment obtenir la documentation détaillée du projet est expliqué à la fin de ce document.
+Ce dépôt est, à l'origine, un exemple extrêmement simplifié de _backend_ pour Sigma, le successeur de Frankiz, un site étudiant permettant de gérer les groupes et les étudiants du plateau de Saclay.
 
-Pour avoir un guide détaillé de l'installation de l'environnement de dev (i.e accès en écriture aux dépôts, installation de Node.js, npm, VSCode et les extensions utilisées), voir [ce carnet](https://carnets.binets.fr/yhvva08BQiWBZ0r0rS3RMw#).
+Le "vrai" projet se trouve ici : <https://gitlab.binets.fr/br/sigma-backend> 
 
-Pour obtenir une copie du projet, cloner le dépôt par :
-```bash
-git clone git@gitlab.binets.fr:br/sigma-backend.git
-# ou
-git clone https://gitlab.binets.fr/br/sigma-backend.git
-```
-
-## Installer les dépendances *npm*
-On utilise un serveur node.js avec [express.js](https://expressjs.com/). Ce serveur est configuré dans [`app.ts`](./src/app.ts) puis lancé sur le port 3000 dans [`index.ts`](../src/index.ts). 
+De la même façon que ce dernier, gdd-sigma-poc est destiné à servir d'API à un _frontend_ *au code entièrement séparé*. Le dépôt pour le "vrai" serveur front se trouve ici : <https://gitlab.binets.fr/br/sigma-frontend> (on l'appellera indifféremment serveur front, front ou frontend...)
 
-Utiliser Node.js permet d'utiliser facilement [*npm*](https://www.npmjs.com/) (Node Package Manager). Une "dépendance" est un package utilisé dans le projet.
+**Les lignes qui suivent sont issues du README du vrai sigma-backend, au moment du fork. Elles ont pour but de permettre au lecteur de rapidement mettre en place et lancer un sigma-poc en local.** 
+Cependant contrairement au vrai projet, on suppose que le lecteur connaît déjà un peu les outils utilisés (npm, nodejs, expressjs, webpack, knex...), par concision. De plus, par simplicité, on a omis d'intégrer les mémos à JSDoc.
 
+### Documentation
+#### Description formelle du framework de gestion des droits
+#### Mémos sur l'implémentation
+#### Mémos des développeurs
+#### Code JS : JSDoc
 
-On trouve la liste des dépendances dans [`package.json`](../package.json). Express est un exemple de dépendance normale, utilisée en production ; nodemon et ESLint (voir infra) sont des dépendances dev (`devDependencies`), utilisées seulement en mode développement.
+## Installer les dépendances *npm*
+On utilise un serveur node.js avec [express.js](https://expressjs.com/). Ce serveur est configuré dans [`app.ts`](./src/app.ts) puis lancé sur le port 3000 dans [`index.ts`](../src/index.ts). 
 
-Les dépendances s'installent avec `npm install`. Cette commande a deux comportements possibles selon la valeur de la variable `NODE_ENV` (vérifier avec la commande `echo "$NODE_ENV"`):
+Les dépendances npm s'installent avec `npm install`. Cette commande a deux comportements possibles selon la valeur de la variable `NODE_ENV` (vérifier avec la commande `echo "$NODE_ENV"`):
 * si `NODE_ENV` n'est pas configuré : on installe tout
 * si `NODE_ENV` == `development` : on installe tout
 * si `NODE_ENV` == `production` : on n'installe pas les dépendances développeur
 
-Pour installer les dépendances spécifiées dans `package.json` il faut donc lancer :
-```bash
-npm install
-```
-
 Les dépendances principales utilisées sont :
 - *knex.js*, qui permet de construire des requêtes SQL facilement,
 - *GraphQL*, qui fournit une couche d'abstraction pour l'échange de données frontend-backend,
@@ -163,22 +155,6 @@ npm run start # ou le raccourci: npm start
 ```
 Comme indiqué dans src/index.js, ceci lance un serveur servant l'application express sur le port 3000.
 
-## Alternative : déployer dans un conteneur Docker
-L'image Docker est définie dans [`Dockerfile`](../Dockerfile). Il s'agit d'une distro Alpine avec Node.js et libstdc++. Lors du _build_ les dépendances _runtime_ dont dépend le `bundle.js` sont installées.
-
-Compiler l'image :
-```bash
-docker build -t sigma-api .
-```
-Faire tourner le conteneur :
-```bash
-docker run sigma-api
-```
-Idem mais avec un LDAP custom :
-```bash
-docker run -e LDAP_URI=ldap://172.17.0.1:8389 sigma-api
-```
-
 ## Mode développement / staging / production
 Deux variables d'environnement gerent le mode de déploiement de l'application : `NODE_ENV` et `TARGET_ENV`. 
 - `NODE_ENV` détermine dans quel mode sont configurés node et tous ses modules : en particulier, des que `NODE_ENV === production`, de nombreux modules mettent en place des optimisations et les `devDependencies` ne sont plus installés... Par convention, `NODE_ENV` ne doit prendre que les valeurs `development` ou `production`.
@@ -187,67 +163,46 @@ Deux variables d'environnement gerent le mode de déploiement de l'application :
 Voici plus en détail les 3 contextes différents de déploiement : 
 - mode "développement" (quand on compile et fait tourner le serveur en local) :
     - installer toutes les dépendances avec `npm i`
-    - configurer l'environnement : `.env` avec `TARGET_ENV=development` 
+    - configurer l'environnement : `.env` avec `TARGET_ENV=development` et `LDAP_PASSWD="XXX"` avec XXX mot de passe obtenu des dévs précédents
     - setup la BDD `sigma_dev` et la populer avec `npm run migrate && npm run seed`
     - compiler le serveur : `npm run watch`
     - démarrer Nodemon : `npm run start`
 - mode "staging" (quand on lance l'application en mode dev sur un serveur pour des tests) :
     - installer toutes les dépendances avec `npm i && npm i -g knex` (on a besoin de tout pour pouvoir compiler)
-    - configurer l'environnement : `.env` avec `TARGET_ENV=staging`
+    - configurer l'environnement : `.env` avec `TARGET_ENV=staging` et `LDAP_PASSWD="XXX"` avec XXX mot de passe obtenu des dévs précédents
     - setup la BDD `sigma_staging` et la populer avec `knex migrate:latest --env staging`
     - compiler le serveur en mode production : `npm run build`
     - démarrer le serveur : `npm run start_prod`
 - mode "production" (quand on lance l'application précompilée en `bundle.js` en prod) :
     - **définir NODE_ENV** : `export NODE_ENV=production` dans la session terminal
     - installer seul les dépendances prod : `npm i` (les devDependencies ne sont plus installées)
-    - configurer l'environnement : `.env` avec `TARGET_ENV=production`
+    - configurer l'environnement : `.env` avec `TARGET_ENV=production` et `LDAP_PASSWD="XXX"` avec XXX mot de passe obtenu des dévs précédents
     - setup la BDD `sigma_prod` et la populer avec `npm run migrate`
     - lancer le serveur précompilé : `npm run start_prod`
 
 ## 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).
 
-Les plus importants sont détaillées ci-dessous :
-- `npm run build` : transpiler avec Webpack, en mode production
-- `npm run dev` : idem, mais en mode développement
-- `npm run watch` : idem, mais retranspile automatiquement dès que le code est modifié.
-- `npm run start` : lancer un serveur Node avec nodemon
-- `npm run start_prod` : lancer le serveur avec Node
-- `npm run doc` : générer la doc JSDoc
-- `npm run lint` : discontinué
-- `npm run eslint` : vérifier la syntaxe de tous les fichiers .js du dossier src/
-- `npm run tslint` : vérifier la syntaxe de tous les fichiers .ts du dossier src/
-- `npm run tsfix` : vérifie et corrige
-- `npm run tsc` : compile le code TypeScript
-- `npm run test` : démarre les tests unitaires
-- `npm run ldap_test` : démarre uniquement les tests du LDAP
-- `npm run migrate` : exécute les migrations knex
-- `npm run rollback` : annuler les migrations knex
-- `npm run seed` : exécute les seed knex (fake données)
-
-`npm run start` démarre en fait le serveur buildé [`build/bundle.js`](../build/bundle.js) avec [nodemon](https://nodemon.io/), un outil de dév qui le redémarre automatiquement après toute modification *du bundle*.
-
+`npm run start` démarre le serveur buildé [`build/bundle.js`](../build/bundle.js) avec [nodemon](https://nodemon.io/), un outil de dév qui le redémarre automatiquement après toute modification *du bundle*.
 Donc, lancer `npm run watch` dans un terminal et `npm run start` dans un autre permet de rebuilder **et** relancer automatiquement le serveur, après toute modification *du code source*.
 
 ## Panneau d'administration
 
 Il est accessible par navigateur au path [/adminview/admin](localhost:3000/adminview/admin) ; n'importe quel path devrait rediriger dessus. 
 
-L'accès y est protégé par une page d'authentification, les identifiants à utiliser sont ceux de Frankiz. 
-Le hruid (i.e. prenom.nom) de l'utilisateur doit de plus être sur une whitelist des hruid autorisés. Pour l'instant cette whitelist est configurée dans les variables d'environnement [.env](../.env).
+L'accès y est protégé par une page d'authentification, les identifiants à utiliser sont ceux de Frankiz.  Le hruid (i.e. prenom.nom) de l'utilisateur doit de plus être sur une whitelist des hruid autorisés. Pour l'instant cette whitelist est configurée dans les variables d'environnement [.env](../.env).
 
-### Accès direct à la BDD
+Ce panneau doit prendre de plus en plus d'importance au fur et à mesure que la base Sigma s'enrichit, et que l'on veut faire de plus en plus de choses avec des permissions de plus en plus fines.
 
+### Accès direct à la BDD
 Le panneau d'administration sert (ou plutôt, servira à terme) à accéder directement à la BDD propre de sigma, grâce à une API REST. Autrement dit : 
 - on accède à la table `table_name` par une requête GET à [adminview/db/table_name](localhost:3000/adminview/db/table_name),
 - et aux colonnes `columns` de cette table par une requête GET à [/adminview/db/table_name?columns=columns](localhost:3000//adminview/db/table_name?columns=columns).
 
 ### GraphQL Voyager
-
 L'application Voyager, accessible à [/adminview/voyager](localhost:3000/adminview/voyager), permet de visualiser le « graphe » sous-jacent à la structure de l'API.
 
 ### GraphQL Playground
-
 == Attention, comme tout GraphQL Playground est géré directement par le package apollo-server-express, les requêtes dans le Playground **ne sont pas** soumises au mêmes règles de permission que dans adminview. (D'ailleurs, `/graphql` n'est même pas un sous-path de `/adminview`.) ==
 
 Accéder via un navigateur à `/graphql` renvoie l'application GraphQL Playground.

docker-compose.production.yml

-version: '3'
-
-services:
-  sigmapsql:
-    image: postgres:alpine
-    restart: always
-    environment:
-      POSTGRES_USER: sigma
-      POSTGRES_PASSWORD: sigmapw
-      POSTGRES_DB: sigma_prod
-    volumes:
-      - "sigmapsql-data:/var/lib/postgresql/data"
-  
-  sigmaback:
-    image: ${DOCKER_IMAGE}
-    environment:
-      NODE_ENV: production
-      TARGET_ENV: production
-      HOST:
-      PORT:
-      FRONTEND_SERVER_URL:
-      LDAP_URI: ldap://ldapdev.eleves.polytechnique.fr:389
-      LDAP_DN: uid=sigma,ou=services,dc=frankiz,dc=net
-      LDAP_PASSWD:
-      DB_HOST: sigmapsql
-      DB_USER: sigma
-      DB_PASSWD: sigmapw
-      ADMINS: "oliver.facklam hadrien.renaud"
-    depends_on:
-      - sigmapsql
-    ports:
-      - "3000:3000"
-    restart: always
-
-volumes:
-  sigmapsql-data:

sigma-backend.service

-[Unit]
-Description=Version dev de sigma-backend
-Wants=network-online.target
-After=network-online.target
-
-[Service]
-WorkingDirectory=/srv/sigma/sigma-backend
-ExecStart=/usr/bin/node build/bundle.js
-Restart=always
-
-[Install]
-WantedBy=multi-user.target