INTERNET-BASERAT GRÄNSSNITT FÖR DATABASHANTERING I ETT PORTALSYSTEM

Transkript

1 Examensarbete 20 poäng D-nivå INTERNET-BASERAT GRÄNSSNITT FÖR DATABASHANTERING I ETT PORTALSYSTEM Reg.kod: Oru-Te-EXA089-D105/05 Camilla Larsson Magisterprogrammet i Datateknik160 p Örebro vårterminen 2005 Examinator: Lars Karlsson INTERNET-BASED INTERFACE FOR HANDLING DATABASES IN A PORTAL SYSTEM Örebro universitet Örebro University Institutionen för teknik Department of Technology Örebro SE Örebro, Sweden

2

3 Sammanfattning Denna rapport beskriver framtagningen av ett Internet-baserat användargränssnitt för uppdatering av information i en databas. Arbetet är utfört på uppdrag av NovaCast Technologies AB. Målet med arbetet var att implementera detta gränssnitt som sedan skulle integreras i ett befintligt portalsystem, mysubcontract. På grund av svårigheter med utvecklingsmiljön har fokus istället lagts på att ta fram ett detaljerat lösningsförslag för hur ett sådant gränssnitt kan skapas. Förutom detta lösningsförslag har en mindre studie av portaler på Internet, som har liknande funktioner som mysubcontract, genomförts. Abstract This report describes the development of an Internet-based interface for updating information in a database. The work has been done for NovaCast Technologies AB. Initially the goal was to implement such an interface and then integrate it with an existing portal system, mysubcontract. Due to difficulties with the development environment a detailed solution for how to implement the interface has been produced instead. Apart from this a small study of portals on the Internet, that are similar to mysubcontract, have been done. 1(48)

4 Förord Denna rapport är ett resultat av ett examensarbete som omfattar 20 poäng på magisterprogrammet i datateknik vid Örebro universitet. Arbetet utfördes på NovaCast Technologies AB i Ronneby under våren Jag vill passa på att tacka alla på NovaCast Technologies AB och Thomas Padron McCarthy, min handledare vid universitetet, för den hjälp jag har fått under arbetets gång. 2(48)

5 Innehåll 1 INLEDNING NOVACAST TECHNOLOGIES AB PROBLEM PROJEKTBESKRIVNING ETAPPER MÅL KRAV PÅ UTFORMNINGEN AV SYSTEMET Beskrivning Befintliga funktioner Funktioner som ska utvecklas kravlista TEKNIKER HTML ASP Allmänt om ASP Objekt i ASP XML PHP VISUAL BASIC JAVASCRIPT VBSCRIPT SQL ADO JÄMFÖRELSE AV ASP OCH PHP STUDIUM AV DET BEFINTLIGA SYSTEMET FÖR INMATNING AV INFORMATION UPPBYGGNAD GRÄNSSNITTET MYSUBCONTRACT IDAG SÄKERHET Kryptering SQL-injektion Cross-site scripting Lösenord STUDIUM AV OLIKA LÖSNINGAR I BEFINTLIGA PORTALER PÅ INTERNET ANVÄNDARVÄNLIGHET STUDIUM AV PORTALER Subcontract Solutions TechPilot CastingTrade.com DISKUSSION OCH SLUTSATSER Registrering Inmatningar Felhantering Inloggning (48)

6 6 FÖRSLAG TILL PRINCIPLÖSNING INLOGGNING MANUAL INRE STRUKTUR INMATNING SÄKERHET GODKÄNNANDE UNDERRÄTTELSE OM NY INFORMATION DET NYA SYSTEMET INLOGGNING INMATNING SÄKERHET GODKÄNNANDE UNDERRÄTTELSE OM NY INFORMATION FORTSATT ARBETE/MÖJLIG VIDAREUTVECKLING UTVÄRDERING/ANALYS TERMINOLOGI REFERENSER...45 BILAGA 1 PRODUKTBLAD MYSUBCONTRACT (48)

7 1 Inledning 1.1 NovaCast Technologies AB NovaCast Technologies AB i Ronneby har som huvudsaklig verksamhet att utveckla och marknadsföra datorsystem för simulering, teknisk beredning och processtyrning till den fordonsorienterade gjuteriindustrin. Företaget har sedan starten 1981 arbetat med att lösa komplicerade metallurgiska problem inom gjuteriindustrin. De erfarenheter som de har skaffat sig under sina många år inom branschen har bearbetats och utvecklats till avancerade programvaror som distribueras över hela världen. I december 2004 hade NovaCast Technologies AB över 300 aktiva kunder i 39 olika länder. 1.2 Problem NovaCast Technologies AB har en Internet-portal kallad mysubcontract. Avsikten med portalen är att sammanföra köpare och säljare av gjutgods. På portalen finns bland annat en söktjänst för att hitta gjuterier. För mer information om mysubcontract se bilaga 1. Gjuterier som har sin information på portalen har i dagsläget ingen möjlighet att själva lägga till ny information om sitt företag och sina produkter. De kan inte heller modifiera befintlig information. Informationen som finns i systemet måste läggas in och uppdateras av personal på NovaCast Technologies AB. Detta medför ett omfattande manuellt arbete och ibland kan det ta flera dagar innan ny information blir synlig i portalen. NovaCast Technologies AB önskar därför vidareutveckla sitt befintliga system, genom att skapa en process som tillåter representanter för gjuterierna att modifiera och lägga till information. 5(48)

8 2 Projektbeskrivning Detta kapitel beskriver uppgiften som NovaCast Technologies AB ville ha hjälp med att lösa. 2.1 Etapper NovaCast Technologies AB har delat upp projektet i fem olika etapper. Dessa är: 1. Studium av det befintliga systemet för inmatning av information. Under denna etapp ska det befintliga systemet med källkod, dokumentation och portal studeras. De tekniker som används i systemet och uppbyggnaden av systemet ska beskrivas under ett separat kapitel i denna rapport. Se kapitel 3. I detta kapitel kommer även en liten jämförelse mellan två av de vanligaste metoderna för att skriva webbsidor, ASP och PHP presenteras. I nästföljande kapitel beskrivs det befintliga systemet. I anknytning till detta ska metoder för säkerhet på Internet studeras och beskrivas kortfattat. 2. Studium av olika lösningar i befintliga portaler på Internet. Befintliga portaler på Internet ska studeras och analyseras i syfte att ta reda på hur liknande system fungerar. De portaler som studeras ska ha liknande funktioner som mysubcontract. Portalerna ska studeras med tanke på användarvänlighet. Se kapitel Förslag till principlösning för Internetbaserad uppdatering av databasen. Efter att ha studerat olika lösningar på Internet ska en lösning, som tar hänsyn till de krav som NovaCast Technologies AB har ställt på den nya processen, tas fram. Förslaget på lösning kommer att redovisas i kapitel Implementering av systemet. Då NovaCast Technologies AB har godkänt ett förslag till principlösning, ska lösningen implementeras och lyftas in i det befintliga systemet. Se kapitel 6 för resultatet av denna etapp. 5. Testning av systemet. Då en lösning har implementerats ska dess funktionalitet och användarvänlighet testas praktiskt både av utvecklaren och av ett antal användare. Denna etapp genomfördes inte och kommer därför inte att redovisas i denna rapport. 2.2 Mål Målet är att få en process som gör det enklare att lägga till nya gjuterier, samt uppdatera de befintliga gjuterierna i portalen mysubcontract. Denna nya process innefattar att personal på ett gjuteri själva ska kunna lägga in sin information på portalen så att det manuella arbetet, idag utfört av personal på NovaCast Technologies AB, minskas. Koden för den nya processen ska läggas till i det redan befintliga systemet på sådant sätt att den befintliga inre strukturen bibehålls. 2.3 Krav på utformningen av systemet Beskrivning Framtagningen av denna nya process innefattar att skapa ett Internetbaserat användargränssnitt. Detta gränssnitt ska göra det möjligt för gjuterier att själva lägga till och 6(48)

9 redigera den information som finns om företaget på portalen mysubcontract. Det nya gränssnittet kommer att utvecklas genom att kombinera ihop delar av systemets befintliga källkod tillsammans med ny källkod. Utvecklingen kommer huvudsakligen att ske i ASP och Visual Basic 6.0, vilket är vad det befintliga systemet till stor del är uppbyggt av. För mer information om ASP och Visual Basic se kapitel 3 nedan Befintliga funktioner Systemet består av en webbplats där det finns olika möjligheter för inloggning. Bland annat kan man logga in som vanlig användare eller som administratör. Möjlighet finns också att logga in som en representant för ett gjuteri, idag finns dock inga aktiva användarkonton av denna typ. Det finns förutom dessa tre några andra inloggningsalternativ. Dessa alternativ berörs inte av det nya systemet som ska utvecklas och därför beskrivs de inte heller i denna rapport. Nedan beskrivs i några punkter huvuddragen för inloggning som användare och inloggning som administratör. Inloggad som vanlig användare finns möjlighet att: Redigera personliga uppgifter Ändra lösenord Söka gjuterier Läsa nyheter Ta del av övrig information som finns på sidan Inloggad som administratör finns möjlighet att: Administrera användarkonton Administrera information om företag Administrera nyheter Administrera reklam Se statistik för webbplatsen Funktioner som ska utvecklas kravlista Nedan följer en lista på de krav som det nya systemet ska eller bör uppfylla. Representanter för gjuterier ska själva kunna logga in och lägga till information om sitt företag. Ingen manual ska behövas för att kunna mata in eller redigera information. Eftersom det nya systemet kommer att användas av representanter från företag och inte av administratörer, ställs högre krav på användarvänlighet än i det befintliga systemet. Inga ändringar ska göras av den befintliga inre strukturen i systemet. Inmatning av information bör ske via färdiga mallar. Det nya systemet ska uppfylla krav på säkerhet, speciellt gällande behörighet och innehållskontroll. En administratör ska godkänna den information som matas in av personal på ett företag innan den publiceras på portalen. Då ny information finns för godkännande bör administratören underrättas om detta på något sätt. 7(48)

