ASP.NET Core 2.0 Web-API Ubuntu 16.04 -palvelimella

(1)

ASP.NET Core 2.0 Web-API Ubuntu 16.04 -palvelimella

Ammattikorkeakoulututkinnon opinnäytetyö Visamäki, Tietojenkäsittelyn koulutusohjelma

Syksy 2018 Jussi Porrassalmi

(2)

TIIVISTELMÄ

Tradenomi, Tietojenkäsittelyn koulutusohjelma Visamäki, Hämeenlinna

Tekijä Jussi Porrassalmi Vuosi 2018

Työn nimi ASP.NET Core 2.0 Web-API Ubuntu 16.04 palvelimella Työn ohjaaja /t Erkki Laine

TIIVISTELMÄ

Opinnäytetyön tavoitteena oli toteuttaa yksinkertainen, autentikoinnin sisältävä web-API Ubuntu-palvelimelle käyttäen ASP.NET Corea ke- hittämiseen. Tutkimuskysymykset joihin työssä keskityttiin, olivat mikä on ASP.NET Core, miten suojata web-api ja miten ASP.NET web-API otetaan käyttöön Ubuntu palvelimella.

Tutkimuskysymyksiin haettiin vastauksia tutustumalla monipuolisesti dokumentaatioihin ja muihin verkkolähteisiin sekä käytännön kokei- lulla. Työ on jaettu teoria- ja käytännön osuuksiin. Teoriaosassa kerro- taan käytännön osuudessa käytettävistä tekniikoista yleisesti ja käy- tännön osuudessa käydään läpi API:n toteutusta ja käyttöönottoa näyt- tämällä koodiesimerkkejä ja kuvakaappauksia.

Työtä aloittaessa työn tekijällä ei ollut kokemusta web-kehityksestä tai Linux-palvelimen hallinnasta. Opinnäytetyölle asetetut tavoitteet täy- tettiin ja työssä tutustuttiin ASP.NET Coren ominaisuuksiin web-apin toteutukseen käytettävien ominaisuuksien näkökulmasta ja niitä hyö- dyntämällä toteutettiin toimiva yksinkertainen web-API Linux Ubuntu 16.04 palvelimelle Monista materiaaleista kävi ilmi, että jo olemassa olevaa ASP.NET 4.x sovellusta ei välttämättä kannata lähteä muuttamaan käyttämään ASP.NET Corea, mutta soveltuu uusiin projekteihin hyvin ASP.NET Core version 2.x myötä.

Avainsanat API, ASP.NET, backend, REST, web-kehitys

Sivut 26 sivua

(3)

ABSTRACT

Degree Programme in Business Information Technology Visamäki, Hämeenlinna

Author Jussi Porrassalmi Year 2018

Subject ASP.NET Core 2.0 Web-API on Ubuntu 16.04 server Supervisors Erkki Laine

ABSTRACT

The aim of this thesis was to develop a simple web API with authentication using ASP.NET Core and deploy it to Ubuntu server. The main research problems in this thesis were, what is ASP.NET Core, how to protect web API and how ASP.NET web API is deployed to Ubuntu server.

The methods to solve the research problems were studying various documentations, other online resources and hands on testing of the techniques. The thesis is divided into theory and practical parts. The theoretical part concentrates on the techniques used in the practical parts and the practical part discusses how the API was developed and deployed including screenshots and code examples.

The author of the thesis had no previous experience with web development or how to control Linux server. Goals set for the thesis were met and simple and working web API with authentication was developed using the technologies that the theory part consists of, and the API was deployed to Linux Ubuntu 16.04 server.

The thesis was interesting and educational for the author and the code and skills learned while producing this thesis can be used in future for own or work-related projects. Many of the studied materials stated that you probably should not upgrade existing ASP.NET 4.x applications to use ASP.NET Core but for new projects ASP.NET Core 2.x is good op- tion.

Keywords API, ASP.NET, backend, REST, web-development Pages 26 pages

(4)

SISÄLLYS

1 JOHDANTO ... 1

2 TEKNIIKAT ... 2

2.1 Kehitysalusta .NET Core ... 2

2.2 Web-kehitysalusta ASP.NET Core... 3

2.2.1 ASP.NET Core MVC ... 3

2.2.2 Dependency Injection ASP.NET Coressa ... 4

2.2.3 Kestrel ... 5

2.3 Entity Framework Core ... 5

2.4 ASP.NET Core kehitysympäristöt ja API päätepisteiden testaustyökalut ... 6

2.5 Representational State Transfer (REST) API ... 7

2.6 REST APIn suojaaminen ... 8

2.6.1 Autentikointi ... 8

2.6.2 Autorisointi ... 9

2.6.3 Muita huomioon otettavia asioita ... 10

2.7 JSON WEB TOKEN (JWT) ... 10

3 KÄYTÄNTÖ ... 12

3.1 Projektin luonti ... 12

3.2 Riippuvuudet ... 13

3.3 Modelit ja tiedonsiirto-oliot ... 14

3.4 Datacontext ja repositoryt ... 15

3.5 Kontrollerit ... 16

3.6 Startup.cs ... 18

3.7 Linux-palvelimen valmistelut ja API käyttöönotto ... 19

3.8 Sovelluksen siirtäminen palvelimelle ... 22

3.9 API-päätepisteiden testaaminen ... 22

4 YHTEENVETO ... 24

LÄHTEET ... 25

(5)

SANASTO

API: Application programming interface eli ohjelmointirajapinta. Mää- ritelmä, jolla sovellukset kommunikoivat keskenään.

DI: Dependency Injection on palveluiden injektoimista muiden luokkien käytettäväksi

EF: Entity Framework on ORM (Object Relational Mapper), jonka avulla tietokannan kanssa voi toimia .NET olioilla.

HTTP: Hypertext Transfer Protocol.

JSON: JavaScript Object Notation on avoimen stantardin tiedosto- muoto, jonka avulla välitetään tietoa.

JWT: JSON web tokens on turvallinen tapa esittää ja siirtää tietoa, kuten käyttäjädataa kahden osapuolen välillä JSON objektina.

NuGet: Microsoftin paketinhallintajärjestelmä .NET-ympäristölle.

REST: Representational State Transfer on http-protokollaan pohjau- tuva arkkitehtuurimalli, jolla toteutetaan ohjelmointirajapintoja.

Tiedonsiirto-olio: Data Transfer Object (DTO) on olio jota käytetään siirtämään tietoa palveluiden välillä tai, kun palautetaan käyttäjälle tietoa, mutta ei haluta palauttaa kaikkia modelin sisältämiä kenttiä.

(6)

1 JOHDANTO

