Projekt 02, VED house

Planering

Syfte

Projektet ska vara en utökning av VED house, Projekt 03 från webbutveckling 1/tillämpad programmering 1, och ska implementera ett fungerande backend-system för att kunna lagra bokningar globalt på en databas. Mycket av planeringen från Projekt 03 består i detta projekt, och det enda som ändras är hur bokningssystemet fungerar.

Funktioner

Projektet ska använda en PHP-backend som fungerar som ett API. Servern ska ha en anslutning till en MySQL-databas för att lagra bokningar, administratörinlogg och öppettider.

Applikationen ska fortfarande nyttja mycket av JavaScript-koden som redan skapats för projektet, men den ska skrivas om så att den kontaktar serverns API istället för att den lagrar bokningarna i cookies.

Administratorsidan ska skrivas om och implementera ett inloggningssystem, där man ska även kunna ändra öppettider på dagarna, samt se och eventuellt ta bort bokningar.

Databasmodeller

Resultat

Länk till bokningssida
Länk till administratorsida och källkod
Inlogg: admin, lösenord: @dmin##

Till slut fungerar bokningssystemet. Följande funktioner har implementerats:

REST API skriven i PHP.
Öppettider som visas på VED huvudsidan.
Sida för att lägga bokningar.
Hantering av bokningar.
Hantering av bokningsinställningar, d.v.s. bokningslängd, bokningsintervall och antal platser.
Hantering av öppettider, samt förmågan att lägga till undantag till de vanliga öppettiderna.

API

Min API använder sig av en modifiering till serverns routerkod via .htaccess, som leder alla webbförfrågan som börjar på https://als070804sn.hemsida.eu/api till api/api.php. Då hanteras webbförfrågan och vidareleds till rätt API endpoint. Beslutet att ändra routerkoden gjordes för att hålla alla API-förfrågan inom en viss standard och se till att det fungerar smidigt. Servern kontrollerar inkommande parametrar och ser till att de är formatterade på rätt sätt. Utifrån detta utförs databas-anrop som antingen hämtar eller förändrar data. Vissa API endpoints kräver autentisering med en token, som hämtas genom api/ved/admin/login. Denna token används som en Bearer token i Authorization headern vid API-förfrågan där det krävs.

Lägga bokningar

Sidan för att lägga bokningar kontaktar API med hjälp av JavaScript. Eftersom en stor del av funktionaliteten var redan skriven i förra projektet, behövdes inte den skrivas om. Det krävdes fortfarande en hel del anpassning till API, eftersom datan behöver hämtas från webbservern, vilket sker asynkront. Från användarens perspektiv har ingenting förändrats, utan bokningarna läggs till på precis samma sätt som innan.

Administratorsidan

Administratorsidan har också förändrats. Sidan kontaktar API för att hämta och läsa data. Detta används för att logga in, hämta och eventuellt ta bort bokningar, ändra tidtabeller och ändra bokningsinställningar. Dessutom har sidan har fått ett inloggningssystem som använder ett relativt enkelt tokensystem för att sköta autentisering. Denna token lagras som en cookie i webbläsaren och expirerar efter 24 timmar. Man har valet att logga ut, vilket skickar en till inloggningssidan, samt skickar en förfrågan till servern att ta bort token.

Säkerhet

Alla API-förfrågan som interagerar med en databas använder sig av PHP PDO parametrar för att förhindra SQL-injektion när parametrar från klienten används. Dessutom lagras alla lösenord i databasen i form av SHA-256 hasher. Dessa hasher har saltats med en 32-byte slumpad sträng för att förhindra storskaliga brute-force attacker och rainbow table lookup.

Typiskt så brukar API tokens komma i par – en autentiseringstoken och en refresh token. För att komma åt vanliga resurser använder man autentiseringstoken som oftast har en kortare livstid. När denna går ut använder man sin refresh token, som har mycket längre livstid, för att få en ny autentiseringstoken.

Jag har tagit beslutet att inte gå denna väg och istället har jag enbart en autentiseringstoken med lång livstid och ingen refresh token. Detta har jag gjort eftersom mängden användare är begränsad till administratörerna. Det innebär att risken för att användarens token sprids är mycket låg eftersom den kommer endast lagras på enstaka enheter och befinna sig på privata nätverk. Dessutom ville jag hålla autentiseringsdelen till projektet relativt enkelt.