10 3 Tekniker Under detta kapitel beskrivs de olika tekniker som systemet bygger på. Även PHP, som inte används i systemet, kommer att beskrivas kortfattat eftersom det tas upp i en jämförelse senare i detta kapitel. 3.1 HTML HTML står för HyperText Markup Language och är en teknik som används för att skapa webbsidor [1]. För att kunna titta på informationen på en webbsida krävs en webbläsare som tolkar HTML-koden. Koden är uppbyggd av olika taggar som är inneslutna mellan tecknen < och >. Det finns många olika taggar i HTML. Ett exempel är <B>, som gör att texten som står efter taggen blir fet. De flesta taggarna i HTML står i par, med en starttagg och en sluttagg. Exempelvis innebär <B>Fet text</b> att texten mellan taggarna blir fet, medan text utanför inte påverkas av kommandot. Sluttaggen är likadan som starttaggen förutom att den alltid börjar med tecknet /. Man kan säga att starttaggen aktiverar kommandot och sluttaggen inaktiverar det. Det finns en grundläggande struktur hos HTML-dokument som alltid måste följas. Först i varje dokument så specificeras vilken version av HTML som används. Detta görs med hjälp av taggen <!DOCTYPE>. Taggen <HTML> står alltid med i början på dokumentet. Dokument ska alltid avslutas med </HTML> för att stänga denna tagg. Därefter kommer taggen <HEAD> som stängs med </HEAD>, mellan dessa taggar skrivs information som används av webbläsaren. Denna del av dokumentet brukar kallas för dokumentets huvud. Här kan exempelvis webbsidans titel ligga, om den har någon sådan. Sist kommer <BODY> som stängs med </BODY>. Denna del kallas för dokumentets kropp. Mellan dessa taggar finns den information som besökare på webbsidan kommer att se. För mer information om HTML se [1]. HTML-kod för en enkel webbsida kan se ut så här: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " <HTML> <HEAD> <TITLE>En enkel webbsida</title> </HEAD> <BODY> Det är här det mesta av innehållet på webbsidan finns! </BODY> </HTML> Sparar man denna fil i exempelvis programmet Anteckningar, med ändelsen.html, och sedan öppnar filen med webbläsaren Internet Explorer ser det ut som i figur 1 nedan. 8(48)

11 Figur 1: En enkel webbsida skriven i HTML-kod. 3.2 ASP Allmänt om ASP ASP står för Active Server Pages [7]. Det är en teknik utvecklad av Microsoft för att kunna skapa dynamiska webbsidor. Med dynamiska webbsidor menas att en webbsida kan ändra utseende beroende på vid vilken tidpunkt den besöks eller beroende på vad besökaren väljer att utföra på webbsidan. Ett enkelt exempel på en dynamisk webbsida är en sida som visar aktuellt klockslag. Detta är något som inte är möjligt med ren HTML-kod. Tekniken bygger på att enklare programmeringskod, ASP-kod, bakas in i vanlig HTML-kod. ASP-koden körs sedan på webbservern där webbsidan ligger lagrad. I samband med att ASP-koden körs översätts den till vanlig HTML-kod, som sedan kan tolkas av besökarens webbläsare. En fil som innehåller ASP-kod ska ha ändelsen.asp, detta för att webbservern ska kunna känna igen och hantera filen på ett korrekt sätt. När ASP-kod bakas in i HTML-koden måste detta markeras. Vanligen markeras det med hjälp av avgränsarna <% och %>. Allt som står emellan de två avgränsarna tolkas som ASP-kod av webbservern. I kombination med ASP brukar något skriptspråk användas, ex. VBScript som beskrivs närmare i avsnitt 3.7 nedan. Vilket skriptspråk som används specificeras överst i ASP-filen, se exemplet nedan. Koden för en enkel webbsida som använder ASP tillsammans med VBScript kan se ut så här: <%@LANGUAGE = "VBScript"%> <HTML> <HEAD> <TITLE>En enkel webbsida</title> </HEAD> <BODY> Det här är en enkel ASP-sida.<BR> Dagens datum: <%=Date%> </BODY> </HTML> Efter att webbservern har översatt koden till vanlig HTML-kod ser den ut så här: <HTML> <HEAD> <TITLE>En enkel webbsida</title> 9(48)

12 </HEAD> <BODY> Det här är en enkel ASP-sida.<BR> Dagens datum: </BODY> </HTML> Då någon besöker webbsidan ser den ut som i figur 2 nedan. Figur 2: En enkel webbsida som använder ASP och VBScript. För att kunna använda ASP bör webbservern ligga på en dator som har Windows NT 4.0 eller senare versioner av Windows installerat. ASP-tekniken är som tidigare nämnts utvecklad av Microsoft, tidigare fungerade den endast på Microsofts egen webbserver IIS 1. Idag finns det dock tilläggsprogram för att kunna köra ASP på andra operativsystem [22]. Exempel på ett sådant program är Sun Java System Active Server Pages 4.0 [17], som möjliggör att ASP körs på bl. a. operativsystemen Linux och Solaris Objekt i ASP Som nämndes ovan är ASP inte något egentligt programmeringsspråk, utan snarare en samling objekt som används för kommunikation mellan webbserver och webbläsare. I ASP finns det sju stycken objekt som alla har varsitt användningsområde. Varje objekt har också ett antal egenskaper och metoder knutna till sig. De olika objekten beskrivs kortfattat i punktform nedan. Application - används för att knyta samman ASP-filer som har en gemensam uppgift. Eftersom Application-objektet är gemensamt för alla användare, används det även för att lagra information som flera användare kan behöva. Request används för att förmedla information från användaren till webbservern. Response används för att förmedla information från webbservern till användaren. Server används för att komma åt egenskaper och metoder hos externa objekt på webbservern. Session används för att lagra information om en enda användare. 1 IIS står för Internet Information Services och finns att få gratis med Windows NT 4.0 eller senare versioner av Windows. 10(48)

13 ObjectContext används endast för kommunikation med Microsoft Transaction Server, ett program som bl. a. hanterar förfrågningar från en användare till en webbserver. Error används för att visa detaljerad information om fel som inträffar i skript som finns skrivna inuti en ASP-sida. För ytterligare information om objekt i ASP se [23]. 3.3 XML XML står för extensible Markup Language och är ett markeringsspråk. Enligt Benoît Marchal [4] kan XML sammanfattas som: en uppsättning standarder för att utbyta och publicera information på ett strukturerat sätt. XML är utvecklat av W3C 2 för att komma förbi de begränsningar som finns i HTML. En nackdel med HTML är att fördefinierade taggar krävs för allt. Eftersom olika användare kräver olika typer av taggar, innebär detta att språket hela tiden har byggts på. Att ett språk blir större innebär också att det blir svårare att hantera. XML bygger till viss del på samma principer som HTML (se avsnitt 3.1), men det finns en viktig skillnad: HTML är till för att visa data medan XML är till för att beskriva och lagra data. Detta innebär att XML inte ska betraktas som en ersättare för HTML utan snarare som ett komplement [24]. XML används endast för att beskriva data. För att visa de data som XMLdokumentet beskriver behöver ett program skrivas. Detta kan göras på många olika sätt och behandlas inte vidare här, för mer information se [4]. Som nämndes ovan är språken uppbyggda på liknande sätt. De två största språkmässiga skillnaderna är att XML är striktare och att man definierar sina taggar själv. Till exempel kräver XML att man alltid använder både en starttagg och en sluttagg, i HTML är detta inte alltid nödvändigt. XML är skiftlägeskänsligt vilket innebär att <tagg> inte är detsamma som <TAGG>. I HTML skulle dessa taggar tolkas lika. Ett XML-dokument börjar vanligtvis med taggen <?xml version= 1.0?>. Detta är en deklarationstagg som talar om att dokumentet är ett XML-dokument och att version 1.0 av XML används. Exempel på XML-kod för att beskriva en person: <?xml version= 1.0?> <person> <namn>camilla</namn> <alder>24</alder> <bor>sverige</bor> </person> XML-koden ovan beskriver en person. Om man skulle spara denna kod i en fil med ändelsen.xml och sedan öppna filen med webbläsaren Internet Explorer ser det ut som i figur 3 nedan. 2 World Wide Web Consortium, en organisation som bestämmer över utvecklingen och underhållningen av många webbstandarder 11(48)

14 Figur 3 Exempel på en XML-fil. Figur 3 ovan illustrerar det faktum att XML är utvecklat för att beskriva innehållet, inte för att presentera det. För att kunna presentera informationen i XML-filen på ett snyggt sätt krävs att någon ytterligare teknik används. Hur detta görs beskrivs inte närmare här, men ett sätt är att använda stilmallar som innehåller information om hur innehållet i XML-filen ska visas. 3.4 PHP PHP står för PHP Hypertext Preprocessor och är ett skriptspråk utvecklat för att skriva dynamiska webbsidor [6]. Språket utvecklades av Rasmus Lerdorf för att han ville veta hur många som var inne och tittade på hans CV som han lagt ut på webben. PHP har öppen källkod vilket innebär att koden är tillgänglig för allmänheten så att vem som helst kan vidareutveckla språket. På liknande sätt som för ASP (se avsnitt 3.2) så bakas PHP-koden in i HTML-koden. PHPkoden körs sedan på webbservern där webbsidan ligger lagrad. I samband med att en besökare efterfrågar en webbsida omvandlas all PHP-kod till HTML-kod av PHP-tolken på webbservern. HTML-koden skickas sedan vidare till besökarens webbläsare som tolkar och visar innehållet på webbsidan. Filer som innehåller PHP-kod ska ha ändelsen.php, detta för att webbservern ska kunna känna igen och hantera filen på ett korrekt sätt. När PHP-kod bakas in i HTML-koden måste detta markeras. Vanligen markeras det med hjälp av avgränsarna <?php och?>, men det kan även förkortas till <? och?>. Allt som står emellan de två avgränsarna tolkas som PHP-kod av PHP-tolken på webbservern. Koden för en enkel sida som använder PHP kan se ut så här: <HTML> <HEAD> <TITLE>En enkel webbsida</title> </HEAD> <BODY> <?php echo "Det här är en enkel PHP-sida.<BR>"; echo "Dagens datum: "; echo date("y-m-d");?> 12(48)

