Databasplan

Databasen består av:

• användardata
• synkdata

Användardata

Användarnas data som tillhör appen.

Illustration av databas vi suser case.

Skapa konto

Klient:

• väljer lösenord (P)
• genererar nyckel (DK) baserat i lösenordet (P), "Derived Key", enligt standard (ex. PBKDF2).
• Genererar PermaNonce (PN) baserat i P eller DK.
• generera uuidv7 som användar-id. (UID)
• uuid7 är primär identifierare, för enkelhet: användare anger ytterligare identifierar som användarnamn. (UNAME)

Sedan

{
  “user_name“: UNAME,
  "user_id": UID,
  "perma_nonce": PN,
}

Skickas till server, server lägger in i tabellen "users".

Server skapar ett internt uuid som är INT för användaren. Följande lagras på server i tabell users:

{
  “user_name“: UNAME,
  "user_id": UID,
  "internal_user_id": IUID,
  "perma_nonce": PN,

}

Logga in

Klienten:

• anger lösenord
• genererar nyckel (DK) baserat i lösenordet (P), "Derived Key", enligt standard (ex. PBKDF2).
• Genererar PermaNonce (PN) baserat i P eller DK.
• anger användarnamn (UNAME)

Sedan:

{
  “user_name“: UNAME,
  "perma_nonce": PN,
}

Server tillåter nu trafik genom websocket om PN stämmer med vad servern lagrat, annars stäng websocket. Servern vet nu klientens interna användare-ID.

Skick data

Klienten:

• genererar UUIDv7 för data som ska lagras (DBID).

{
  “data_block_id“: DBID,
  "data": DATA,
}

Skickas till servern. Servern vet intern UID för klienten då klienten har genomgått autentifikation.

In i tabellen data_blocks:

{
  “internal_user_id“: IUID,
  “data_block_id“: DBID,
  "data": DATA,
}

Hämta/ändra/radera data

Klienten:

• Klienten vet UUIDv7 (DBID) för datan som ska hämtas. Klient skickar bara:

{
  “data_block_id“: DBID,
}

Servern gör direkt select via DBID.

Samma princip för ändra och radera datablock.

Version 2 med kryptering

Krypterad ... Samma som version 1, men klienten genererar en krypteringsnyckel (EK), den krypteras med DK till KEK (key encrypted key). Klient krypterar data med EK innan det skickas till server. Klient skickar KEK vid något tillfälle för lagring på server. Den behöva för möjliggöra byte av lösenord utan att kryptera om allt. EK baseras inte på lösenordet.

Synkdata

Alla strukturer som är nödvändiga för realtidssynkronisering mellan anslutna enheter.

Idé: Använd Redis

Avsikten är att ha en uppdateringshistorik där klient 1 gör en uppdatering som lagras på servern. När klient 2 loggar in hämtas alla uppdateringar sedan en given tidsstämpel och den lokala kopian modifieras därefter. Jag tänkte först på en historiktabell i databasen, men funderar nu på Redis istället. Kanske kan databasen användas som en fallback-mekanism om Redis blir full.

Behöver monitor och reglage av redis synsk-system, för kunna se prestanda samt reglera gränsvärden.

Motargument

Redis minne, som lagras i RAM, är mer flyktigt, mer begränsat. Kräver komplexitet för kontinuitet och att hantera begränsningar.

Behöver vi skriva parallell historik till databas? Kan vi ha historik enbart i redis? Problem: redis minnet töms (server omstart,... persistent memory? Kräver då skriva till hårddisk, motverkar avsikt undvika det, och är intervall baserat (?) så risk förlora data). Problem: Redis minne fullt, ingen mer plats.

Lösning (?): i de få fall data töms, ha mekanism där klienten kan upptäcka det och återställa via databas.

Scenario: redis-minne raderas, ex. omstart av server, redis minne börjar fyllas igen, klient återvänder efter det

Kommer klient missa den data som raderades och bara få data efter omstarten?

Klienten ska då jämföra lokal databas tidsstämpel med serverns databas tidsstämpel

Idé - separat historiktabell i databasen