Skip to main content

Development-Logs

Uge 8 – Deployment

Hvad jeg har implementeret

Denne uge har jeg deployet CIT til DigitalOcean, så API’et kan bruges uden at køre på min egen computer.

API’et er tilgængeligt på:

https://api.antwi.dk/api/v1/incidents

Endpointet kræver et gyldigt JWT. Derfor får man 401, hvis man åbner linket direkte uden et token.

Build og GitHub Actions

Jeg har tilføjet Maven Shade Plugin, som samler projektet og dets biblioteker i én fil: app.jar. Min Dockerfile bruger Java 17 og starter serveren fra denne fil.

January 1, 0001

Uge 7 – Security

Hvad jeg har implementeret

Denne uge har jeg tilføjet registrering og login til CIT. Passwords gemmes som en bcrypt-hash, og ved login får brugeren et JWT, der gælder i en time. Jeg brugerTokenSecurity-bibliotek, og nøglen hentes fra JWT_SECRET.

Brugere, passwords og roller

Min User har fået et passwordHash. Når en bruger oprettes med navn, e-mail og password, hasher constructoren passwordet med bcrypt. Ved login bruger verifyPassword() bcrypt til at kontrollere det indtastede password mod den gemte hash.

January 1, 0001

Uge 6 – REST & Test

Hvad jeg har implementeret

Denne uge har jeg lavet automatiserede tests af mit REST API med REST Assured og Hamcrest. Jeg brugte mine DAO-tests og Hotel API fra undervisningen som hjælp.

Testopsætning

Testcontainers starter en separat PostgreSQL-database. Før hver test rydder jeg tabellerne og opretter en testbruger og en hændelse. Serveren og testene bruger den samme testdatabase.

Hvad testene kontrollerer

Jeg har nu 7 API-tests:

  • GET af alle hændelser: Kontrollerer status 200 og JSON som indholdstype.
  • GET med kontrol af indhold: Kontrollerer, at listen indeholder testhændelsens titel.
  • GET via ID: Kontrollerer, at den rigtige hændelse returneres med det forventede ID, titel og status.
  • POST: Opretter en hændelse og kontrollerer status 201, et genereret ID og de forventede felter. Hændelsen hentes bagefter med GET for at kontrollere, at den er gemt.
  • POST med tom titel: Kontrollerer status 400 og fejlbeskeden Titel må ikke være tom.
  • PUT: Ændrer titel, beskrivelse, severity og status. Et efterfølgende GET kontrollerer, at ændringerne er gemt.
  • DELETE: Kontrollerer status 204 og en tom response body og derefter et GET på samme ID skal give 404.

Resultat

Alle syv tests i ApiTest bestod ved kørslen. Det var kun API-testklassen, ikke hele projektets tests.

January 1, 0001