-- MijnBesluit - aanmeldingen van de app bewaren, zodat ze een herstart overleven
--
-- Waarom deze tabel er komt: de app blijft aangemeld en komt er daarna in met de vingerafdruk
-- of de code van de telefoon. Dat werkt alleen zolang de server het sessietoken nog kent. De
-- sessies stonden in het geheugen van de SocketServer, dus elke herstart van de service - een
-- uitrol, een Windows-update 's nachts, een reboot van de server - gooide ze allemaal weg. Het
-- toestel wist dan nog wie je was, de server niet meer, en je moest weer een code uit je mail
-- halen. Precies wat de vingerafdruk zou moeten voorkomen.
--
-- Het token zelf staat er NIET in, alleen de SHA-256 ervan - dezelfde afspraak als bij de
-- inlogcodes. Wie de database in handen krijgt, krijgt daarmee dus geen werkende sessies mee:
-- uit een hash valt geen token terug te rekenen.
--
-- `verloopt_op` schuift op bij gebruik, maar niet bij elk verzoek. Dat zou een schrijfactie per
-- aanroep betekenen voor iets waar een uur speling volstaat bij een termijn van veertien dagen.
--
-- Draaien met:
--   mysql -u root -p mijnbesluit < db\16_sessies.sql
--
-- Opnieuw draaien mag: er gebeurt dan niets.

USE `mijnbesluit`;

CREATE TABLE IF NOT EXISTS `sessies` (
  `id`            BIGINT        NOT NULL AUTO_INCREMENT,
  `token_hash`    VARBINARY(32) NOT NULL,   -- SHA-256 van het token; nooit het token zelf
  `user_id`       BIGINT        NOT NULL,
  `person_id`     BIGINT        NOT NULL,
  `toestel`       VARCHAR(120)      NULL,
  `aangemaakt_op` DATETIME(3)   NOT NULL,
  `verloopt_op`   DATETIME(3)   NOT NULL,
  `laatst_gezien` DATETIME(3)   NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_sessies_token` (`token_hash`),
  KEY `ix_sessies_verloopt` (`verloopt_op`),
  CONSTRAINT `fk_sessies_user` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB;

-- DE RECHTEN STAAN HIER MET OPZET NIET.
--
-- De verleiding was groot: een nieuwe tabel zonder GRANT is onzichtbaar tot iemand hem gebruikt,
-- en dan zegt de server "INSERT command denied" terwijl de gebruiker alleen "Er ging iets mis"
-- ziet. Precies wat er op 17 september gebeurde - inloggen in de app liep erop stuk.
--
-- Maar de scripts vanaf 03 worden ook door de uitrolagent gedraaid, met een beperkt
-- databaseaccount dat helemaal geen rechten mág uitdelen. Een GRANT hier zou die hele uitrol
-- laten struikelen, en de oplossing "geef dat account dan GRANT-rechten" maakt het uitrolkanaal
-- machtiger dan het hoeft te zijn. Rechten uitdelen is inrichten, en dat doet een mens één keer.
--
-- De rechten staan dus in 02_applicatiegebruiker.sql, en een zelfcontrole
-- ("Elke tabel geeft de applicatiegebruiker rechten") legt elke CREATE TABLE in deze map naast
-- die lijst. Die vangt het al vóór de uitrol, en dat is de goede plek.

SELECT 'Klaar. Vergeet 02_applicatiegebruiker.sql niet als dit een nieuwe server is.' AS melding;