week 1: Gebruikersregistratie en -authenticatie

[technoviumunlimited]

Opdracht: Ontwerp en Implementatie van Gebruikersrechtenbeheer in MySQL en NoSQL

Doel: Het doel van deze opdracht is om een diepgaand begrip te ontwikkelen van zowel relationele als NoSQL-databasesystemen, en hoe deze kunnen worden gebruikt voor het beheren van gebruikersrechten binnen een applicatie. Studenten zullen leren hoe ze een systeem kunnen ontwerpen en implementeren met gebruikersrollen zoals admin, docent, student, en bedrijf, eerst in een MySQL-database en vervolgens in een NoSQL-database (Firebase).

Deel 1: Ontwerp van een Genormaliseerde ERD voor MySQL

Ontwerp een genormaliseerd Entiteit-Relatie Diagram (ERD) voor een MySQL-database. Het ERD moet entiteiten bevatten voor gebruikers, rollen (admin, docent, student, bedrijf) en de relaties tussen deze entiteiten. Zorg ervoor dat het ontwerp rekening houdt met beveiliging en efficiëntie. Deel 2: Implementatie in NoSQL met Firebase en Node.js

Vertaal het relationele databaseontwerp naar een NoSQL-schema geschikt voor Firebase. Ontwikkel Node.js-functies om de gebruikersrechten te beheren in de NoSQL-database. Implementeer functies voor het creëren, lezen, bijwerken en verwijderen van gebruikers en hun rollen. Eindproduct:

Een volledig gedocumenteerd ERD voor MySQL. Een gedocumenteerd schemaontwerp voor Firebase. Werkende Node.js-functies voor gebruikersrechtenbeheer. Een verslag waarin de verschillen tussen de relationele en NoSQL-aanpak worden besproken, inclusief de voor- en nadelen van elk.

[donfokker]

Voorbeeld ERD

Permissions: Zorgt voor stuctuur, houd in welke machtigingen de gebruiker heeft.

Roles: Geeft een idee wat de functie is van de gebruiker en geeft beeld over zijn permissies.

User: Bevat de gegevens van de gebruikers binnen het systeem.

Session: Logt de gegevens waneer een gebruiker is ingelogt op het systeem.

Password_reset_token: Wanneer een gebruiker zijn inlog is vergeten kan die persoon een password reset token aanvragen om zijn inlog te kunnen resetten.

Game: Bevat bepaalde gegevens van een game.

[Void787]

een voorbeeld van hoe de database met login gegevens omgaat, het idee achter deze ERD is dat als een user inlogt het word opgeslagen in login attempts of deze nou geslaagd of gefaald is. Dis is zodat als er iets mis gaat de Admin kan zien wie er allemaal heeft ingelogd en wie het geprobeerd heeft.

Password reset request heeft hetzelfde doeleinde als login attempts. Sessies heeft als doel om aan te geven wanneer iemand bepaalde acties doet op de website die de sessie nodig hebben zoals games, sessies zal daar in tegen een grotere rol hebben als we een soort koopbaar element toevoegen aan de website.

Security logs heeft als doel een groot archief te zijn met alles wat er op de website gebeurt, alles wat met de database te maken heeft word hier opgeslagen. al denk ik wel dat er op de website een soort filter functie moet zijn hiervoor want deze tabel word heel groot heel snel. Ook denk ik dat het regelmatig schoonmaken van deze tabel heel belangrijk is.

[nielstoemen]

[MoenirElIbrahimi]

deze database ontworpen om informatie over spellen, gebruikers, gebruikersrollen, gebruikerssessies, inlogpogingen en beveiligingslogs te beheren. Het vergemakkelijkt het bijhouden van gebruikersactiviteiten, spelletjes, en beveiligingsgebeurtenissen binnen het systeem.

[Void787]

een voorbeeld voor hoe de firebase eruit zou kunnen zien:

