Research and Development 1/^Archief/2009-2010/06/Fase1

Uit Werkplaats
< Research and Development 1‎ | ^Archief‎ | 2009-2010‎ | 06
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken

Fase 1

Framework

In de pilot is te lezen dat wij zelf een groot deel de PHP code zelf schrijven.

Hier zijn wij op terug gekomen. Er is nu besloten om een PHP framework te gebruiken. Dit zorgt er voor dat het project sneller ontwikkeld kan worden. Een (goed) framework bied een grote standaard functionaliteit zoals database query builders, sessions, etc.

De keuze is nu gevallen op het Kohana: The Swift PHP Framework (v3.x, [1]). Kohana (v3.x) is een light weight maar krachtig PHP framework. De keuzen is hier op gevallen door Leon, die er al ervaring mee had. Een groot voordeel van Kohana is de structuur waarin applicatie gemaakt worden: het 'cascading filesystem' en het HMVC pattern (Hierarchical-Model-View-Controller pattern). Kohana is ook een goed geïmplementeerd modulair framework. Zo kan je makkelijk extra functionaliteit toevoegen die automatisch door het hele framework gebruikt kan worden. Dit kan handig toegepast worden met plug-ins voor dOPE (bijv. een extra programmeertaal voor de editor).

Het HMVC pattern word nog niet zo veel toegepast. Kohana is één van de eerste, bekendere, PHP frameworks dit HMVC toe past. Voor meer informatie over HMVC, volg deze link: [2].

Maar natuurlijk zouden wij niet voor een specifiek framework kiezen als deze ons niet bevalt. Kohana vinden wij lekker werken en de keuzen was dan ook snel gemaakt.

User model

Omdat we toch een (H)MVC pattern gebruiken kan je makkelijk models onderscheiden. Zo ook, natuurlijk, een User model.

Omdat dOPE een site is waar gebruikers aan projecten kunnen werken, is het noodzakelijk dat je weet wie zich op de site bevind en of hij/zij wel aan een project mag werken. Hier voor kan je makkelijk een 'user' systeem gebruiken. Een gebruiker moet zich eerst aanmelden op de site alvorens hij/zij aan zijn/haar projecten kan werken, etc.

De user moet een unieke ID hebben (userID), een naam (firstName en lastName), natuurlijk een wachtwoord (lees hier verderop meer over) en een email (als 'username' en voor mailen van meldingen etc.).

Er kan dus makkelijk een model gemaakt worden voor een user. Omdat dOPE een webapplicatie is, en niet alleen daarom, is het handig om gebruikers in een relationele database op te slaan. We gebruiken hier in eerste instantie MySQL voor omdat deze het makkelijkst te installeren / gebruiken is op standaard webservers (is vaak aanwezig op webservers en heeft een handige beheer tool phpMyAdmin).

Om users later te kunnen filteren (non-actieve users, etc.) worden er nog wat extra velden opgeslagen. Namelijk:

  • registeredOn (timestamp)
  • lastLoggedInOn (timestamp)
  • firstActivatedOn (timestamp)
  • lastActivatedOn (timestamp)

Ook heeft een user een 'veld' activated (bool). Als een account aangemaakt wordt, wordt door middel van een account activatie mechanisme afgedwongen dat een email bestaat. Dit voorkomt (gedeeltelijk) spam accounts. Elke keer als de email gewijzigd wordt (dus bij registratie en via settings -> email wijzigen) moet de account dmv. een link die via een email verstuurd wordt, (opnieuw) geactiveerd worden.

Nog een belangrijk punt bij een user model in een database is dat een wachtwoord van een user nooit als 'plain text' opgeslagen mag worden. Gebruikelijk is dan ook om een wachtwoord eerst 'hashen' alvorens deze op te slaan. Om te kijken bij de login of het opgegeven wachtwoord overeenkomt met de opgeslagen wachtwoord moet de opgegeven wachtwoord eerst gehashed worden waar na de beide hashen gewoon vergeleken kunnen worden.

Omdat hashes met de krachtige computer vandaag nog steeds gekraakt kunnen worden moet de hash-functie zorgvuldig gekozen worden. Om het 'kraken' van hashes te vertragen hebben we een simpele, maar effectieve oplossingen bedacht. Namelijk:

  • Een 'salt' toevoegen
  • Meerdere keren hashen

Vooral het meerdere keren hashen vergroot de kraak tijd aanzienlijk. Dit is omdat een hash gebruteforced wordt. Dit is een methode die simpel weg (op een slimme manier) alle mogelijkheden probeert. Komt het resultaat uit op een de zelfde hash, dan weet je het origineel (het wachtwoord). Als je nou meer als een keer hashed, wordt deze methode een zeer tijdrovende bezigheid.

We hebben als hash-functie SHA512 gekozen. Dit staat voor Secure Hash Algorithm (512 bits). Dit is al een relatief moeilijk te 'kraken' hash-functie.