Opinnäytetyön teoriaosassa tutustutaan ASP.NET Core ympäristöön sekä muihin tekniikoihin, joita web APIn käytännön osuuden toteuttamiseen käytetään. ASP.NET on jo kohtuullisen pitkäikäinen ympäristö, ja Coren myötä alustariippumattomuus ja modulaarisuus lisää mahdol- lisuuksia käyttää sitä kehitykseen isommissa ja pienemmissä projekteissa.

Käytännön osuudessa toteutettiin yksinkertainen API, jonka toimintoi- hin kuuluu rekisteröityminen, sekä päätepisteiden autorisointi token- pohjaisesti JWT-tokenilla. Valmis toteutus otettiin käyttöön Ubuntu palvelimella.

Työn aiheeseen päädyin halusta kehittää omaa osaamista web-ohjel- moinnin osalta ja toivon myös työllistyväni web-tekniikoiden parissa tulevaisuudessa. Suurin osa aiemmasta ohjelmointikokemuksesta suuntautui työpöytäsovelluksiin ja pienempiin työkaluihin.

Työn tavoitteena on selvittää, mikä ASP.NET Core on ja kuinka sillä toteutetaan yksinkertainen web-API Linux-palvelimelle ja tämän myötä lisätä omaa tietoa ja taitoa web- ja mobiilisovellusten taustapalvelujen toteuttamisesta sekä palvelimen hallintaan liittyvissä asioissa.

Tutkimuskysymykset:

 Mikä ASP.NET CORE on?

 Miten suojata API?

 Miten ASP.NET CORE API otetaan käyttöön Ubuntu-palvelimella?

(7)

2 TEKNIIKAT

Luvussa tutustutaan tekniikoihin ja teknologioihin, joita hyödynnetään käytännön osuudessa.

2.1 Kehitysalusta .NET Core

.NET Core on Microsoftin ja .NET-yhteisön ylläpitämä yleiskäyttöinen ja avoimen lähdekoodin (MIT-lisenssi) alustariippumaton kehitysalusta, jonka avulla voi kehittää konsoli ja ASP.NET web -sovelluksia sekä pilvi- palveluita Windows, macOS ja linux -alustoille. .NET Core lisättiin .NET Foundationiin vuonna 2014 ja sen versio 1.0 julkaistiin kesäkuussa 2016. (Microsoft 2016a.)

.NET Coreen kuuluu:

 .NET runtime (CoreCLR ja peruskirjasto mscorlib), joka sisältää ros- kankerääjän, JIT-kääntäjän, .NET tietotyypit ja muita matalan tason luokkia

 CoreFX, joka on kokoelma ohjelmistokehys-kirjastoja, jotka sisältävät luokat tiedostojärjestelmille, kokoelmille, konsolille, ja monille muille perusominaisuuksille

 .NET CLI (Command Line Interface) työkalut, joita käytetään .NET Core sovellusten kääntämiseen, suorittamiseen, testaamiseen ja NuGet pakettien hallintaan

 .NET Compiler Platform (Roslyn-kääntäjä)

 “dotnet”- app host, joka valitsee ja suorittaa sovelluksen ajoympäris- tön. (Microsoft 2016a.)

.NET Core ja ASP.NET Core ovat alustoja, jotka koostuvat NuGet-pake- teista. .NET Coren versiossa 1.0 lähes kaikki ominaisuudet tarjottiin pie- ninä .NET base class librarysta pilkottuina pieneen määrään ominaisuuksia keskittyneinä NuGet-paketteina, mikä mahdollisti sen, että sovellus oli erittäin modulaarinen ja sisälsi vain tarvittavat paketit. Pie- nien pakettien myötä muodostui kuitenkin käytettävyys- ja yhteenso- pivuusongelmia, kun jokaiseen projektiin täytyi lisätä kaikki tarvittavat paketit erikseen ja oikeiden pakettien löytäminen oli haastavaa. Versi- osta 2.0 alkaen on käytettävissä järjestelmänlaajuiset metapaketit, joihin voi viitata projektista. Kun sovelluksen kohdistaa käyttämään .NET Core App 2.0:n, niin sovellus viittaa automaattisesti .NET Core App 2.0 metapakettiin, jolloin kaikki .NET Core 2.0 ominaisuudet ovat käytettä- vissä, mutta vain viitatut ja käytetyt paketit käännetään. (Strahl 2018.) Nuget-metapaketit ovat kokoelma Nuget-paketteja, joita käytetään usein yhdessä. Metapakettien etuna on se, että ne ovat versioituja ja testattu toimivaksi yhdessä käytettävänä. (Microsoft 2016b.)

(8)

2.2 Web-kehitysalusta ASP.NET Core

ASP.NET Core on avoimeen lähdekoodiin (Apache Licence 2.0) perustuva alustariippumaton web-ohjelmistokehys, jota käyttämällä voi ke- hittää web tai IoT -sovelluksia ja mobiilitaustapalveluita. ASP.NET Core -sovelluksia voidaan kehittää, kääntää ja suorittaa MacOS, Linux ja Windows -ympäristöissä käyttämällä .NET Corea tai käyttämällä täyttä .NET Frameworkia Windows-ympäristössä. ASP.NET Core on aikaisem- piin ASP.NET versioihin nähden kirjoitettu suurilta osin uudestaan ja on modulaarisempi. (Fritz 2016.)

Microsoft.AspNetCore.All on NuGet –metapaketti ASP.NET Corelle, joka sisältää kaikki tuetut ASP.NET Core tiimin tekemät paketit, kaikki tuetut Entity Framework Core paketit ja edellä mainittujen käyttämät sisäiset ja kolmansien osapuolien riippuvuudet. (Microsoft 2017a.)

2.2.1 ASP.NET Core MVC

ASP.NET Core MVC ohjelmointikehyksen avulla voidaan tuottaa web- sovellus tai –API käyttäen Model-View-Controller –suunnittelumallia, joka erottaa sovellukset kolmeen ryhmään Model (malli), View (nä- kymä) ja Controller (kontrolleri), joista näkymää ei käytetä APIin.

ASP.NET Core MVC kehykseen kuuluu:

Routing: URL-mappauskomponentti ohjaa sisään tulevat pyynnöt oi- kealle kontrollerille ja sen toimintametodille riippumatta siitä, miten tiedostot on palvelimelle sijoitettu, käyttämällä globaalisti määritet- tyjä URL-formaatteja tai kontrolleritasolla [Route]-attribuuteilla.

Model binding: muuttaa pyyntöjen datan olioiksi, joita kontrolleri osaa käsitellä.

Model validation: sen avulla modelien propertyille voidaan antaa va- lidointiattribuutit, joiden avulla voidaan määrittää esimerkiksi, onko joku ominaisuus pakollinen tai onko merkkijono email-osoite tai onko sillä minimi/maksimipituus. Nämä ominaisuudet voidaan tarkistaa kontrollerin toimintametodissa ja palauttaa virhe, jos tiedot ovat puutteelliset tai väärät.