15 </BODY> </HTML> Efter att webbservern har översatt koden till vanlig HTML-kod ser den ut så här: <HTML> <HEAD> <TITLE>En enkel webbsida</title> </HEAD> <BODY> Det här är en enkel PHP-sida.<BR>Dagens datum: </BODY> </HTML> Då någon besöker webbsidan ser den ut som i figur 4 nedan. Figur 4 En enkel webbsida som använder PHP. För att kunna använda PHP måste det först installeras på den webbserver som man använder. Att installera PHP är gratis och en installationsfil kan hämtas hem från PHP:s webbsida 3. PHP fungerar på de allra flesta plattformar som finns, exempelvis Windows, Linux, Unix och Mac OS. 3.5 Visual Basic 6.0 Visual Basic 6.0 är ett programmeringsspråk utvecklat av Microsoft. Visual Studio är det utvecklingsverktyg som används tillsammans med Visual Basic 6.0. Utvecklingsverktyget är till för att underlätta vid skapandet av grafiska användargränssnitt. Saker som exempelvis knappar och inmatningsfält går att skapa genom att klicka med musen. Visual Basic kan bland annat användas för att programmera funktionalitet i ett användargränssnitt eller för att skapa egna komponenter. Komponenterna sparas i DLL-filer och i med detta blir klasserna inuti komponenterna återanvändbara i andra projekt. DLL-filer kan användas på vilken dator som helst som har Windows. Genom att spara DLL-filen på en dator och sedan registrera den så blir komponenten tillgänglig på datorn. För mer information om hur registrering av en DLLfil går till se [14] (48)

16 3.6 JavaScript JavaScript är ett skriptspråk som är utvecklat av Netscape. Den största skillnaden mellan ett skriptspråk och ett traditionellt kompilerat programmeringsspråk är att ett skriptspråk kan köras direkt i datorn eller webbläsaren utan att koden först behöver kompileras (d.v.s. omvandlas från källkod till körbar kod). JavaScript används främst för att göra webbsidor mer dynamiska och möjliggöra interaktion med webbsidans besökare [5]. Med hjälp av JavaScript kan beräkningar och funktioner utföras på besökarens dator istället för på webbservern. Detta har flera fördelar. Bland annat fås en lägre belastning på webbservern som sidan ligger på och det går snabbare för besökaren. Eftersom information inte behöver skickas till eller tas emot från webbservern varje gång sidan laddas om. JavaScript infogas i HTML-kod med hjälp av en särskild tagg som talar om var JavaScript-koden börjar respektive slutar. Nedan följer ett exempel på en HTML-sida där JavaScript används. <HTML> <HEAD> <TITLE>En enkel webbsida med JavaScript</TITLE> <SCRIPT LANGUAGE = JAVASCRIPT > <!-- function info() { alert('denna sida använder JavaScript'); return false; } --> </SCRIPT> </HEAD> <BODY onclick=info()> Webbsida med JavaScript. </BODY> </HTML> Sparar man denna fil i exempelvis programmet Anteckningar, med ändelsen.html och sedan öppnar filen med webbläsaren Internet Explorer ser det ut som i figur 5 nedan. Figur 5 Webbsidan som innehåller JavaScript-koden Om en besökare klickar någonstans på sidan så kommer en meddelanderuta upp som ser ut som i figur 6 nedan. 14(48)

17 Figur 6 Meddelanderuta som är gjord med JavaScript 3.7 VBScript VBScript är ett skriptspråk som är utvecklat av Microsoft. Namnet är en förkortning för Visual Basic Scripting Edition. Språket fungerar endast med Microsofts webbläsare Internet Explorer. VBScript härstammar från programmeringsspråket Visual Basic och används för att göra webbsidor mer dynamiska [1]. Med hjälp av VBScript kan beräkningar och funktioner utföras på besökarens dator istället för på webbservern. I det stora hela fungerar VBScript på liknande sätt som JavaScript, se avsnitt 3.6 ovan. VBScript behöver inte nödvändigtvis köras i besökarens webbläsare. Det går även att köra VBScript på webbservern. Fördelen med detta är att skriptet då kommer åt resurser som finns på webbservern. Sådana resurser kan exempelvis vara en databas. Nedan följer ett exempel på en HTML-sida där VBScript används. <HTML> <HEAD> <TITLE>En enkel hemsida med VBScript</TITLE> <SCRIPT LANGUAGE = "VBSCRIPT"> <!-- Function Info MsgBox "Denna sida använder VBScript" End Function --> </SCRIPT> </HEAD> <BODY onclick = Info> Webbsida med VBScript. </BODY> </HTML> Sparar man denna fil i exempelvis programmet Anteckningar, med ändelsen.html, och sedan öppnar filen med webbläsaren Internet Explorer ser det ut som i figur 7 nedan. 15(48)

18 Figur 7 Webbsidan som innehåller VBScript-koden. Om en besökare klickar någonstans på sidan så kommer en meddelanderuta upp som ser ut som i figur 8 nedan. Figur 8 Meddelanderuta som är gjord med VBScript. 3.8 SQL SQL står för Structured Query Language och är ett språk som används för att läsa, modifiera, lägga till och ta bort data i en relationsdatabas. I en relationsdatabas lagras data i tabeller, där varje tabell består av ett antal rader och kolumner. Beroende på vilken databashanterare man väljer att använda så finns det olika dialekter av SQL. De mest grundläggande kommandona är dock desamma för alla dialekter. För att ha möjlighet att ställa en SQL-fråga till en databas behöver en koppling upprättas till databasen. Detta sker vanligtvis med en speciell objektsamling som heter ADO, mer information om detta finns i avsnitt 3.9 nedan. För mer information om SQL se [2]. Figur 9 nedan visar hur en tabell i en databas kan se ut. Denna tabell har tre rader och fyra kolumner och den håller reda på personers idnr, namn, ålder och land. Figur 9 Exempel på hur en tabell i en databas kan se ut. För att hämta information från tabellen behöver en SQL-fråga ställas till databasen. Om man exempelvis vill ha reda på namnen på alla personer som ligger i tabellen Personer, kan man skriva: 16(48)

19 SELECT Namn FROM Personer Detta innebär att all data som ligger i kolumnen Namn i tabellen Personer hämtas från databasen. Det vill säga Camilla, Helena och Fredrik returneras. 3.9 ADO ADO står för ActiveX Data Objects och det är ett gränssnitt som bland annat kan användas för att upprätta kommunikation mellan en databas och en webbsida. Tekniken är utvecklad av Microsoft och kan användas tillsammans med ASP och SQL. För att skapa en koppling till en databas måste man på sin ASP-sida använda sig av två stycken inbyggda objekt som finns i ADO. Dessa två objekt heter Connection och Recordset. Connection används för att upprätthålla själva kopplingen och Recordset används för att hantera data till och från databasen. För mer information om ADO se [21] Jämförelse av ASP och PHP I detta avsnitt diskuteras kortfattat ASP och PHP som har presenterats ovan. Diskussionen kommer främst att beröra för- och nackdelar med de olika teknikerna att skapa webbsidor. Syftet är att reflektera över om PHP hade kunnat användas till mysubcontract istället för ASP. Både ASP och PHP har kommit till för att underlätta skapandet av dynamiska webbsidor. De bygger på liknande teknik, d.v.s. enklare programmeringskod som bakas in i HTML-kod. En viktig del av mysubcontract är de formulär som används för inmatning. Därför är det av stor betydelse hur inmatade värden tas om hand. I ASP skickas information som en besökare matat in i ett formulärfält vidare med hjälp av objektet Request. Det finns två olika metoder för detta, POST och GET. Bägge metoderna kräver att ytterligare en metod anropas för att den inmatade informationen ska kunna bearbetas. Jämfört med PHP så är detta invecklat. I PHP finns möjlighet till direkt åtkomst till den inmatade informationen genom användandet av formulärfältets namn. En skillnad mellan de bägge är att PHP har ett stort antal inbyggda funktioner. Detta innebär att många av de saker som någon kan tänkas vilja göra på sin webbsida redan finns implementerade, så istället för att skriva en egen funktion kan anrop till en befintlig funktion göras. I ASP finns inte ett lika stort utbud av inbyggda funktioner, däremot så finns de sju olika ASP-objekten, som var för sig har ett antal metoder. Dessa metoder innehåller dock inte lika mycket som de inbyggda funktionerna i PHP. En möjlighet när man använder ASP är att använda sig av komponenter. Komponenter är filer som installeras på webbservern, dessa tillför funktionalitet till ASP. Man kan skriva egna komponenter eller välja att använda sig av andras. Mysubcontract är till stor del uppbyggt på användandet av sådana komponenter. Den inre strukturen som systemet har skulle därför vara svår att bibehålla med PHP. I PHP kan man definiera sina egna funktioner, men det skulle ändå vara svårt att återskapa den 3- skiktsmodell som systemet använder sig av. Slutsatsen av denna diskussion är att ASP är bättre lämpat för mysubcontract eftersom det inte finns något enkelt sätt att bygga upp den önskade strukturen om PHP skulle användas. 17(48)

20 4 Studium av det befintliga systemet för inmatning av information Under denna etapp har den existerande dokumentationen om systemet studerats. Dokumentationen har bidragit till en djupare inblick i hur systemet är uppbyggt idag. Även källkoden för det befintliga systemet har studerats för att få en översikt över vilka delar av systemet som berörs av den nya processen. 4.1 Uppbyggnad Systemet är uppbyggt av en webbserver (IIS 5.0) och en databasserver (Microsoft SQL Server 7.0). När en användare besöker webbsidan så kommunicerar användarens webbläsare med webbservern. Webbservern i sin tur sköter all kommunikation med databasen. Detta åskådliggörs i figur 10 nedan. W ebbläsare W ebbserver Databas server Figur 10 Översikt över systemet. IIS 5.0 ASP VB Facade VB Busine ss VB Dat abase MSSQL 7.0 FileServer XML På webbservern finns ASP-sidor och annan källkod som gemensamt bygger upp den befintliga portalen. På databasservern finns en databas som innehåller all data (information om företag, etc.) som ASP-sidorna använder sig av. De tekniker som används är ASP, HTML, XML, Visual Basic, VBScript och JavaScript. För kommunikation mellan webbserver och databas används ADO och SQL-kommandon. Dessa olika tekniker beskrivs mer ingående ovan, se kapitel 3. Systemet är uppdelat i olika skikt eller lager, där varje skikt har sin egen funktion. ASPfilerna har som uppgift att presentera innehållet på webbsidorna, det är här det grafiska användargränssnittet ligger. Till sin hjälp har ASP-filerna komponenter som är skrivna i Visual Basic (VB, se avsnitt 3.5). Dessa komponenter är i sin tur fördelade över tre skikt, VB Facade, VB Business och VB Database. På svenska kan man kalla dessa skikt för presentationsskiktet, logikskiktet och databasskiktet. Presentationsskiktet ansvarar för att: Inhämta information från användaren Skicka användarinformation till logikskiktet för bearbetning Ta emot resultat från logikskiktet Presentera resultat för användaren Logikskiktet ansvarar för att: Ta emot information från presentationsskiktet 18(48)

