School of Mathematics and Systems Engineering
Reports from MSI - Rapporter från MSI
Utvecklandet av en webbcommunity
Hur kan en programmerare gå till väga vid utveckling av en webbcommunity?
Erik Flachmeyer
Jun 2005
MSI Report 05091
Växjö University ISSN 1650-2647
SE-351 95 VÄXJÖ ISRN VXU/MSI/IV/E/--05091/--SE
Växjö universitet
Matematiska och systemtekniska institutionen IVC 730: Examensarbete
Handledare: Gunnar Mosnik Examinator: Jonas Werner
Klas Gäre
Utvecklandet av en webbcommunity
Hur kan en programmerare gå till väga vid utveckling av en webbcommunity?
Erik Flachmeyer
Juni 2005
Abstrakt
Denna uppsats kommer att ta upp teorier och olika lösningar för hur en utvecklare för en webbplats kan gå till väga för att skapa en community för webben av olika slag. För att få reda på hur de olika momenten och problemen kan lösas så har en fullständig community utvecklats. Denna community har som profilering att rikta sig mot högskolestuderande på Växjö universitet.
Webbplatsen i fråga har varit under utveckling sedan hösten 2003 och blev officiell för första gången under februari månad 2004. Därefter började medlemmarna registrera sig, och fram till sommaren 2004 var det strax över 600 som registrerat sig på sidan. Under hösten 2004 så beslutade utvecklaren sig för att skapa en ny version av sidan efter att den första lagts ner under sommaren strax innan på grund av komplikationer med serverleverantören.
Den nya versionen började utvecklas och såg sedan dagens ljus under februari månad 2005. Sidan och utvecklaren ifråga är Campusportalen och Erik Flachmeyer (som även är författaren till denna uppsats).
Abstract
This thesis will consider theories and different solutions that a developer of a website can take advantage of when creating a community for the web. To find out how the different questions and problems can be solved, a complete community for the web has been developed. This community has as a profile to concentrate on students at Växjö University.
This Internet site has been under development since the autumn of 2003 and became official for the first time during the month of February 2004. Afterwards, the members started to drop in and in the front of the summer of 2004 there had become just above 600 members that registered themselves of the site. During the autumn of 2004, the developer decided to create a new version of the site, after that the first one had been closed, due to complications with the server supplier.
The new site started to be developed and became available to the public during the month of February 2005. The site and developer in question is Campusportalen and Erik Flachmeyer (which also is the author of this thesis).
Förord
Denna rapport beskriver mitt examensarbete inom Systemvetenskapliga programmet, 120/160p vid Växjö universitet med informatik som huvudämne. Examensarbetet är skrivet av Erik Flachmeyer med Gunnar Mosnik som handledare och Jonas Werner samt Klas Gäre som examinatorer.
Examensarbetet är skriven utifrån baserade kunskaper inom PHP, MySQL, UML och allmänna datatermer. Därför är denna rapport inriktad till läsare med grundläggande kunskaper inom dessa områden. Rapporten kommer inte att ge någon närmare förklaring för hur exakt allmän PHP kod fungerar eller hur en användare kan ställa frågor till en MySQL databas, utan endast ge grundläggande praktiska exempel och teori om hur en utvecklare kan gå till väga. Dock kommer exempel att beskrivas med kommentarer och förklaringar.
Innehållsförteckning
1 Inledning... 6
1.1 Bakgrund ...6
1.2 Campusportalens historia ... 7
1.3 Syfte och problemformulering ...7
1.4 Metod... 8
2 Formgivning och design ... 10
2.1 Olika typer av upplägg ...10
2.1.1 Siddesign ...10
2.1.2 Innehållsdesign ... 10
2.1.3 Webbplatsdesign... 11
2.2 Campusportalens design och upplägg ... 11
3 Systemen kring Campusportalen ...13
3.1 Interna system...13
3.1.1 Databasen och dess funktioner ... 13
3.1.2 Webbhotell och dess olika system...15
4 Struktur och funktionalitet...17
4.1 Målgrupp ...17
4.2 Registrering ...17
4.2.1 Användarvillkor... 17
4.2.2 Personuppgiftslagen (PUL) ...18
4.2.3 Registreringsprocessen ...18
4.3 Inloggningsprocessen ...20
4.4 Säkerhet och sessioner...21
4.5 Gästboksfunktioner och intern E-post ...22
4.6 Forum ... 23
4.7 Relationer ... 24
4.8 Profileringssida... 25
4.8.1 Bilduppladdning till profileringssidan...25
5 Resultat ... 27
5.1 Funktioner på Campusportalen...27
5.1.1 Inloggad som student...27
5.1.2 Inloggad som administratör ...28
5.2 Reflektion ... 28
6 Referensförteckning ... 30
7 Bilagor ...32
Databasschema ... 32
Figurförteckning
2.2.1 Bild av Campusportalen ... 11
3.1.1 Filstrukturen på Campusportalen... 15
4.2.1 Registreringsprocessen ... 19
4.2.2 Beskrivning av tabellen ”unactive” ...19
4.3.1 Beskrivning av tabellen ”student” ...20
4.5.1 Beskrivning av tabellen ”guestbook” ...22
4.6.1 Beskrivning av forumstabellerna...24
4.7.1 Beskrivning av tabellen ”relations”...25
1 Inledning
1.1 Bakgrund
Allt eftersom att Internet växte sig framåt och blev större, nådde det vidare till många svenska hem. Internet blev ett enkelt sätt att kommunicera med andra människor som användarna inte träffat eller sett innan. Ett utav startskotten för detta var IRC (Internet Relay Chat) som utvecklades av Oikarinen (1997). IRC utvecklades redan 1988 vid Uleåborgs universitet i Finland. Enkelt kan det sägas att IRC är ett protokoll för hur användare på ett enkelt sätt kan kommunicera med varandra i skriftform mellan datorer på Internet.
Då bandbredden och tillgängligheten för allmänheten ökade blev det även vanligare med att företag fanns på Internet samt att privatpersoner började skaffa sig privata hemsidor. Idag finns det troligen något företag som inte har någon form för presentation på Internet. Detta var främst efter att World Wide Web framställdes av Tim Berners-Lee vid MIT’s (Massachusetts Institute of Technology) laboratorium (Leiner, Barry M. m.fl. (2003)).
Detta blev startskottet för skapandet av samlingsplatser på Internet där folk kunde diskutera med varandra i nyhetsgrupper, forum på webbsidor osv. En fråga som en utvecklare då kan ställa sig är: Varför inte sammanställa alla dessa funktioner som e- post, diskussionsgrupper, forum osv. i en och samma virtuella samlingsplats?
Virtuella samlingsplatser, eller communities som det även kallas, var speciellt i början, något som var väldigt unikt för Sverige. Något liknande utomlands fanns eller finns knappt att tillgå. Det enda som har slagit kraft utomlands är så kallade singelsidor vilket är sidor där användaren har möjlighet att stämma träffar med andra ensamstående människor. Communities med andra profileringsområden finns knappt utanför Sverige.
En av de första virtuella samlingsplatserna var Lunarstorm som gjorts av LunarWorks AB (2005). Sidan startades ursprungligen 1996 och hette då StajlPlejs.
Uppföljaren Lunarstorm blev offentlig vid millennieskiftet och samtidigt kommersiell.
Idag finns en uppsjö av olika communities med olika profileringsområden. Några av de största idag är Lunarstorm, Helgon (2005) och PlayAhead (2005). Dessutom finns MLSS (2003) som inriktad studentcommunity i Halmstad, Lund och Växjö. För arbetsmarknaden finns bland annat OpenBC (2005) som fungerar bland annat som kontaktförmedling.
Personligen blev jag mycket intresserad av communities och om hur de fungerade. Jag var ofta inne på många olika communities och undersökte deras funktionalitet samt design. Efter ett tag blev intresset så pass påtagligt att utmaningen att försöka skapa en egen community var ett faktum. En design för en eventuell framtida sida började skapas. Samtidigt studerades programkod som användes i liknande funktioner. Det här var för att få en förståelse för hur programkoden fungerade. Efter ett tag började sidan att utvecklas och slutligen blev resultatet Campusportalen (2005a).
Egentligen var syftet med detta projekt från början att ta reda på om jag själv skulle lyckas med att utveckla en community, men även att ta reda på om det skulle vara möjligt att kunna driva en community med inriktning mot studenter på Växjö universitet samt om det fanns något intresse bland användare för detta. Intresset för att sedan skriva en uppsats om ämnet samt utvecklingen kring det hela väcktes i samband med en uppsatsskrivning av Svensson och Tingdahl (2004), där många teorier kring kommunikation och socialpsykologi tas upp, som bland annat handlar mera om människans agerande kring vad som driver en person till att träffa andra personer över
Internet. Den uppsatsen var för mig väldigt intressant då den tog upp många av de aspekter som jag personligen aldrig ägnat en tanke åt. Då kommunikation och socialpsykologin kring området i princip var ”avklarat” så ville jag ägna mig mer åt den tekniska biten kring hela projektet när det kommer till denna uppsats.
1.2 Campusportalens historia
Sidan drevs i två omgångar och har ända sedan början underhållits och utvecklats av en och samma person, Erik Flachmeyer. Den första versionen av sidan började utvecklas under hösten 2003.
För att sidan skulle kunna finnas på Internet, så måste den placeras på en server av något slag. En enkel och snabb lösning för detta var den ideella riksföreningen TechGroup (2005) med säte i Växjö. TechGroup bistod med komplett server samt Internet uppkoppling för denna i utbyte mot reklam åt föreningen på sidan.
Sidan blev under början av 2004 tillgänglig för allmänheten, dock var sidan inte officiell än. Tanken var att endast en liten grupp människor skulle använda sig av sidan för att testa dess funktioner och liknande. Främst för att stöta på buggar och liknande som eventuellt kunde finnas på sidan, men även för att komma med positiv och negativ kritik kring sidans utformande, placering av knappar på de olika sidorna osv.
Efter ett antal dagar, ansågs sidans buggar och användarnas förslag att vara åtgärdade. Därmed ansågs sidan vara officiell och ryktet började sprida sig kring sidans existens. Användarantalet började öka och sidan blev alltmer populär. Totalt fick Campusportalen över 600 medlemmar.
Under sommaren 2004 bröts samarbetet mellan utvecklaren och TechGroup och sidan blev därmed tvungen att läggas ned i brist på serverutrymme. I samband med detta började utvecklaren att se över sidans databasstruktur och programmeringsmässigt och en rejäl omstrukturering inleddes för att i framtiden underlätta underhållsarbetet.
Sidan låg nere under hela hösten 2004 under tiden som omstruktureringen ägde rum. Databasen omstrukturerades rejält och även programkoden. Dessutom fick sidans design ett rejält ansiktslyft då den gamla togs helt bort och en ny skapades. Ett svårt beslut inför den nya versionen av sidan var huruvida användarna från den gamla versionen skulle finnas kvar eller om användarna fick registrera sig på nytt. Det slutade med att användarna på den nya sidan fick omregistrera sig. Främsta anledningen till detta var att den nya databasen skiljde sig alltför mycket från den gamla och det skulle vara svårt samt väldigt tidskrävande att konvertera om den till den nya databasstrukturen.
Under februari månad 2005 blev den nya versionen av sidan officiell efter en tids testande och modifieringar. Sidan fick sin plats på webbhotellet Gate9 Webhosting (2005). De omedelbara reaktionerna från de nya användarna har varit mycket positiva och konstruktiva. Dessutom har den nya versionen bidragit till att sidan används i större utsträckning av varje användare, exempelvis är det flera användare online samtidigt än tidigare samt att funktionerna används alltmer flitigt. En uppgradering av sidan har alltså hittills gett resultat.
1.3 Syfte och problemformulering
Denna rapport kommer att omfatta utvecklandet av Campusportalen (2005a), vilka moment som kan ingå i en community och hur en utvecklare kan gå tillväga för att skapa en sådan sida. Därför kommer alla beskrivningar och presentationer av funktioner
utgå ifrån just Campusportalen i denna uppsats. Dessutom kommer en del problemområden som en utvecklare kan stöta på att tas upp samt en del praktiska frågor kring utvecklandet. Det är främst utvecklandet kring den senaste versionen som kommer att tas upp, då den har modifierats mycket sedan den första versionen.
Genomgången av de olika funktionerna kommer till stor del att vara väldigt ytlig, medan andra väsentliga moment kommer att tas upp lite mer på djupet.
Syftet med denna uppsats samt utvecklandet av Campusportalen var att lära mig praktiskt och teoretiskt hur en utvecklare kan gå till väga för att utveckla en community.
Det främsta syftet med utvecklingen av sidan var att lära mig det tekniska bakom en mer omfattande webbsida, och inte bara hur en utvecklare kan göra en så kallad personlig hemsida, vilket var det enda jag kunde innan utvecklingen av sidan satte fart.
En annan bidragande orsak till utvecklingen och uppsatsen är att i framtiden ha ett konkret exempel på vad jag kan göra i samband med webbutveckling. Detta är främst för att ha en mer eller mindre komplett produkt att visa upp för en eventuell framtida arbetsgivare. Detta blev startskottet för min uppsats och kom därmed på frågeställningen:
• Hur kan en programmerare gå till väga vid utveckling av en webbcommunity?
1.4 Metod
För att ta reda på hur en utvecklare kan gå till väga, så skapades en egen community från början (utan någon mall eller liknande att utgå ifrån). Det här sättet är kanske inte det enklaste, men dock det mest lärorika sättet då utvecklaren själv måste förstå alla moment om hur de olika sakerna sitter ihop och samarbetar. Det här var exakt vad som gjordes. Arbetet började genom att börja studera andra liknande sidor. Hur de har lagt upp sina sidor samt vad för funktioner som de använder sig av. På så vis samlades mycket inspiration om vad som skulle passa till Campusportalen. Slutresultatet kan då tänkas vara det som just denna utvecklare ville ha på en community, men då jag själv var del av målgruppen så var det här inte ett helt felaktigt spår att ta. Dessutom tog jag mycket hjälp av nära och bekanta (som också tillhör produktens målgrupp) för att bolla fram idéer om vad som skulle vara bra för just denna community. En inställning som fanns redan från början var att göra något liknande det som redan fanns, dock saknades något som var stilrent utan en massa ”flashiga” bilder och effekter.
Campusportalen började skapas ifrån grunden och programmerandet var igång.
På så vis måste utvecklaren själv ta hand om de olika problemmomenten, då ingen annan är lika insatt i din egen kod som du själv. Visst finns det hjälp att tillgå, faktiskt en hel del, men det är bäst att prova själv att lösa ett problem först, sen be om hjälp eller be en annan kunnig person att titta igenom koden så att utvecklaren inte missat något kritiskt. Dock kan det ta tid för den utomstående att sätta sig in i koden och förstå syftet.
Men en annan åsikt skadar aldrig.
Campusportalen började utvecklas med hjälp av skriptspråket PHP 4, och även PHP 5 (2004) när denna fanns tillgänglig, samt databasprogrammet My-SQL (2005).
Allt detta installerades på en dator med Ms Windows XP och serverprogrammet Apache (2005). PHP används för att programmera de olika funktioner som kan tänkas behövas och att ställa frågor till en databas (exempelvis My-SQL) samt att behandla dessa. Både PHP och My-SQL är open-source, vilket innebär att språkens källkod är öppen för alla att inspektera. Detta medför att det finns flera som har möjlighet att sätta sig in i språkens uppbyggnad och hur de fungerar rent teknisk och inte bara praktiskt. En annan
följd av detta är att det finns många supportsidor, främst på Internet, som omfattar dessa två språk.
Det finns alternativ till PHP och My-SQL. Dessa är utvecklade av företaget Microsoft och heter ASP (Active Server Pages) respektive Access. En klar nackdel att använda sig av dessa produkter är att de kostar pengar att använda, samt att supporten till väldig stor del drivs av Microsoft och även detta kostar pengar. I och med att PHP och My-SQL är open-source så är detta gratis och ett stort antal supportsidor finns att tillgå. Dock är det många communities som använder sig av ASP/Access kombinationen (bland annat Lunarstorm och Helgon), trots att det kostar pengar.
Troligen har dessa språk tilltalat dessa utvecklare mer personligen än PHP/My-SQL.
(Denna slutsats har dragits genom att filändelserna på sidorna är .asp) Generellt är det detta som är enda skillnaden, vilka språk det är som tilltalar utvecklaren personligen, då båda språken ofta utför samma uppdrag lika bra. Syntaxen (språkens ”grammatik”) är i princip likadan men ibland löses diverse problem på olika sätt.
Anledningen till att PHP och My-SQL valdes i samband med utvecklingen var att författaren personligen inte visste någonting om något skriptspråk (programmeringskod som presenterar ett flöde över hur en uppgift skall lösas som sedan tolkas av en server) och kände därmed att det var bra att ha tillgång mycket support som dessutom var gratis.
2 Formgivning och design
2.1 Olika typer av upplägg
Hemsidor på Internet kan struktureras och se ut på otaliga sätt. Vissa staplar sin information rakt uppochner, medan andra använder sig av snygga introduktioner innan användaren kommer in på sidan. I princip så finns det lika många designer som det finns webbutvecklare, vilket vilken användare som helst kan komma underfund med efter några minuters surfning på nätet.
Dock kan dessa kategoriseras en del. Fil.dr Jakob Nielsen (2001) har delat in några av dessa olika designer i följande kategorier: siddesign, innehållsdesign och webbplatsdesign. Det finns en fjärde och sista kategori, intranätsdesign, men denna är irrelevant för detta ämne och tas därmed inte upp. Nielsen beskriver de olika kategorierna på nedanstående sätt.
2.1.1 Siddesign
Siddesign är den mest omedelbara aspekten av all webbdesign. Användarna kan med dagens webbläsarteknik, betrakta en sida åt gången (eller flera sidor om flera skärmar eller extremt höga upplösningar finns tillgängliga). En annan viktig aspekt är att ytterst få personer besöker en webbplats för att titta eller njuta av dess design. Det som egentligen intresserar är innehållet. En viktig sak att tänka på är att se till att sidorna som utvecklas fungerar på andra plattformar och att de fungerar bra på äldre utrustning.
Något av det viktigaste att tänka på är att se till att sidorna fungerar på webbläsare som är några år gamla, det är inte alla människor som vet att man kan/bör uppdatera sin mjukvara. Designen bör även vara anpassad åt lägre upplösningar, då de flesta använder lite lägre upplösning. Dessutom bör sidan vara åtkomlig för dem som fortfarande använder sig av modem, och det skall inte ta för lång tid att ladda ner/få fram sidan.
2.1.2 Innehållsdesign
I innehållsdesign handlar allt om innehållet och inte så mycket om snygga knappar, bilder osv. Innehållsdesign kan beskrivas som en teaterpublik: När föreställningen är över så är målet att publiken ska diskutera hur bra föreställningen var, inte hur estetiskt tilltalade kostymerna och scensättningen var. Anledningen till att folk kopplar upp sig är i själva verket på grund av innehållet på de olika sidorna som folk besöker.
Nielsen (2001) poängterar att det finns två avgörande faktorer vilka är det kvalitativa innehållet och den andra är hur lätt det är att hitta rätt sida, vilket främst handlar om webbplatsdesign. Kvalitativt innehåll innebär något annat på webben än i traditionella medier. Välskrivna texter och roliga knappar/bilder är alltid uppskattat, men är inte avgörande när det kommer till kvalitet. De frågor som en användare ställer sig är ”Vad har jag för nytta av detta?” och ”Hur löser detta mitt problem?”
Då användarna är väldigt målinriktade och otåliga, så måste innehållet ge snabba svar och snabbt visa att sidan kan vara till nytta för användaren.
2.1.3 Webbplatsdesign
Siddesign får i många lägen stor uppmärksamhet i dagens medier. Webbplatsdesign handlar mycket om upplägget för en sida. Detta är en stor utmaning, då det inte bara är innehållet som håller kvar besökaren på hemsidan. Sidan måste trots allt vara trevlig att vistas på. Samtidigt, om informationen inte är väl strukturerad, så hittar besökaren inte det som det söks efter.
För en utvecklare är det frestande att hoppas på att tekniska lösningar som exempelvis sökmotorer, skall lösa problemen med att leda användaren till det som söks.
Idag har utvecklingen gått rätt långt framåt och ofta så hittar användaren det som denne letar efter, men hittar användaren just det som du vill att denne skal hitta? Ingen sökmotor hittar just din sida om sidan saknar ordentliga och informativa beskrivningar.
2.2 Campusportalens design och upplägg
Bild 2.2.1: Bild av Campusportalen efter att användaren loggat in sig. Sidan är av enkel design med logotypen uppe till vänster samt menyrad till vänster och innehållet i mitten.
I samband med utvecklingen av Campusportalen, så har det bästa och viktigaste försöks att lyftas fram från de olika designmetoderna som finns. Då olika webbläsare tolkar programmeringskod olika så kan detta vara en rätt så stor utmaning.
Kontinuerligt under utvecklingen så har Campusportalen jämförts med de största webbläsarna, Mozilla Firefox, Netscape Navigator och Microsoft Internet Explorer, enligt statistiken från W3 Schools (2005). Det viktigaste har då varit att se till att sidan fått samma utformning och funktionalitet. När tillfället ges, testas produkten även i äldre webbläsare.
Enklaste sättet är att konstant under utvecklingen se till att resultatet blivit detsamma på samtliga webbläsare. Detta kan enkelt göras med att ha båda webbläsare tillgängliga under hela utvecklingsprocessen. Personligen föredrar jag att ha två dataskärmar tillgängliga till en och samma arbetsstation. Detta medför att en utvecklare enkelt kan ha programmeringskoden tillgänglig konstant på en av arbetsytorna, och själva resultatet, från en eller flera webbläsare, på den andra.
I samband med utvecklingen av Campusportalen har många av kategorierna, bland de olika designtyperna, varit i åtanke vid utvecklingen. Bland annat är
webbplatsen byggd för en upplösning på 800*600 pixlar eller mera och inte alltför belastande för modemanvändare, dvs. inte alltför mycket tung grafik som tar mycket filutrymme.
Utseendet på webbplatsen ligger det inte mycket tid bakom för att få det se snyggt ut. Däremot ligger det väldigt många timmar bakom för att få det se enkelt, stilrent och neutralt ut. En snygg och enkel design är det som uppskattas mest i längden.
En jämförelse som kan göras är att titta på dagstidningar, som läses av många människor varje dag, men skulle knappast vinna några priser för deras design.
Jag skulle vilja hävda att en utvecklare kommer mycket längre med enkel design som denne behärskar istället för något som utvecklaren eventuellt inte behärskar. I de lägena där utvecklaren inte till fullo behärskar tekniken blir det ofta ”för mycket av det goda”, och sällan bra i slutändan.
3 Systemen kring Campusportalen
3.1 Interna system
Bakom Campusportalen finns det en del interna system. Systemen i sig sköter kopplingarna mellan de olika funktionerna som kan tänkas finnas. Rent allmänt för sidor med databaser så finns det en del kopplingar. Dessutom finns det förmodligen en del system en utvecklare får ta hänsyn till eller nyttja sig av på webbhotellet.
3.1.1 Databasen och dess funktioner
En databas är enligt Susning.nu (2005) en strukturerad samling data, som kan vara information eller sifferuppgifter, som lagras och bearbetas med hjälp av en dator. Det viktigaste kännetecknet för en databas är dess struktur, vilket gör att detta är närmare besläktat med register, kortlådor än exempelvis ett filträd eller innehållet i ett dokument.
Främsta kännetecknet för en databas är samlingen data, och inte programmet/hjälpmedlet som kan hantera informationen.
För att kunna hantera mängden information i en databas, behövs en databashanterare (DBMS). Ett exempel på detta är phpMyAdmin (2005) som kan administrera en MySQL databas. Den absolut vanligast förekommande databaskonstruktionen är relationsdatabasen och programspråket SQL. MySQL är alltså en variant av SQL.
I samband med struktureringen finns det en rad regler som bör följas. Dessa kallas för normaliseringsregler (normalformer och normalisering (2003)). Dessa brukar förkortas 1NF, 2NF och 3NF.
Första normaliseringsregeln (1NF) säger att tabellerna måste innehålla atomära värden, med andra ord endast ett värde per ruta i databasen. Finns det flera värden, eller finns det önskemål att kunna lagra flera värden för en kolumn, så är det bästa alternativet att använda sig av en kopplingstabell. Dessutom måste det på varje rad finnas ett unikt värde, vilket kallas för ”primär nyckel”.
2NF innebär att 1NF måste vara uppfylld. Dessutom måste data som är gemensamma för flera rader, brytas ut till egna tabeller. Dessa tabeller ska sedan relateras till varandra med hjälp av ”foreign key”.
3NF säger att 2NF måste vara uppfylld. I övrigt får det inte finnas icke- nyckelattribut som är beroende av något annat icke-nyckelattribut.
När det väl finns en databas att tillgå, måste utvecklaren se till att själva hemsidan kan nå denna och använda sig av olika data som finns i denna. Detta kan göras med bland annat skriptspråket PHP (som nämnt innan i rapporten). I PHP kan en utvecklare enkelt göra en anslutning till en databas samt ställa olika frågor till denna.
Detta görs enkelt med en rad funktioner som hanterar saker som anslutning, ställa frågor etc. Som exempel används följande kod för att ställa en fråga till en databas:
database.php:
<?php
$config["dbHost"]="adressen till databasservern";
$config["dbUser"]="användarnamn";
$config["dbPassword"]="lösenord";
$config["dbName"]="namnet på databasen";
function connectToDatabase() { global $dbLink,$config;
if(!($dbLink=@mysql_pconnect($config["dbHost"],$config["dbUser"]
,$config["dbPassword"]))||
!@mysql_select_db($config["dbName"],$dbLink)) { $_REQUEST["page"]="dberror";
} }
function dbQueryRow($query) { $result=DbQuery($query);
if(mysql_num_rows($result)) {
return mysql_fetch_array($result);
} else {
return array();
} }
?>
$config variablerna innehåller användarinformation som är nödvändig för att göra en databasanslutning. Dessa innehåller adress, lösenord och namnet på den databasen som skall användas. Funktionen connectToDatabase, som ansluter till databasen, körs en gång vilket är i samband med att användaren försöker logga in på sidan. Dessa rader bör ligga i en egen fil för enklare korrigering. Inloggningsuppgifterna behöver inte korrigeras när de väl är satta.
Därefter har vi en av funktionerna som används till att göra databasanrop, nämligen dbQueryRow. Denna funktion förutsätter att svaret från databasen endast blir en rad. För att ställa frågor som returnerar flera rader från databasen krävs en funktion som returnerar en associativ lista. Själv har jag använt mig av en funktion som jag kallar dbQueryAssocArray för detta ändamål. Med ovanstående kod kan information enkelt hämtas med funktionen dbQueryRow:
<?php
$a = ”SELECT nickname FROM student WHERE id = 802”;
$result = dbQueryRow($a);
?>
Funktionen ställer en fråga till databasen, och resultatet lagras i variabeln ”$result”.
$result[’nickname’] hade i detta fallet innehållit strängen ”webmaster” då detta är användarnamnet hos användaren med id-nummer 802.
I princip är det detta som görs hela tiden, att data hämtas från databasen.
Därefter sker diverse olika saker beroende på förutsättningarna i databasen och vilka funktioner som skapats i koden. Om ovanstående kod hade varit med dbQueryAssocArray, dvs. att en associativ lista har hämtats, så måste en loop skapas som går igenom varje lista för att sedan skriva ut denna:
<?php
$a = ”SELECT nickname,id FROM student WHERE id < 100”;
$results = dbQueryAssocArray($a);
foreach ($results as $result) { print $result[‘nickname’];
print $result[‘id’];
}
?>
Ovanstående kod hämtar flera listor ifrån databasen. Därefter sker en loop som går igenom varje lista och skriver ut användarnamnet och id-numret.
3.1.2 Webbhotell och dess olika system
I samband med att en sida lanseras, måste sidan finnas på en server. Min egen plan var att ha en dator med serverprogramvaran installerad som sedan kopplats till min privata Internetanslutning. Detta satte dock min Internetleverantör stopp för. Det är inte tillåtet att egna servrar på SUNET’s studentnät, vilket var där jag själv var ansluten till, enligt deras policy. Därmed blev jag tvungen att leta efter webbhotell att ha sidan på.
Att leta efter ett webbhotell som passar för ens egna syften är inte det enklaste.
Det finns ett väldigt stort utbud och alla med sina tjänster och priser. Dock en viktig erfarenhet jag fick lära mig var att som köpare erhålles vad denne betalar för. Med andra ord är det inte bara att leta efter det första bästa billiga webbhotellet en utvecklare kan hitta. Det är mycket viktigt att titta i olika forum för att se vad andra människor haft för erfarenheter av de olika webbhotellen. Själv använde jag mig av PHP Portalen (2005) som har mycket välanvända forum där webbutvecklare diskuterar frågor kring PHP, MySQL, webbhotell etc. Slutligen valde jag Gate9 Webhosting (2005), av anledningen att jag kunde starta med ett litet paket och sedan utöka efter behov. Med litet paket menas att det inte ingick alltför mycket utrymme ifrån början, utan en utvecklare kan vänta och se hur mycket som egentligen behövs, vilket är svårt att beräkna ifrån början.
I samband med att ett webbhotell väljs, så är det viktigt att utvecklaren vet ifrån början vilka olika funktioner och liknande som finns tillgängliga. Som PHP programmerare är det viktigt att ha i åtanke med just detta. Detta kan enkelt göras genom en funktion inom PHP som heter phpinfo (2005c). Denna funktion finns ofta tillgänglig hos webbhotellen så att en potentiell kund kan se vad som finns att tillgå på servrarna. Det som syns är vilka funktioner inom PHP som finns tillgängliga. Det kan handla om vilka paket som sköter bildhantering eller kopplingar till databaser som finns tillgängliga.
I mitt fall skulle det enligt Gate9 finnas möjlighet att ifrån min hemsida skicka e-post, som exempelvis kan användas vid registreringen (se avsnittet registreringsprocessen). Detta visade sig dock inte att fungera i praktiken. Detta slutade med att jag fick använda mig av egendefinierade funktioner då de funktioner i PHP som används för att skicka e-post inte fungerade. Så trots att webbhotellet hade e-post stöd, så fungerade inte funktionen korrekt. Det är därför viktigt att ha rejäla användartester innan sidan sätts i bruk på allvar (se avsnittet Campusportalens historia), då kan allt till synes vara bra, men inte fungera i praktiken.
Bild 3.1.1: Filstrukturen på Campusportalen.
Mappen ”campusportalen.com” är rotkatalogen. Under denna finns
”cgi-bin”, ”error-doc”, ”inc” och ”www”. De två förstnämnda styrs av servern och används inte direkt av utvecklaren själv. Mappen ”inc”
innehåller funktionerna och databasanropen som används på sidan.
Under den finns mappen ”www” som innehåller all html-kod och design.
Denna mapp är offentlig och nås direkt i samband med besök på sidan.
Med andra ord är denna mapp direkt kopplat till domänen (ex:
www.campusportalen.com). På så vis är mappen ”inc” inte direkt åtkomlig av användarna på sidan, utan kan endast nås genom att någon sida i ”www” anropar en funktion som finns i ”inc”, eller genom en ftp- anslutning.
När webbhotellet är valt, ska filerna laddas upp och databasen skapas. I samband med filöverföringen används ett protokoll som kallas FTP. Detta protokoll används ofta i samband med filöverföringar hos webbhotell. Detta kan göras enkelt med s.k. ftp- program som WS-FTP, CuteFTP etc.
En viktig aspekt kring uppladdningen är att se till att det finns en offentlig katalog och en katalog som inte är det. Den icke-offentliga katalogen kan inte nås direkt från Internet, utan bara via en ftp-anslutning eller om en PHP funktion på övriga sidan anropar dessa filer (se bild 3.1.1 för exempel). Denna katalog är därmed bra att använda till filer som definitivt inte skall ha någon åtkomst för användare. Detta kan vara filer som innehåller olika funktioner och databasanrop. Dessa filer skall inte vara offentliga då en utomstående enkelt kan se hur en användare kan kringgå systemet för att direkt skada sidan. Vilka kataloger som skall vara offentliga eller inte, kan sällan bestämmas av utvecklaren själv, då detta är inställningar på servern. I mitt fall fick jag ta hjälp av Gate9’s kundtjänst som löste detta utan problem.
4 Struktur och funktionalitet
4.1 Målgrupp
Campusportalens huvudsakliga målgrupp är högskolestudenter vid Växjö universitet.
Dock har i princip vem som helst med en egen e-postadress möjlighet att registrera sig på sidan. Detta öppnar möjligheter för de personer som är intresserade av studentliv, men som dock inte studerar, att bli medlemmar på sidan. Med andra ord sträcker sig denna målgrupp till personer som är runt 18-30 år gamla av att döma på ungefär vilka åldrar det var som rörde sig inom den första versionen av Campusportalen.
En annan målgrupp som webbplatsen riktar sig till är studentföreningar och studentpubar. Bland funktionerna på webbplatsen finns en annonseringstjänst där studentföreningarna och studentpubarna kan publicera sina evenemang så att de har en extra kanal ut till sina medlemmar.
4.2 Registrering
I samband med registrering på Campusportalen, så är det en hel del funktioner som används. Dessutom finns det en massa som en utvecklare måste ta hänsyn till.
4.2.1 Användarvillkor
Att registrera sig som en användare på Campusportalen är inga svårigheter. Dock finns det mycket administrativt arbete bakom. Användare hittar lätt kryphål i policys och liknande för att göra något som eventuellt inte ska vara tillåtet. Dock kan de flesta problemen undvikas genom att införa användarvillkor.
En användare måste aktivt godkänna Campusportalens användarvillkor (2005b) för att kunna komma vidare i registreringen. Med att aktivt godkänna ett dokument menas att användaren måste själv göra någonting för att visa att användaren godkänner kraven. I detta fall handlar det om att användaren efter att ha läst användarvillkoren måste bocka i en kryssruta som bekräftar att användaren tagit del av samt godkänt användarvillkoren. Görs inte detta så är det inte möjligt att fortsätta registreringen.
Sedan 2003 finns en lag om elektronisk kommunikation (2003). Denna lag säger att om en webbplats innehåller cookies, måste användaren informeras om detta.
Dessutom måste användaren informeras om vad dessa cookies används till och hur de kan undvikas om användaren skulle önska detta. Här är användarvillkoren ett lämpligt ställe att nämna detta.
Många kan tycka att användarvillkor är något som inte behöver finnas och att det bara är en massa text som ingen läser. Dock är användarvillkor eller liknande nödvändigt för att ha en riktlinje för hur användare skall bete sig på sidan. Dessutom finns det regler att hänvisa till i samband med tvister och andra dispyter.
En hel del av avsnitten i användarvillkoren är tagna direkt utifrån verkliga livet.
Exempelvis måste lagar och andra regler som gäller i övrigt i samhället efterföljas, trots att det är en webbplats användaren rör sig på. Många av dessa avsnitt i användarvillkoren kan därför ses som påminnelser om vad som gäller i verkliga livet.
Andra regler, som används av många communities, är att användaren måste sköta sig väl inne på webbplatsen. Exempelvis så tolereras inte dåligt uppförande eller beteende, oanständigt språkval och rasism/nazism.
Bland användarvillkoren finns även varningar om att brott mot villkoren resulterar i varningar skickas till berörd användare och i värsta fall polisanmälan samt avstängning från webbplatsen.
Andra regler och riktlinjer som finns i villkoren omfattar hur användare skall gå till väga för fotouppladdning av profilbild samt vad som får finnas i köp- och säljmarknaden. Närmare beskrivning kring detta kommer att omfattas i avsnittet kring
”Profileringssida”.
4.2.2 Personuppgiftslagen (PUL)
En av de viktigare aspekterna i samband med att värva medlemmar, är att se till att personuppgiftslagen, PUL (1998), efterlevs. Detta görs enkelt genom att ta med denna aspekt i samband med användarvillkoren. PUL innehåller bestämmelser kring hur människor skyddas mot att deras personliga integritet kränks genom behandling av personuppgifter. PUL trädde ikraft 1998 och ersatte den tidigare datalagen. PUL bygger på direktiv ifrån EU.
I samband med godkännandet av användarvillkoren på Campusportalen (2005b) accepterar användaren följande:
”Som användare av Campusportalen godkänner jag att uppgifter, som jag delat eller kommer att dela med mig, får lagras på Campusportalens system.” (Campusportalen 2005b)
Ovanstående text gör att utvecklaren håller sig i enlighet med PUL.
4.2.3 Registreringsprocessen
Registreringsprocesser för communities är väldigt lika varandra. Även många Internetbutiker och andra tjänster på nätet följer ungefär samma struktur. De flesta registreringsformulär innehåller först användarvillkoren som efterföljs av formulärfält där användaren får fylla i sina uppgifter.
Campusportalen följer dessa ”normer”. Överst på registreringssidan (som nås via en knapp ifrån startsidan) finns användarvillkoren följt av en rad olika formulärfält (se bild 4.2.1 nedan). På dessa fält har användaren möjlighet att fylla sin e-postadress och önskat användarnamn. E-postadressen och användarnamnet måste vara unik av den anledningen att en och samma person inte ska ha möjligheten att registrera två användare på samma e-postadress. Skulle det vara möjligt att ha två användare med samma användarnamn, så skulle detta lätt skapa förvirring väl inne på sidan. E- postadressen går igenom en validering för att kontrollera att den har formen xx@yy.zz, där ”z” kan vara två till fyra tecken lång och ”y” måste vara två tecken eller längre.
Detta med anledning att vissa toppdomäner har bara två tecken i slutet (t.ex. vxu.se) och andra har fyra (t.ex. microbes.info). Andra domäner med formatet xx@yy.zz.zz går också igenom.
Därefter skall ett lösenord fyllas i. Detta lösenord kommer att sedan användas tillsammans med användarnamnet vid inloggningen. Lösenordet skall även bekräftas, av säkerhetsskäl, vid registreringen då det endast syns punkter (eller stjärnor beroende på webbläsare) där lösenordet fylls i. Därefter finns ett par fält att fylla i som är frivilliga, nämligen för- och efternamn. Dessa fält är frivilliga då dessa syns på användarens profilsida.
Bild 4.2.1: Botten på registreringssidan där användaren har möjlighet att fylla i sina uppgifter.
Användaren skall sedan fylla i vilken studieort vederbörande bor i. Att det bara fanns Växjö att välja mellan beror på att webbplatsen endast var aktuell för studerande
på Växjö universitet då denna uppsats skrevs. Användaren kan därefter fylla i vilket område denna bor i Växjö. Slutligen fyller användaren i födelsedatum samt kön. Till sist måste användaren bocka i att denna har läst och förstått användarvillkoren.
unactive
Bild 4.2.2: Beskrivning av tabellen ”unactive”.
id nickname password email name lastname city residence sex birth activatecode regdate
int varchar varchar text text text int int enum date varchar date
När användaren väl fyllt i alla uppgifter så kontrolleras dessa av servern. De kontroller som sker är exempelvis att se till att användarnamnet är ledigt samt att e- postadressen inte finns registrerad sedan tidigare. Har inte alla uppgifter fyllts i korrekt så får användaren möjlighet till att korrigera sina inmatningar. Är allt korrekt ifyllt skickas användaren vidare i processen och får ett besked om att en registrerings e-post skickats till adressen som angavs vid registreringen. I e-postmeddelandet finns inte bara användaruppgifter som användarnamn och lösenord, utan även en aktiveringskod.
Denna kod skall sedan anges i ett aktiveringsformulär, som nås via en länk från startsidan. I samband med detta så matas samtliga uppgifter in i en tabell vid namn unactive i databasen (se bild 4.2.2 för tabellbeskrivning). Tabellstrukturen är väldigt enkel och har i princip inga kopplingar till andra tabeller, bortsett ifrån raderna city och residence som är kopplade till tabellerna med samma namn. Dessa tabeller innehåller samtliga orter och bostadsområden som är aktuella för systemets användare. Id är en räknare som är unik som används för att samtliga rader i tabellen skall vara unika. Det finns även andra kolumner som är unika, men id finns av den anledningen att det ska vara enkelt att koppla med andra tabeller, då detta är enklast med ett unikt
siffervärde. Nickname och password är användarens användarnamn respektive
lösenord. Sex, birth och regdate är användarens kön, födelsedatum och registreringsdatum.
Password krypteras med tekniken PHP: md5 (2005b), vilket i praktiken innebär att om md5 tekniken tillämpas på ett lösenord, så kan en användare endast få fram lösenordet genom att jämföra med det riktiga lösenordet. Md5 tekniken är en så kallad envägskryptering. Aktiveringskoden activatecode slumpas fram med hjälp av en slumpgenerator som genererar en sträng på 20 tecken blandat med siffror och bokstäver.
Processen med aktiveringskoden finns till för att det ska finnas en korrekt e- postadress till varje användare. Detta förhindrar en användare att bli medlem om denne inte innehar en korrekt e-postadress. Aktiveringskoden måste stämma överens med activatecode i tabellen unactive och i så fall flyttas användaren över till tabellen student (se bild 4.3.1) och kan därefter logga in på Campusportalen.
Använder användaren sig inte av sin aktiveringskod inom en dag, raderas användaren från registreringen (posten raderas från tabellen unactive).
Tyvärr finns det olika inställningar hos olika e-post servrar. Ibland kan detta medföra att registreringsmailen hamnar i en skräpmapp eller rent av slängs.
Anledningen till detta är olika spam-skydd (”spam” är ett uttryck för e- postmeddelanden som innehåller oönskad reklam och annat ”skräp”). I och med att varje e-postmeddelande, praktiskt taget, ser likadana ut med tanke på att flera meningar och ämnesraden i varje meddelande ser likadana ut så tolkas det av vissa servrar som spam och slängs därmed. Detta medför att många som registrerar sig inte får sina e- postmeddelanden med aktiveringskoden i. Ett sätt att ”lösa” detta på är att skriva ett meddelande i samband med registreringen som tipsar användaren att titta i skräpmappar och liknande efter sitt aktiveringsmail (se botten på bild 4.2.1).
4.3 Inloggningsprocessen
Användaren loggar in sig på Campusportalen på traditionellt vis, dvs. att fylla i ett användarnamn och lösenord i ett inloggningsformulär.
Tabellen student (se bild 4.3.1) liknar unactive mycket, men det finns en rad skillnader. Dels finns inte activatecode kvar i student. Däremot finns profileinfo, lastlogin, lastupdate och online. Vi ska nu gå lite närmare in på vad dessa olika saker är för något.
Profileinfo innehåller den text som användaren har skrivit på sin egen profileringssida vilket är ganska vanligt att alla användare har på communities i dagens läge. Lastlogin är tid och datum för när användaren loggade in senast på sidan. Många system har ytterligare kontroller för när användare loggar in.
Detta kan exempelvis göras med en separat tabell där en ny rad läggs till varje gång en användare loggar in. Det som lämpligtvis
sparas i den tabellen är vilken användare som loggade in och vilken tid det var. Önskar man, så kan ytterligare fakta läggas in i samband med detta, exempelvis vilket IP- nummer användaren hade och vilken webbläsare som användes.
id nickname password email name lastname city residence sex birth profileinfo regdate lastlogin lastupdate online
int varchar varchar text text text int int enum date text Date datetime datetime enum
Bild 4.3.1: Beskrivning av tabellen ”student”.
student
Lastupdate är dag och tid för när användaren senast var aktiv efter inloggningen.
Med aktiv menas då användaren har bläddrat mellan olika sidor. Denna kontroll är inte något som är nödvändigt för en community, dock har jag själv valt att lägga in denna kontroll. Detta med anledning av att det finns en html-frame på sidan som uppdateras varannan minut. Denna frame håller koll på om användaren fått något gästboksinlägg
eller liknande. Denna frame som egentligen är en iframe ligger direkt under logotypen för Campusportalen (se bild 2.2.1). I samband med att denna uppdateras så uppdateras lastupdate i databasen. Med hjälp av detta vet systemet enkelt om en användare är inloggad eller inte. Detta kan göras enkelt med en funktion som avgör att en användare är utloggad om tiden i lastupdate är äldre än tre minuter och uppdaterar i så fall online till falskt. Om användaren är inloggad på sidan så är online sant. Denna funktion läggs in med anledning av att det inte är alla som bryr sig om att logga ut, utan stänger bara ner webbläsarfönstret.
När användaren fyllt i sitt användarnamn och lösenord i formuläret, skickas informationen till servern för att jämföras med tabellen student. Nickname och password jämförs med tabellen och kontrolleras att dessa finns på samma rad i databasen. Är detta inte fallet möts användaren av ett meddelande om att inloggningen misslyckades på grund av felaktigt användarnamn/lösenord. Om allt stämmer enligt tabellen så loggas användaren in. I samband med inloggningen så uppdateras lastlogin och lastupdate. Lastupdate uppdateras även, som nämnt ovan, vid varje sidbyte inom Campusportalen. Dessutom sätts online till sant.
4.4 Säkerhet och sessioner
PHP är ett skriptspråk som är väldigt enkelt. Det tar inte lång tid innan en användare lärt sig göra enklare funktioner. I och med att språket är så enkelt som det är, så är det många som är kunniga inom området, varav de flesta är mer kunniga än dig själv.
Som webbutvecklare skall du aldrig anta att just din egen sida är ointressant för crackers att förstöra. Crackers i detta fall handlar om vad vanliga människor skulle kalla för hackers. Hackers i sig är inte farliga då de besitter enorm kunskap om säkerhet och liknande och oftast påpekar för ägaren om de hittat en säkerhetslucka. Däremot är crackers aningen farligare då de använder sin kunskap för personlig vinning.
Varför ska en utvecklare anta att ens egen sida kan bli utsatt? Lika väl som att vi alla någon gång har kört lite för fort, eller kastat en glasflaska i marken. Varför har vi gjort detta? Troligen mest för att det har varit kul vid det givna tillfället. Det fungerar likadant för crackers, det är kul att tänja på lagen lite eller helt enkelt bara förstöra.
En teknik som kallas XSS, som är en förkortning för Cross Site Scripting (förkortningen CSS är redan upptagen av Cascading Style Sheets), gör det möjligt att utföra diverse elakheter på en webbsida genom att bland annat manipulera data i formulär eller i adressfältet. På communities och andra stora webbsidor så finns det ofta en rad olika formulärfält där användaren kan skicka in text, exempelvis forum, e-post och gästböcker. Dessa data måste kontrolleras så att servern inte tolkar denna felaktigt.
Med lite smart inmatning så kan en cracker åstadkomma väldigt stor skada, exempelvis radera delar eller hela databasen. Detta kan göras genom att en cracker vet vart och hur denne kan mata in en MySQL sats som gör just detta. Andra saker som kan hända är att sidan får ett speciellt utseende då crackern matat in HTML kod som enkelt kan förstöra utseendet på sidan. Andra möjligheter som finns är att exempelvis mata in HTML-kod som länkar till en annan webbsida med kod som utför diverse otrevligheter på användarens dator (CV-databas (2003)). Det som kan hända är praktiskt taget allt som kan göras med JavaScript, vilket bland annat är stöld av cookies som innehåller användarnamn, lösenord osv. Nedan följer ett exempel:
<a href=”#”
onmouseover=”location.href=’http://www.server.se/nasty.php’”>
Ovanstående kod gör att när muspekaren rör sig över länken så öppnas en ny sida som utför koden som finns på länkdestinationen. Men det finns hjälp emot detta.
Det finns en rad olika funktioner i PHP som hjälper mot just sådana problem. De inmatade värdena ”tvättas” i dessa funktioner innan de används i dina egna funktioner på sidan som utför databasförfrågningar och dylikt. Ett exempel på detta är htmlspecialchars (2005d). Funktionen ändrar all imatad text till HTML entiteter, vilket innebär att all inmatad text ser ut som text för servern och klienten och inte tolkas som PHP- eller HTML kod. Därmed kan koden inte åstadkomma någon skada.
En annan viktig aspekt kring säkerhet är att se till att all viktig kod ligger i externa filer som i sin tur ligger i en katalog som inte är åtkomlig från Internet (se avsnitt Webbhotell och dess olika system).
Sessioner är något som en utvecklare blir bekant med i samband med utveckling kring communities och liknande. Sessioner kan jämföras med cookies, som lagrar information om användaren på klienten, men sessioner lagras på servern. De här så kallade sessionscookies försvinner när användaren stänger ner webbläsarfönstret. De är således användbara i samband med inloggningssystem. För att starta en session gör du på följande sätt:
<?php
session_start();
?>
Ovanstående kod ska finnas överst på alla sidor efter inloggningen. Detta är för att servern skall förstå att sessioner kommer att användas på sidan. I samband med sessioner skapas sessionsvariabler, $_SESSION[’variabel’]. I dessa variabler finns information kring vilket ip-nummer besökaren har, vilken webbläsare som används, vilket land besökaren är ifrån etc.
Dessutom kan utvecklaren själv lagra globala variabler för varje användare.
Exempelvis kan id-numret för en student från tabellen student lagras i
$_SESSION[”userId”] i syfte av att veta vilket id-nummer en given användare har. Ett enkelt användningsområde är att veta om användaren ifråga besöker sin egen profileringssida eller inte. På så vis vet servern om det ska finnas ytterligare alternativ för användaren eller inte, exempelvis möjlighet till att ändra sin användarinformation.
I samband med att användaren loggar ut eller stänger ner webbläsarfönstret så ska sessionerna avslutas vilket kan göras med nedanstående kod:
<?php
session_start();
session_unset();
session_destroy();
?>
Med tanke på ovanstående kod så finns det möjlighet att veta om en användare är online eller inte. Finns det ingen session för en specifik användare, sätts online i tabellen student till falskt och användaren antas därmed vara utloggad.
4.5 Gästboksfunktioner och intern E-post
En av de många olika funktioner som är ganska genomgående för en community på Internet är gästböcker. Varje användare har en egen gästbok som oftast är offentlig och som är fri för alla att skriva i.
Gästboken är rent tekniskt sett inget avancerat. Det svåra är hur en utvecklare rent designmässigt skall presentera en gästbok på skärmen, så att det blir lättläst och lätt att överskåda. Ett enkelt sätt för att ta reda på vad som skulle passa just din community, är att titta omkring på övriga communities på nätet för att skaffa inspiration.
En viktig aspekt bland gästböckerna är att all inmatad kontrolleras, så att det inte finns HTML eller PHP kod eller liknande i texten som rent av kan förstöra sidan (läs stycket om Säkerhet och Sessioner).
guestbook gbid
gbto gbfrom content gbnew gbanswer gbtime
int int int text enum enum timedate
Bild 4.5.1: Beskrivning av tabellen ”guestbook”
Tabellen över gästboken, guestbook, (se bild 4.5.1) är enkel att förstå. Raden gbid är en unik räknare för att alla gästboksinläggen ska få ett unikt id-nummer. Raderna gbto och gbfrom är vilka personer som inlägget är ägnat till och vem det är ifrån. Dessa rader är direkt kopplade till id i tabellen student.
Content är självaste innehållet i meddelandet som skall presenteras och gbtime är dag och tid för när meddelandet skrevs. Gbnew och gbanswer är huruvida inlägget är nytt och om det är besvarat av användaren det är ägnat till eller inte. Dessa
två rader är satta till sant respektive falskt när inlägget skickas, och gbnew sätts till falskt efter meddelandet lästs av mottagaren och gbanswer sätts till sant när mottagaren besvarat inlägget.
Funktioner kring ett internt e-postsystem ser i praktiken likadant ut. Enda skillnaden är att alla inläggen är hemliga för alla förutom avsändaren och mottagaren.
Detta kan lösas med $_SESSION som diskuterades i avsnittet Säkerhet och Sessioner.
Säg att en inloggad användare vill titta i sin egen gästbok, så kan detta lösas med följande MySQL sats:
<?
$guestBookMessages = “SELECT * FROM guestbook WHERE gbto =
”.$_SESSION[‘userId’].” ORDER BY gbtime DESC”;
$result = dbQueryAssocArray($guestBookMessages);
?>
Ovanstående MySQL sats säger att allt ska hämtas ifrån tabellen guestbook där raderna gbto är lika med användarens egna id-nummer, som sedan innan finns lagrad i variabeln
$_SESSION[”userId”], från tabellen student. Sedan skall dessa sorteras efter ordningen de skrevs enligt gbtime. För att se en annan användares gästbok så ändras gbto till det id-numret som gäller för den besökta användaren. I samband med e-post gäller det att se till att det endast visas e-postmeddelanden för den inloggade användaren och ingen annan. Detta kan lösas genom att se till att det endast är meddelanden för den inloggade användaren som visas i samband med visning av e-post sidan.
4.6 Forum
Forum är ofta en väldigt stor del av en community. På Campusportalen finns ett ganska omfattande forum med en hel del olika diskussionsämnen. På de större communities, exempelvis Lunarstorm och Helgon, finns det också forum som används mycket utav användarna.
Det finns en hel del olika forum att tillgå på Internet. Många av dessa är väldigt bra. En av dessa är phpBB (2005) som dessutom är gratis. phpBB används bland annat av det välbesökta forumet PHPportalen (2005). Själv försökte jag använda mig av phpBB. Det fanns massor av guider att ta hjälp av och konfigureringen gick smärtfritt.
Dock tyckte jag inte att phpBB passade för Campusportalen. phpBB är väldigt avancerat med väldigt många funktioner där de flesta inte skulle behövas och slutligen bara förvirra användarna. Därmed ville jag försöka göra ett enklare forum själv.
Anledningen till detta var att få ett forum som dels passade in grafiskt och funktionsmässigt till webbsidan.
Det konstruerades tre tabeller i databasen för forumet (se bild 4.6.1). Tabellen forum_category är vilka huvudkategorier som finns och var och en av dessa har ett unikt id-nummer (vilket är genomgående för alla dessa tab
samt en beskrivning av dessa, forum_category. I tabellen forum_subject finns alla ämnen som i sin tillhör någon kategori. Detta medför att raden forum_subject_category är kopplad till forum_category_id för att visa vilken kategori respektive ämne tillhör. Raderna forum_subject och forum_subject_desc är namnet på ämnet samt en kortare beskrivning på vad ämnet handlar om.
eller), forum_category_id,
Bild 4.6.1: Beskrivning av tabellerna
”forum_category”, ”forum_subject”
och ”forum_msg”.
I tabellen forum_msg finns en rad olika funktioner för forumet. Forum_subject är kopplat till tabellen forum_subject och avgör vilket ämne som meddelandet tillhör. Threadstart avgör huruvida det givna inlägget är första inlägget för en tråd i forumet.
Om denna är sann, listas därmed övriga inlägg som har samma thread_id som det givna inlägget. Om raden threadclosed är sann så innebär det att denna tråd är stängd, vilket innebär att tråden är avslutad och att inga fler inlägg kan skrivas i den givna tråden. Msg_student avgör vilken användare som är författaren till respektive meddelande. Msg_topic, msg_content och msg_time är meddelandets ämnesrad, innehåll och tiden meddelandet skrevs. Slutligen finns raden msg_read som är en räknare som ökas med ett för varje gång som tråden läses.
På Campusportalen finns därefter ett antal fler funktioner. Detta är funktioner som exempelvis talar om vem som svarat på ett specifikt meddelande, samt talar om svaret är läst av trådförfattaren eller inte.
På forumets förstasida presenteras kategorierna, och för varje kategori presenteras sedan vilka underämnen som finns. Där har användaren möjlighet att välja vilket ämne denne vill läsa. Därefter listas alla inlägg där threadstart är sann med det givna forum_subject_id ifrån tabellen forum_subject. Väljs en tråd därefter så listas alla inlägg med det givna thread_id.
4.7 Relationer
Detta avsnitt kommer att handla om relationer. Det är inte relationer med avseende på databashantering eller liknande, utan relationer mellan människor. En vanligt förekommande funktion på communities är just relationer. Detta handlar om att två användare kan skapa en relation med varandra. Detta summeras ofta upp på någon form av lista där alla relationer listas, sorterat efter relationstyp. Detta används främst för att enkelt hitta en specifik användare som respektive användare ofta har kontakt med.
Funktionen går ut på att på varje användares profilsida finns en knapp som leder till en sida där användaren kan skapa en relation med den andra användaren ifråga. Där kan relationstyp väljas, exempelvis vän, nära vän, kompis etc. Därefter får den tillfrågade användaren en förfrågan om att godkänna denna relation. Godkänns denna så hamnar denna användare på dennes kontaktlista och vice versa. Godkänns den inte raderas förfrågan.
Denna funktion kan lösas på många sätt, då det är en väldigt svår funktion att utforma rent tekniskt. Detta är en tvåvägs relation som kan lösas genom att varje rad i databasen motsvarar en relation från en användare. Detta medför att det skulle krävas två rader i databasen för varje relation, då den andra användaren har samma relation med den förste användaren.
Dock har jag gjort en egen lösning på detta genom att endast använda mig av en rad i databasen (se bild 4.7.1) i tabellen relations. Id är, som vanligt, en unik räknare för att skilja varje relation åt. User1 och user2 är användaren som ursprungligen startar en relation respektive den som svarar.
Type är vilken relationstyp som används. Detta kan lösas genom att ha relationstypen som fritext i tabellen eller koppla in en till tabell där alla tillgängliga relationer listas med varsitt id-nummer. Själv har jag valt det senare alternativet.
Bild 4.7.1: Beskrivning av tabellen ”relations”.
Changeto är om någon önskar att byta relation. Då byter användarna på user1 och user2 plats så att det alltid är användaren på user1 som är den som frågar om ny eller byte av relation. Changeto representerar den relation som det önskas att byta till.
Accept är sedan nyckeln i det hela. Där har jag själv använt mig av sifferkoder.
Exempelvis så betyder ”11” att user1 önskar att skapa en relation och ”12” betyder att user1 önskar att byta befintlig relation. När väl ett uttänkt sifferkodsystem är utarbetat kan en utvecklare enkelt anpassa kodningen så att rätt saker utförs när det är tänkt.
4.8 Profileringssida
Varje användare har, som nämnt innan i uppsatsen, en egen profileringssida att presentera sig själva på. Det kan vara saker som vilket område användaren bor i, civil status, fritext, kontaktinformation och mycket annat. Dessutom finns möjligheten att ladda upp en egen bild av sig själv.
Denna sida skall givetvis kunna ändras av varje enskild användare. Dock finns det saker som inte är editeringsbara, exempelvis kön, ålder och användarnamn.
Användarnamnet är ej editeringsbart av den anledningen att det skulle förvirra övriga användare om en användare skulle byta användarnamn konstant. Likadant är det med kön samt födelsedatum, som istället anges i samband med registreringen. Det som sker vid editeringen av en profileringssida är bara uppdatering av tabellen student för respektive användare. Där kan rader enkelt läggas till i tabellen för att motsvara fritext och annat.
4.8.1 Bilduppladdning till profileringssidan
På Campusportalen har varje användare möjlighet att ladda upp en profileringsbild.
Detta är för att på ett enkelt sätt se vem användaren är, exempelvis om det skulle vara någon som vissa användare känner igen ifrån verkliga livet. Dock finns vissa regler att ta hänsyn till.
I Campusportalens användarvillkor (2005b) finns regler för just fotouppladdning. Dessa säger att bilderna måste föreställa användarna själva ifråga och ingen annan. Dessutom får bilderna inte innehålla otillåtna symboler och Sveriges lag måste följas. Hur kontrolleras detta?
Det löses enklast med en form för bildvalidering. I bild 3.1.1 visas katalogstrukturen för Campusportalen. I mappen users finns en undermapp (syns dock ej på bilden) som heter notval (som i ”icke validerade”). Här hamnar bilderna som användarna laddar upp. I samband med att bilderna laddas upp så döps filerna om till det användar-id som användaren ifråga har enligt databastabellen student. På så sätt syns det enkelt vilken bild som tillhör vilken användare.
När bilderna ligger i mappen notval är dessa ej synliga för övriga användare, utan det är endast bilder som ligger i users som är synliga på själva sidan. Att validera en bild är därför inte svårare än att flytta respektive bild från mappen notval till users.
Detta kan givetvis även lösas med hjälp av databasen, dock valde jag själv att göra på detta vis då det praktiskt sett är enklare ju mindre system som dras in i varje moment.
Det finns en funktion som avgör vad för bild som skall visas för respektive användare. Finns en bild för användaren i mappen users så visas bilden, annars visas en alternativ bild som visar att användaren inte har laddat upp någon godkänd bild.
5 Resultat
5.1 Funktioner på Campusportalen
Under utvecklingen av webbportalen så har en mängd olika funktioner skapats. De mest genomgående funktionerna och hur de fungerar har redan tagits upp i denna rapport.
Dock finns det ytterligare en mängd funktioner och inställningar att tillgå som användare och administratör. Nedan finns en kort lista över funktioner som finns att tillgå på Campusportalen.
5.1.1 Inloggad som student
När själva registreringen är slutförd så finns det en del inställningar som inte är går att ändra på. Dessa är saker som ålder, kön och användarnamn. Dock går övriga saker att ändra på. Studenter har inte tillgång till riktigt alla funktioner på sidan, men de som finns att tillgå är:
• Sökning: Söka efter andra studenter beroende på vad de studerar, vilka medlemskap de innehar, ålder, kön, civil status samt boendeområde.
• Min Sida: Användarens egen profileringssida. Här finns möjlighet att ändra profileringstext och medlemskap samt att ladda upp en profilbild.
• Mail: En intern e-postfunktion som bara fungerar bland medlemmarna inom sidan.
• Gästbok: Kan ses som en offentlig e-post, som kan läsas av alla medlemmarna på portalen.
• Mina kontakter: Sida där användarens egna kontakter sammanställs. Här kommer även relationsmeddelanden från andra användare.
• Dagbok: Enkel dagboksfunktion där inläggen antingen kan vara helt privata, läsbara av dem som det finns en relation med, eller offentlig för samtliga.
• LIVE!: Ett klotterplank där användare snabbt kan skriva av sig lite.
• Marknad: Köp- & säljmarknad för sidans användare.
• Forum: Ett forum där det mesta mellan himmel och jord kan diskuteras.
• Inställningar: Möjlighet till att ändra lösenord, samt länkar till sidan där profileringssidan kan ändras.
De funktioner som finns tillgängliga innan inloggningen är:
• Registrering/aktivering av konto.
• Inloggning på sidan.
• Få ett nytt lösenord skickat till sig ifall användaren glömt sitt. Detta skickas till användarens e-post.
I forumet kan det dessutom finnas användare som är moderatorer i vissa ämnen. Detta innebär att användaren ifråga har möjlighet till att stänga trådar och ändra/ta bort olämpliga inlägg.