Dependency Injection: Palvelut rekisteröidään ensin ja kontrolle- rit/luokat voivat pyytää tarvitsemansa palvelut konstruktorissa.

Filters: Kontrollereille voidaan määrittää suodattimia, joilla suorite- taan ennalta määritettyjä tehtäviä ennen tai jälkeen toimintametodin suorittamista ja niitä voidaan käyttää kontrolleritasolla tai toiminta- metoditasolla. Sovelluskehykseen kuuluu useita suodattimia, kuten [Authorize]-attribuutilla suoritettava suodatin.

(9)

Web API: Verkkosivujen ja sovellusten lisäksi ASP.NET Core MVC:ssä on tuki Web APIen toteuttamiseen, jonka avulla voidaan luoda taus- tapalveluita verkkosivuille/-sovelluksille ja mobiilisovelluksille. Ohjel- mointikehyksessä on sisäänrakennettu tuki datan formatointiin JSON ja XML formaateissa.

Testattavuus: ASP.NET Core ASP.NET soveltuu hyvin testattavaksi yk- sikkötesteillä rajapintoja ja dependency injectionia käyttämällä, sekä integraatiotesteihin testihostia ja muistinvaraista tietokantaa käyttä- mällä Entity Frameworkin kanssa. (Microsoft 2018a).

2.2.2 Dependency Injection ASP.NET Coressa

ASP.NET on alusta asti suunniteltu hyödyntämään DI:tä (Dependency Injection) ja ASP.NET Core –sovellukset voivat hyödyntää sisäänraken- nettua ohjelmistokehyspalvelua. (Microsoft 2016d).

DI:n avulla luokille tarjotaan niiden tarvitsemat riippuvuudet (oliot, rajapinnat) jollain tavalla sen sijaan, että ne luotaisiin luokan sisällä.

Yleensä tämä toteutetaan injektoimalla riippuvuudet luokan konstruktorissa, jotka sitten luodaan luokan luonnin yhteydessä. Usein luokat vaativat abstraktiota (interface) varsinaisen toteutuksen sijaan. Tämä mahdollistaa löyhemmän riippuvuuden luokkien välillä, kun ei ole ko- vakoodattuja riippuvuuksia. Konstruktori-injektoinnissa (Kuva 2) on otettava huomioon, että luokalla on vain yksi soveltuva konstruktori, jonka näkyvyys on julkinen. Konstruktorin voi myös kuormittaa, mutta tuki on vain yhdelle kuormitukselle, jonka kaikki argumentit voidaan toteuttaa DI:llä. (Microsoft 2016d).

ASP.NET Core sisältää sisäänrakennetun IoC-säilön (Inversion Of Cont- rol container). StartUp.cs luokan ConfigureServices-metodissa (Kuva 1) konfiguroidaan IoC-säilön sisältämät palvelut, sekä lisätään alustan tar- joamia ominaisuuksia, kuten Entity Frameworkin DbContext ja ASP.NET MVC tai omia palveluita. (Microsoft 2016d).

Kuva 1. Palvelujen rekisteröinti IoC-säilöön (Microsoft 2016d.)

(10)

Kuva 2. Konstruktori injektointi (Microsoft 2016d.)

2.2.3 Kestrel

Kestrel on ASP.NET Core projektipohjiin sisältyvä web-palvelin, joka julkaistiin ASP.NET Coren yhteydessä. Kestrel ei kuitenkaan sisällä kaikkia täysiverisen web-palvelimen ominaisuuksia, kuten SSL-terminointia, GZip pakkausta tai URL-uudelleenkirjoitusta, mutta tämän vuoksi se on nopea. Kestreliä voi käyttää itsekseen tai täysiverisen web-palvelimen, kuten IIS:n, Apachen tai Nginx:n takana, jotta saavutetaan laajemmat konfiguroinnit ja suojaus. (Stackify 2017).

2.3 Entity Framework Core

Entity Framework (EF) Core on avoimeen lähdekoodiin perustuva alustariippumaton ORM (object-relational mapper), jonka avulla kehittäjät voivat käyttää tietokantaa käyttämällä .NET olioita.

EF Core tukee kahta lähestymistapaa kehittämiseen:

 Code first lähestymistavassa tehdään ensin domain luokat, joiden pohjalta EF Core API luo tietokannan ja taulut.

 Database first lähestymistavassa EF Core API luo domain- ja context- luokat jo olemassa olevasta tietokannasta. EF Core ei kuitenkaan tue visuaalista suunnitteluohjelmistoa tai luontityökalua, joten tuki tähän

(11)

lähestymistapaan on rajoitettu. Kuvassa 3 näkyvät Entity Framework Core -lähestymistavat. (Entity Framework Tutorial 2017).

Kuva 3. Entity Framework Core Lähestymistavat (Entity Framework Tu- torial 2017.)

2.4 ASP.NET Core kehitysympäristöt ja API päätepisteiden testaustyökalut

Visual Studio on erittäin paljon ominaisuuksia sisältävä IDE, jolla voi näyttää, muokata ja kääntää lähes millaista koodia vain ja julkaista Androidille, iOS:lle, Windowsille ja pilveen. VS:n ominaisuuksiin kuuluu mm. Intellisense, virheenkorjaus ja versionhallinta -työkalut, SQL- palvelinselain sekä toiminnot Azure-pilvipalvelun kanssa toimimiseen.

Visual studioon on myös saatavilla laajennoksia Microsoftin kehittäjien ja yhteisön toimesta. Visual Studiosta on saataville kolme versiota, joista Community Edition on ilmainen yksittäiselle kehittäjälle. (Micro- soft 2018b).

Visual Studio Code on kevyt ja ilmainen avoimeen lähdekoodiin perus- tuva alustariippumaton koodieditori, joka on suunniteltu modernien pilvipalveluiden ja web-sovellusten kehittämiseen. VSC:n ominaisuuksiin kuuluu mm. sisäänrakennettu Intellisense, debug-työkalu ja versionhallinta-ominaisuudet. (Visual Studio Code 2018). VSC tukee myös suurta määrää lisäosia, joiden avulla voidaan lisätä tuki eri ohjelmoin- tikielille ja -kehyksille, kuten C# asentamalla ”C# for Visual Studio Code (powered by OmniSharp)” –lisäosa. (Visual Studio Code 2017).

