Datateknik C, Examensarbete, 15 högskolepoäng
MEDDELANDEMOTOR FÖR ANONYM
KOMMUNIKATION
Anders Lindin
Dataingenjörsprogrammet, 180 högskolepoäng
Örebro vårterminen 2016
Examinator: Lars Karlsson
MESSAGE ENGINE FOR ANONYMOUS COMMUNICATION
Örebro universitet Örebro University
Institutionen för School of Science and Technology naturvetenskap och teknik SE-701 82 Örebro, Sweden
Sammanfattning
Denna rapport beskriver arbetsgången för att utreda och ta fram ett lösningsförslag för hur en meddelandemotor skul-le kunna impskul-lementeras i TeamTags delvis redan befintliga system. Små delar av impskul-lementeringen som infördes under projektet presenteras också.
Abstract
This report describes the workflow to investigate and develop a solution proposal for how a messaging engine could be implemented in TeamTags partly already implemented system. Small parts of the implementation that was introduced during the project is also presented.
Förord
Jag vill först tacka min huvudhandledare Kjell Mårdensjö som har ställt upp under hela projektets gång genom att ge stöd, svara på akademiska frågor och kommit med bra idéer angående projektet. Han har utan tvekan varit den lärare som haft störst inverkan och inspirerat mest under studietiden, så stort tack Kjell.
Jag vill också tacka Tomas Marcusson och Hans Niward som gav mig chansen att utföra arbetet på Osolo och har hjälpt till att besvara många frågor kring projektet när problem uppkommit.
Sist men inte minst vill jag tacka alla på Osolos kontor som bidragit till en bra stämning och arbetsmiljö. Tack för att ni också tog er tid att diskutera problem och lösningar.
Innehåll
1 Inledning 4 1.1 Bakgrund . . . 4 1.1.1 Osolo Consulting AB . . . 4 1.1.2 Projektets bakgrund . . . 4 1.2 Projekt . . . 4 1.2.1 Befintligt system . . . 4 1.2.2 Meddelandemotor . . . 5 1.3 Syfte . . . 6 1.4 Krav . . . 6 1.5 Fördjupning . . . 72 Metoder och verktyg 8 2.1 Metoder . . . 8 2.1.1 Användningsfall . . . 8 2.2 Verktyg . . . 8 2.2.1 Programvara . . . 8 2.2.2 Språk . . . 9 2.2.3 Programbibliotek . . . 9 2.3 Övriga resurser . . . 9 2.3.1 Informationssökning . . . 9 2.3.2 Dokumentation . . . 9 3 TeamTags 10 3.1 Tag . . . 10 3.2 Typer . . . 11 4 Anonym kommunikation 12 4.1 Anonymizers . . . 12 4.2 Onion routing . . . 13 4.3 Peer-to-peer (P2P) . . . 13 5 Genomförande 15 5.1 Planering . . . 15 5.2 Analys . . . 15 5.2.1 Kravanalys . . . 15 5.2.2 Användningsfallsanalys . . . 15 5.2.3 Databasanalys . . . 20 5.3 Design . . . 20 5.3.1 Lösningsförslag . . . 20 5.3.2 Implementation . . . 25 6 Resultat 26 6.1 Översikt . . . 26
6.2 Mappning av lösningsförslag mot användarfall . . . 26
6.3 Test av e-postimplementering . . . 27
7.2.1 Databas . . . 28
7.2.2 Attacker . . . 28
7.3 Reflektion kring eget lärande . . . 29
7.3.1 Kunskap och förståelse . . . 29
7.3.2 Färdighet och förmåga . . . 29
7.3.3 Värderingsförmåga och förhållningssätt . . . 29
Litteraturförteckning 29
A Användningsfall 31
1 Inledning
1.1 Bakgrund
1.1.1 Osolo Consulting AB
Osolo är ett konsultbolag med 20-talet anställda konsulter i en platt organisation med kontor i Stockholm och Örebro. Företaget arbetar främst inom webbutveckling, teknisk projektledning, systemarkitektur, programmering, test inom systemutvecklingsområdet och har också levererat flertalet Windows-applikationer.
1.1.2 Projektets bakgrund
När en samarbetspartner, Hans Niward var på resa till Australien såg han att det såldes lagbrickor ungefär på samma sätt som det i Sverige såldes Bingolotter eller salami, genom att lokala lag eller föreningar som behöver pengar gick runt och sålde dessa. Han tyckte det var en smart idé då föreningarna fick en chans att sälja en produkt som faktiskt många kunde har nytta av. Ofta med andra typer av produkter som föreningar och lag sålde så blev det närstående som tvingades att köpa för att få produkten såld. Han tog med konceptet hem till Sverige och ville i samarbete med Osolo ta fram en lösning och lansera produkten under namnet TeamTag.
Befintliga produkter som liknade lagbrickor i Sverige var nyckelbrickor som sattes på nyckelknippor som t ex SSFs Nyckelbricka, mySafetys Nyckelbricka eller Keybacks Polisbrickan. Deras metod kräver att upphittaren lämnar upp-hittad nyckelknippa med nyckelbricka i postlåda eller på polisstation. En långsam process där det tar lång tid innan ägaren kan få tillbaka sitt borttappade föremål.
En TeamTag var tänkt att fungera ungefär som en nyckelbricka, med skillnaden att upphittare också hade möjlighet att kontakta ägaren till det borttappade föremålet direkt. Detta gjorde det möjligt för ägaren att få tillbaka föremålet mycket snabbare än med befintliga metoder. Dessutom var tanken att TeamTags kunde användas till fler föremål än bara nyckelknippor som t ex mobiltelefon, resväskor, husdjur m.m.
1.2 Projekt
Uppgiften i projektet var att utreda, ta fram ett lösningsförslag och delvis implementera delar av en meddelandemotor för TeamTags redan påbörjade system. Meddelandemotorn skulle hantera inkommande och utgående meddelanden och hur dessa skickades och togs emot. Genom att inledningsvis utföra en kravanalys och användningsfallsanalys skulle ett lösningsförslag framställas för hur meddelandemotorn skulle kunna implementeras i det befintliga systemet.
1.2.1 Befintligt system
Vissa delar av systemet var redan påbörjat men inte färdigställda. Utöver meddelandemotorn saknades det stora de-lar för att systemet skulle kunna fungera korrekt. De dede-lar som i någon utsträckning redan var implementerade var följande:
TeamTag.DAL (Data Access Layer) Ett lager mellan applikation och databas för att kunna spara, hämta och utföra ändringar i databasen.
Administratörsverktyg Verktyg för att kunna administrera TeamTags, lägga till och ändra kampanjer, använda och ändra i databasen. Denna del utvecklades under projektets gång av en anställd på företaget.
TeamTag.Web En attrapp till webbsida utvecklad med hjälp av open source-systemet Umbraco som är ett inne-hållshanteringssystem för att hantera och publicera olika typer av informationsinnehåll på webbsidan.
Applikationer för mobiltelefoner Applikationer under utveckling för Android och iPhone fanns för att kunna test-köra delar av systemet.
1.2.2 Meddelandemotor
Meddelandemotorn skulle utredas och implementeras som ett eget projekt i det befintliga systemet. Den behövde kunna skicka ut meddelanden som SMS, e-post och även hantera inkommande meddelanden och översätta dessa till generiska meddelanden för TeamTag-systemet för lagring i databas. Den behövde också kunna generera nya medde-landen då tidsgräns för inaktiv användare nåtts och då skicka ut påminnelser eller meddemedde-landen på andra kommunika-tionskanaler. Meddelandemotorn skulle också kunna flagga händelser så administratörer kunde ta över ärendet. I figur 1.2.2.1 nedan går det att se hur kommunikationen mellan upphittare och ägare sker. Initierande av kommu-nikation görs av upphittaren som använder upphittade TeamTagens identifikationskod för att kontakta ägaren via TeamTags system och meddelandemotor. Några sekvensscheman för hur kommunikationen kan gå till kan ses i fi-gur 1.2.2.2, där schema (a) beskriver ett önskat scenario, (b) och (c) vad som sker när ägaren inte svarat innan timeout nåtts. Användningsfall för hur kommunikation skulle gå tillväga går att läsa i rapportens bilaga A.
Figur 1.2.2.2: Sekvensschema över olika kommunikationsvägar genom tänkta meddelandemotorn. (a) beskriver initie-randet av kommunikation mellan upphittaren och ägaren, (b) och (c) vad som sker då timeout nås.
1.3 Syfte
Syftet med projektet var att främst utreda och ta fram ett lösningsförslag och i viss mån implementera en meddelan-demotor och regler för hur motorn skulle fungera. Genom implementering av meddelanmeddelan-demotorn skulle upphittare, ägare, kontaktpersoner, säljare och administratörer från företaget kunna kommunicera med varandra över olika platt-formar så att tjänsten fungerade på önskvärt sätt.
1.4 Krav
Att utreda och utarbeta ett lösningsförslag för hur en meddelandemotor skulle kunna implementeras för att klara föl-jande:
• Kommunikation mellan systemets användare. • Anonymitet mellan användare.
• Ärendehantering.
• Hantera SMS-tjänst, SQLServer, SMTP-server. • Loggning av händelser i databasen.
• Meddelandemotorn ska vara separerat från det kompletta systemet. • Strukturering av databas för att hantera meddelanden.
1.5 Fördjupning
Som fördjupning till arbetsuppgiften valdes det att fördjupas i ämnet anonymitet. Detta för att TeamTag-systemet till viss del krävde att hålla användare av systemet anonyma gentemot varandra under konversationens gång. Fördjup-ningsdelen går att läsa i kapitel 4 av rapporten.
2 Metoder och verktyg
Detta kapitel går igenom metoder och verktyg som användes för att genomföra projektet. Det förklarar även varför dessa metoder och verktyg valdes och hur de fungerar.
2.1 Metoder
Eftersom handledare på företaget vill kunna stämma av löpande att projektet fortskred på rätt sätt innan implemente-ring och ändimplemente-ringar i det befintliga systemet infördes så utfördes arbetet i olika steg. Dessa steg går att läsa mer om i kapitel 5. För att framställa en analys och komma fram till ett lösningsförslag till projektet så skapades användnings-fall för att definiera hur systemet skulle hantera olika scenarion som skulle kunna inträffa.
2.1.1 Användningsfall
För kartläggning och uppsättning av funktionella krav av mjukvarusystem kan verktyg som användningsfall användas [1]. Användningsfall går ut på att identifiera vilka aktörerna till systemet är, förklara terminologin inom systemet och definiera hur systemet fungerar för olika scenarion. Användningsfall skapar ett slags kontrakt mellan intressenter och systemet för hur det ska bete sig [2]. Användningsfall kan också driva projektet framåt genom att hjälpa till i arbetet med identifiering och specificering av klasser och gränssnitt [1].
2.2 Verktyg
Val av verktyg som användes baserades på Osolos systemuppsättning och verktyg de använde. Osolo arbetar främst i Windowsmiljö med Microsoftprodukter för att utveckla och tillhandahålla tjänster och produkter. Därför var det naturligt att använda de verktyg som de redan använder för att fullfölja projektet.
För att skriva rapporten användes ordbehandlingsprogrammet LYX. Ett verktyg som är speciellt anpassat för att skriva vetenskapliga artiklar och passade därför bra att skriva rapporten i.
2.2.1 Programvara
Microsoft Visual Studio 2013 En avancerad programutvecklingsmiljö från Microsoft. Används för att utveckla program till Microsoft Windows och också webbsidor.
Microsoft SQL Server 2014 Microsofts databashanterare som använder sig av Transact-SQL (T-SQL) som fråge-språk och är av relationstyp.
Microsoft SQL Server 2014 Managment Studio Program som används för att konfigurera, behandla och admini-strera Microsoft SQL Server-databaser. Gör det lättare att få överblick över databaser genom grafiskt gränssnitt där användare av programmet kan bläddra i databasens struktur för att göra ändringar eller ställa frågor.
LYX Ordbehandlingsprogram som är öppen källkod och bygger på LATEX. Har stöd för referensdatabaser och är
användbar för att skriva vetenskapliga artiklar.
JabRef referensdatabaseditor och insticksprogram för bland annat ordbehandlingsprogrammet LYX. Används för att skapa bibliotek av referenser.
2.2.2 Språk
C# Ett objektorienterat programmeringsspråk utvecklat av Microsoft som stödjer många programmeringsparadig-mer. Språket är baserat på C++ men likar till en stor del programmeringsspråket Java.
Transact SQL (T-SQL) Påbyggnad på IBM:s språk SQL utvecklat för att ställa frågor till, ändra eller definiera databaser för att underlätta lagring, ändring och hämtning av information.
REST-kommandon Använder HTTP-standarden för att använda grundläggande kommandon och interagera med objekt och presentera dessa.
SMTP-kommandon Används för att skapa, skicka och hantera e-postmeddelanden.
2.2.3 Programbibliotek
ASP.NET (Active Server Pages) Ramverk för att bygga dynamiska webbsidor som bygger på öppen källkod och är utvecklat av Microsoft. Är baserat på .Net framwork och har fördelen att det är komponent- och eventbaserat. Microsoft Exchange Web Services (EWS) Klassbibliotek som tillhandahåller möjligheten att kommunicera med Microsoft Exchange server för hantering av e-post.
OpenPOP Ramverk för att hämtning av e-post från e-postserver som bygger på öppen källkod.
2.3 Övriga resurser
2.3.1 Informationssökning
För informationssökning efter vetenskapliga artiklar, böcker och annan information användes Örebro universitets bib-liotek och deras databaser. Databaser som användes var bland annat Scopus och SpringerLink. Sökningar utfördes också på Google för att hitta övrig information.
2.3.2 Dokumentation
För SMS-Gateway användes dokumentation från SMS-teknik om hur deras tjänst fungerar. SMS-teknik är ett företag som TeamTag vid tiden för projektet använde för att skicka och ta emot SMS.
Dokumentation för Mixrosoft Exchange Web Services för att kunna använde Microsofts ramverk för hämtning och skickande av e-post.
3 TeamTags
På varje TeamTag finns det en slumpmässig unikt genererad identifikationskod. Denna kod knyts till en ägare genom att de registrerar och aktiverar identifikationskoden. Genom att scanna QR-kod eller gå till TeamTags webbsida och fylla i identifikationskoden blir upphittaren dirigerad till en webbsida där kommunikation med ägaren kan utföras. Dessa sidor ser lite olika ut beroende på vilket typ av tag det berör. Brickorna för TeamTag kommer i resten av rap-porten också gå under benämningen tag eller bricka.
3.1 Tag
En tag är en bricka eller klistermärke med en QR-kod, identifikationskod och i vissa fall beroende på storlek på bric-kan också ett telefonnummer som illustreras i figur 3.1.0.1. Idén med TeamTags är att QR-koden eller identifikations-koden används för att ge upphittaren av föremål med en tag möjlighet att direkt kommunicera med ägaren. På så vis skulle föremålet kunna returneras till ägaren på ett snabbt och smidigt sätt.
LAG - 2X3KLRM +46 703 111 222 333
Figur 3.1.0.1: Figuren illustrerar informationen som finns på en TeamTag. Överst är en QR-kod, mellerst en identifi-kationskod och nederst ett telefonnummer.
QR-Kod En QR-kod (Quick Response) är en tvådimensionell streckkod som innehåller information. TeamTags QR-koder byggs upp av ett http prefix enligt följande: http://teamtag.se/tag/?id= +identifikationskod. De flesta mo-derna mobiltelefonerna kan i dagsläget scanna av dessa koder och ta del av informationen de innehåller.
Identifikationskod En identifikationskod är en unik kod som består av följande tre delar: • Prefix: Ett prefix som identifierar vilken förening eller företag som sålt brickan. • Kodvärde: En slumpgenererad unik kod.
• Checksumma: En checksumma baserad på prefix och kodvärdet. Det används för att kunna avgöra om identifi-kationskoden är giltig.
Telefonnummer Beroende på storlek på tagen kan det stå ett telefonnummer på den som går till TeamTags system. Med hjälp av telefonnumret skulle det vara möjligt att skicka SMS till ägaren genom att meddelandet tas emot av TeamTags systemet och sedan vidarebefordras till ägaren.
3.2 Typer
Det finns ett antal olika typer av tags med olika egenskaper som ämnar olika föremål. Dessa kan ses i figur 3.2.0.2 , listan nedan där också information vilken typ av sida man blir dirigerad till.
• Nycklar Tag man sätter nyckelknippa. Behöver hålla ägaren anonym från upphittaren så denna inte kan komma åt ägarens adress. Dirigering sker till en sida där upphittaren kan skriva meddelanden till ägaren.
• Husdjur En tag som sätts på husdjurets halsband. Dirigering sker till en sida där det finns information om hus-djuret och möjlighet att kommunicera ägaren.
• Nödfall Finns som plastkort som ägaren kan ha i plånboken och också som klistermärke. Dirigering sker till en sida där det finns information om ägarens medicinska uppgifter och kontaktmöjligheter.
• Resväska En bricka som kan sättas på en väska med hjälp av en liten vajer. Dirigering sker till sida med möj-lighet att kommunicera ägaren.
• Mobil En klisterlapp som kan klistras på mobiltelefon. Dirigering sker till sida med möjlighet att kommunicera ägaren.
• Övriga Det finns också några andra olika versioner av klistermärken och brickor i olika storlekar som kan fäs-tas på diverse föremål för att ge upphittaren möjlighet att kontakta ägaren på liknande sätt för de andra brickor-na.
4 Anonym kommunikation
Detta avsnitt behandlar anonym kommunikation, vad det innebär, några olika varianter och hur de går till väga för att hålla kommunicerade parter anonyma gentemot varandra och utomstående.
Säkerhet när det gäller datakommunikation behandlar ofta områden som integritet, tillgänglighet och att kommunika-tionen är konfidentiell mellan kommunicerande parter. Många tekniker har utvecklats för att skydda kommunikatio-nen så att dessa inte blir störda, avlyssnade eller att kommunicerande parter blir identifierade [3]. Vissa applikationer och tjänster kan kräva användaranonymitet för att skydda användaren från olika typer av attacker [4]. I TeamTags fall är användarinformation känslig när t ex en ägare till TeamTag har tappat bort sin nyckel. Om upphittaren kan komma åt information om vem ägaren är och dess adress kan upphittaren gå in i ägarens hus med nyckeln. Därför krävs det i vissa fall att ägaren och upphittare kan hållas anonyma gentemot varandra.
Enligt undersökning utförda av företaget kan fler tänka sig att returnera upphittade föremål om det finns en möjlig-het för dem att kunna vara anonyma, därför är det också viktigt att även kunna hålla upphittaren anonym gentemot ägaren.
Definition Anonymitet, ett stadium där identitet är okänd eller dold [4]. Att vara anonym är att inte tillkännage sin rätta identitet vilket tillåter anonyma aktörer att dölja sin relation till olika aktioner de utfört [3, 4].
Metoder Det finns många metoder för anonym kommunikation. Nedan följer några olika varianter som kan använ-das för olika ändamål när anonymitet önskas.
4.1 Anonymizers
Anonymitetstjänst som ger tillgång till internet på användarens vägnar [4]. Tjänsten är byggd för att skydda använ-darnas information så de inte ska kunna bli identifierade [4]. Detta genom att användare kopplar upp sig mot anony-mitetstjänstens proxyserver och låter datatrafiken gå genom denna [5]. Proxyservern agerar då som en sköld mellan användaren och internet [5]. När en användare vill utföra en aktion skickas den till proxyservern som utför aktionen åt användaren [5]. Utifrån ser det ut som att det är proxyservern som utför aktionen. När informationen kommer tillbaka till proxyserver dirigeras den tillbaka till användaren [4, 5]. I figur 4.1.0.1 illustrerar interaktionen mellan användare och internet med hjälp av en anonymitetstjänst med endast en kontaktpunkt.
Om endast en proxyserver används mellan användare och internet som i figur 4.1.0.1 kan information om användaren fångas upp genom att analysera in- och utgående nätverkstrafiken från proxyservern. Om en användare t ex försö-ker nå en webbsida via proxyservern och skickar ut 5 stycken förfrågningar till proxyservern och utgående trafik från proxyservern är 5 förfrågningar med en liten fördröjning så kan kopplingen göras vilken användare som skickade vad genom proxyservern. På samma sätt kan storlek på in- och utgående paket jämföras för att identifiera kopplingen mel-lan in- och utdata. För att förebygga detta kan utskicken från proxyservern slumpmässigt fördröjas en kortare stund för att kartläggningen ska bli svårare. Servern kan också skicka ut egna slumpmässiga förfrågningar till andra sidor för att försvåra ytterligare. Genom att använda fler proxyservrar som trafiken går genom mellan användaren och den slutgiltiga källan blir det också svårare att avlyssna och analysera trafiken för att göra kopplingen till vilken använda-re som skickar vilka förfrågningar. [5]
4.2 Onion routing
Infrastruktur för privat kommunikation över publika nätverk som t ex internet. Tillhandahåller anonymitet och är mot-ståndskraftig mot både nätverktrafiksanalys och avlyssnande [6]. Först och främst skyddar onion routing mot att kun-na länka ihop vilka två parter som kommunicerar och i andra hand skydda identiteterkun-na på de som kommunicerar från varandra [3]. Meddelanden skickade över nätverket är krypterade i lager som bara kan dekrypteras del för del genom att skickas genom kedjan av onion-routrar [3]. När ett meddelande ska skickas över nätverket så bestäms först vilka onion-routrar meddelandet ska skickas genom innan meddelandet ska nå slutdestinationen [7]. När kedjan av routrar meddelandet ska skickas genom är bestämd hämtas publika krypteringsnycklar för var och en av de utvalda routrarna som används för att kryptera meddelandet innan det skickas. Vid varje onion-router dekrypteras ett litet omslutande skikt av meddelandet som innehåller information om vilken nästa router i kedjan som meddelandet ska skickas till [7]. Sista skiktet tas om hand av sista routern i onion-nätverket och skickas därefter till mottagaren i klartext [6]. Eftersom varje skikt utanpå meddelandet endast innehåller krypterad information om nästa destination meddelandet ska till kan inte meddelandets slutgiltiga destination avläsas genom att avlyssna en onion-router i nätverket [3]. I fi-gur 4.2.0.2 illustreras hur ett krypterat meddelande skickas över onion-nätverket och på dess väg framåt dekrypteras del för del innan meddelandet kommer fram till mottagaren.
Figur 4.2.0.2: Illustration av meddelande skickat över nätverk med onion routing
När det är låg trafik över routrarna i nätverket kan attacker (timing attacks) som på liknande sätt som för anonymizers med en proxyserver användas. Genom att avlyssna in- och utgående trafik kan vägen från avsändare till mottagare följas så att information om dessa avslöjas [6].
4.3 Peer-to-peer (P2P)
Ett P2P-nät är ett nät som inte bygger på hierarkisk struktur. Med det menas att det inte bygger på klient-servermodellen utan består av noder som kan vara både server och klient samtidigt vilket illustreras i figur 4.3.0.3 nedan. Istället för att använda en eller flera centrala servrar som klienterna skickar information genom skickas informationen till andra användare som är kopplade till P2P-nätverket. [8]
Figur 4.3.0.3: Illustrerar skillnad mellan P2P (vänster) och klient-server (höger)
För att kunna dölja vem avsändare och mottagare är skickas information i paket av en bestämd storlek runt mellan fle-ra användare kopplade till nätverket. På så vis döljs den egentliga mottagaren eftersom det inte går att avgöfle-ra vilken den slutgiltiga destinationen är för paketet som skickas. Eftersom alla paket som skickas inom nätverket är av samma storlek försvåras också mappningen mellan in- och utgående paket. För att göra det ännu svårare att avlyssna nätver-ket kan skräppanätver-ket skickas ut till andra användare på slumpmässiga tider. [9]
Problem med system som detta är att paket skickas i onödan för att dölja avsändare och mottagare. Det ger upphov till ett långsammare nätverk eftersom mer information går genom kommunikationskanalen än nödvändigt. [8]
5 Genomförande
5.1 Planering
Första veckorna gick åt till planering, informationssökning och samtal med företaget för att förstå, få information kring arbetsuppgiften och diskutera olika tillvägagångssätt. Vi kom fram till att genom att dela upp projektet i olika steg med leverans efter varje. På så vis kunde handledare på företaget se att projektet var på väg i rätt riktning. De steg som projektet delades upp i var enligt följande.
• Kravanalys • Användningsfallanalys • Lösningsförslag • Implementation
5.2 Analys
5.2.1 Kravanalys
För att tjänsten skulle fungera på önskvärt sätt fanns det vissa krav meddelandemotorn skulle uppfylla. Dessa krav sattes upp redan i ett tidigt skede för att få en klar bild av vad implementeringen av meddelandemotorn i systemet faktiskt skulle behöva åstadkomma. De krav som sattes upp går läsa i tidigare avsnitt i rapporten under avsnitt 1.4.
5.2.2 Användningsfallsanalys
För att få klarhet över systemet och funktionella krav gjordes en utförlig användningsfallsanalys. För att förstå hur användningsfall var uppbyggda lästes exempel från andra projekt som det fanns tillgång till på företaget. Använd-ningsfallen användes för att ta fram olika scenarion för hur tjänsten kunde användas och hur systemet skulle hantera dessa.
Inledningsvis identifierades aktörerna som var tänkta att använda systemet. Utifrån identifieringen av aktörer och de-lar av systemet skapades en förkde-laringsdel över terminologier som användes inom användningsfallen. Detta för att läsare av användningsfallen lätt skulle kunna förstå och följa användningsfallens gång. Därefter kunde arbetet med att skriva användningsfall utföras utifrån aktörerna och vilka scenarion de kunde ställas inför. Användarfallen kan läsas i bilaga A.
5.2.2.1 Identifiering av aktörer
Genom att bland annat gå igenom delar av den befintliga databasen kunde flera aktörer till tjänsten identifieras enligt följande.
Ägare Person som köpt och registrerat tags.
Anhörig Person som ägaren angett som anhörig. Kontaktas om ägaren inte är anträffbar och har möjlighet att svara på meddelande i ägarens ställe.
Upphittare Person som hittat föremål med tag och försöker får kontakt med ägaren för att lämna tillbaka föremål. Administratör Person som underhåller systemet och hjälper ägare, anhöriga och upphittare att lösa problem. Säljare Person som säljer tags.
5.2.2.2 Terminologi
Utifrån identifieringen av aktörer och delar av systemet skapades en förklaringsdel över termer som användes inom användningsfallen. Detta för att läsare av användningsfallen lätt skulle kunna förstå och följa användningsfallens gång. Under arbetet med att skriva användningsfall utökades också terminologin allteftersom nya begrepp tillkom. 5.2.2.3 Användningsfall
Med de uppsatta aktörerna kunde scenarion framställas om hur aktörerna skulle kunna komma att agera och hur sy-stemet skulle reagera på dessa ageranden. Genom att ta hjälp av anställda på företaget och diskutera olika situationer kunde nya möjliga användningsfall också identifieras.
Med hjälp av användningsfallen kunde problemområden för systemet identifieras. Det som blev tydligt var t ex att systemet kunde få problem när en aktör i form av ägare, anhörig eller upphittare blir involverad i fler en ett pågående ärende och använder annat kommunikationssätt än TeamTags webb för att kommunicera. Problemen som identifiera-des under skrivandet av användningsfallen beskrivs tydligare under nästa sektion 5.2.2.4 i rapporten.
Genom att utreda och skriva användningsfall blev överblicken och tänk funktionalitet i projektet tydligare. Förståel-sen för redan implementerade delar av systemet och hur dessa fungerade ökade dessutom.
5.2.2.4 Problemområden
I detta avsnitt behandlas problemområden som identifierades under användningsfallsanalysen och lösningsalternativ för dessa.
Meddelandehistorik Integritetsproblem kunde uppstå när en upphittare hittat en tag som tidigare var med i ett ak-tivt ärende och scannar QR-koden. Eftersom tagens identifikationskod användes för autentisering vid inloggning på TeamTags webb så skulle den nya upphittaren kunna se tidigare kommunikation mellan ägare och föregående upphit-tare. Information som skulle kunde vara känslig.
Lösningar
1. Genom att stänga ärenden äldre än sju dagar skulle möjligheten att se information från föregående konversa-tion begränsas. Ett föremål med en tag kommer troligtvis inte tappas med så korta intervaller särskilt ofta men inga förutsättningar kan tas för att den inte skulle kunna hända. Påföljder blir att historik i ärenden som tagit lång tid kan försvinna från kommunikationen då ett nytt ärende måste sättas upp om tiden för senaste inkomna meddelandet överstigit sju dagar.
2. Att ge möjlighet för ägaren att stänga pågående ärenden när föremål returnerats. Om ägaren tappar bort föremål med tagen igen kommer ett nytt ärende då skapas och ingen historisk information fanns då för upphittaren att se.
3. Upphittaren får efter scanning skapa ett upphittarkonto med lösenord för att kunna logga in och se meddelande-historik.
Tredje alternativet skulle medföra bäst skydd när det gäller att dölja historik från föregående ärende. Problemet med-för istället att proceduren med-för en upphittare blir krångligare, något som kan med-försämra viljan att lämna tillbaka med-föremål. För att skydda tidigare upphittares och ägarens integritet borde istället lösningarna ett och två implementeras då detta ger bättre skydd än om bara en av lösningarna implementeras.
Autentisering TeamTag-systemets autentiseringsprocess skedde olika för olika typer av användare. För att upp-hittare och anhöriga inte skulle behöva skapa användarkonton och registrera sig krävdes annan typ av autentisering för dessa typer av användare. I tabell 5.1 visas vilka autentiseringsmetoder som var tänkta att finnas beroende av an-vändartyp. Om en upphittare har egna tags och vill använda SMS eller e-post för att kommunicera kommer systemet att få problem att skapa en ny upphittare eftersom den kan hitta användaren som en ägare i systemet. Detta skulle även gälla för anhöriga som är innehavare av tags.
Tabell 5.1: Tabellen visar olika alternativ för autentisering beroende på användartyp.
Lösningar Genom att införa en tabell i databasen för ärenden och koppla alla meddelanden som tillhör en kon-versation till denna. Med en kolumn i tabellen för att se om ärendet är aktivt eller inte skulle inkomna meddelanden kunna kopplas samman med användare som är med i ett aktivt ärende först och främst. Om meddelande kommer från avsändare som inte med i aktivt ärendet skapas ett nytt ärende om meddelandet innehåller en identifikationskod. Föl-jande scenarion finns nedan och flödesschema över dessa finns i figur 5.3.1.7.
1. Meddelande kommer in till systemet och innehåller identifikationskod till tag som inte stämmer överens med ärende avsändare redan är involverad i. Nytt ärende skapas och avsändaren blir i det ärendet upphittare. 2. Meddelande kommer in till systemet och avsändaren finns med i pågående ärende. Användaren autentiseras
med hjälp av inkommande meddelandet avsändaradress.
3. Meddelande kommer från upphittare innehållande en identifikationskod från en tag. Nytt ärende sätts upp och användaren som skickade meddelandet sätts upp som upphittare.
4. Meddelande utan identifikationskod från tag inkommer. Meddelandet kan inte kopplas till något pågående ären-de och inget nytt ärenären-de skapas. Svarsmedären-delanären-de skickas tillbaka om att fel uppstått.
På så sätt skulle autentiseringen i systemet behandla inkommande meddelanden och koppla till rätt användare när det skulle ske. Annat problem uppstår i punkt 1 då användaren blir involverad i fler än ett pågående ärende. Detta behandlas i problemområdet ”Flera pågående ärenden” nedan.
Flera pågående ärenden Om ägaren skulle vilja använda SMS eller e-post för att kommunicera med upphittare och nytt ärende kommer in till ägaren så kunde inte SMS och e-post längre kunna användas för kommunikation. Pro-blemet som uppstod berodde på autentiseringsmetoden när ett meddelande skulle komma in till TeamTagsystemet. Autentiseringen avgörs genom avsändarens telefonnummer eller e-postadress och kopplas till ett ärende. Eftersom numret skulle vara knutet till två pågående ärenden skulle inte systemet veta vilket ärende meddelandet är ämnat för vilket illustreras i figur 5.2.2.1 nedan.
Figur 5.2.2.1: Illustration över problem med länkning av SMS och e-post till aktörer med fler än ett pågående ärende Lösningar
1. En lösning skulle vara att användaren inleder SMS eller e-post med en identifikationsnyckel för kommunika-tionstråd när fler än ett ärende uppenbarade sig. Systemet kunde då identifiera vilket ärende meddelandet var ämnat för att skicka vidare meddelandet till det ärendets mottagare.
2. När systemet ser att en användare är involverad i mer än ett pågående ärende skickas meddelande ut på SMS eller e-post (beroende på vald kommunikationskanal) att kanalen i fråga inte längre kan användas utan hänvisar till TeamTags webbsida och inkluderar en länk dit för fortsatt kommunikation. På så vis skulle användaren kun-na gå in på webbsidan och välja vilket ärende och skicka meddelande. Nackdelar med denkun-na metod skulle vara då användaren saknar tillgång till internet och inte kan nå webbsidan.
På grund av användarvänlighet anses implementering två vara mindre krångligt för användare än att behöva hålla koll på och fylla i rätt identifikationsnyckel för att skicka meddelande till rätt ärende. Problem med avsaknad av internet skulle då vara bestående. Förhoppningsvis anser aktören att konversationen är tillräckligt viktig för att uppsöka plats där internetkoppling finns för att fullfölja ärendet.
Kommunikation mellan tre parter Men implementerad databas och struktur för systemet kunde endast kommu-nikation för ett ärende mellan upphittare och ägare kunna föras. Det innebar ett problem när en tredje part i detta fall anhörig till ägaren blir kontaktad. Detta eftersom det inte fanns kolumner för anhörig att skicka och ta emot medde-landen i meddelandetabellen i databasen.
Ett annat problem som kunde uppstå är när både ägare och anhörig har skickat meddelanden i ärendet och upphittaren svarar på ett av dessa. Det fanns ingen möjlighet att avgöra till vilket meddelande upphittaren svarade på. Problemet illustreras i sekvensdiagrammet i figur 5.2.2.2 (a).
a) , b)
Figur 5.2.2.2: Sekvensdiagram över trepartskommunikation. Lösningar
1. Räkna anhörig som ägaren. Genom att räkna en ägares anhörig som ägaren skulle systemet bara se den anhö-rigas kommunikationskanaler som extra kanaler för ägaren. På så vis skapas en konversation mellan två parter som egentligen innehåller fler aktörer.
2. Lägga till kolumner i meddelandetabellen för in- och utgående från anhörig. På så vis kunde meddelande spe-cifikt bli skickade till just anhörig och systemet skulle kunna hålla reda på att det är en anhörig som skickade eller tog emot meddelandet.
3. Skicka meddelandet från upphittare till både ägare och anhörig på deras respektive senaste använda kommuni-kationskanaler. På så vis får båda svar av upphittaren och kan läsa det istället för att det bara skulle skickas till den som skrev det senaste meddelandet.
Med en sammanslagning av lösning två och tre skulle systemet kunna hålla reda på och skicka meddelanden till samt-liga inblandade. Vad som också skulle vara viktigt är att bestämma hur systemet ska hantera meddelande från ägare och anhörig och om de skickas till varandra också. Annars skulle t ex upphittarens svar kunna vara osammanhäng-ande för den part som får svarsmeddelosammanhäng-andet som svaret egentligen inte var ämnat för. Med kommunikation som i se-kvensdiagram (b) i figur 5.2.2.2 kan detta undvikas.
Meddelandelängd En begränsning med SMS är att den endast kan innehålla 160 tecken. Om avsändare skriver meddelande med annan källa som t ex e-post som ska till en mottagare som SMS kan det bli problem om storleken överstiger vad som får plats i ett SMS. SMS-Gateway som användes vid tillfället då projektet utfördes kunde hantera meddelande som är upp till 6 SMS långa och skicka dessa som en samling.
Lösningar
1. Dela upp meddelandet i mindre fragment och skicka i omgångar till mottagaren. 2. Skicka meddelandet på annan kanal istället som kan hantera meddelandestorleken.
3. Dela upp meddelandet i två delar, en kortare del med inledning av meddelandet och länk till TeamTags webbsi-da för kommunikation där hela meddelandet kan läsas.
För att skicka SMS behöver TeamTag använda sig av tjänsten som tillhandahålls av TeamTag.Gateway. Varje SMS som skickas genom tjänsten kostar och därför skulle det bli mindre lönsamt att använda alternativ ett. Problem med alternativ två är att mottagaren förväntar sig svar på SMS om det är senaste kanalen mottagaren skickade från. Om meddelandet då skulle skickas över annan kanal kan det ta längre tid för mottagaren att upptäcka att svar inkommit vilket kan leda till att ärenden tar längre tid att klara upp. Därför anses att alternativ tre skulle vara det fördelaktigaste av de listade alternativen, det håller SMS-kostnaderna lägre och notifierar ändå mottagaren. Problemet med alternativ tre är om mottagaren inte har tillgång till internet och då endast läsa en liten del av meddelandet.
5.2.3 Databasanalys
Eftersom databasen inte var färdigimplementerad så saknades det delar för att få meddelandemotorn och systemet att fungera som tänkt. Genom att gå igenom databasen, läsa exempeldata som fanns inlagd och se på olika scenarion från användningfallsanalysen kunde problem med dess struktur upptäckas.
Det som upptäcktes var bland annat var meddelandetabellen där meddelande som behandlas av systemet sparades på ett rörig sätt. Detta på grund av att det fanns många olika sorters användartyper som kunde skicka och ta emot medde-landen som låg i separata tabeller i databasen. Referenserna till en viss kommunikationstråd sparades genom att refe-rera till föregående meddelande i trådens id. På så vis kunde konversationer sparas i databasen men på ett ineffektivt sätt. För att kunna ta ut en hel konversation måste en fråga till databasen för varje meddelande som finns i konversa-tionen ställas istället för att kunna hämta alla meddelanden från en konversation direkt.
Det fanns inget sätt att markera ett ärende som uppklarat och på så vis få svårigheter att dölja meddelandehistorik som beskrivs under problemområden i sektion 5.2.2.4.
Utifrån dessa problem utvecklades en ny databasarkitektur. Först ritades arkitekturen ut i form av ett EER-diagram (Enhanced Entity-Relationship) som går att se i figur 5.3.1.3 eftersom det ofta är ett bra sätt att börja [10]. Utifrån dessa ritades tabeller upp och hur strukturen för dessa skulle kunna se ut och finns att se i figur 5.3.1.6.
Delar av den nya arkitekturen implementerades för att testa hur databasen och Entity Framework i ASP.NET kunde hantera arv. Det visade sig fungera på tänkt sätt och kan läsas mer om i lösningsförslaget.
5.3 Design
5.3.1 Lösningsförslag
Det slutgiltiga lösningsförslaget för hur meddelandemotorn kunde implementeras och användas behandlas i detta av-snitt av rapporten. Det är utarbetad med hjälp av uppkomna problemområden från tidigare analyser.
5.3.1.1 Meddelandehantering
Ett av TeamTags mål var att ha ge användare av tjänsten möjlighet att använda många olika kommunikationskana-ler. Dels för att göra tjänsten så flexibel och användarvänlig som möjligt och dels så kunde användare av tjänsten då kontaktas även om tillgång till vissa av alternativen inte var tillgängliga. Meddelandemotorns uppgift var att kunna hantera samtliga kommunikationssätt och sköta överföringen mellan olika kanaler som t ex när ett meddelande kom in via SMS och skulle gå ut som e-post beroende på mottagarens preferens. I figur 5.3.1.1 visas förslag på hur syste-met skulle kunna byggas upp för hantera meddelandeflödet mellan de olika kanaler med inkommande och utgående meddelanden. Bilaga B innehåller data om hur meddelande kan komma in och skickas ut från systemet.
Figur 5.3.1.1: Illustration över meddelandeflöde i systemet.
E-post För att kunna skicka och ta emot e-post krävs att det finns en e-postserver. TeamTag använde sig redan utav en Microsoft Exchange server för detta med uppsatt konto och mailadress. Genom att skapa ett klassbibliotek (Team-Tag.Email) och sedan en klass vardera för att skicka (EmailSender) och ta emot (EmailRetreiver) så skulle meddelan-demotorn använda dessa för att skicka och ta emot meddelanden. För att få rätt struktur på meddelandena krävs också att de kunna översättas fram och tillbaka från e-postmeddelanden till generiska meddelanden för TeamTags system. Detta skulle bli EmailHandler-klassens uppgift som också sköter hämtning och utskick av meddelanden till och från meddelandemotorn med hjälp av TeamTag.Email.
Eftersom e-postservern som användes vid projektets utförande var en Microsoft Exchange e-postserver skulle det gå att använda Microsoft Exchange Web Services (EWS) som är ett klassbibliotek gjort av Microsoft. Detta gör det möj-ligt att hämta och skicka e-post med denna typ av e-postserver. Genom att schematiskt kalla på funktionen i Email-Retreiver med någon minuts mellanrum kunde e-post hämtas in till meddelandemotorn för bearbetning.
En mer generell lösning skulle vara att använda sig av OpenPOP. OpenPOP är ett tredjepartsprogrammet och ramverk för att hantera kommunikation och hämtning av e-post med POP3-protokollet och bygger på öppen källkod. Lös-ningen skulle då fungera för flera olika typer av e-postservrar och skulle bli flexiblare att använda. Nackdelar med denna metod är att OpenPOP stödjer inte lika många funktioner som EWS har för koppling med Microsoft Exchange. TeamTag behöver dock inte speciellt stor funktionalitet för att hämtning av e-post och därför borde OpenPOP vara det bättre alternativet då inte systemet blir låst att fungera med bara en typ av e-postserver.
För att inte e-post ska försvinna i hanteringen om fel skulle uppstå föreslås att hanteringen innefattar en slags säker-hetslösning för hämtade meddelanden från server. Funktion enligt följande flödesschema i figur 5.3.1.2 nedan fö-reslås.
SMS Tjänsten för SMS-Gateway köptes in av annat företag och alternativen för att ta emot meddelande var att in-komna SMS skickas till en inkorgen hos deras server som meddelandemotorn får hämta från, få de skickade till en e-postadress eller URL. Alternativet att få meddelandena skickade till samma e-e-postadress som användes för hantering av inkommande e-post skulle kunna användas för att förena hämtningen av både SMS och e-post. Fördelar gentemot att hämta från inkorg hos SMS-Gateway skulle vara att implementationen för att hämta e-post också skulle användas för att hämta SMS istället för att använda två liknande funktioner, en för SMS och en för e-post. Nackdelar med att hämta meddelande från e-postserver är att det körs schematiskt med en tids mellanrum för se om det inkommit nya meddelanden. Denna fördröjning försvinner om man låter SMS-Gateway skicka meddelandet direkt till TeamTags webb istället och behandlar meddelandet så fort det kommer in. Eftersom SMS är ett snabbare kommunikationssätt än e-post som kräver snabbare leveranstider anses det vara det bättre alternativet för att få ett snabbare meddelande-flöde mellan användarna.
SMS har begränsningar i hur många tecken ett meddelande kan innehålla. Det påverkar att meddelanden som skickas in och ut inte alltid kan skickas hela. Alternativet som föreslås är att meddelanden av längd som är längre än begräns-ningarna för SMS och ska skickas som SMS endast skickar inledningen av meddelandet med en länk till resterande delen som presenteras på TeamTags webbsida för kommunikation.
Webbmeddelanden Meddelanden som skulle visas på webben behövde inte skickas ut via meddelandemotorn ut-an hut-anterades av HTTP och REST-tjänster. När webbsidut-an i TeamTag.Web för kommunikation mellut-an ut-användarna i ärendet besöks så skickas meddelandena i from av HTML till mottagaren som kan läsa konversationen i en webblä-sare. Sidan är ämnad att visa meddelandena som var sparade i databasen och tillhörde konversationen med hjälp av TeamTag.DAL.
Webbmeddelanden som skulle kom in via webben gör så via webbformulär där användare skriver i meddelande och eventuella ändrar eller sparar användarinformation som e-postadress och/eller mobiltelefonnummer. Dessa meddelan-den skickas ska sedan skickas ut till mottagaren och sparas i databasens meddelandetabell. Genom att sätta maximal meddelandelängd till 160 tecken kan med säkerhet också webbmeddelandet omvandlas och skickas som SMS vilket föreslås.
5.3.1.2 Integritet
E-postsignaturer Signaturer i e-post visade sig vara en svaghet för systemet, det kunde leda till att en användare av tjänsten som ville vara anonym råkade avslöja sin identitet genom att de skickade e-post med signatur. I signaturen kunde uppgifter om användaren i fråga finnas vilket kunde leda till att mottagare fick information och kunde identifie-ra avsändaren. Eftersom olika progidentifie-ram använde olika metoder för att behandla signaturer på e-post så finns det ingen säker metod för att filtrera bort dessa från e-postmeddelanden. Mozillas e-postprogram Thunderbird använde t ex ”–” för att särskilja meddelandetext och signatur, där Microsofts Outlook endast använde en radbrytning. Eftersom han-teringen av signaturer inte var standardiserad så kunde inte TeamTag garantera att informationen i signaturerna inte kom med i meddelanden till mottagare. För att förebygga att känslig information som kunde finnas i signaturer inte skickades ut föreslås att TeamTag utfärdar en påminnelse och varning att ta bort signaturer för ärenden där det kan vara känsligt.
5.3.1.3 Databasstruktur
Databasen som redan var implementerad i projektet var inte färdig för att kunna användas av en meddelandemotor utan behövde modifieras eller byggas om för att få tjänsten att fungera som tänkt. Den alternativa arkitektur som togs fram till den implementerade databasen går att se i figur 5.3.1.3. De största förändringen gentemot redan implemente-rad databas är tillägget av basklass för användare (User) och en ny entitetstyp för ärenden (Case).
Figur 5.3.1.3: Illustration föreställer EER-diagram av föreslagen arkitektur för databasen
Användare Det fanns ett antalet olika typer av användare som var tänkt att använda systemet. Dessa användartyper var uppdelade i olika tabeller i databasen utan koppling till varandra. Det medförde att tabeller som t ex meddelande-tabeller (Messages) fick ett ganska rörigt utseende som illustreras i figur 5.3.1.4 där det finns två kolumner för varje typ av möjlig användare, en om användaren är mottagare och en om användaren är avsändare.
Figur 5.3.1.4: Illustration över delar av tabellen Messages i database.
För att få en mer överskådlig tabell föreslås en arvsstruktur med en generell superklass för användare (User) som and-ra typer av användare ärvde från i enlighet med EER-diagand-rammet i figur 5.3.1.3. Skillnaden i meddelandetabellen skulle bli att tabellen endast innehåller en kolumn vardera för avsändare (sender) och mottagare (receiver) som il-lustreras i figur 5.3.1.5. Med förslaget som presenterats så skulle även koden för att hitta sändare och mottagare bli lättare. Detta eftersom ett meddelande som sparas i databasen alltid kommer ha en avsändare och en mottagare och dessa två kolumner kommer alltid innehålla denna information till skillnad från tidigare där ett antal kolumner i tabel-len måste kontrolleras för att hitta dessa.
Figur 5.3.1.5: Illustration över delar av föreslagen meddelandetabell med generell superklass för användare. Efter testimplementering med arv i fristående projekt med Entity Framework i ASP.NET lyckades det med att göra slagning mot databasen och få fram vilken subklass av användare en specifik användare var. På vis behövs inte lag-ring av användartyp i superklassen för användare.
Ärende Implementerade databasen använde värdet i kolumn ThreadId som refererar tillbaka till ett meddelandes id (Id i ”Message”-tabellen) för att identifiera vilken konversation ett meddelande tillhörde. På så vis kunde olika konversationer särskiljas. Problem uppstår då ett ärende blir uppklarat eftersom det inte går att avaktivera ärendet då det inte finns någon kolumn i meddelandetabellen för detta. En lösning för detta skulle vara att lägga till en kolumn i meddelandetabellen för detta ändamål. Problemet med den lösningen är att alla meddelanden i konversationen som är bundna till varandra med ThreadId måste kontrolleras för att se om ett ärende är aktivt eller inte.
Alternativet som föreslås använder den nya entitetstypen ärende (Case). Den underlättas kopplingen mellan en tag och ett ärende. Genom att skapa tabellen för ärenden (Case) och lägga till en kolumn med ärende-id (CaseId) som il-lustreras i figur 5.3.1.6 SQL-frågorna till databasen förenklas. På så vis behöver bara meddelandenmotorn kontrollera meddelanden för aktiva ärenden och kan på ett lätt sätt avsluta ett ärende.
Figur 5.3.1.6: Illustrerar beroendet mellan tabellerna Message, Case och TeamTag (Tag). 5.3.1.4 Ärendehantering
Varje gång det kommer in ett meddelande med en korrekt tag-kod ska ett nytt ärende öppnas. Så länge inte meddelan-dets avsändaradress stämmer överens med ärende som är kopplad till samma tag-kod, då kopplas meddelandet till det ärendet.
Med införande av entiteten ärende (case) som en tabell i databasen skulle också lösningen för autentisering från pro-blembeskrivningsdelen i 5.2.2.4 lösas. Funktion för autentisering skulle då fungera enligt flödesdiagrammet i fi-gur 5.3.1.7 nedan.
Ytterligare funktionalitet för att avsluta uppklarade ärende skulle kunna införas när ägare skickar texten ”UPPKLA-RAT” i SMS med eller som ämnesrad i e-post. Detta för att i så hög mån som möjligt undvika att nya upphittare inte kommer åt meddelandehistorik från föregående fall som tagen varit inblandad i.
5.3.1.5 Loggning
För att kunna logga information om ärenden och dess meddelanden behövs den befintliga loggningsfunktionaliteten byggas ut. Nya loggningstyper behöver implementeras för bland annat meddelandemotorn och dess olika meddelan-detyper som t ex för att skicka SMS eller e-post. Detta för att hjälpa administratörer som ska kunna se när fel inträf-far.
Förslagsvis borde varje del likt befintliga loggningen som bygger på händleser (events) läggas till. Så för varje kom-munikationskanal bör det implementeras loggningsevent som aktiveras när meddelande skickas eller fel uppstår för dessa. Det borde förslagsvis också finnas reservlösning av loggning på fil då kontakt med databasen inte kan upprät-tas.
5.3.1.6 Anonymitet
Det finns två huvudanledningar till varför tjänsten behöver kunna hålla användare anonyma gentemot varandra. Ef-tersom att de går att få reda på en persons adress genom dennes identitet måste ägarens identitet hållas hemlig om ägaren skulle tappa bort t ex nycklar. Enligt undersökning från företaget så skulle fler upphittare kunna tänka sig att försöka kontakta ägaren för att lämna tillbaka föremål om de fanns möjlighet att vara anonym. På grund av dessa an-ledningar behöves någon slags anonymitetsfunktionalitet implementeras i projektet.
Genom att implementera tjänsten liknande en anonymizer där TeamTags server agerar som proxyservern skulle ano-nymitet mellan användare kunna säkerställas. När meddelande från avsändaren mottagits rensas användarinformation bort om så önskas innan meddelandet skickas vidare till den tilltänkta mottagaren av meddelandet. Vem som är mot-tagaren av meddelandet håller servern reda på genom att se över aktiva ärenden, vilka som är delaktiga i ärendet och deras kontaktinformation. På så vis vet inte avsändaren till vem meddelandet skickas och båda parter kan hållas ano-nyma gentemot varandra. Om ärende inte finns och ny identifikationskod från TeamTag kommer in skapas nytt ärende och ägaren och upphittaren läggs till i ärendet vilket beskrivs i avsnittet om ärendehantering ovan. På så vis kommer inte användarna få ta del av varandras uppgifter utan endast TeamTag-systemet vet om den informationen.
5.3.2 Implementation
E-posthantering För att meddelandemotorn skulle kunna skicka och ta emot meddelanden i form av e-post behöv-des tjänster för behöv-dessa implementeras. Därför skapabehöv-des ett klassbibliotek för e-post med namnet TeamTag.Email vars uppgift var att hämta e-post från e-postservern och skicka utgående meddelanden i form av e-post. Det skapades två klasser, en för att ta emot och en för att skicka e-post som illustreras i 5.3.1.1. Klassen EmailSender användes för att skicka ut e-postmeddelande via e-postserver. Den användes av meddelandemotorn vars klass EmailHandler som gjor-de om ett generiskt medgjor-delangjor-de lagrat i databasen till e-postformat och kallagjor-de på funktionaliteten för att skicka iväg meddelandet. EmailRetriever hade som uppgift att hämta och returnera olästa meddelanden från e-postserver och ra-dera dessa på e-postservern om hämtningen lyckades.
Eftersom e-postservern som användes var av typ Microsoft Exchange server kunde klassbiblioteket Microsoft Ex-change Web Services (EWS) användas. Detta gjorde det möjligt att hämta meddelanden från e-postservern när med-delandemotorn kördes, göra om dessa till generiska meddelanden för TeamTagsystemet med hjälp an EmailHandler och spara dessa i databasen.
Då användning av EWS kräver att e-postservern var av typ Microsoft Exchange Server så implementerades på inrå-dan från företaget också en mer generell lösning med tredjepartsprogrammet openPOP för att kunna utföra hämtning-ar från flera olika typer av e-postservrhämtning-ar. Email.Retreiver-klassen byggdes således om till att använda POP3-protokoll för att kommunicera och hämta meddelanden från e-postservern. För att försöka minimera risken för att e-post för-svinner på vägen implementerades hämtningen enligt flödesschemat i figur 5.3.1.2.
6 Resultat
6.1 Översikt
Efter utfört arbete fanns att tillstå ett dokument med användningsfall, ett lösningsförslag och även implementerade delar av meddelandemotor med avseende på e-posthantering.
Genom framställningen av användningsfall kunde delar av systemet analyserar och ett lösningsförslag för meddelan-demotorimplementation kunde utformas. Även andra delar av systemet kunde dra nytta av användningsfallen för att se hur systemet skulle reagera i olika scenarion som behandlade meddelandehantering och kommunikation som t ex hantering av registrering av användare som köpt tags.
Genom att använda lösningsförslaget var det tänkt att meddelandemotorn skulle kunna implementeras och fungera i enighet med användningsfallen. Delar av lösningsförslaget följdes för att implementera delar av meddelandehante-ringen och då främst för e-post.
Eftersom projektet i största del var ett utredningsarbete för hur en meddelandemotor kunde implementeras var det svårt att testa den slutgiltiga funktionaliteten. Istället fick lösningsförslaget analyseras mot de utarbetade använd-ningsfallen så att resultatet teoretiskt kunde säkerställas.
6.2 Mappning av lösningsförslag mot användarfall
Genom framställningen av användningsfallen i bilaga A kunde utifrån dessa lösningsförslaget utformas. För att ut-göra om lösningsförslaget faktiskt följde användningsfallen fick en mappning mellan dessa utföras. De delar av som kunde mappas mot användningsfall var följande.
Ärendehantering Hantering av ärenden beskrevs främst i användningsfallen 5.1-5.4 då upphittare av tag försökte initiera kontakt med ägare. Utifrån dessa fall kunde bland annat flödesschemat i figur 5.3.1.7 jämföras. Som synes följer lösningsförslaget om ärendehantering användningsfallen väl.
Det finns även vissa tillägg i ärendehanteringen som beskriver händelse då meddelande för redan pågående ärende el-ler felaktig identifikationskod inkom till systemet som stämde överens med de andra användningsfallen som hanterar kommunikation.
Meddelandehantering Alla användningsfall behandlar på ett eller annat sätt meddelandekommunikation eftersom den centrala delen i arbetet bestod av utredning av meddelandemotor. Därav var meddelandehantering en central roll både inom lösningsförslaget och användningsfallen.
Genomgång mellan lösningsförslaget med avseende på användningsfallen visade inga avvikelser för konflikt mellan dessa för samtliga meddelandetyper som kan ses i bilaga B. På så vis anses det påvisat att lösningsförslaget skulle kunna implementeras för att stödja funktionaliteten som önskades utifrån användningsfallen.
Databasstruktur Eftersom användningsfallen koncentrerade sig på att beskriva meddelandehantering fanns inte mycket att jämföra databashanteringen med. Med lösningsförslagets databasstruktur skulle funktionaliteten från an-vändningsfallen kunna styrkas eftersom det gick att starta nya ärenden, koppla samman dessa med meddelanden och användare som var delaktiga i dessa. På så sätt är det troligt att lösningsförslagets struktur skulle fungera för
ändamå-6.3 Test av e-postimplementering
Efter införandet av postimplementering utfördes tester på dess funktionalitet. Genom att det skickades post till e-postservern som sedan hämtades och togs hand om av TeamTag.Email kunde funktionaliteten säkerställas. De tester som utfördes var följande:
• Hårddiskutrymme: Systemet kunde avgöra om det fanns tillräckligt med utrymme för att hämta e-post. • Hämtning: E-post kunde hämtas från e-postservern.
• Filtrering: Endast e-post som inte hade med vissa ord i ämnesfältet kom igenom filtret.
• Lagring på fil: inkomna e-post sparades först på fil innan systemet raderade dessa från e-postservern. • Återskapa från fil: e-post sparade till fil kunde återskapas från fil och användas av systemet.
7 Diskussion
I detta kapitel diskuteras projektets resultat utifrån kravspecifikation och även utvecklingspotential.
7.1 Uppfyllande av projektets krav
Under projektets gång ändrades ändamålet att arbetet i projektet skulle bli mer av utredningskaraktär och framtagning av ett lösningsförslag istället för implementering. Bakgrunden till det var att de två ansvariga för projektet på företa-get hade olika föreställningar om projektets karaktär, där den ena var mer inriktad på att det skulle vara ett teoretiskt arbete och den andra på praktiskt. På så vis förändrades kraven från krav som skulle implementeras till krav som teo-retiskt skulle lösas i lösningsförslaget.
Krav som kan anses uppfyllda i och med framtagningen av lösningsförlaget följer nedan, detta eftersom de behandlas och finns lösningar för hur de skulle kunna implementeras.
• Kommunikation mellan systemets användare. • Anonymitet mellan användare.
• Ärendehantering.
• Hantera SMS-tjänst, SQLServer, SMTP-server. • Loggning av händelser i databasen.
• Meddelandemotorn ska vara separerat från det kompletta systemet. • Strukturering av databas för att hantera meddelanden.
De krav som skulle kunnat utredas mer skulle är bland annats loggningen av händelser i databasen och på fil. Ef-tersom det redan fanns ett sätt för att logga diverse andra delar av systemet lades inte mycket vikt vid om det utfördes på rätt sätt. Det hade också varit bra om mer tid funnits och fler delar från lösningsförslaget hade kunna implemente-rats och testats mer praktiskt.
7.2 Projektets utvecklingspotential
7.2.1 Databas
Befintlig databas var inte normaliserad i någon högre utsträckning så därav togs det fram ett nytt förslag för imple-mentering av databas som inte kom till användning under projektets gång. På grund av tidsbrist och den stora arbets-börda det skulle innebära att ändra databasens design så blev inte ändringen kring arv av utan de mindre ändringarna beskrivna i lösningsförslaget var lämpligare att införa som t ex att lägga till ärende-tabell. För att få en tydligare data-bas med färre null-värden skulle även de andra förslagen kunna implementeras.
7.2.2 Attacker
Anonym kommunikation Eftersom TeamTags anonyma kommunikation liknar metoden som anonymizers an-vänder så kan också TeamTags system utsättas för samma typer av attacker. Genom att fördela servertrafiken över ett
Brute-force attacker Känslig data som medicinska tillstånd och sjukdomar kan finnas om ägare med vissa typer av tags som t ex nödfallstag. Obehöriga som utför brute-force attacker skulle kunna få tillgång till dessa data genom att testa olika identifikationskoder på TeamTags webbplats tills den hittar giltiga identifikationskoder. Ett sätt att förhind-ra attackerna skulle vaförhind-ra inföförhind-randet av CAPTCHAS.
CAPTCHAS är ett program som används för att kunna skilja på människa och dator. Genom att visa en förvrängd serie av tecken som användaren ska skriva in för att förfrågan ska utföras kan brute-force attacker begränsas. [11]
7.3 Reflektion kring eget lärande
7.3.1 Kunskap och förståelse
Vid inledningen av projektet hade jag väldigt lite insyn i hur planeringen gick till och vilka metoder som användes för att utreda nya systemutvecklingsprojekt. Stora delar av projektet gick ut på att utreda möjliga scenarion tjänsten skul-le kunna utsättas för och utifrån dessa hitta probskul-lemområden och lösa dessa innan impskul-lementationens början. Efter att ha arbetat med utredningsprojektet har jag kommit till insikt att något som kan verka simpelt snabbt kan växa till ett mycket komplext problem på grund av små begränsningar i delar av tjänsten. Lärdom om att det kan vara oerhört viktigt att göra en utförlig analys av projektet innan implementationen startar, dels för att slippa behöva göra om im-plementationen för att något inte fungerat som man tänkt sig och dels för att få klarhet i hur projektet faktiskt är tänkt att fungera.
7.3.2 Färdighet och förmåga
En av de största utmaningarna var att göra användningsfall som täckte av så många scenarion som möjligt. Eftersom erfarenheten kring användningsfall var begränsad innan projektet var det svårt att komma igång och skapa en bra struktur. Efterhand när det blev mer naturligt gav det väldigt mycket för förståelsen av projektet i helhet då de gav upphov till många frågor till hur systemet var tvunget att fungera. Detsamma gäller för framtagning av ett lösnings-förslag. Jag är tacksam för att jag haft möjligheten att lära och använda mig av dessa metoder för att utreda funktiona-litet i ett system, Jag tror jag kommer ha mycket nytta av det även i framtiden.
Det var också intressant och nyttigt att lära sig mer om området kring anonymitet och olika metoder för att bibehålla den och vilka svårigheter varje metod ställs inför.
7.3.3 Värderingsförmåga och förhållningssätt
Det var viktigt att gå in för projektet som om det vore ett riktigt jobb. Det innebar att vara på företagets kontor samma tider och utföra arbetet med de anställda på företaget.
Arbetet som till största del var att utarbeta ett lösningsförslag gjordes enligt företagets vilja att leverera delar av pro-jektet i steg och med vissa metoder som följdes.
Mycket vikt lades på att lägga fram användarfall som såg professionella ut eftersom det var en viktig del av utred-ningsarbetet. Det gav också en blick från potentiella kunder och upphittares perspektiv och hur dessa kunde agera. Genom att diskutera med medarbetare kunde många andra scenarion också komma fram och lösas.
Litteraturförteckning
[1] G. Booch, I. Jacobson, och J. Rumbaugh, The unified modeling language user guide. Addison Wesley Long-man Inc, 1999, ISBN: 0321267974.
[2] A. Cockburn, Writing Effective Use Cases, ser. Crystal series for software development. Pearson Education, 2000, ISBN: 0201702258.
[3] G. Danezis, “Better anonymous communications,” Ph.D. dissertation, University of Cambridge, January 2004. [4] R. Shirey. (2007, August) Internet security glossary. Internet. Network Working Group. Hämtad 2016-05-11.
URL: https://tools.ietf.org/html/rfc4949
[5] W. Stewart. (2007) How anonymizers work. Internet. Besökt 2016-05-11. URL: http://www.livinginternet.com/i/ is_anon_work.htm
[6] D. Goldschlag, M. Reed, och P. Syverson, Hiding routing information, ser. Lecture Notes in Computer Science. Springer Berlin Heidelberg, Maj 1996, vol. 1174, ISBN: 978-3-540-61996-3.
[7] G. Fanti och P. Viswanath, “Algorithmic advances in anonymous communication over networks,” 2016 Annual Conference on Information Science and Systems (CISS), pp. 133–138, Mars 2016.
[8] V. Scarlata, B. Levine, och C. Shields, “Responder anonymity and anonymous peer-to-peer file sharing,” in Network Protocols, 2001. Ninth International Conference on. IEEE, November 2001, pp. 272–280, ISBN: 0-7695-1429-4.
[9] L. Xiao, Z. Xu, och X. Zhang, “Mutual anonymity protocols for hybrid peer-to-peer systems,” in Proceedings of the 23rd International Conference on Distributed Computing Systems. IEEE Computer Society, Maj 2003, pp. 68–75, ISBN: 0-7695-1920-2.
[10] T. Padron-McCarthy och T. Rich, Databasteknik. Studentlitteratur AB, Lund, 2013, ISBN: 978-91-44-04449-1. [11] C. Pope och K. Kaur, “Is it human or computer? defending e-commerce with captchas,” IT Professional, vol. 7,
A Användningsfall
Användningsfall - TeamTag
Anders Lindin
Innehåll
1 Begrepp att använda 3
2 TeamTagSystem 6
2.1 Webb . . . 6 2.1.1 Umbraco . . . 6 2.2 Data Access Layer (DAL) . . . 6 2.3 Base (Business Logic) . . . 6 2.4 Message Engine . . . 6 2.5 Library . . . 6 2.6 Admin . . . 6 2.7 Databas . . . 7
3 Ägare 9
3.1 Ägare aktiverar TeamTag-låda . . . 9 3.2 Ägare svarar på inkommet SMS . . . 10 3.3 Ägare använder SMS för att svara på meddelande . . . 10 3.4 Ägare använder TeamTag Webb för att svara på meddelande . . . 10 3.5 Ägare använder e-post för att svara på meddelande . . . 11 3.6 Ägare får meddelande på e-post och har inte tillgång till internet . . . 11 3.7 Ägare har fått tillbaka borttappat föremål och vill ändra ärendet till uppklarat . . . 11 3.8 Ägare är ej anträffbar . . . 12 3.9 Ägare blir inblandad i fler än ett öppet ärende . . . 13
4 Anhörig 14
4.1 Anhörig kontaktas när ägare är oanträffbar . . . 14 4.2 Anhörig använder TeamTag Webb för att svara på meddelande . . . 15 4.3 Anhörig kontaktas, är redan involverad i ett ärende och saknar tillgång till internet . . . 15 4.4 Anhörig blir inblandad i fler än ett öppet ärende . . . 15
5 Upphittare 17
5.1 Upphittare skickar SMS med TeamTagens identifikationskod . . . 17 5.2 Upphittare scannar QR-kod på TeamTag . . . 17 5.3 Upphittare fyller i identifikationskod på TeamTag Webb . . . 18 5.4 Upphittare ringer TeamTags kundtjänst. . . 18 5.5 Upphittare fyller i kontaktuppgifter på TeamTag Webb ”finder tag info” . . . 19 5.6 Upphittare fyller i kontaktuppgifter på TeamTag Webb ”finder tag info pets” . . . 19 5.7 Upphittare fyller i kontaktuppgifter på TeamTag Webb ”finder tag info emergency” . . . 20 5.8 Upphittare fyller i kontaktuppgifter på TeamTag Webb ”found not active” . . . 20 5.9 Upphittare skriver meddelande till ägare på TeamTag Webb ”finder conversation” . . . 21 5.10 Upphittare försöker kontakta ägare till en TeamTag som inte är aktiverad . . . 21 5.11 Upphittare blir inblandad i fler än ett öppet ärende . . . 22 5.12 Upphittare använder TeamTag Webb för att svara på meddelande . . . 22
6 TeamTagSystem 23
6.1 TeamTagSystem skickar meddelande till mottagare . . . 23 6.2 TeamTagSystem underrättar ägare om förlängning av TeamTag . . . 23 6.3 TeamTagSystem tar hand om inkommande meddelande via TeamTag Webb . . . 24
6.6 TeamTagSystem flaggar händelsen och administratör tar över ärendet . . . 24 6.7 TeamTagSystem får in meddelande om TeamTag som tidigare varit med i ärende . . . 25 6.8 TeamTagSystem ska vidarebefordra meddelande som är för långt för rymmas i ett SMS . . . 25
1 Begrepp att använda
Ägandebevis
TagBox.BoxCode
Består av koder i form av QR-kod och URL knutna till ägarens konto på teamtag.se där ägaren kan administrera sina TeamTags och ägarinformation.
Ägare
Owner
Person som och har TeamTags och ägandebevis för dessa.
Anhörig
OwnerContact
Person som är anhörig till ägaren och är med på ägarens anhöriglista. Kan komma att kontaktas om inte ägaren svarat på meddelande inom en viss tid.
Upphittare
Finder
Person som hittat en borttappat föremål som har en TeamTag.
Administratör
Administrator
Person som jobbar som systemansvarig på TeamTag och har behörighet att utföra ändringar i systemet. Kan hjälpa till med att försöka föra kommunikation med ägare eller upphittare om något fel inträffat eller någon av dessa varit onåbar.
Kundtjänst
Administratörer som tar hand om inkommande telefonsamtal och hjälper kunder med ärenden.
Säljare
TeamMember
Person i lag eller förening som säljer TeamTags.
Kontaktperson
TeamMember
Mottagare
Ägare, upphittare, anhörig, administratör eller säljare som ett meddelande är ämnat för.
Avsändare
Ägare, upphittare, anhörig, administratör eller säljare som skickar ett meddelande.
TeamTag-låda
TeamBox
Låda innehållande ägandebevis och TeamTags.
TeamTag
Tag
Bricka eller klistermärke med unik identifikationskod som kan sättas på föremål som till exempel nyckelknippa eller mobiltelefon.
Alla TeamTags har en ItemCode (identifikationskod), en QR-kod som innehåller dels URL till teamtag.se och dels ItemCode. Vissa TeamTags (beroende på dess storlek) har också ett telefonnummer till SMS-Gateway.
QR-kod
En QR-kod (Quick Response) är en tvådimensionell streckkod som innehåller information. TeamTags QR-koder byggs upp av ett http prefix enlig följande: http://teamtag.se/tag/?id= +identifikationskod. De flesta moderna mobiltelefo-nerna kan i dagsläget scanna av dessa koder och ta del av informationen de innehåller.
Identifikationskod
ItemCode
En unik kod som står på en TeamTag och som består av följande tre delar: Prefix: Ett prefix som identifierar vilken förening eller företag som sålt brickan. CodeValue: En slumpgenererad unik kod.
Checksum: En checksumma baserad på koden Prefix och CodeValue som används för att kunna avgöra om identi-fikationskoden är giltig.
URL
URL (Uniform Resource Locator), på svenska kallat webbadress, är den teckensträng som identifierar en viss resurs på nätet, till exempel en webbsida: http://teamtag.se/
SMS-Gateway
SMS-tjänst som TeamTagSystem använder för att kunna ta emot och skicka SMS.
• Inkommande SMS ska enligt planeringen komma in till en webbsida i TeamTagSystem via push-anrop. • Utgående ska med ett push-anrop i TeamTagSystem skickas till SMS-Gateway.
TeamTagSystem
System som möjliggör tjänsten för TeamTags och sköter datalagring och möjliggör meddelandehantering för kommu-nikation mellan användare.
Försäljningsapp
Applikation till mobiltelefon som säljare kan använda för att sälja och hjälpa till med aktiveringen av TeamTag-lådor. Kan också användas för att skicka meddelande mellan säljare och också påminna nya kunder att aktivera sina Team-Tags.
