Tutorial - En adminapplikation

1. Introduktion

Vi har i två tidigare tutorials byggt ett inloggningssystem och sedan också kopplat denna till en databas. Mycket av funktionaliteten från den senare applikationen är bra men det är inte tillräckligt för att nå alla målen i denna kurs. Därför gör vi nu ett tredje försök att bygga klart detta projekt.

Just projekt är ett nyckelord då vi skall göra detta som ett projekt med allt från en projektplan till utvärdering och dokumentation av färdig applikation värdig ett mindre projekt.

1.1 Uppgiften

Det som skall läggas till och förändras från de tidigare två tutorials är följande;

  • Vi behöver skapa en projektplan.
  • Databasen som vi byggde i det tidigare projektet behöver förändras lite, vi behöver lagra krypterade lösenord och vi skall också kunna stänga av en användare så att användarens konto inte går att logga in på.
  • När vi bygger om databasen så behöver vi för dokumentationens skull skapa en ER-modell och en databasmodell vilket vi hoppade över i den senaste tutorialen.
  • Vi behöver skydda oss mot SQL-injection vid inloggning och dessutom hantera inloggning med ett krypterat lösenord.
  • Vi behöver skydda oss mot skadlig kod så att inte olika skript kan påverka applikationen.
  • Vi skall göra en tillräcklig dokumentation av vårt projekt och även utvärdera vårt arbete.

1.2 Förutsättningar

För att kunna följa denna tutorial så behöver du ha en fungerande inloggningsapplikation med koppling till databasen enligt den tutorial som vi använde när vi byggde applikationen. Om du har byggt vidare på tutorial eller om den ser lite annorlunda ut så borde du ändå kunna följa denna tutorial och implementera det som jag gör fast med lite ändringar.

Börja med att ta en kopia på mappen där den tidigare applikationen finns och döp den nya mappen till något bra. Jag döper den till admin eftersom vi bygger en adminapplikation. Tanken är denna applikation skall kunna bli grunden till andra applikationer som du bygger senare.

Varför skapar jag ett nytt projekt när jag enkelt skulle kunna bygga vidare på det som redan heter inloggdb, eller något liknande? Delvis så handlar det om att det är bra att ha olika versioner av projekt ifall vi skulle gå fullständigt vilse i vår vidareutveckling men det kan också vara så att ett annat projekt som du vill bygga senare passar sig bättre att utgå ifrån inlogg eller inloggdb.

2. Projektplan

Enligt kunskapsdokument: projektstöd så beskrivs hur en projektplan bör se ut för att planera ett projekt. Projektplan är ett viktigt dokument för att samla information inför ett projekt, inte minst ett webbprojekt. En projektplan ser naturligtvis olika ut beroende på storleken på projektet och hur många utvecklare som deltar i projektet. Nu gör vi ett litet projekt vilket också gör att vi kan skapa en enkel projektplan.

De delar jag anser behöver finnas med i vårt projekt är följande.

2.1 Syfte och presentation av uppgiften

Här beskriver vi kort projektet och om det finns en tydlig uppgift eller beställning så går det ofta att använda delar av denna text. I vårt projekt skulle vi kunna skriva att Projektet är en skoluppgift i kursen Webbserverprogrammering01(/Webbutveckling01) och är en beställning av läraren. Projektet innebär att vi skapar ett databasdrivet system som hanterar olika användare och deras inloggning i ett system. Syftet med uppgiften är att det skall vara ett examinerande projekt där jag visar på kunskaper för att nå ett betyg på kursen.

Skriv det med egna ord så har du presenterat uppgiften och syftet med projektet.

2.2 Skiss

En enklare skiss (trådskiss eller mockup) över applikationens utseende. Detta är extra viktigt ifall du jobbar med front-end (webbutveckling). Jag har gjort en enklare skiss på hur sidan såg ut i version 1 när vi skapade inloggningaspplikationen.

Gör en egen enkel skiss över hur du vill att applikationen skall se ut, stötta gärna med att tala om ifall du använder något css-ramverk för att få till det rätta utseendet.

2.3 Funktioner

Ge en kort beskrivning av de funktioner som kommer finnas i den applikation som vi bygger. Finns det få funktioner så kan de förklaras lite mer ingående, finns det väldigt många så gäller det att göra en mer översiktlig beskrivning.

I detta projekt så skulle jag beskriva funktionerna ungefär så här;