Riders on JetBrainsin toteuttama maksullinen .NET IDE, joka toimii Windows, macOS ja useilla Linux-distribuutioilla. Riders tukee suurinta osaa .NET sovelluksista, sekä niihin käytettäviä kieliä kuten C#, F#, VB.NET, ASP.NET, XAML, XML, JavaScript, TypeScript, JSON, HTML, CSS, SCSS, LESS, and SQL. Ridersin ominaisuuksiin kuuluu koodin analysointi ja refaktorointi, yksikkötestaus, debug-työkalu, versionhallinta ja SQL- tietokantatyökalu. (JetBrains 2018).

(12)

Postman on Abhinav Asthanan luoma http client web-palveluiden tes- taamiseen. Postmanin avulla voidaan testata, kehittää ja dokumen- toida web APIa. Postman on tarjolla Google Chrome selaimen lisäosana sekä Google paketoituna sovelluksena erikseen käytettynä. Postma- nilla voi lähettää http-pyyntöjä APIlle kaikilla http-verbeillä (esim. GET, POST) ja liittää headeriin ja bodyyn pyyntöön tarvittavat tiedot, kuten tokenit, JSON-objektit tai tiedostot. Kun kutsu on tehty, API palauttaa statuskoodin. Tehdyt pyynnöt tallentuvat, jolloin niitä on helppo käyt- tää uudestaan ja näin helpottaa testaamista. (Wagner 2014).

2.5 Representational State Transfer (REST) API

REST-arkkitehtuuri, joka on suunniteltu käyttämään olemassa olevia protokollia. Vaikka sitä voi käyttää lähes minkä protokollan kanssa vain, hyödynnetään web-APIssa yleisesti http-protokollaa. REST voi toimia erityyppisten tietoformaattien kanssa, kuten XML, JSON ja YAML. (Mu- lesoft n.d).

REST koostuu kuudesta rajoitteesta:

 Asiakaspalvelin: rajoite edellyttää erillistä asiakasta ja palvelinta, joilla on omat rajatut roolinsa.

 Tilattomuus: REST APIt ovat tilattomia, mikä tarkoittaa sitä, että pyynnöt voi tehdä riippumatta muista pyynnöistä ja jokainen pyyntö sisältää kaiken tiedon, jotta pyyntö voidaan toteuttaa.

 Välimuisti: Jos data on sellaista, mikä voidaan tallentaa välimuistista käytettäväksi, tulisi vastauksessa osoittaa, että data voidaan säilyttää määritetyn ajan välimuistissa, jotta uuden pyynnön tullessa resurssi voidaan välittää asiakkaalle takaisin ilman, että tieto haetaan palveli- melta uudestaan.

 Yhdenmukainen rajapinta: Rajapinnan pitää tarjota muuttumaton vakioitu tapa asiakkaan ja palvelimen väliseen kommunikointiin, kuten http:n käyttö, CRUD (luo, lue, päivitä, poista) –toiminnot ja JSON

 Kerroksittainen järjestelmä: Kerroksittainen järjestelmä koostuu ker- roksista, joilla jokaisella on oma vastuualueensa.

 Ladattava koodi: ainoa vapaaehtoinen rajoite, joka mahdollistaa koo- din tai applettien välittämisen APIn kautta, joka mahdollistaa sen, että järjestelmä ei ole riippuvainen vain omasta koodirakenteestaan.

(Mulesoft n.d).

REST APIssa suositellaan käyttämään tiettyjä HTTP-metodeja tietyn tyyppisiin pyyntöihin. Taulukossa 1 kuvattujen yleisimpien metodien li- säksi on olemassa HEAD, OPTIONS, TRACE ja CONNECT, joita käytetään harvemmin. (Reichart 2017).

Taulukko 1. REST APIssa yleisimmin käytetyt HTTP-metodit ja niiden käyttö (Reichart 2017).

(13)

HTTP-metodi Käyttö

HTTP POST luo uuden resurssin

HTTP GET noutaa resurssin eikä muokkaa sitä mitenkään HTTP PUT resurssin päivittäminen

HTTP DELETE resurssin poistaminen

REST APIt käyttävät myös vastauskoodeja, joita palautetaan, kun pyyntö on toteutettu tai tapahtuu jokin virhe. HTTP määrittää neljä- kymmentä vakioitua vastauskoodia. Koodit on jaettu viiteen kategori- aan, jotka on esitetty taulukossa 2.

Taulukko 2. HTTP vastauskoodikategoriat (Reichart 2017)

Kategoria Kuvaus Esimerkki

1xx: informatiivinen Pyyntö vastaanotettu 100 (Continue) 2xx: onnistunut Pyyntö suoritettu onnistu-

neesti

201 (Created) 3xx: uudelleenohjaus Uudelleenohjaukseen liit-

tyvät tilakoodit

302 (Found) 4xx: asiakasvirhe asiakkaan tekemät virheet 404 (Not Found) 5xx: palvelinvirhe palvelimella tapahtunut

virhe

500 (Internal Ser- ver Error)

2.6 REST APIn suojaaminen

APIN yleisin tehtävä on välittää dataa muille sovelluksille, jolloin on tär- keää huolehtia, että käyttäjällä on pääsy vain sallittuihin resursseihin.

2.6.1 Autentikointi

Autentikointi on käyttäjän todentamiseksi suoritettava prosessi, jossa käyttäjältä saadaan pääsytiedot, jotka validoidaan ja jos pääsytiedot ovat kelpaavat, niin käyttäjällä on pääsy autorisoituihin resursseihin.

(Microsoft n.d.). Yksinkertaisimmillaan autentikointiin käytetään tun- nusta ja salasanaa, mutta muita muotoja on esimerkiksi kaksi-/moni- vaiheinen tai token-pohjainen tunnistautuminen. (Restcase 2018).

HTTP Basic -autentikoinnissa käyttäjä/sovellus lähettää käyttäjätun- nuksen ja salasanan HTTP-headerissa todistaakseen autentikoinnin jokaisella kutsulla. Tämä tapa on yksinkertainen toteuttaa eikä vaadi ses- sioita, evästeitä, kirjautumissivuja tai muita erityisempiä ratkaisuja.

Ongelmana on kuitenkin se, että tunnukset eivät ole salattuja vaan BASE64-koodattuja, ja ilman salattua yhteyttä ne on mahdollista kaa- pata. Basic-autentikointia suositellaan harvoin käytettäväksi. (Sando- val 2018).

(14)

Token-pohjainen autentikointi on tilaton ja palvelin ei tallenna mitään tietoja käyttäjästä tai sessiosta, minkä ansiosta sovellus on skaalautu- vampi, kun koneita voi lisätä tarpeen mukaan riippumatta siitä, missä käyttäjä on kirjautuneena. (Sevilleja 2015). Client lähettää kirjautuessa käyttäjän antamat tunnukset yhden kerran ja autentikointipalvelu palauttaa tokenin, joka sisältää tarvittavan datan käyttäjän tunnista- miseksi ja voimassaoloajan, jotta tunnuksia ei tarvitse lähettää jokaisella kutsulla. Token lähetetään jokaisessa pyynnössä käyttäjätietojen sijasta. (Kotian 2017).