21 Validera inmatningar Skicka vidare information till databasskiktet för utförandet av begärda operationer Ta emot resultat från databasskiktet Skicka det bearbetade resultatet till presentationsskiktet Databasskiktet ansvarar för att: Skapa en uppkoppling mot databasen Ta emot förfrågningar från logikskiktet Utföra kommandon mot databasen Skicka efterfrågad information tillbaka till logikskiktet Figur 11 nedan visar informationsflödet mellan de olika skikten i systemet. <<ASP> > ASP <<VB> > Facade Components <<VB> Business > Components <<VB> Database > Components <<SQL> > Database Figur 11 Kopplingar mellan de olika skikt som finns i systemet. De övriga teknikerna fungerar även de som ett stöd till ASP-sidorna. JavaScript och VBScript används för att hantera data och XML används för att formatera de nyheter som kan läsas på portalen. 4.2 Gränssnittet mysubcontract idag Mer information än vad som redovisas här om de tjänster som erbjuds på mysubcontract finns i bilaga 1. Då en användare skriver in i sin webbläsare så visas idag en första sida där användaren kan välja att logga in, se figur 12 nedan. För att få tillgång till de tjänster som portalen erbjuder, bl.a. att söka efter gjuterier, krävs det att man loggar in. Som användare kan man ändra sin egen personliga information. Till den informationen hör bland annat yrkesroll, adressuppgifter och lösenord. De lösenord som används till portalen måste vara minst åtta tecken långa. Av dessa tecken måste minst ett tecken vara något annat än en bokstav och det sista tecknet måste vara en bokstav. 19(48)

22 Figur 12 Första sidan på mysubcontract. För att få tillgång till ett vanligt användarkonto på portalen behöver NovaCast Technologies AB kontaktas. Denna kontakt kan ske antingen med hjälp av e-post, telefon eller via ett intresseformulär som finns på webbsidan. NovaCast Technologies AB skapar sedan ett användarkonto via administratörsgränssnittet och inloggningsuppgifterna skickas till användaren. Gjuterier som vill registrera sig och lägga till sin information i portalen fyller i två stycken registreringsblanketter. Dessa finns tillgängliga på portalen och kan antingen skickas till NovaCast Technologies AB via e-post eller skrivas ut och skickas med vanlig post. NovaCast Technologies AB lägger sedan in informationen i portalen via administratörsgränssnittet. Då ett företag har fått sin information inlagd i portalen går det att söka efter företaget och då visas dess information enligt figur 13 nedan. I figuren har all företagsinformation ersatts med gråa streck. 20(48)

23 Figur 13 Webbsida som visar företagsinformation. För att lägga till information i portalen krävs att en administratör loggar in. Detta görs via en separat inloggningssida. Sidorna som administratörer använder skiljer sig kraftigt från de sidor som vanliga användare ser. Administratörsgränssnittet består av enkla vita sidor utan grafiska finesser, se figur 14 nedan. Figur 14 Administratörsgränssnittet på mysubcontract. Det finns en användarmanual för administratörer som beskriver de olika funktionerna i administratörsgränssnittet. Själva formuläret för inmatning av företagsinformation finns på en och samma sida. Inmatningsfälten är grupperade i kategorier efter vilken typ av information som ska matas in, exempelvis kontaktinformation och gjutmetoder. I formuläret finns det 21(48)

24 ingen beskrivande text och inte heller några hjälp-knappar. Den enda vägledning som ges på webbsidan är att de obligatoriska fälten markeras med en asterisk (*). Det är inte möjligt att lägga till ett gjuteri utan att först ge information i samtliga obligatoriska fält. Skulle en administratör vara i behov av hjälp kan de använda sig utav användarmanualen. 4.3 Säkerhet I detta avsnitt beskrivs saker som man bör ta hänsyn till ur säkerhetssynpunkt då man skapar inloggningar och formulär för användning på Internet. Avsnittet börjar med en beskrivning av kryptering som är ett verktyg för att dölja information i meddelanden. Därefter beskrivs två olika tekniker som kan användas för att utvinna information eller förstöra på webbsidor. De tekniker som beskrivs är SQL-injektion och cross-site scripting. Åtgärder som man kan vidta för att undvika att bli utsatt för en lyckad attack av en illvillig besökare tas också upp i denna del. Avsnittet avslutas med en kortfattad beskrivning av vad man bör tänka på när man skapar lösenord Kryptering Själva ordet kryptering kommer ifrån grekiskans "krypto" som betyder dölja [19]. Kryptering har använts i över tusen år. Historiskt sett har det främst använts för att styra länder och kommendera arméer. Ofta skickades meddelanden till trupper med hjälp av sändebud. Dessa sändebud blev emellanåt tillfångatagna och meddelandet hamnade i orätta händer. För att förhindra att fienden skulle kunna tolka meddelandet utvecklades metoder för att dölja budskapen i meddelandena. Det var så krypteringen föddes [8]. Kort kan man säga att kryptering innebär kodning av information. Syftet är att ingen förutom den tänkte mottagaren av informationen ska kunna förstå eller bruka informationen till något användbart. Vanligen används matematiska algoritmer för att konvertera klartext (vanlig text) till kryptotext (otydbar text). Denna konvertering kallas för kryptering. När meddelandet når mottagaren konverterar denne tillbaka kryptotexten till klartext, som mottagaren kan läsa och förstå. Denna konvertering kallas för dekryptering. Figur 15 nedan illustrerar ett något förenklat krypteringsförfarande från sändare till mottagare. Figur 15 Kryptering och dekryptering av ett meddelande SQL-injektion Formulär används på webbsidor för att ta emot inmatningar från besökare. Dessa inmatningar kan av en illvillig besökare användas i destruktivt syfte. Det finns olika tekniker för att genom olika inmatningar få fram information eller sabotera. En av dessa tekniker är SQL-injektion [10]. Tekniken innebär att besökaren försöker utföra kommandon eller få tillgång till data på databasen genom att mata in SQL-kod i inmatningsfält. Denna teknik utnyttjar det faktum att inmatningar gjorda av användare ofta används i en SQL-fråga som sedan skickas till databasen. 22(48)