{ "-NinrwyfZSW6B00pLSm1": { "GameID": 1, "Time": 1, "Level": "voorbeeld@email.com", "GamesPlayed": "geheim123" }, "-Ninrwyf_ZXyDkzuhjmn": { "GameID": 1, "Time": 1, "Level": "token123", "GamesPlayed": "2023-01-01 12:00:00" }, "-NinrwyfvpiR7gG0DduI": { "GameID": 1, "Time": "Admin", "Level": "Full Access" }, "-NinrwyftW1oK35KgmqQ": { "GameID": 1, "Time": 1, "Level": "2023-01-01 12:30:00", "GamesPlayed": "Security event occurred" }, "-NinrwyfHCts5hJRUvWh": { "GameID": 1, "Time": 1, "Level": "2023-01-01 12:45:00", "GamesPlayed": "192.168.0.1" }, "-NinrwyfHSTUljuecdKU": { "GameID": 1, "Time": 1, "Level": 1 }, "-Ninrwyfy6_fyrZDC0RQ": { "GameID": 1, "Time": "2023-01-01 14:00:00", "Level": 5, "GamesPlayed": 10 } }

[MoenirElIbrahimi]

Mijn idee is dat je in User bij de firestore een role toevoegt waar je kan kiezen tussen bezoeker, student, docent, bedrijf en admin. Met dit kan je in de code de permissions beschrijven. Bezoeker:

Kan alleen lezen (bekijken). Geen schrijfrechten. json match /{document=**} { allow read; allow write: if false; } Student:

Kan games toevoegen aan Firestore. json match /games/{document} { allow read; allow create: if request.auth != null; } Docent:

Kan games en logposts toevoegen aan Firestore. Kan games goedkeuren. json match /games/{document} { allow read; allow create, update, delete: if request.auth != null && request.auth.token.roles.includes('docent'); }

match /logposts/{document} { allow read, create; allow update, delete: if request.auth != null && request.auth.token.roles.includes('docent'); } Bedrijf (In progress)

Admin: Heeft alle rechten, inclusief het verwijderen van games en logposts. json match /{document=**} { allow read, create, update, delete: if request.auth != null && request.auth.token.roles.includes('admin'); }

[MoenirElIbrahimi]

const admin = require('firebase-admin'); const serviceAccount = require('path/to/serviceAccountKey.json');

admin.initializeApp({ credential: admin.credential.cert(serviceAccount), databaseURL: 'https://your-project-id.firebaseio.com', });

const uid = 'userUid'; // het UID van de gebruiker aan wie je de rol wilt toewijzen

// Voeg aangepaste claims (rollen) toe aan de gebruiker admin.auth().setCustomUserClaims(uid, { roles: ['student'] }) .then(() => { console.log('Aangepaste claims (rollen) toegevoegd aan de gebruiker.'); }) .catch(error => { console.error('Fout bij het toevoegen van aangepaste claims (rollen):', error); });

[MoenirElIbrahimi]

mogelijke structuur

• gebruikers (collection)

  • {userUid} (document)
  • email: "gebruiker@example.com"
  • roles: ["student"]

• games (collection)

  • {gameId} (document)
  • titel: "Game Titel"
  • beschrijving: "Een beschrijving van de game"
  • status: "pending" // In afwachting van goedkeuring
  • createdBy: "gebruikerUid" // UID van de gebruiker die de game heeft geüpload

• logposts (collection)

  • {logpostId} (document)
  • inhoud: "Logpost inhoud"
  • game: "gameId" // Verwijzing naar de bijbehorende game
  • createdBy: "gebruikerUid" // UID van de gebruiker die de logpost heeft gemaakt
  • approved: false // Alleen relevant voor docenten en admins

[nielstoemen]

Json nosql schema: { "LoginAttempts": { "_id": "ObjectId", "attempt_id": 1, "attempts": 3, "user_id": 123 },

"Users": { "_id": "ObjectId", "user_id": 123, "role": ["admin", "user"], "username": "john_doe", "info": "Some information", "password": "hashed_password" },

"Sessions": { "_id": "ObjectId", "session_id": 456, "user_id": 123, "begin_time": ISODate("2023-01-01T12:00:00Z"), "end_time": ISODate("2023-01-01T13:00:00Z") },

"SecurityLog": { "_id": "ObjectId", "log_id": 789, "logs": "Some logs", "errors": "Some errors", "session_id": 456, "user_agent": "UserAgent String", "ip_address": "192.168.1.1" },

"PasswordReset": { "_id": "ObjectId", "reset_id": 987, "old_password": "hashed_old_password", "new_password": "hashed_new_password", "user_id": 123 } }

[liam-kilsdonk]

Dit is de eerste versie van het ERD, het toont hoe gebruikers rollen kunnen worden geïmplementeerd. er is bewust niet gekozen voor een "Session entity" sessie tokens horen niet in de database zelf te worden opgeslagen maar lokaal zoals in het geheugen van de browser.