I adminsystemet finns följande funktioner;

  • Inloggning av registrerad användare.
  • Möjlighet att skapa ny användare.
  • Ett användarkonto kan uppdateras och tas bort.
  • Ett användarkonto kan inaktiveras så att en användare förlorar möjligheten att logga in.

Systemet är enkelt i sin uppbyggnad men är förberett för att kopplas ihop med andra applikationer där ett adminsystem behövs.

Beskriv nu funktionerna i ditt system med dina egna ord. Om du tidigare har byggt till egna funktioner så se till att dessa finns med i beskrivningen.

2.4 Övrigt

I hjälpdokumentet om projektplanen så finns det exempel på att ta med information om tidsplanering och gemensam kodstandard. Det är sådant som är mest intressant ifall projektet är avsevärt större än det projekt som vi för tillfället bygger.

Därför tycker jag att det är onödigt att ta med dessa punkter för tillfället.

2.5 Projektplan som fysiskt dokument

Slutför nu det dokument som du döper till projektplan. Hur du skapar detta dokument är upp till dig. Har du fått en beställning av en kund så vill kunden säkert ha denna som ett dokument som är möjligt att skriva ut. I denna kursen så dokumenterar vi ju med hjälp av WordPress så skapa en post eller en page beroende på hur du vill dokumentera detta projekt. Sedan när dokumentationen och utvärderingen skall redovisas så kan du göra det i en page, eller i en eller flera post.

Låt också projektplanen vara ett levande dokument. Om du väljer att jobba vidare med detta projekt efter att min tutorial är slut så behöver du uppdatera din projektplan. Att ha inaktuella dokument kopplade till ett projekt är allt för vanligt och väldigt trist.

3. Databasen

Då har det blivit dags att ta tag i databasen. Först måste vi kika på hur databasen ser ut som vi skapade i vår tidigare tutorial. Eftersom vi inte har någon utskriven datamodell så får vi kika på det enda som vi har tillgängligt, vilket är SQL-koden för att skapa databasen.

Kodexempel: sql för tabellen user