25 Nedan följer ett exempel på hur denna teknik kan användas, exemplet är en del av ett större exempel som återfinns i [10]. Låt oss säga att vi har ett formulär som frågar efter användarnamn och lösenord, där dessa inmatningar sedan används i en SQL-fråga på följande sätt: Sql_query = ''SELECT * FROM users WHERE userid = ' '' + username + '' ' AND password = ' '' + password + '' ' ''; Detta betyder i klartext: hämta all information från tabellen users (användare) där userid (användarnamnet) och password (lösenordet) är lika med det som användaren matat in. En illvillig besökare kan i detta fall ange texten nedan som användarnamn. 'OR 1=1-- Detta innebär att SQL-frågan ser ut som följer när den skickas till databasen: Sql_query = ''SELECT * FROM users WHERE userid = ''OR 1=1 -- ' AND password = ' '' + password + '' ' '' ; När denna SQL-fråga körs i databasen så kommer all information om alla användare returneras. Att detta sker beror på att villkoret userid = ''OR 1=1 alltid kommer att vara sant och det som kommer efter kommenteras bort med --. För mer information om SQL se avsnitt 3.8 ovan. Exemplet ovan är till för att illustrera risken med SQL-injektion och det är bara ett exempel på hur denna teknik kan användas för att hämta information från en databas. SQL-injektion kan också användas för att t.ex. lägga till information, ta bort tabeller eller ta bort all information i hela databasen. För att undvika att formulär kan användas på detta sätt behöver alla inmatningar gjorda av användare kontrolleras noga. Exempelvis kan en funktion som ersätter alla enkla citationstecken (') med dubbla citationstecken ('') användas. Kanske även en funktion som söker efter specifika ord och genererar felmeddelanden om de hittas. Sådana ord kan vara typiska SQL-kommandon som drop, delete eller select. Viktigt är att denna kontroll av inmatad information körs på webbservern och inte i användarens webbläsare. Skulle inmatningarna kontrolleras i användarens webbläsare finns möjlighet för illvilliga användare att kringgå kontrollerna Cross-site scripting Cross-site scripting är precis som SQL-injektion en teknik som illvilliga användare kan använda sig av för att få fram information eller sabotera dynamiska webbsidor. Den här tekniken innefattar en mängd olika saker som en illvillig användare kan göra. Här kommer endast ett fåtal av dessa nämnas. En av de saker som kan göras är att lägga till ett eget formulär på en webbsida. Då en intet ont anande besökare sedan besöker sidan och fyller i information i formuläret skickas all information direkt till den illvillige användaren. Tekniken går till så att en illvillig användare matar in exempelvis HTML, JavaScript eller VBScript i ett inmatningsfält. Nedan finns ett exempel på hur detta kan gå till, exemplet är hämtat från [18]. Låt oss anta att vi har ett formulär som tar emot inmatningar från användare och sedan skriver ut dem på skärmen. Det kan exempelvis röra sig om en gästbok på en webbsida. En illvillig användare matar in följande text i ett av inmatningsfälten: 23(48)

26 <script>alert('xss!')</script> Är det så att webbsidan inte är skyddad mot cross-site scripting kommer en meddelanderuta med texten XSS! att visas varje gång som någon besöker webbsidan. Denna meddelanderuta är i och för sig ganska oskyldig, men en illvillig användare kommer antagligen att försöka utföra värre saker än att visa en meddelanderuta. Cross-site scripting kan även användas för att utföra kommandon på en dator som tillhör en av webbsidans besökare. Detta sker oftast genom att användaren klickar på en länk till en webbsida. Denna länk har en illvillig användare manipulerat så att den länkar till ett skript. Detta skript körs sedan på användarens dator då användaren klickar på länken. För att undvika att en webbsida kan utsättas för cross-site scripting behöver alla inmatningar gjorda av användare kontrolleras noga. Dels kan data valideras genom att kontrollera att inmatningarna som användaren gör stämmer överens med de förväntade. Ska ett telefonnummer matas in kan man kontrollera att inmatningen endast innehåller siffror samt tecknen -, +, ( och ). Det är inte alltid man vet vad användaren kan tänkas ange för information. Då kan man istället se till att filtrera bort vissa speciella tecken. Till exempel bör tecknen > och < filtreras bort, eftersom de används för att skriva taggar i HTML. För mer information om cross-site scripting och hur man skyddar sin webbsida mot det se [11] Lösenord På en webbsida där det går att logga in har varje användare ett användarnamn med tillhörande lösenord. Lösenord kan vara en säkerhetsrisk om de hanteras felaktigt. Ett dilemma med lösenord är att de inte får vara för enkla att gissa samtidigt som de ska vara lätta för användaren att memorera. Är lösenorden för enkla innebär det att de lätt kan knäckas av någon obehörig. Om de istället är för svåra kan det hända att användaren skriver ner lösenordet på ett papper som sedan kan hittas av någon obehörig. Det finns en mängd metoder för att försöka knäcka lösenord. Här nämns endast två exempel på metoder. Råstyrkemetoden testar varje möjlig kombination av tecken tills den korrekta kombinationen hittas. Med denna metod är man garanterad att hitta lösenordet någon gång. Beroende på hur ett lösenord är utformat kan råstyrkemetoden kräva mycket tid och mycket datorkraft. Faktorer som spelar in är bl.a. längden på lösenordet och hur många olika tecken som kan användas. Består lösenordet av endast siffror och bokstäver så går det fortare att knäcka jämfört med ett lösenord där även specialtecken används. En annan metod för att knäcka lösenord är ordlistmetoden där ord för ord ur en ordlista testas tills lösenordet är funnet. Metoden är snabbare än råstyrkemetoden men fungerar bara då lösenordet är ett ord som finns med i ordlistan. Simson Garfinkel [3] har sammanställt en lista på saker man ska tänka på då man väljer ett lösenord. Man ska exempelvis undvika att använda sitt eget (eller någon annans) namn, telefonnummer, födelsedatum eller adress. Helst ska riktiga ord på vilket språk som helst undvikas. Detta för att förhindra att någon knäcker lösenordet med hjälp av ordlistmetoden. Ett bra lösenord enligt Garfinkel bör vara minst 7-8 tecken långt. Det bör innehålla specialtecken, vara enkelt att skriva och lätt att komma ihåg. Lösenord bör bytas med jämna mellanrum och samma lösenord bör inte användas till användarkonton på olika webbsidor. 24(48)

27 5 Studium av olika lösningar i befintliga portaler på Internet Tre olika befintliga portaler på Internet har studerats och jämförts med mysubcontract. Dessa portaler har funktionalitet som liknar den som finns på mysubcontract, d.v.s. de är alla portaler för att sammanföra köpare och säljare av gjutgods. De tre portalerna som har studerats är: Subcontract Solutions [16], TechPilot [20] och CastingTrade.com [9]. Innan de tre portalerna studeras närmare kommer ett avsnitt där begreppet användarvänlighet presenteras. 5.1 Användarvänlighet Användarvänlighet är något som kan vara subjektivt: det en användare upplever som självklart och enkelt kan vara otydligt för en annan. Hur man upplever något beror ofta på tidigare erfarenheter. Under denna rubrik ges en kort inblick i saker man bör ha i åtanke då man vill skapa ett användarvänligt gränssnitt. De teorier som presenteras här ligger som grund för det avsnitt med diskussion och slutsatser som avslutar detta kapitel. Enligt Joel Spolsky så är ett användargränssnitt väldesignat om det uppför sig precis som dess användare förväntar sig att det ska göra [15]. Han menar att användare bygger upp en mental modell av hur de tror att ett program ska fungera. Denna modell bygger ofta på användarens tidigare erfarenheter av liknande program. Vidare har även programmet en modell över hur det själv fungerar, i form av källkod. Denna modell överensstämmer med hur programmet fungerar i realiteten. Desto mer användarens mentala modell överensstämmer med programmets modell, desto mer kommer användaren känna att hon har kontroll över vad programmet gör. Hur hög kontroll användaren upplever att hon har, påverkar hur lycklig användaren känner sig då hon använder programmet. Spolsky hävdar också att det är viktigt att vara konsekvent vid skapandet av användargränssnitt. Innan man väljer att skapa något nytt bör man alltid ta i beaktande vad som gjorts tidigare och hur det ser ut i andra populära program. Detta för att användare som använt andra datorprogram ofta förväntar sig att det fungerar likadant i alla program. Fungerar programmet inte likadant eller åtminstone liknande så kommer användarna att bli besvikna. Enligt Spolsky läser användare ogärna långa stycken med text. För att öka chansen att användarna läser meddelanden bör man försöka minimera antalet ord som används i meddelanderutor och liknande. Alla användare kan inte kontrollera musen speciellt bra, därför bör man som utvecklare inte göra komponenter som ska kunna klickas på för små. Vilket typsnitt man använder kan också vara av betydelse. Används ett typsnitt där bokstäverna har olika storlek kan det vara svårt att se skillnad på exempelvis bokstäverna i och l. Givetvis är det bättre för användaren om det är enkelt att läsa det som står. Av denna anledning så rekommenderar Spolsky att typsnitt där varje bokstav tar upp lika mycket plats används i inmatningsfält. Jacob Nielsen [12] är en känd användbarhetsexpert för webben. Han har bl. a. skrivit om när kryssrutor ska användas respektive när alternativknappar ska användas. Nielsen menar att det är viktigt att följa standarder för hur varje komponent ska användas. Följer en webbsida standarden så underlättar det för användaren, som enklare kan förutspå och förstå hur delar av webbsidan ska användas. Standarden säger bl. a. att: Alternativknappar ska användas då två eller fler alternativ som är ömsesidigt uteslutande finns i en lista. D.v.s. endast ett alternativ kan och ska väljas. 25(48)

28 Kryssrutor ska användas när flera alternativ är valbara i en lista. D.v.s. användaren kan välja att kryssa i valfritt antal alternativ eller inget alls. Finns det bara ett alternativ bör en ensam kryssruta användas. Denna ska användaren kunna antingen kryssa i eller ur. Nielsen har själv lagt till ytterligare tio punkter som han anser är viktiga vid användandet av dessa två komponenter. Han hävdar bl. a. att det är viktigt att låta alternativknappar och kryssrutor se ut på ett sådant sätt att användarna känner igen dem. Detta är viktigt eftersom komponenterna har funnits länge och många användare är bekanta med utseendet på dem. Nielsen menar vidare att det är viktigt vilket ordval man använder. För kryssrutor ska det vara enkelt att förstå vad som händer om man väljer att kryssa i den. Med alternativknappar är det viktigt att kunna täcka in alla tänkbara alternativ, är detta av någon anledning inte möjligt bör en övrigt-knapp finnas. Else Nygren har gjort en rapport som innehåller underlag för bedömning av användargränssnitt [13]. Trots att rapporten är ganska gammal, den skrevs år 1995, så håller många av dess riktlinjer ännu idag. Då inmatningar krävs ska det tydligt framgå i vilka fält som inmatning är möjlig, vad som ska matas in och i vilket format. Det ska vara tydligt vilka fält som är obligatoriska och vilka som är frivilliga. Obligatoriska fält bör alltid ligga före frivilliga. Ju fler värden som är angivna i förväg desto bättre, det ska dock framgå om de går att redigera eller inte. Finns det en rad olika alternativ bör dessa presenteras med hjälp av rullgardinsmenyer, där de vanligaste alternativen ska presenteras först. Det är viktigt att användaren tillåts att göra fel och att systemet tydligt talar om hur hon kan korrigera sina misstag. Felaktiga inmatningar ska rättas till så snabbt som möjligt och användaren ska inte behöva börja om från början med sin inmatning. 5.2 Studium av portaler I detta avsnitt studeras de tre portalerna Subcontract Solutions [16], TechPilot [20] och CastingTrade.com [9]. Gemensamt för dessa portaler är att användare själva kan registrera sig och skapa ett användarkonto. För att få tillgång till ett användarkonto på mysubcontract så måste papper skrivas ut och skickas in till NovaCast Technologies AB. Då de tre portalerna har studerats har dessa frågor betraktats: 1. Hur lätt är det att hitta till registreringen? 2. Ges någon hjälp före registrering? 3. Hur ser registreringsförfarandet ut? 4. Vilken typ av formulär och komponenter används? 5. Ges någon hjälp under registrering? 6. Hur lätt är det att hitta till inloggningen? 7. Ges relevanta felmeddelanden då användaren misslyckas med inloggning? Nedan återfinns korta redogörelser för hur registrerings- och inloggningsförfarandet sker på de olika portalerna. En kortfattad beskrivning ges också för varje portal. Tyngdpunkten i redogörelserna ligger på att ta upp och diskutera olika lösningar ur användarvänlighetssynpunkt. Syftet med redogörelserna är inte att beskriva varje detalj i dessa processer, utan snarare att belysa intressanta delar för vidare diskussion. 26(48)

29 5.2.1 Subcontract Solutions Subcontract Solutions [16] beskriver sig själva som en oberoende plattform för att effektivisera marknadsföring och framskaffande av gjutning och smide. Webbsidan innehåller bl. a. en söktjänst för att hitta gjuterier, smedjor eller leverantörer till dessa. Det går att välja mellan språken engelska, franska och tyska på webbsidan. På första sidan syns tydliga länkar till registrering. Det finns två alternativ: man kan registrera sitt företag som köpare eller som gjuteri/smedja. Eftersom intresseområdet för denna rapport rör gjuterier, har det senare alternativet valts för denna studie. Då man väljer att registrera sig kommer man vidare till en ny sida, där registreringen kan påbörjas. Längst ner på sidan finns länkar där man kan hämta hem den senaste versionen av webbläsarna Internet Explorer och Netscape Navigator. Detta för att förhindra eventuella navigationsproblem. Formuläret som ska fyllas i är på en sida och obligatoriska fält markeras med en röd asterisk (*). Först väljer man vilken typ av registrering man vill göra (om man är villig att betala för extra funktionalitet eller vill ha gratisvarianten). Detta val görs med alternativknappar, vilket innebär att det endast är möjligt att välja ett alternativ. Inget av alternativen är förvalt. Därefter kommer information om företaget, namn, adress, etc. Sedan ges möjlighet att välja vilken typ av företag man har. Detta val är lite tvetydigt eftersom det görs med kryssrutor och varje alternativ är markerat som obligatoriskt. Möjlighet finns att välja flera alternativ om företaget man registrerar både är exempelvis ett gjuteri och en köpare. Användarnamn och lösenord väljs under registreringen. De förklaringar som ges till formuläret är att lösenordet som väljs måste innehålla minst fyra tecken och att under rubriken kommentarer kan man skriva in sin reklamkod om man har någon sådan (se figur 16 nedan). Figur 16: En del av registreringsformuläret på Subcontract Solutions. 27(48)

30 Man fortsätter vidare genom att klicka på Next (Nästa) och avbryter genom att klicka Cancel (Avbryt). Om man missar att fylla i någon obligatorisk information får man upp ett nytt fönster med en lista över de fält man missat att fylla i. Den information man hittills matat in finns kvar i fönstret med formuläret, så man behöver inte börja om från början. När all obligatorisk information är ifylld och man klickar på Next, kommer man vidare till en sida där man får se sin inmatade information. Här måste man godkänna villkoren för tjänsten innan man klickar på Register (Registrera) för att registrera sig. Här ges också alternativen Back (Tillbaka), om man vill ändra någon information och Cancel (Avbryt) om man vill avbryta registreringen. Inloggningen till sidan finns tillgänglig på det övre vänstra hörnet på startsidan. Där skriver man direkt in användarnamn och lösenord. Möjlighet finns att klicka på forgot password (glömt lösenord) om man behöver hjälp med att komma ihåg sitt lösenord. Då man har angett användarnamn och lösenord loggar man in genom att klicka på OK. Det går även att använda Tab-tangenten för att komma till OK-knappen och trycka på Retur-tangenten. Trycker man på Retur-tangenten i lösenordsfältet händer ingenting. Misslyckas man med inloggning får man upp en sida där man uppmanas att kontrollera sina inloggningsdata. Även här ges möjlighet att få hjälp med ett bortglömt lösenord. Alternativ ges också att registrera sitt företag, om man inte har något giltigt användarkonto. Här finns dock tre alternativ för att registrera sig, förutom de som nämns på startsidan kan man även välja att registrera sig som leverantör till gjuterier/smedjor TechPilot TechPilot [20] beskriver sig själva som en marknadsplats som täcker in allt mellan tillverkningstekniker och verktyg till maskiner. De vänder sig till hela tillverkningsindustrin alltså inte enbart till gjuterier eller smedjor. Webbsidan innehåller bland annat en söktjänst för att hitta leverantörer. Det går att välja mellan språken engelska och tyska på webbsidan. På förstasidan finns en snabbmeny där bl.a. Registration (Registrering), går att välja. Då man väljer att registrera sitt företag kommer en ny sida upp, där det på vänstersidan finns en lista med fyra punkter där registreringens olika moment finns. Denna lista är inte klickbar. För att gå till de olika momenten måste man välja Continue (Fortsätt) och stega sig igenom dem i tur och ordning. Beskrivande text finns som talar om att den person som genomför registreringen blir Company administrator (Företagsadministratör), d.v.s. den person som kan lägga upp användarkonton för övrig personal på företaget. Det står även att man vid ett senare skede kan välja att byta företagsadministratör. Efter genomförd registrering kommer användarinformation och ett formulär för bekräftelse av registreringen skickas via vanlig post. Man uppmanas även att ta en titt på deras aktuella prislista. Därefter kommer första delen av formuläret. Här finns endast obligatoriska fält (dessa markeras med en pil), men här nämns inte vad pilen står för. I detta formulär ska information som företagsnamn, adress och namn på den som registrerar företaget anges. Därefter klickar man på Continue (Fortsätt) och då kontrolleras den information man angett mot den befintliga databasen för att undvika dubbletter. Missar man någon information fås samma sida tillbaka. De obligatoriska fält som inte har fyllts i, markeras med röd text under inmatningsfältet. Texten talar om att det är nödvändigt att fylla i information. Den information som man har matat in i formuläret finns kvar. Under formuläret ges två olika telefonnummer som man kan ringa om man har problem med registreringen. Det finns också en länk till ett kontaktformulär. Första sidan på formuläret ser ut som i figur 17 nedan. 28(48)

31 Figur 17: Första sidan av registreringsformuläret på TechPilot. Här har inte efternamnet angetts, därav den röda texten under inmatningsfältet. Vid registreringens nästa steg berättas det att obligatoriska fält är markerade med en pil. Formuläret innehåller delar av den information man angett i föregående steg samt ett antal nya fält som ska fyllas i. Vissa instruktioner ges inuti formuläret som t.ex. hur många tecken som är tillåtna i vissa inmatningsfält. På ett ställe är det möjligt att välja flera alternativ ur en lista. Hur man gör detta står beskrivet i texten i formuläret. Formuläret är uppdelat i tre delar, där den andra delen beskrivs som en frivillig del. Trots detta är ett av fälten markerat som obligatoriskt och man kommer heller inte vidare till nästa steg utan att ange information i detta fält. Alternativknappar används då endast ett alternativ får väljas och kryssrutor används då flera alternativ kan väljas. Det finns ingen knapp där man kan välja att avbryta registreringen, bara en knapp för att fortsätta. Nästa steg är att fylla i personlig information. Detta steg är nu markerat i listan till vänster. Av någon anledning markerades inte det första steget. Här finns både alternativ för att fortsätta och för att gå tillbaka till föregående steg. Väljer man att gå tillbaka och sedan fortsätta vidare till steg två igen, så finns information som man skrivit in i formuläret på steg två fortfarande kvar. Vid några av alternativen finns en liten ruta som man kan klicka på. Vid klick på rutan visas en sida med ytterligare information om vilken typ av inmatningar användaren förväntas göra. Användarnamnet får man välja själv och lösenordet kommer att skickas med vanlig post när registreringen är klar. Steg tre är att godkänna deras villkor. Även här finns en tillbakaknapp och en fortsätt-knapp. Det fjärde och sista steget är att godkänna all information som man har lagt till. Inloggningen finns tillgänglig vid det övre vänstra hörnet på startsidan. Där skriver man direkt in användarnamn och lösenord. Möjlighet finns att klicka på Password forgotten? (Lösenord glömt?) om man behöver hjälp med att komma ihåg sitt lösenord. Då man har angett användarnamn och lösenord loggar man in genom att klicka på Login (Logga in). Det går även att trycka på Retur-tangenten i lösenordsfältet eller använda Tab-tangenten för 29(48)

32 att ta sig till Login-knappen och sedan trycka Retur. Lyckas inte inloggningen, fås en sida upp där man uppmanas att kontrollera sina login data. Sedan kan man testa att logga in igen. Alternativ ges även för att få hjälp med bortglömt lösenord eller att registrera sitt företag CastingTrade.com CastingTrade.com [9] beskriver sig själva som ett on-line system där varje gjutare av metall i världen ska kunna vara tillgänglig för varje köpare av delar gjutna i metall. Webbsidans innehåll är uppdelat mellan fem olika steg i processen för att gjuta delar i metall. För varje del finns en separat söktjänst för att hitta leverantörer till just den delen i processen. Det går att välja mellan språken engelska, kinesiska och spanska på webbsidan. För att komma till registreringen måste man på första sidan först ange vilket av de fem stegen som man är intresserad av. Alternativet Foundry Guide (Gjuteriguide) valdes för denna studie eftersom det är det alternativet som ett gjuteri ska välja. Efter att intresseområde angetts kan man välja att registrera sig, antingen med simple profile (enkel profil) eller full foundry surveys (full gjuterikartläggning, fritt översatt). Alternativet full gjuterikartläggning har inga obligatoriska fält och det går bra att skicka in formuläret utan att ange någon information alls. Man erhåller ingen inloggning om detta alternativ väljs, därför har alternativet enkel profil valts för denna studie. Obligatoriska fält markeras med en asterisk (*). Information om att webbläsaren Internet Explorer rekommenderas för att kunna registrera sig ges. Det används inga kryssrutor eller alternativknappar. Country (Land) är den enda inmatningen där alternativ ges, i form av en rullgardinsmeny. Formuläret består av en enda sida. Användarnamnet och lösenordet får man välja själv, se figur 18 nedan. Det finns en Submit-knapp (Skicka in) och en Reset-knapp (Återställ). Figur 18: En del av registreringsformuläret på CastingTrade.com. 30(48)

33 Missar man att fylla i någon information ges ett felmeddelande från SQL Server som talar om att värdet NULL inte kan sättas i ett visst fält. Detta meddelande syns på en i övrigt tom webbsida. Väljer man att gå tillbaka med sin webbläsare så finns informationen man har matat in kvar i formuläret. Det verkar inte finnas någon kontroll av inmatad information, eftersom sidan godkänner ex. att två helt olika lösenord anges samt en e-postadress bestående av enbart siffror. Alla obligatoriska fält behöver inte heller fyllas i för att det ska vara möjligt att skicka in informationen. Endast för ett fåtal av dem gäller att SQL Server inte tillåter att de lämnas tomma. För att komma till inloggningen måste man först, precis som vid registreringen, ange ett intresseområde. Därefter kan man välja att logga in för att uppdatera sin profil. Väljs detta alternativ fås en ny sida upp där användaren kan logga in. Inget alternativ för bortglömt lösenord visas, men däremot finns ett alternativ för att registrera sig. Då man har angett användarnamn och lösenord loggar man in genom att klicka på Submit (Skicka in). Det går även att trycka på Retur-tangenten i lösenordsfältet eller använda Tab-tangenten för att ta sig till Submit-knappen och sedan trycka Retur. Lyckas inte inloggningen visas samma sida med ett meddelande som talar om att användarnamnet inte finns, alternativt att lösenordet inte är korrekt. Man uppmanas att försöka logga in igen. Det ges ingen information om hur man kan återfå ett förlorat lösenord. Även här ges alternativet att registrera sig. 31(48)

34 5.3 Diskussion och slutsatser Registrering Två av portalerna har länkar till registreringen via första sidan, vilket gör registreringen enkel att hitta. En av portalerna, CastingTrade.com, kräver att man specificerar vilket område man är intresserad av innan registreringen kan påbörjas. Detta i sig är ingen nackdel, men gör registreringen lite svårare att hitta. Slutsatsen blir att registreringen hittas enklast om det finns en tydlig länk till den via portalens första sida. Informationen som erbjuds innan registreringen varierar mellan de olika portalerna. Subcontract Solutions har i huvudsak information som talar om vad som är bra med deras tjänst samt vilka alternativ som finns för betalning. De upplyser om vilka webbläsare som sidan fungerar bäst med längst ner på sidan. TechPilot beskriver hur registreringen går till, vad som händer efter registreringen samt hur man gör för att skapa flera användare för ett företag. CastingTrade.com talar om vad informationen kommer att användas till och upplyser om lämplig webbläsare. Mängden information varierar som sagt. Vilken information bör då vara med? Enligt Spolsky läser användare ogärna längre stycken text och därför bör överflödig information väljas bort [15]. En del användare kan behöva mer information än andra. Det kan därför vara lämpligt att minimera informationen som står på sidan och istället tala om var användaren kan finna mer information. På så sätt får de som vill veta mer tips om var de kan finna information, samtidigt som de som inte vill ha mer information slipper. TechPilot använder en symbol i form av tecknet i inuti en orange ruta för att indikera när mer information finns. Klickar användaren på symbolen fås ytterligare information inuti ett extrafönster. Denna lösning innebär att formuläret som användaren håller på att fylla i stannar kvar i bakgrunden. När användaren har läst klart informationen kommer hon enkelt tillbaka till formuläret. Att nämna lämplig webbläsare bör räknas som viktig information eftersom det är något som krävs för att webbsidan ska fungera tillfredsställande. En bra lösning är att ha den informationen högt upp på sidan. Om sidan inte fungerar speciellt bra för en användare så är risken stor att användaren inte slutför registreringen. Genom att ha information långt ner på sidan är det möjligt att användaren missar denna information och låter bli att registrera sig på grund av att sidan inte fungerar tillfredsställande. Det är kanske inte så många användare som byter webbläsare enbart för att kunna registrera sig men de får i alla fall en förklaring till varför webbsidan inte fungerar. Den bästa lösningen vore att försöka utforma webbsidan så att den fungerar med de flesta webbläsare Inmatningar Samtliga portaler talar om för användaren vilka fält som är obligatoriska genom att markera dem på något sätt. Att markera obligatoriska fält med en asterisk (*) är relativt vanligt på webben. En nackdel med TechPilot är att det på registreringens första sida, inte nämns hur obligatoriska fält markeras. Det nämns först på registreringens andra sida. De har dessutom valt ett relativt ovanligt sätt att markera obligatoriska fält. Markeringarna görs med en pil i en orange ruta, som till utseendet liknar den symbol de använder för att markera att ytterligare information finns (se avsnitt ovan). Detta kan upplevas något förvirrande för användaren eftersom informationssymbolen är klickbar, medan rutan med pilen inte är det. Rutan med pilen används även vid två tillfällen för att indikera länkar. Varav den ena tar en till ett supportformulär medan den andra öppnar ett extrafönster med information. Deras val av 32(48)

35 markering går stick i stäv med Spolskys teorier om att vara konsekvent vid skapandet av användargränssnitt [15]. Använder man andra symboler än de allmänt vedertagna bör användarna informeras om detta tidigast möjligast. En och samma symbol bör också innebära samma sak överallt. Även om en förklaring hade getts på första sidan, hade missförstånd kunnat uppstå på grund av detta. Enligt Nygren bör obligatoriska fält alltid ligga före frivilliga [13]. Om detta efterföljs underlättas inmatningen för de användare som är ivriga att ta sig igenom registreringen och inte tycker det är viktigt att ange all information. Ingen av portalerna följer detta till punkt och pricka, Subcontract Solutions har dock en bra lösning. De har grupperat inmatningsfälten i olika kategorier, bl.a. företagets adressuppgifter och kontaktpersonens adressuppgifter. Under varje kategori kommer först de obligatoriska fälten och sedan de frivilliga. Hade de valt att först lista samtliga obligatoriska fält hade ordningen blivit rörig. Eftersom fält från olika kategorier då skulle ha blandats. Något som skulle kunna innebära att exempelvis företagets faxnummer och vilket språk kontaktpersonen föredrar att använda hamnar bredvid varandra. Detta skulle vara förvirrande för en användare. De andra portalerna blandar obligatoriska och frivilliga fält med varandra på ett mer ostrukturerat sätt. TechPilot har även de en indelning i kategorier, men var de obligatoriska fälten hamnar under kategorierna varierar. CastingTrade.com har ingen indelning i kategorier. Slutsatsen är att Subcontract Solutions lösning är att föredra, eftersom de obligatoriska fälten är enkla att hitta. I samtliga formulär är det tydligt i vilka fält inmatningar kan göras. För CastingTrade.com kan inmatningar göras i samtliga fält. För de övriga två gäller att då inmatning inte är möjlig finns det inget vitt inmatningsfält, utan texten står direkt på bakgrunden. Nygren menar att ju fler värden som är angivna i förväg desto bättre är det. CastingTrade.com har ett värde valt i förväg, United States i fältet Country (Land). Antagligen är huvuddelen av deras användare från detta land. TechPilot använder en del värden som är valda i förväg, bl. a. är Default language (Standardspråk) satt till English (Engelska). Eftersom många av fälten i dessa formulär innehåller namn eller kontaktuppgifter som är unika för alla företag, är det inte så många av värdena som kan sättas i förväg. En annan sak som Nygren poängterar är att om olika alternativ finns bör dessa presenteras med rullgardinsmenyer. Ett tillägg bör dock göras för att få detta påstående aktuellt; flera alternativ kan även presenteras med hjälp av alternativknappar eller kryssrutor. CastingTrade.com innehåller endast en rullgardinsmeny. I övrigt används endast vanliga inmatningsrutor. De bägge andra formulären innehåller en blandning av alla tre komponenterna. En nackdel med att använda vanliga inmatningsrutor jämfört med andra komponenter, är att användaren får möjlighet att göra inmatningar som inte är korrekta. Vanliga inmatningsrutor innebär också att formuläret blir tyngre att fylla i. Oftast tar det längre tid att förstå vilken information som efterfrågas och sedan ange denna via tangentbordet jämfört med att välja alternativ ur en lista Felhantering Nygren menar att det är viktigt att tillåta att användaren gör fel och att systemet talar om tydligt hur misstagen ska korrigeras [13]. De tre portalerna hanterar felaktiga inmatningar eller avsaknad av obligatorisk information på lite olika sätt. TechPilot och Subcontract Solutions har relevanta felmeddelanden då användaren har missat att ange obligatorisk information. Användaren får veta exakt vad hon har missat att fylla i. Skillnaden är hur de väljer att visa informationen, inuti formuläret respektive inuti ett extrafönster. CastingTrade.com verkar dock sakna denna hantering: det ges ett felmeddelande, men det är onödigt komplicerat. De felmeddelanden som ges verkar komma direkt från deras databasserver. Exakt vilket fält användaren har missat att fylla i kan därför vara svårt att tyda 33(48)

36 ut. För att komma tillbaka till formuläret måste användaren välja Tillbaka i sin webbläsare. I två av portalerna tillåts användaren att göra misstag, medan i det tredje fallet hanteras inte misstag gjorda av användaren alls av gränssnittet. Vad gäller felaktiga inmatningar så gör TechPilot och Subcontract Solutions kontroll av den e-postadress som anges. I övrigt verkar inga kontroller göras. Exempelvis att ange enbart bokstäver som telefonnummer tillåts av alla tre formulären. Ett antagande är att anledningen till att just e-postadressen kontrolleras är att e-post är det kommunikationssätt som föredras. Stämmer e-postadressen finns det också möjlighet för företaget som sköter portalen att kontakta företaget som registrerar sig. E-postadressen används även då man vill återfå ett förlorat lösenord. Ytterligare ett antagande är att företag som registrerar sig på denna typ av portal ofta är angelägna om att informationen de matar in är korrekt. De skulle förmodligen aldrig mata in bokstäver som telefonnummer med flit. Trots detta kan dock fel uppstå och det är därför viktigt att inmatad information kontrolleras Inloggning Precis som för registreringen så kräver CastingTrade.com att man specificerar intresseområdet, innan möjlighet ges att logga in. Jämfört med de andra portalerna, som har inloggningen uppe i vänstra hörnet på startsidan, så krävs ytterligare två klick med musen. Detta är värt att beakta då man har en portal där användare behöver logga in ofta. I fallet med CastingTrade.com så behöver användarna endast logga in då de vill uppdatera informationen om sitt företag. De andra bägge portalerna kräver att användaren är inloggad för att få tillgång till alla de tjänster som erbjuds, vilket innebär att det är viktigare för dem att ha inloggningen på första sidan. Många av de inloggningar som finns på webben tillåter att man i lösenordsfältet trycker på Retur-tangenten för att loggas in, istället för att tvingas klicka med musen eller använda Tabtangenten. Detta fungerar att göra i två av de tre inloggningarna. För Subcontract Solutions inloggning fungerar det inte, detta är en nackdel då deras inloggning i detta avseende inte liknar övriga inloggningar på webben. En användare som är van att logga in med en tryckning på Retur-tangenten riskerar att bli sittande framför datorn och vänta på att bli inloggad efter att denne har tryckt på Retur-tangenten. När hon väl inser att det inte fungerar kan detta väcka viss irritation. I den händelse att användaren misslyckas med att logga in så ges relevanta felmeddelanden av samtliga portaler. Två av portalerna talar om hur ett förlorat lösenord kan återfås, medan den tredje inte gör det. Om en användare av någon anledning inte har kvar sitt lösenord och vill logga in på denna portal, ges ingen hjälp till användaren vilka åtgärder som krävs för att kunna återfå lösenordet. 34(48)

37 6 Förslag till principlösning I detta kapitel kommer de olika kraven från avsnitt tas upp och ett förenklat förslag på lösning kommer att redovisas för varje krav. För varje del i lösningsförslaget beskrivs ungefär vad som krävs för att implementera just den delen. Beskrivningarna håller sig dock på en ganska abstrakt nivå. Att gå in i detalj på hur de olika delarna kan implementeras ligger utanför den här rapporten. 6.1 Inloggning Som nämndes i avsnitt ovan finns redan en typ av användarkonton som är tänkta att användas av representanter för gjuterier. Ändringar behöver dock göras i själva databasen för att ge dessa användarkonton rättighet att redigera ett gjuteris information på portalen. Dessa användarkonton behöver också kopplas ihop med ett specifikt gjuteri. Denna ihopkoppling kan göras antingen genom att skapa en ny kolumn i en befintlig tabell eller genom att skapa en helt ny tabell endast avsedd för detta ändamål. Det förstnämnda alternativet innebär att antingen tabellen för användarkonton eller tabellen för företagsinformation får en ny kolumn. Eftersom tabellen för användarkonton är densamma för alla typer av användarkonton är denna extra kolumn endast användbar för ett fåtal konton. Gällande tabellen för företagsinformation så är det inte säkert att alla företag kommer att ha ett användarkonto ihopkopplat med sig. Därför skulle en extra kolumn där inte heller vara användbar för samtliga rader i tabellen. Alternativet att skapa en ny tabell verkar därför vara det bästa. Detta alternativ liknar också det sätt som databasen är uppbyggd på idag. Exempelvis så finns en separat tabell för att kombinera ihop ett företag med de typer av legeringar som de använder. Kod behöver skrivas för att möjliggöra att denna ihopkoppling görs via administratörsgränssnittet. Inloggningen för den nya typen av användarkonton kan ske via samma inloggningssida som vanliga användare använder. Kod behöver skrivas så att den sida som idag hanterar inloggningen kan kontrollera vilken typ av användare det är som loggar in. Är det en representant för ett gjuteri som loggar in så ska ett extra alternativ för att redigera information om företaget finnas i menyn. Detta innebär att ändringar behöver göras även på första sidan som visas efter inloggning. När användaren väljer detta nya menyalternativ ska en webbsida som hanterar inmatningar visas. För detta ändamål behöver en ny webbsida med ett formulär skapas. Se avsnitt 6.4 nedan. 6.2 Manual För att uppfylla de krav som ställs på användarvänlighet kommer formuläret för inmatning av information att skapas med resultaten från kapitel 5 i åtanke. Dessa resultat sammanfattas i punktform nedan: Information om vilka webbläsare som sidan fungerar med ska finnas högt på sidan. Information om vad som sker efter att användaren har matat in information ska finnas. För varje del i formuläret ska alternativ för hjälp finnas, förslagsvis visas hjälpen på en ny sida eller i ett extrafönster. Obligatoriska fält ska markeras med en röd asterisk (*) och användaren ska upplysas om detta. I den mån det är möjligt ska obligatoriska fält placeras först i formuläret, annars först i en kategori. Det ska vara en tydlig skillnad mellan fält där inmatningar är möjliga och fält där inmatningar inte kan göras. 35(48)

38 Där så är lämpligt ska alternativ sättas som förval. Då flera alternativ finns att välja mellan ska kryssrutor, alternativknappar eller rullgardinsmenyer användas. Användarna ska tillåtas att göra fel och vid fel ska relevanta felmeddelanden ges. 6.3 Inre struktur För att bibehålla den inre strukturen i systemet kommer alla nya funktioner som skapas att noga struktureras i olika skikt i enlighet med det som beskrivs i avsnitt 4.1 ovan. Där så är lämpligt ska nya funktioner läggas till i befintliga filer med kod. I så stor utsträckning som möjligt ska kod från det befintliga systemet återanvändas. Alla nya funktioner och filer som skapas ska följa samma namngivningsregler som används i det befintliga systemet. Det finns ett dokument med kodningsregler som har använts under utvecklingen av det befintliga systemet. Dessa regler ska studeras noga och efterföljas. 6.4 Inmatning Inmatning av företagsinformation från användaren kommer att ske via ett formulär. Detta formulär kommer att finnas på den nya webbsida som nämns i avsnitt 6.1 ovan. Utseendet på de befintliga webbsidorna för att visa information om ett gjuteri ska användas som mall för formuläret, se figur 13 ovan. Detta innebär att formuläret kommer att bestå av tre flikar. Om så är nödvändigt kan eventuellt nya flikar komma att införas. Denna nya ASP-sida kräver att en del tillägg görs till de befintliga Visual Basic-komponenterna. Kod behöver skrivas för att kunna lagra den information som representanten för ett gjuteri matar in. Denna information ska inte skriva över den befintliga informationen som finns om gjuteriet i databasen. Förslaget är att informationen lagras i en separat tabell i databasen. Lämpligast ur säkerhetssynpunkt vore egentligen om en helt ny databas skapas för lagring av informationen. Detta eftersom användarna då inte får någon möjlighet att komma åt de delar av databasen där den information som visas på portalen lagras. Detta alternativ skulle dock kräva antingen en hel del ändringar i den befintliga strukturen eller att en mängd nya filer skapas. Används en tabell för att lagra informationen så kan den befintliga koden för databaskopplingen lämnas mer eller mindre orörd. Detta innebär att färre ändringar behöver göras i det befintliga systemet. Varje ändring i databasskiktet kräver nästan oundvikligen att motsvarande ändringar görs både i logikskiktet och i presentationsskiktet. På grund av detta är en tabell den lösning som föredras. 6.5 Säkerhet Användarnamn och lösenord ska krypteras. En indikering om att det är dags att byta lösenord ska komma upp vid inloggning då lösenordet inte har bytts på sex månader. En ny funktion ska skrivas som blockerar användaren från att logga in under fem minuter, om användaren inom en femminutersperiod har angett felaktiga uppgifter tre gånger i följd. All inmatad information från användaren ska genomgå en noggrann kontroll innan den läggs till i databasen. Dessa kontroller kommer att läggas till i de befintliga Visual Basickomponenterna i form av nya funktioner. Två olika typer av kontroller ska implementeras för att säkerställa både att användaren anger information som är giltig samt att användaren inte gör några skadliga inmatningar. 36(48)

39 6.6 Godkännande Då en administratör loggar in på mysubcontract ska hon ha möjlighet att få en lista på de gjuterier som har information som väntar på godkännande. Administratören ska sedan kunna titta på informationen från varje gjuteri och därefter ha möjlighet att godkänna den. Godkännandet görs genom att klicka på en knapp. Då en administratör har godkänt information ska den informationen skriva över den befintliga informationen om gjuteriet i databasen. Detta innebär att informationen blir synlig i portalen. Samtidigt ska också informationen tas bort från den tabell som har använts i väntan på godkännande. För att kunna göra detta behöver tillägg göras i koden för administratörsgränssnittet samt i några Visual Basic-komponenter. 6.7 Underrättelse om ny information Varje gång en representant för ett gjuteri redigerar eller lägger till information ska en administratör underrättas om detta via e-post. E-postmeddelandet kan vara likadant oavsett vilket gjuteri det är som har uppdaterat sin information. Anledningen till att e-post är valt som metod är att administratören ska slippa att kontinuerligt logga in på mysubcontract för att kontrollera om ny information finns. Kod för att skicka e-post ska läggas till i den nya webbsida som ska skapas för formuläret. 37(48)

40 7 Det nya systemet Under detta kapitel beskrivs de delar av den nya processen som blivit implementerade enligt ovan beskrivna förslag på lösning. På grund av problem med bland annat upprättandet av utvecklingsmiljön har inte många delar av processen blivit implementerade. För många utav delarna har dock kod skrivits för att ge exempel på hur en implementering kan se ut. Denna kod har dock i de allra flesta fall varken körts eller testats. Av denna anledning har etapp fem i projektet (se avsnitt 2.1 ovan) inte genomförts. Under rubrikerna nedan så beskrivs vad som har gjorts för varje del i systemet och vad som återstår att göra. Exakt hur de nya tabeller och funktioner som ska implementeras ska se ut redovisas inte här. Den främsta anledningen till detta är att NovaCast Technologies AB inte vill att deras källkod sprids vidare. Därför nöjer sig rapportförfattaren med att redogöra för var dessa ändringar ska göras, exempelvis i ASPfiler, i databasen eller i Visual Basic-komponenter. 7.1 Inloggning Inget av det som nämns under avsnitt 6.1 har implementerats. Däremot så har detaljerade beskrivningar för hur samtliga saker under rubriken ska genomföras skrivits. De ändringar som behöver göras i databasen för att ge användarkontona de rättigheter som krävs för att kunna redigera information om ett gjuteri har beskrivits i detalj. Det som återstår är att föra in dessa ändringar i databasen. För att kunna göra ihopkopplingen av ett användarkonto och ett företag behöver en ny tabell införas i databasen. Hur denna tabell ska se ut har beskrivits i detalj. Tabellen är inte införd i databasen. För att administratörerna ska kunna göra ihopkopplingen behöver även ändringar göras i koden för administrationsgränssnittet. Några nya rader kod behövs på den ASP-sida som hanterar inmatningen av företagsinformation. Exempel på kod för detta finns. Det krävs också några nya funktioner i befintliga Visual Basic-komponenter. Exempel på kod för dessa nya funktioner finns också. Användare med den nya typen av användarkonton ska kunna logga in via den befintliga inloggningen för vanliga användare. För att möjliggöra detta behöver ny kod införas i de ASP-sidor som hanterar inloggningen. ASP-sidorna behöver funktioner för att kunna kontrollera vilken typ av användare som loggar in. Dessa funktioner behöver läggas till i befintliga Visual Basic-komponenter. Var de nya funktionerna ska läggas till finns specificerat. Det finns även exempel på kod för dessa funktioner. För att visa det nya alternativet i menyn behöver ändringar göras i första sidan som visas då en användare har loggat in. Här behövs inga tillägg av nya funktioner. De ändringar som behöver göras kan göras direkt i koden för ASP-sidan. Exempel på kod för detta finns. 7.2 Inmatning En prototyp har tagits fram för utseendet på inmatningsformuläret som det är tänkt att representanterna på gjuterier ska använda. I figur 19 nedan visas hur denna prototyp ser ut. 38(48)

41 Figur 19 Prototyp för inmatningsformulär. Prototypen innehåller inte så många av de funktioner som formuläret ska ha. För att få dessa funktioner i formuläret så behöver en mängd nya funktioner skapas i befintliga Visual Basickomponenter. Bland annat så behövs funktioner för att skriva information som användaren matar in i formuläret till den nya tabellen i databasen. Exempel på kod för dessa funktioner finns. Den nya tabellen som ska användas för att mellanlagra information som väntar på godkännande har beskrivits i detalj. Det återstår dock att införa tabellen i databasen. Återstår gör också att skriva färdig själva formuläret. Förutom fliken Kontakt info så finns det ytterligare två flikar där inmatningar ska vara möjliga. Dessa flikar är inte iordninggjorda för detta ändamål även om delar av dem är implementerade. Det ska även finnas hjälpknappar och mer beskrivande text i formuläret. Bland annat så ska information om vilka webbläsare formuläret fungerar med att läggas till. Detta kan dock inte göras förrän formuläret är färdigt och testat med de olika webbläsarna. Hanteringen av fel och felmeddelanden behöver också implementeras. Var detta ska göras och hur koden kan se ut finns specificerat. 7.3 Säkerhet Det har inte gjorts några försök med att kryptera användarnamn och lösenord. För att göra detta krävs att ett certifikat införskaffas. En funktion som vid inloggning kontrollerar hur gammalt lösenordet är återstår att skriva. Är lösenordet mer än sex månader gammalt ska användaren informeras om att det behöver bytas. Kvar att implementera är också en funktion som blockerar användaren från att logga in under fem minuter, om användaren inom en femminutersperiod har angett felaktiga uppgifter tre 39(48)