Kuva 4. Kotian (2017) Token Based Authentication for Web API's

2.6.2 Autorisointi

Autorisointi on prosessi, joka määrittää mitä käyttäjä saa tehdä. Pää- käyttäjä voi esimerkiksi luoda, muokata tai poistaa dokumentteja, mutta normaalikäyttäjälle voidaan sallia vain lukuoikeus. Autorisointi on itsenäinen ja erillään autentikoinnista oleva toiminto, mutta vaatii jonkin tyyppisen autentikointitavan. (Microsoft 2016c).

ASP.NET Core API autorisointia hallitaan Authorize-atribuuteilla, joita voi käyttää Controller tai toimintotasolla. Autorisointiperusteena voi olla esimerkiksi rooli (Kuva 6), kirjautunut käyttäjä tai käytäntö. Ku- vassa 5 on esitetty yksinkertainen luokka, joka on suojattu kontrolleritasolla [Authorize]-attribuutilla, eli toiminnot vaativat kirjautumisen, mutta Login()-toiminto on sallittu myös kirjautumattomille [AllowAno- nymous]-atribuutilla. (Microsoft 2016c).

Kuva 5. Yksinkertainen autorisointi ASP.Net Coressa (Microsoft 2016c.)

(15)

Kuva 6. Roolipohjainen autorisointi ASP.NET Coressa (Microsoft 2016c.)

2.6.3 Muita huomioon otettavia asioita

Clientin ja APIn välinen liikenne tulisi aina salata käyttämällä HTTPS:ää HTTP:n sijasta, koska HTTP:n keskeyttäminen ja tietojen lukeminen on suhteellisen helppoa. (Wills 2018).

Pyyntöjen määrä kannattaa rajoittaa DoS-hyökkäysten välttämiseksi ja toimia palveluntarjoajan kanssa, jotka tarjoavat DoS-hyökkäyssuo- jausta. (Wills 2018).

Autentikointiin on hyvä toteuttaa rajoitus kirjautumisyrityksiin, hyök- käyksien vaikeuttamiseksi. Kun käyttäjä antaa väärät käyttäjätunnuk- set liian monta kertaa, estetään kirjautumisyritykset määritetyksi ajaksi kyseisestä IP-osoitteesta. (Wills 2018).

Käyttäjän syöttämät tiedot on validoitava yleisten hyökkäysten estä- miseksi, kuten SQL injektio. Käyttäjän lähettämän datan tietotyyppi tulee myös tarkastaa. Jos käyttäjän odotetaan lähettävän JSON-dataa, niin hyväksytään vain pyynnöt, joiden Content-Type header on määri- tetty application/json. (Wills 2018).

2.7 JSON WEB TOKEN (JWT)

JWT on kuvattu RFC 7519 avoimessa standardissa turvallisena tapana esittää ja siirtää tietoa, kuten käyttäjädataa kahden osapuolen välillä JSON objektina. JWT on kompakti merkkijono, joka voidaan lähettää URL:ssä, POST-parametrina tai HTTP headerissa, ja se voidaan allekir- joittaa käyttämällä HMAC algoritmia tai RSA julkinen/privaatti avainpa- rilla. JWT-merkkijono koostuu kolmesta osasta jotka on erotettu pis- teellä toisistaan: HEADER.PAYLOAD.SIGNATURE. (Stecky-Efantis 2016).

Tokenin allekirjoittaminen suojaa sen tiedot muutoksilta, mutta tietoja ei kuitenkaan salata ja ne ovat luettavissa. Tämän vuoksi payload- ja header-osioihin ei pitäisi sisällyttää ilman salausta mitään tietoa, mitä ei haluta ulkopuolisten tietoon, ja lähettämisessä tulisi käyttää HTTPS- yhteyttä. (Stecky-Efantis 2016).

(16)

Header sisältää tiedon siitä, mikä tokenin tyyppi on ja millä algoritmilla allekirjoitus tulee laskea. Header JSON BASE64Url-koodataan JWT:n ensimmäiseksi osaksi. (JWT n.d.)

Payload on JWT:n toinen osa, joka sisältää lähetettävät tiedot (claim).

Vaatimustyyppejä on kolme: rekisteröity, julkinen ja yksityinen. Rekis- teröidyt vaateet sisältävät suositeltuja, mutta ei pakollisia ennalta määriteltyjä yhteentoimivia vaateita, kuten voimassaoloaika, aihe ja kohdeyleisö. Payload JSON BASE64Url-koodataan JWT:n toiseksi osaksi. (JWT n.d.)

Signature-osan muodostamiseen tarvitaan koodatut header ja payload, secret ja algoritmi, joka on määritelty headerissa. Allekirjoi- tuksella varmistetaan, että tieto ei ole muuttunut matkalla. Signature lasketaan uudestaan aina, kun joku tieto muuttuu. (JWT n.d.)

Header

{

"typ": "JWT", "alg": "HS256"

}

Payload

{

"sub": "1234567890", "name": "John Doe", "admin": true

}

Signature