-- Created by Vertabelo (http://vertabelo.com)
-- Last modification date: 2018-12-07 10:59:39.599

-- tables
-- Table: user
CREATE TABLE user (
    userId int NOT NULL AUTO_INCREMENT,
    username varchar(30) NOT NULL,
    password varchar(60) NOT NULL,
    CONSTRAINT user_pk PRIMARY KEY (userId)
);

-- End of file.

Det vi ser är att vi har en tabell som heter user och som består av tre attribut.

  • userId, som automatiskt räknar upp ett heltal.
  • username, en sträng som får innehålla max 30 tecken.
  • password, en sträng som får innehålla max 60 tecken.

På rad 10 så skapas också en primärnyckel som kopplas till attributet userId.

3.1 Förändringar

Under punkt 1.1 i denna tutorial så talade vi om att vi behövde förändra databasen lite. Vi behövde se till att vi kunde lagra krypterade lösenord och att det går att stänga av en användares konto så att hen inte kan logga in. Detta är en snällare variant mot att ta bort en användare helt. Att ta bort en användare innebär att vi inte kan återskapa data om denna användare men om vi bara inaktiverar användaren så finns ju all lagrad data kvar.

En snabb googling visar att den krypteringsteknik jag tänker använda, SHA-1, skapar en hashad kod som består av 40 st hexadecimala tecken. I den databas vi redan har så finns det utrymme att lagra lösenord på 60 tecken. Vi behöver alltså inte ändra detta, om vi nu inte vill minska storleken på det fältet.

Att lägga till en flagga för att stänga av ett konto är inte så svårt men vi hamnar snabbt i en teoretisk diskussion om vilken datatyp vi vill använda. Det finns en skola som säger att datatypen borde vara boolean. Detta gäller speciellt de som är vana vid att programmera i språk där variabler deklareras som C++, C#, Java mfl. De som mest programmerar språk med dynamiska datatyper som PHP, Python tycker kanske inte att det är lika viktigt att det just måste vara en boolean. Ett stort problem med PHP är att boolean inte är så tydligt som det borde vara. Googlar du på php boolean problem så får du en hel radda med exempel där det uppstår värden som vi inte riktigt förväntar oss. Många av problemen är väl nördiga i sin utformning men det känns inte bra att jobba med en datatyp som kan ge oss obehagliga fel. Därför förespråkar jag att vi använder oss av datatypen int och använder 1 som positivt eller ok och 0 som negativt eller inte ok. På det sättet skapar jag en flagga som är lätt att ta emot och hantera. Vill vi dessutom bara ändra den ett steg, (0 blir 1 och 1 blir 0) så kan vi göra det väldigt enkelt med en matematisk operation [i = (i+1)%2], vilket gör att vi inte behöver bygga upp en if-else-struktur för att vända på en flagga.

3.2 ER-modell

Dags att bygga ER-modellen för vår databas som vi använde i förra tutorialen fast med tillägget att vi lägger till ett attribut för att låsa ute en användare. Då gäller det att hitta ett bra namn på detta attribut. Jag tycker det är lämpligt att använda active för att kunna visa att användaren är aktiv eller inte. En aktiv användare kan logga in, en som inte är aktiv kan inte logga in.

ER-modell

ER-modellen skapar du i draw.io och när du är klar så exporterar du en bild på din ER-modell för denna skall du sedan lägga med i dokumentationen.

3.3 Databasmodell

Då tar vi informationen från vår ER-modell och bygger upp en databasmodell i Vertabelo.

Databasmodell

För att kika närmare på vilka inställningar jag har gjort i databasmodellen så tar jag fram SQL-scriptet som används för att skapa tabellen.

SQL-skript

Här ser vi att userId och username ser ut som tidigare. Jag har minskat längden på attributet password så att det endast rymmer 40 tecken, fler behövs inte då SHA-1 genererar en hash med den längden. Jag har också lagt till active med datatypen int och detta attribut har fått ett defaultvärde på 1 då jag tycker att det rimligaste i vår applikation är att en nyskapad användare får access till systemet. Hade vi använt oss av ett system där användaren får ett verifikationsmail som skall besvaras innan kontot blir aktivt så hade vi troligtvis satt ett annat värde. Här finns ytterligare en fördel med att använda datatypen int istället för en boolean som bara har två värden. Vi kan nu sätta vilka värden vi vill, 0 för spärrad, 1 för aktiv, -1 för ett konto som behöver verifieras osv.

Exportera en bild på din Databasmodell och SQL-skriptet för dessa behöver du när du skapar din databas och till dokumentationen.

3.4 Skapa databasen

Dags att skapa databasen på din dator. Öppna PHPMyAdmin och skapa en ny databas som du döper till något lämpligt, jag kör på admin. Eftersom vi har skapat ett nytt projekt i en ny mapp så är det lika bra att skapa en ny databas. Detta för att kunna ha flera olika versioner av vårt system tillgängligt om det skulle behövas.

När databasen är skapad så kör du SQL-skriptet som du hämtade från Vertabelo.

Om allt har gått som det är tänkt så har du nu en databas med en tom tabell. Populera denna tabellen så att du får några användare så att vi kan logga in i vårt system när vi kommer så långt.

Populerad tabell

Nu har vi skapat vår lätt förändrade databas och nu är det dags att börja göra de ändringar i PHP-koden som behövs.

4. Förändra PHP-koden

Innan vi förändrar någonting så skall vi se att den mappen vi tidigare skapade fungerar att köra. Öppna den applikationen i en webbläsare och testa. Om mappen nu ligger inom webbservern så borde applikationen fungera. Det finns dock ett problem. Om du inte har ändrat namn på databasen i filen database_connection.php så kommer du fortfarande ansluta mot din gamla databas. Detta måste vi ändra.

Kodexempel

Testa igen och se att du kan logga in med någon användare som du har i den nya databasen. Det funkade hos mig så där är det dags att fundera på vilka förändringar vi skall göra?

De saker som jag vill lägga till vår applikation är följande;

  • Implementera active så att vi kan stänga av en användare. Denna användare skall inte kunna logga in. I inloggat läge skall vi lägga till aktiv/inaktiv som ett alternativ under händelse.
  • Lösenord skall krypteras och ändringar behöver göras så att det fungerar.
  • Se till att det inte går att logga in genom SQL-injection.
  • Förhindra att skadlig kod påverkar hemsidan.

Vi gör förändringarna i den ordningen som de är skrivna.

4.1 Aktiv/inaktiv användare

När jag populerade min tabell så skapade jag tre användare varav en satte jag activ till 0. Det innebär att denna användare inte skall kunna logga in i systemet. Om du testar att logga in nu så kommer det att fungera så det måste vi spärra på något sätt.

Att lösa detta är enkelt, det handlar bara om att förändra SQL-satsen när vi loggar in. Just nu kollar vi bara att användarnamn och lösenord matchar, men vi måste lägga till ett argument till och det är active = 1.

Kodexempel

Testa nu att logga in med användare som är aktiv respektive användare som inte är aktiv. Denna lilla ändring borde spärra de användare som inte skall ha tillgång till systemet. Meddelandet en spärrad användare får är samma som man får vid felaktig inloggning. Här kan man fundera på om vi vill ge ett annat felmeddelande. Om man väljer att göra så behöver vi istället låta SQL-satsen vara som den var tidigare men innan vi godkänner inloggningen så behöver vi kolla att värdet på active, om det är 1 så genomförs inloggningen annars skrivs ett meddelande ut. Fördelen med detta är att en användare som är van att ha tillgång till systemet får ett bättre meddelande där det kanske står att kontakta ansvarig person. Nackdelen med denna typ av meddelande är att de bottar som försöker logga in på olika sidor på nätet kan fånga upp detta meddelande och förstår då att kombinationen av användarnamn och lösenord är giltigt och skulle då kunna lägga till denna kombination i sin lista över kombinationer att testa på andra webbplatser. Här behöver du som utvecklare, eller beställaren, ta ett beslut. Just i detta fallet så låter vi det vara som det är.

Nu måste vi kunna ändra värdet för en aktiv/inaktiv användare. Jag vill lägga detta som ytterligare en länk bland händelserna [ta bort] [ändra] i adminlistan.

Jag börjar med att se till att det står att användaren är aktiv eller inaktiv i en egen klammerbox. Detta göra jag genom att hämta värdet från active från databasen och gör om 1 eller 0 till text som jag kan skriva ut.

Kodexempel Webbsidan

På rad 27-31 så kan jag nu fortsätta att bygga upp innehållet i klammerbox, jag vill slänga in en länk för att kunna förändra värdet och jag skulle också vilja färgkoda texten så att det lyser grönt om man är aktiv och rött om man är inaktiv. Men vi börjar med länken så att vi kan klicka på texten och ändra värde. Vi har gjort något liknande när vi väljer att ta bort en användare. Om vi istället skapar en händelse som ändra om användaren är aktiv genom att hämta id, läsa av värdet för aktiv just nu och ändrar detta innan vi skickar tillbaka det till databasen. Vi skapar en fil som vi döper till changeActiveUser.php.

Kodexempel

Testar du applikationen nu så går det att göra en användare aktiv eller inaktiv.

Webbsidan

Det jag vill göra nu är att förstärka texten active/inaktiv med färg för att göra det lättare att se tydligt. Här skulle vi kunna använda oss av symboler eller bilder istället vilket är smidigt ifall vi har väldigt många användare. Att lägga till sortering eller filtrering hjälper ju också till men det skall vi inte göra i denna uppgiften.

Du behöver formatera färgen på länken beroende på om texten visar active eller inactive. Det gör du enkelt med css. Jag använder mig av ett ramverk där ett antal nyckelfärger redan finns namngivna och jag kan enkelt ange dessa.

Kodexempel

Utskriften ser då ut på följande sätt.

Webbsidan

Då är vi klara med den punkten och kan gå vidare till nästa del.

4.2 Kryptera lösenordet

Att kryptera själva lösenordet är enkelt, det finns en inbyggd funktion i php för att kryptera med sha-1. Det går också att kryptera lösenord på webbsidan http://www.sha1-online.com som vi kan klistra in i databasen. Vi gör det lite snabbt så att vi får in de krypterade lösenorden i databasen. Hur du gör det spelar ingen roll, det viktigaste är att det kommer in i databasen. När det är gjort så ser det ut på följande sätt.

Webbsidan

Nu är frågan om det är intressant att skriva ut lösenordet eftersom det är krypterat. Men så länge vi utvecklar applikationen så kan det hjälpa oss ifall vi vill se att lösenordet ändras. Men i en färdig applikation bör vi nog välja att ta bort den utskriften och det är ju lätt gjort.

4.2.1 Logga in med krypterade lösenord

När vi nu har ändrat lösenorden i databasen så behöver vi ändra hanteringen av lösenorden i vår applikation. För tillfället går det tex inte att logga in eftersom vi måste kryptera lösenordet innan vi jämför med databasens lagrade lösenord. För att testa att det inte fungerar just nu så logga ut och försök att logga in igen. Bra. Då behöver vi lösa detta.

I den filen som tar hand om inloggningen så behöver vi nu kryptera det inmatade lösenordet innan vi jämför med databasens lagrade lösenord. Att göra detta är enkelt, det handlar bara om att anropa funktionen sha1().

Kodexempel

Testa nu att logga in igen. Nu borde det fungera.

Då är det dags att fundera lite på om det finns fler ställen vi behöver ändra i koden för att alltid jobba med krypterade lösenord. Jag kommer på två ställen, det ena är när vi skapar en ny användare och det andra är när vi skall uppdatera en användares data.

4.2.2 Skapa användare med krypterade lösenord

Vi börjar med skapandet av en ny användare. Vi behöver inte göra något på den sidan som innehåller formuläret men vi måste ändra i sidan som tar emot info från formuläret. Hos mig heter denna sidan insertUser.php. Här gör vi samma sak som vi gjorde tidigare. Vi lägger till funktionen sha1() runt lösenordet som hämtas från formuläret.

Kodexempel

Testa sedan att skapa en ny användare. Det fungerar för mig.

Webbsidan

På min bild så ser du också att jag har breddat sidan lite så att jag slipper få en radbrytning i min tabell.

4.2.3 Uppdatera användare med krypterade lösenord

När vi nu skall uppdatera en användares lösenord så ställs vi inför ett problem.

Webbsidan

I rutan för lösenord så finns redan det krypterade lösenordet. Det innebär att om jag skulle trycka på knappen nu så skulle det redan krypterade lösenordet krypteras en gång till. Här finns det flera sätt att lösa detta problem.

  1. Låt rutan vara tom för lösenord och låt användaren mata in ett lösenord för att kunna uppdatera användaren.
  2. Gör en separat sida för att uppdatera bara lösenordet.
  3. Lägg en knapp eller på något annat sätt markera att lösenordet har blivit ändrat eller inte och har det inte ändrats så görs ingen uppdatering av just lösenord till databasen.

I vårt exempel så kan vi ju också fundera på om vi skall kunna ändra användarnamn på en befintlig användare men det kanske är en annan fråga. Hade vi inte tillåtit detta så hade det endast vara möjligt att ändra lösenord i vår applikation och då hade vi inte haft ett problem. Däremot så hade det kanske varit intressant att skapa två rutor för att ange ett nytt lösenord och att dessa två rutor kollas mot varandra så att lösenordet är lika. Fast det där styrs enkelt av javascript och det är en annan kurs.

Jag väljer att göra den första lösningen. Vi tar bort det förifyllda innehållet för lösenordsrutan så slipper vi av misstag kryptera ett redan krypterat lösenord. Jag tar bort den markerade koden.

Kodexempel

För att kunna uppdatera på rätt sätt så behöver jag i filen updateUser.php nu också kryptera lösenordet som jag tar emot från formuläret.

Kodexempel

Nu kan du testa att uppdatera lösenord för en användare. När jag testar så fungerar det.

4.3 Skydda mot SQL-injection

Detta är egentligen en onödig punkt eftersom vi inför slutprojektet konstaterade att vi får det skydd som behövs när vi använder oss av PDO för att ansluta till databasen. Men för att bevisa att vi inte kan använda oss av SQL-injection för att komma in i vår applikation så skriver du admin' OR 1 = 1; /* i rutan för användarnamn och sedan skriver du något valfritt i rutan för lösenord, den får ju inte vara tom. När du sedan klickar på att logga in så kommer du få meddelande om att du har angivit felaktiga inloggningsuppgifter och att du inte kan logga in.

4.4 Skydda mot skadlig kod

Om du som användare vill vara lite rolig när du skriver in data till databasen så kan du göra en del skada genom att använda html/css/javascriptskod när du gör inmatningar. Vi har tidigare kikat på hur man kan ange en snutt javascriptskod för att få sidan att gå någon helt annan plats än vad som var tänkt. Men det går också att göra mindre skada. Testa att skapa en användare genom att lägga in htmlkoden för rubriknivå1 runt användarnamnet, <h1>Johan<h1>. Vad händer då?

Webbsidan

Så kan vi ju inte ha det. Här finns det flera lösningar. En lösning kan vara att leta efter tecken på skadlig kod i den inmatade strängen. Ett tecken som < kan innebära problem och då skulle vi kunna bestämma att sådan data inte får lagras. Men det är klart att om du har ett forum med fokus på programmering eller matematik så kommer du behöva det tecknet i din text.

Det finns en inbyggd funktion i php som heter htmlentities() som gör om htmltecken så att de skrivs ut istället för att användas. Detta ger oss ett visst skydd men är också användbart tex i kursolle där jag vill att viss htmlkod skall skrivas ut istället för att köras på en sida. Vi använder funktionen htmlentities() på de ställen där det behövs, vilket i vårt fall är när vi läser av användarnamnet från formulär i insertUser.php och updateUser.php.

Kodexempel Kodexempel

Vi behöver inte göra detta på lösenordet eftersom det ändå skall krypteras så finns det ingen risk att den koden skall påverka webbsidan. Jag testar att skapa en ny användare igen på samma sätt med html-kod och nu ser det istället ut så här.

Webbsidan

Det är ju inte speciellt snyggt men det påverkar iaf inte webbsidan på något negativt sätt. Men det är naturligtvis viktigt att göra de kontroller som vi anser att vi vill göra och ta de beslut som är lämpliga för den applikation som vi skapar. En annan PHP-funktion som är intressant är strip_tags() som tar bort html-taggar i en sträng. Med den funktionen kan vi dessutom kolla ifall en sträng innehåller html-taggar och ge användaren ett meddelande att det som matas in inte är godkänt. Nackdelen med att göra detta med PHP är att då har redan formuläret skickats till en ny sida. Om vi löser detta med JavaScript så kan inte användaren skicka formuläret om det inte är korrekt. Men återigen, det ligger inte i denna kursen utan i någon av Webbutvecklingskurserna. Här är dock ett exempel på hur vi kan kolla ifall en inmatning innehåller html-kod.

Viktigt att tänka på är vad som skall skyddas mot, är det HTML-kod så är det en teknik, vill du skydda dig mot JavaScript så kan det behövas andra tekniker.

5. Testa vår applikation

I punkt 4 så listade vi fyra saker som vi skulle förändra i detta projekt. Dessa fyra saker är nu åtgärdade. Det som återstår nu är att testa applikationen så att den fungerar som vi tänkt. Vi lånar det testschema som vi använde i en tidigare tutorial och anpassar den så att den nu även testar den funktionalitet som vi har lagt till.

5.1 Testschema

En sak som är viktig att veta om är att alla webbservrar har sina egna inställningar. Den webbserver du kör lokalt på din dator är inställd på att vara en utvecklingsserver vilket gör att den är lite mer tolerant mot fel. Den server som finns på Binero är inställd i produktionsläge och är mindre tolerant. Därför är det viktigt att testa igenom applikationen ordentligt först lokalt och sedan när den ligger uppe på Bineros server. För att vi inte skall missa något test så är det viktigt att skapa ett testschema så att allt testas innan vi är nöjda och redo att leverera vår applikation. Ett testschema består av ett antal punkter som vi testar en och en.

  • Testa att logga in med korrekt användarnamn och lösenord.
  • Testa att logga in med felaktigt användarnamn och/eller lösenord.
  • Testa att lägga till en ny användare. Logga ut och logga in som den användaren.
  • Testa att ta bort en användare.
  • Testa att uppdatera en användare. Uppdatera lösenord och logga sedan in som denna användare.
  • Testa att du kan göra en användare inaktiv och aktiv genom att klicka på länken.
    • Testa så att du inte kan logga in som en inaktiv användare.
  • Logga ut och försök nå följande sidor genom att skriva in deras adress i URL-rutan. I alla fall så skall du skickas till index med ett meddelande om att du inte har rätt att vara där.
    • changeActiveUser.php (vilket är den enda sidan som vi har skapat ny i denna tutorial, de sidor som fungerade förra gången lär fungera igen)

Testa nu igenom din applikation så att du kontrollerar att allt är ok. Om du stöter på ett problem så behöver du lösa detta. Jag testade igenom min applikation utan fel och kan nu gå vidare till nästa punkt.

5.2 Snygga till koden

Gå nu igenom koden en gång till och se till att bortkommenterad kod tas bort och att koden är kommenterad på ett sätt som du är nöjd med. Du kan ha synpunkter på att jag inte kommenterat koden allt för mycket, då har du chansen att göra detta bättre.

Hade detta varit ett skarpt projekt hade det varit önskvärt om du hade presenterat en sitemap så att en utvecklare som tar över sidan från dig vet hur den är uppbyggd. Är filnamnen bra så går det ganska snabbt att förstå hur allt hänger ihop, men det är ändå tacksamt att ärva en bra dokumenterad applikation.

Om du inte har lagt till CSource till applikationen tidigare så gör det nu och kolla också igenom koden via CSource så att alla lösenord till databasen döljs, det är väldigt viktigt när vi nu är redo att lägga upp applikationen på Bineros server.

Hade denna leveransen gått till kund så borde vi också validera den färdiga html-koden och den css vi använder. Men det ligger mer på kursen inom Webbutveckling.

5.3 Flytta applikationen till Bineros server

Då har det blivit dags att flytta applikation och databas till Bineros server. Detta sker exakt som vi gjorde i vår förra tutorial under punkt 5. Flytta till domän på Bineros server. Min rekommendation är att du skapar en ny databas för detta projekt och låter din gamla databas finnas kvar för det förra projektet.

När applikationen finns på plats så är det återigen dags att gå igenom testschemat under punkt 5.1 för att säkerställa att allt fungerar som det skall även på Bineros server. Det är i den miljön som du sedan skall redovisa.

6. Dokumentation och utvärdering

Då återstår endast att dokumentera vår applikation och att utvärdera arbetet.

6.1 Teknisk dokumentation

Den tekniska dokumentationen skall innehålla de delar som är viktiga för applikationen och som är viktigt att veta om du skulle ta över drift och underhåll av en webbsida. I vårt fall så borde här finnas bilder på ER-modellen, databasmodellen och SQL-scriptet för databasen. Vår databas innehåller ju bara en tabell så den koden kan vi på ett enkelt sätt skriva ut. Hade det varit en större databas sås hade vi troligtvis länkat till en fil med detta script.

Själv applikationen består inte av så många filer så det vore enkelt för oss att lista namnet på alla filer och med en kort mening berätta vad varje fil gör. Att länka till CSource gör det enkelt för den som vill kika på koden att göra det. I vårt fall vill jag ha länken till CSource eftersom det är så du blir bedömd på kodkvaliteten.

En sitemap är grymt snyggt men så fort det blir lite större siter så är det svårt att bygga en sådan på ett överskådligt sätt samtidigt som en liten applikation ofta inte behöver en site-map då det är relativt lätt att skapa sig en egen översiktsbild av hur applikationen är uppbyggd. En viktig sak att tänka på är att döpa filerna på något bra sätt. Även den som inte tidigare har sett vår applikation kan ganska snabbt få en korrekt känsla över vad varje fil gör i vår applikation. Hade filerna hetat fil1.php, fil2.php osv så hade det varit viktigare att göra en lista för utvecklare att få koll på siten.

6.2 Utvärdering

Slutligen så vill jag ha en kort skriftlig utvärdering av arbetet oavsett om du till punkt och pricka följt min tutorial eller om du har byggt om eller byggt vidare på egen hand. Alla ändringar du har gjort är jag särskilt intresserad av. Frågor som kan vara stöd för din text är;

  • Hur har arbetet gått med att följa tutorial. Har det varit lätt/svårt att följa eller tydligt/otydligt att hänga med i utvecklingsprocessen.
  • Vad har du lärt dig under arbetet? Känner du att du nu skulle kunna bygga vidare på eller bygga en liknande applikation på egen hand, eller med min tutorial som stöd?
  • har du valt att bygga om eller bygga vidare på saker i denna tutorial till din egen applikation? Finns det saker som du skulle vilja att jag lade till i tutorial?

6.3 Hur dokumentera

Nu är vi klara med allt arbete för slutprojektet och du skall nu slutföra dokumentationen av projektet. Jag vill att du göra detta i din WordPress, men du får själv avgöra om du väljer att göra det i en page/sida eller om du vill göra det i ett eller flera post/inlägg. Det viktigaste är att det är tydligt och lätt för mig att följa.

7. Hela applikationens kod

I denna tutorial kommer inte hela applikationens kod att visas. Alla ändringar vi har gjort finns tydligt dokumenterade ovan.