55 lines
2.9 KiB
SQL
55 lines
2.9 KiB
SQL
-- 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;
|