HMACSHA256(

base64UrlEncode(header) + "." + base64UrlEncode(payload, secret)

Esimerkin BASE64-koodattu JWT token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiO-

iIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydW V9.dyt0CoTl4WoVjAHI9Q_CwSKhl6d_9rhM3NrXuJttkao (JWT n.d.)

(17)

3 KÄYTÄNTÖ

Käytännön osuudessa tavoitteena oli luoda yksinkertainen API, jolla käyttäjä voi lisätä, poistaa ja listata kuvia suodattamalla ryhmän tai kuvauksen mukaan tai ilman suodatuksia, jotta ASP.NET Core API:n toiminta tulee tutuksi ja samalla myös lisätä osaamista Linux-serverin hal- linnoinnissa. APIssa käytettiin MySQL-tietokantaa Entity Framework Pomelo-providerilla. Repository-suunnittelumallin avulla tietokantaky- selyitä ei tarvitse kirjoittaa useaan kertaan, jos niitä käytetään monessa paikassa, vaan kaikki tietokantakyselyt ovat samassa paikassa. Malli poistaa ohjelman riippuvuuden käytössä olevasta tietokantaohjelmis- tokehyksestä (EF) tai kyselyiden toteutuksesta ja toteutusta voidaankin tämän myötä halutessa helposti vaihtaa toiseen.

Valmis API otettiin käyttöön virtuaalisella Ubuntu 16.04 privaattiserve- rillä, johon asennettiin ja konfiguroitiin NGINX web-palvelin ohjaamaan http-pyynnöt sovelluksen sisäiselle Kestrel web-palvelimelle.

Kehitysympäristönä toimi Windows 10 käyttöjärjestelmä ja Visual Stu- dio Code -tekstieditori seuraavilla lisäosilla varustettuna:

 C# for Visual Studio Code (powered by OmniSharp)

 C# IDE Extensions for VSCode

 NuGet Package Manager

 Deploy

APIn käyttäjätarinat:

 Rekisteröimättömän käyttäjän on pystyttävä luomaan käyttäjätun- nus, jotta voi käyttää palvelua

 Käyttäjän on pystyttävä kirjautumaan palveluun

 Käyttäjän on pystyttävä lisäämään itselleen kuvia

 Käyttäjän on pystyttävä hakemaan kaikki kuvansa

 Käyttäjän on pystyttävä hakemaan tietty kuva

 Käyttäjän on pystyttävä hakemaan kuvia ryhmän tai kuvauksen pe- rusteella.

3.1 Projektin luonti

Projekti luotiin Windowsin komentokehotteessa (Kuva 7) käyttämällä .NET Coren ”dotnet” app hostin web-api pohjaa. Luotu runko (Kuva 8) sisältää esimerkkikontrollerin, sovelluksen käynnistämiseen ja konfigu- rointiin tarvittavat Startup.cs ja Program.cs -tiedostot, sekä Op- pari.API.csproj -tiedoston, johon voidaan määrittää riippuvuudet ja ke- hitystyökaluja.

(18)

Kuva 7. Projektin luonti

Kuva 8. Luotu projekti

3.2 Riippuvuudet

Luodun projektin .csproj-tiedostoon (Kuva 10) lisättiin seuraavat paketit:

 AutoMapper.Extensions.Microsoft.DependencyInjection, jonka avulla Modelit muutetaan tiedonsiirto-olioiksi ja päinvastoin

 Pomelo.EntityFrameworkCore.MySql, jotta Entity Frameworkia voi käyttää projektiin valitun MySQL-tietokannan kanssa

 Microsoft.DotNet.Watcher.Tools CLI-kehitystyökalu, jota käyttämällä sovellus käynnistyy kehittäessä aina uudestaan, kun jotain tiedostoa muutetaan ja tallennetaan.

Lisätyt paketit otettiin käyttöön suorittamalla projektin hakemistossa ko- mento: dotnet restore (Kuva9).

Kuva 9. dotnet restore

(19)

Kuva 10. .csproj-tiedosto

3.3 Modelit ja tiedonsiirto-oliot

APIin luotiin kaksi modelia, Photo.cs ja User.cs (Kuva 11), joiden pohjalta Entity Framework loi tietokantataulut ”code first” lähestymista- paa käyttäen ja joita käytetään tiedon noutoon sekä tallentamiseen.

Käyttäjän ja kuvan välillä on yksi-moneen suhde, eli käyttäjällä voi olla monta kuvaa, mutta kuvalla on aina yksi käyttäjä. Kun model luodaan tai tehdään muutoksia ja samat muutokset pitää saada vastaavaan tie- tokantatauluun, niin Entity Frameworkia käyttäen täytyy luoda code first migration käyttäen ”Add-Migration [kuvaus]” -komentoa, eli luodaan skriptin taulujen muokkaukseen. Migraatiot tallentuvat migrations-hakemistoon, josta niitä voi käydä läpi, poistaa tai palata johinkin tiettyyn migraatioon. Tämän jälkeen skripti pitää vielä suorittaa komennolla ”update-database”, jotta muutokset tietokannan tauluihin tulevat voimaan.

Kuva 11. User.cs model

(20)

Lisäksi luotiin tiedonsiirto-olioita, jotka sisältävät vain tarvittavat ken- tät esim. kirjautumiseen (Kuva 12) tai kuvan palauttamiseen. Model <-

> tiedonsiirto-olio muunnoksiin käytettiin AutoMapperia, joka muuttaa oliot käytäntöpohjaisesti, eli saman nimiset ominaisuudet oliossa siirtyvät uuteen olioon.

Kuva 12. UserForLoginDto.cs tiedonsiirto-olio

3.4 Datacontext ja repositoryt

APIlle luotiin DataContext, joka hoitaa tietokantayhteyden ja siihen määritettiin taulut/modelit joita se käyttää (Kuva 13). DataContext on osa Entity Frameworkia.

Kuva 13. DataContext.cs

Projektiin luotiin myös repository-rajapinnat (Kuva 14) ja toteuttavat konkreettiset luokat autentikoinnille sekä muille toiminnoille. Rajapin- nat kertovat, mitkä toiminnallisuudet perivän konkreettisen luokan (Kuva 15) täytyy toteuttaa. Repositoryille injektoitiin konstruktorissa luotu DataContext.

(21)

Kuva 14. IAuthRepository-rajapinta

Kuva 15. Esimerkki konkreettisen AuthRepositoryn LoginAsync-metodista

3.5 Kontrollerit

APIin luotiin kontrollerit AuthController.cs:n ja PhotosController.cs, joiden käyttöön injektoitiin tarvittavat palvelut konstruktorissa (Kuva 16).

Kuva 16. Palveluiden injektointi AuthControlleriin

AuthController on kaikille vapaa ja ei vaadi tunnistautumista. Kontrol- leri vastaa käyttäjän rekisteröinnistä ja kirjautumisesta. Login() -metodi (Kuva 17) tarkistaa käyttäjän tunnuksen ja salasanan, luo JWT-tokenin

(22)

määritettyjen parametrien mukaisesti ja palauttaa JWT-token merkki- jonon ja käyttäjän tiedonsiirto-oliona, ja jos tunnukset eivät täsmää, niin palautetaan http-tilakoodi 401 Unauthorized.

Kuva 17. AuthController.cs Login()-metodi

Taulukko 3. AuthController toimintometodit

URI HTTP-metodi Toiminto

api/auth/register POST Rekisteröi käyttäjän, noutaa rekis- teröitävät tiedot bodysta.

api/auth/login POST Kirjaa käyttäjän sisälle, noutaa kir- jautumistiedot bodysta.

PhotosControllerille on määritetty [Authorize]-atribuutti kontrolleritasolla ja sen kaikkien toimintometodien käyttäminen vaatii JWT tokenilla tunnistautumisen. Kontrolleri on vastuussa kuviin liittyvistä toi- minnoista, kuten lisää tai hae kuva. GetPhotos() -metodi toteutettiin

(23)

niin, että sille voidaan antaa hakuparametreja (avustava luokka Photo- Params.cs), joiden avulla repositoryssa oleva tietokantakysely suodat- taa haettavat kuvat ryhmän tai kuvauksen mukaisesti, kuten käyttäjä- tarinassa oli vaatimuksena.

Taulukko 4. PhotosController toimintometodit

URI HTTP-

metodi

Toiminto

api/users/{userId}/photos GET Noutaa kaikki käyttäjän kuvat.

Metodille voi antaa hakuparametreja urlissa.

api/users/{userId}/photos/addphoto

POST Lisää kuvan käyttäjälle, noutaa tiedot bodystä

api/users/{userId}/photos/{id}

GET Noutaa yksittäisen kuvan Id:llä

3.6 Startup.cs

Startup-luokan ConfigureServices-metodissa (Kuva 18) lisättiin käy- tössä olleet palvelut ASP.NET:n sisäänrakennettuun IoC-säilöön, josta niitä voitiin injektoida muihin luokkiin.

Kuva 18. Startup.cs ConfigureServices()

Configure-metodissa (Kuva 19) konfiguroitiin ja lisättiin sovelluksen http-pyyntöjen välitoiminnot/ohjelmat (middleware), kuten app.Use- Authentication(), joka lisää autentikoinnin sovellukseen.

(24)

Kuva 19. Startup.cs Configure()

3.7 Linux-palvelimen valmistelut ja API käyttöönotto

Palvelimeksi valikoitui Linux Ubuntu 16.04, jolle täytyi asentaa .NET Core Runtime, jotta sovelluksen voi suorittaa. Ennen ajoympäristön asentamista palvelimelle täytyi rekisteröidä Microsoft-avain ja asentaa tarvittavat paketit. Rekisteröinti täytyy tehdä vain yhden kerran palvelimelle, vaikka myöhemmin ajettaisiin muitakin sovelluksia. Pakettien asennus palvelimelle suoritettiin Putty SSH-yhteyden yli terminaalissa ja asetustiedostojen konfigurointi tehtiin Nano-editorilla, joka sisältyy Ubuntu-asennukseen.

Avaimen rekisteröinti ja pakettien asentaminen suoritettiin Kuvien 20 ja 21 komennoilla:

Kuva 20. Microsoft avaimen rekisteröinti

.NET Core Runtime 2.0.7 asennettiin seuraavilla komennoilla:

Kuva 21. .NET Core runtime asennus

(25)

Sovelluksen sisäistä Kestrel-webpalvelinta varten täytyi tehdä service- tiedosto (Kuva 22), jotta sovelluksen voi suorittaa palvelimella palve- luna. Jos näin ei tekisi ja sovelluksen suorittaisi terminaalissa, niin sovellus olisi toiminnassa vain niin kauan, kuin SSH yhteys on käytössä.

Etuna on myös, että palvelu käynnistää itsensä uudestaan, jos se kaa- tuu.

Kuva 22. Kestrel service asetukset

Palvelun hallinta tapahtui komennoilla:

 Käyttöönotto: systemctl enable kestrel-oppari.service

 Käynnistäminen: systemctl start kestrel-oppari.service

 Palvelun tila: systemctl status kestrel-oppari.service

 Uudelleenkäynnistys: systemctl restart kestrel-oppari.service

 Pysäyttäminen: systemctl stop kestrel-oppari.service

Palvelimelle asennettiin Nginx uudelleenohjaamaan liikennettä Kest- rel-servicelle, joka toimii portissa 5001. Tätä varten Nginx:lle tehtiin asetustiedosto (Kuva 23), joka kertoo sovelluksen sijainnin http://local- host:5001 ja, että pyynnön headerit päivitetään uudelleenohjauksessa.

Kun tiedosto luotiin sites-available hakemistoon, otettiin se käyttöön luomalla symbolinen linkki sites-enabled hakemistoon suorittamalla komento: ln -s /etc/nginx/sites-available/oppari.conf /etc/nginx/sites- enabled/.

(26)

Kuva 23. Nginx asetustiedosto API:lle

Tietokantataulujen luomiseksi palvelimelle VS Coden terminaalissa sovelluksen hakemistossa suoritettiin EF komento: dotnet ef migrations script -o mysql.sql, joka luo MySQL- skriptin (Kuva 24), jolla voidaan luoda tarvittavat taulut tietokantaan, seuraavaksi palvelimen juureen luotiin opparimysql.sql-tiedosto, johon skriptin sisältö kopioitiin komennolla nano opparimysql.sql.

Kuva 24. Tietokantataulujen luonti -skripti

Tietokanta ja sen taulut luotiin kirjautumalla MySQL-monitoriin MySQL:lle määritetyllä tunnuksella käyttämällä komentoa: mysql -u [käyttäjätunnus] -p

MySQL monitor komennot tietokannan luontiin:

 Tietokannan luonti: create database opparidb;

 Tietokantaan siirtyminen: use opparidb;

 Taulujen luonti skriptin ajaminen: source /root/opparimysql.sql;

 Taulujen näyttäminen (Kuva 25): show tables;

Kuva 25. Luodut tietokantataulut palvelimella

(27)

3.8 Sovelluksen siirtäminen palvelimelle

Sovelluksen kääntäminen ja julkaisu palvelimelle siirtämiseksi tapahtui VS Coden terminaalissa komennolla ”dotnet publish”, joka vie valmiit tiedostot \Oppari.API\bin\Debug\netcoreapp2.0\publish\ hakemistoon.

Siirtämisen palvelimelle voi tehdä monella tavalla, esim. FTP-yhteyden kautta. Tämän sovelluksen kohdalla päädyin käyttämään VS Code-lisä- osaa ”Deploy”, jolle tehtiin projektin .vscode hakemistoon settings.json -asetustiedosto (Kuva 26), joka sisältää palvelimen IP- osoitteen, käyttäjätunnukset, kohdehakemiston, sekä käytössä olevan SSH-yksityisavaintiedoston sijainnin ja salasanan, jolla palvelin tunnis- taa käyttäjän. Käytettäväksi yhteystyypiksi määritettiin SFTP, joka käyt- tää FTP:tä SSH tunnelin yli. Siirtäminen tapahtui asetusten määrittämi- sen jälkeen helposti käyttämällä VS Coden ”Command Pallette”:n kautta (CTRL+SHIF+P) valitsemalla ”Deploy: Deploy workspace”.

Kuva 26. settings.json sovelluksen siirtämiseen

3.9 API-päätepisteiden testaaminen

APIn kehittämisen aikana ja palvelimelle siirtämisen jälkeen APIn pää- tepisteiden toimivuutta ja vastauskoodeja testattiin Postman-sovelluk- sella, joka helppo ja yksinkertainen käyttää. Koska osa päätepisteistä vaati kirjautumisen, niin Postmanilla pystyi kirjautumaan käyttäen login-toimintoa (Kuva27), joka palauttaa JWT-authorization tokenin,

(28)

jonka voi lisätä Authorization-headerin arvoksi (Kuva 28). Sovellus helpottaa ja nopeuttaa kehittämistä.

Kuva 27. Kirjautuminen ja paluuviesti

Kuva 28. Authorization Header Bearer tokenin lisääminen

(29)

4 YHTEENVETO

Työssä vastattiin kaikkiin kolmeen asetettuun tutkimuskysymykseen.

Aiheesta ei itselläni ollut aikaisempaa kokemusta ja se osoittautui itsel- leni todella mielenkiintoiseksi ja opettavaiseksi. Aiheesta löytyi kohtuullisen hyvin tietoa internetistä etsimällä. Teoriaosan asioihin pereh- tymisen ja aiheeseen liittyvien videokurssien jälkeen käytännön osuu- teen oli kohtuullisen helppo lähteä ja toteutus sujui ilman suuria ongel- mia. Aikataulun vuoksi raporttiin ei ehtinyt HTTPS käyttöönotto. APIa olisi kohtuullisen helppo lähteä laajentamaan niin, että kuvia siirrettäi- siin APIn kautta johonkin pilvipalveluun ja tallentaa tämä osoite tietokantaan.

Monista materiaaleista kävi ilmi, että jo olemassa olevaa ASP.NET 4.x sovellusta ei välttämättä kannata lähteä muuttamaan käyttämään ASP.NET Corea, mutta soveltuu uusiin projekteihin hyvin ASP.NET Core version 2.0 myötä. Työn aikana tutustuin suureen määrään sivustoja, blogeja ja dokumentaatioita, joiden myötä asiaa tuli myös hieman ai- heen vierestä. Opittuja taitoja .NET Core ympäristössä ja palvelimen hallintaa SSH:n yli aioin hyödyntää jatkossa omissa projekteissa ja työ- elämässä.

(30)

LÄHTEET

Entity Framework Tutorial (2017). Entity Framework Core. Haettu 8.5.2018 osoitteesta http://www.entityframeworktuto-

rial.net/efcore/entity-framework-core.aspx

Fritz, J. (2016). ASP.NET Blog. Announcing ASP.NET Core 1.0. Haettu 3.4.2018 osoitteesta https://blogs.msdn.microsoft.com/web-

dev/2016/06/27/announcing-asp-net-core-1-0/

JetBrains (2018). Features. Haettu 14.5.2018 osoitteesta https://www.jetbrains.com/rider/features/

JWT (n.d). Introduction to JSON Web Tokens. Haettu 3.5.2018 osoitteesta https://jwt.io/introduction/

Kotian, D. (2017). Token Based Authentication for Web API's. Haettu 4.5.2018 osoitteesta https://www.ecanarys.com/Blogs/Arti-

cleID/308/Token-Based-Authentication-for-Web-APIs

Microsoft (2016a). .NET Core Guide. Haettu 9.4.2018 osoitteesta https://docs.microsoft.com/en-us/dotnet/core/

Microsoft (2016b). Packages, metapackages and frameworks. Haettu 10.4.2018 osoitteesta https://docs.microsoft.com/en-us/dot-

net/core/packages

Microsoft (2016c). Introduction to authorization in ASP.NET Core.

haettu 4.5.2018 osoitteesta https://docs.microsoft.com/en- us/aspnet/core/security/authorization/introduc-

tion?view=aspnetcore-2.1

Microsoft (2016d). Dependency injection in ASP.NET Core. haettu 4.5.2018 osoitteesta https://docs.microsoft.com/en-

us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1

Microsoft (2017a) ASP.NET Core Fundamentals. Haettu 14.5.2018 osoitteesta https://docs.microsoft.com/en-us/aspnet/core/fundamentals/index?view=aspnetcore-2.0&tabs=aspnetcore2x

Microsoft (2018a). Overview of ASP.NET Core MVC. Haettu 14.5.2018 osoitteesta https://docs.microsoft.com/en-us/aspnet/core/mvc/overview?view=aspnetcore-2.0

(31)

Microsoft (2018b). Visual Studio IDE overview. Haettu 18.5. osoitteesta https://docs.microsoft.com/en-us/visualstudio/ide/visual-studio-ide#connect-to-services-databases-and-cloud-based-resources Microsoft (n.d.). ASP.NET Authentication. Haettu 3.5. osoitteesta https://msdn.microsoft.com/fi-fi/library/eeyk640h.aspx

Mulesoft (n.d.). What is a REST API?. Haettu 18.5. osoitteesta https://www.mulesoft.com/resources/api/what-is-rest-api-design Reichart, C. (2017). 7 HTTP methods every web developer should know and how to test them. Haettu 18.5.2018 osoitteesta https://as- sertible.com/blog/7-http-methods-every-web-developer-should- know-and-how-to-test-them

Restcase (2018). Introduction to REST API Security. Haettu 3.5.2018 osoitteesta https://blog.restcase.com/introduction-to-rest-api-security/

Sandoval, K. (2018). 3 Common Methods of API Authentication Ex- plained. Haettu 4.5.2018 osoitteesta https://nordicapis.com/3-common-methods-api-authentication-explained/

Sevilleja, C. (2015). The Ins and Outs of Token Based Authentication.

Haettu 4.5.2018 osoitteesta https://scotch.io/tutorials/the-ins-and- outs-of-token-based-authentication

Stackify (2017). What is Kestrel Web Server? How It Works, Benefits, and More. Haettu 3.5.2018 osoitteesta https://stackify.com/what-is- kestrel-web-server/

Stecky-Efantis (2016). 5 Easy Steps to Understanding JSON Web To- kens (JWT). Haettu 3.5.2018 osoitteesta https://medium.com/van- dium-software/5-easy-steps-to-understanding-json-web-tokens-jwt- 1164c0adfcec

Strahl, R. (2018). Ready for Prime Time: .NET Core 2.0 and ASP.NET Core 2.0 Have Arrived. haettu 9.4.2018 osoitteesta

http://www.codemag.com/Article/1803061/Ready-for-Prime-Time- .NET-Core-2.0-and-ASP.NET-Core-2.0-Have-Arrived

Visual Studio Code (2017). Using .NET Core in Visual Studio Code. Ha- ettu 14.5.2018 osoitteesta https://code.visualstudio.com/docs/other/dotnet

Visual Studio Code (2018). Why did we build Visual Studio Code?. Ha- ettu 14.5.2018 osoitteesta https://code.visualstudio.com/docs/edi- tor/whyvscode

(32)

Wagner, J. (2014). Review: Postman Client Makes RESTful API Explora- tion a Breeze. Haettu 17.5.2018 osoitteesta https://www.program- mableweb.com/news/review-postman-client-makes-restful-api-ex- ploration-breeze/brief/2014/01/27

Wills, M. (2018). API Security Checklist. Haettu 17.5. osoitteesta https://www.templarbit.com/blog/2018/01/10/api-security-checklist