T Tekninen spesifikaatio

Transkriptio

1 T Tekninen spesifikaatio OtaShop2 Versio Päivämäärä Tekijä Kuvaus Tarkastettu Karanko Laajennettu selvitystä ylläpitopuolen tekniikasta Ojanen Pieni lisäys replikoinnin kuvaukseen Inkinen Dokumentti tarkastettu ja virheet korjattu Kosunen Inkinen Pankkitietoihin tehtävät muutokset käyttöönoton yhteydessä, kappale 7.1. Puuttuvien pakettien dokumentaatio (Order DAO ja Validator). Dokumentti muutettu vastaamaan Delivery-vaihetta. Muutoksia tietoturva-osioon, järjestelmäalustaan sekä muita korjauksia Inkinen Tietokantapalvelin vaihdettu dokumentissa Ojanen Replikoinnin kuvausta tarkennettu Kärkkäinen Os2admin ja käyttäjätunnusosioita tarkennettu Inkinen Useita kohtia tarkennettu vastaamaan vaihetta I Inkinen Dokumentti tarkastettu ja löydetyt virheet korjattu Ojanen Kannan kuvaus päivitetty Inkinen Oma tietoturvakappale, kuvausta admin-toiminnoista Inkinen Lisätty tietoturvaosio verkkomaksukappaleeseen Inkinen Dokumetti tarkastettu ja löydetyt epäkohdat korjattu Larmo Lisätty Käyttöliittymän kuvaus Ojanen Lisätty DAO:n kuvaus Inkinen Tarkennettu pakettien ja luokkien kuvauksia, käyttöliittymän kuvausta sekä otsikoita Kosunen Lisätty kuvaus language managerista Inkinen Muutoksia rakenteeseen ja otsikoihin. Uutta sisältöä pakettien kuvauksiin Ojanen Tietokannan kuvaus ja ER Inkinen Pohja luotu Sisältö 1. Johdanto 1.1 Asiakirjan tarkoitus 1.2 Määriteltävä tuote 2. Järjestelmä-alusta 2.1 Järjestelmän laitealusta 2.2 Tietokanta sekä laitealusta 3. Järjestelmän arkkitehtuuri 3.1 Järjestelmän yleiskuvaus 3.2 Suunnittelufilosofia 3.3 OtaShop2 Java-paketit ja luokat 3.4 Os2Admin tekniikka 3.5 Tietokantakuvaus 3.6 Liitännät muihin järjestelmiin 4. Käyttöliittymä 4.1 JSP 5. Tekniset päätökset 5.1 Käytetyt tekniikat 1 of 18 04/05/ :08 PM

2 5.2 Hylätyt tekniikat 6. Tietoturva 7. Käyttöönoton valmistelu 8. Lähteet 1. Johdanto 1.1 Asiakirjan tarkoitus Tämä dokumentti on OtaShop2-projektin tekninen spesifikaatio. Asiakirja on tarkoitettu järjestelmän tuleville ylläpitäjille sekä jatkokehittäjille. Dokumentissa selvitetään järjestelmän tekninen toiminta, käytetyt teknologiat sekä ympäristö jossa järjestelmää käytetään. Asiakirja tulee olemaan tärkeä varsinkin projektin loppuvaiheessa, jolloin valmis järjestelmä siirretään asiakkaan hallintaan. 1.2 Määriteltävä tuote Järjestelmä joka määritellään tässä dokumentissa on OtaShop2-verkkokauppa ja sen hallintaan tarkoitettu Os2admin-järjestelmä. OtaShop2 tulee Teknisen Korkeakoulun kirjaston (myöhemmin kirjasto) käyttöön. OtaShop2-kauppaa käytetään Teknillisen Korkeakoulun (TKK) laboratorioiden julkaisujen välittämiseen. Järjestelmä mahdollistaa maksujen, kuten tilauksesta ja postituksesta syntyvien kulujen maksamisen verkkopankin kautta. Ylläpitojärjestelmän avulla voidaan hallita kaupan toimintoja ja se on myös pääasiallinen työkalu tilausten toimitusten hallintaan. 2. Järjestelmä-alusta 2.1 Järjestelmän laitealusta Projektin vaatimukseksi on annettu että järjestelmä tulee toimia "kohtuuhintaisella laitteistolla". Koska järjestelmän vaatimat resurssit ovat riippuvaisia käytetystä sovelluspalvelimesta sekä kaupan asiakkaiden määrästä, ei laitteston enimmäishintaa ole määritelty tarkemmin. Kehitysvaiheessa järjestelmää käytetään laitteistolla ja ohjelmistoilla jotka on määritelty tarkemmin projektisuunnitelmassa. Projektin loppuun mennessä ei vielä ole selvinnyt milloin järjestelmä tullaan ottamaan tuotantokäyttöön, joten järjestelmäalustaa ei olla määritelty tarkemmin. Asiakkaan kanssa on sovittu että alussa saatu alusta johon testikäytössä ollut sovellus palautetaan asiakkaalle projektin lopussa. Testialusta sisältää toimivan järjestelmän jota voidaan käyttää järjestelmän toiminnan esittelemiseen. Tämän lisäksi järjestelmä toimitetaan erillisellä asennuslevyllä (CD-ROM), josta asennus voidaan myöhemmin tehdä haluttuun palvelimeen. Asennuslevy sisältää järjestelmien lähdekoodit, käännösympäristön sekä dokumentaation. Asennuksessa pyritään myöhemmin myös auttamaan mahdollisuuksien mukaan. 2.2 Tietokanta ja laitealusta OtaShop2-järjestelmässä käytetään tietokantapalvelinta tilausten ja maksujen hallintaan. Kaikki pysyvä tieto tallennetaan tietokantaan. Pysyvää tietoa ovat julkaisujen tiedot, tuotteiden toimitukseen liittyvät tiedot sekä tarvittavat asiakastiedot. Julkaisutiedot löytyvät TKK:n kirjaston Tenttu-tietokannasta. Kirjasto päivittää uusimmat tiedot julkaisuista Tenttu-tietokantaan, ja OtaShop2:n julkaisutiedot replikoidaan kerran vuorokaudessa Tenttu-kannasta. OtaShop2:n oma tietokanta luodaan käyttäen standardi SQL:ää. Valmistajakohtaisia laajennuksia ei käytetä. Tällä tavalla voidaan varmistua siitä että otettaessa järjestelmää käyttöön ei olla riippuvasia yhden valmistajan ohjelmistosta tai sen versiosta. Järjestelmän toteutusvaiheessa tulemme käyttämään "Oracle 9i standard"-tietokantapalvelinta. Oracle tietokantapalvelimen lisenssi estää tämän käytön valmiissa tuotteessa, joten se on vaihdettu projektin loppuvaiheessa PostgreSQL-tietokantapalvelimeen. Tietokannan vaihtaminen vaati noin 30h työtä, johon on laskettu mukaan kattava testaaminen. Kannan vaihtaminen uudestaan onnistuu ilman merkittäviä muutoksia muuhun järjestelmään. 3. Järjestelmän arkkitehtuuri 3.1 Järjestelmän yleiskuvaus OtaShop2-verkkokauppa Järjestelmä on pyritty toteuttamaan J2EE-standardin mukaan ja se on suunniteltu helposti laajennettavaksi. Toiminnallisuus on eriytetty omiin paketteihin, ja jokaisella paketilla on julkinen rajapinta jonka kautta sitä käytetään. Modulaarinen rakenne helpottaa järjestelmän laajentamista sekä ylläpitämistä. Seuraavassa lyhyesti kunkin paketin tarkoitus ja toiminta. 2 of 18 04/05/ :08 PM

3 Paketin nimi DAO Cart Order Payment Language Order DAO Validator Lyhyt kuvaus paketin toiminnasta Tietokantahakujen ja kannan ylläpitämiseen liittyvät toiminnot Ostoskorin sekä HTTP-istunnon hallinta Tilausten sekä tuotteiden hallintaan liittyvät toiminnot Maksamisen ja eri maksutapojen hallinta Sivulla näkyvien tekstien lokalisaatio Tilausten luontiin ja tallentamiseen liittyvät toiminnot Käyttäjän kirjoituksien validointi turvalliseen muotoon Pakettien keskinäiset suhteet esitetään seuraavassa kuvassa. 3 of 18 04/05/ :08 PM

4 3.1.2 OS2admin Järjestelmän ylläpito-osio, OS2admin, on toteutettu erillisenä sovelluksena. OS2admin suoritetaan eri ympäristössä kuin itse verkkokauppa, mutta molemmat järjestelmät käyttävät samaa tietokantaa. Suosituksena on että OtaShop2-verkkokauppa asennetaan eri palvelimelle kuin OS2admin. Näin verkkokaupan rikkoutuminen tai siihen kohdistuneet hyökkäykset eivät suoraan pääse vaikuttamaan ylläpitojärjestelmään. Tämä parantaa myös tietoturvaa merkittävästi. 3.2 Suunnittelufilosofia OtaShop2-järjestelmä on suunniteltu käyttäen tunnettuja suunnittelumalleja. Käytetyt mallit sekä niiden lähemmät kuvaukset löytyvät henkilökohtaisen tehtävän Design Patterns -harjoituksesta. 3.3 Java-paketit ja luokat Seuraavassa on selvitetty tarkemmin Otashop2:n java-pakettien toiminta sekä niiden sisältämät luokat. Luokkien tarkka toteutus on luettavissa JavaDoc-dokumentaatiossa DAO DAO-paketti sisältää kaikki tietokantaan liittyvät toiminnot. Paketissa mallinnetaan myös kaupassa myytävät tuotteet, sekä niihin liittyvät tiedot. Paketti on suunniteltu siten että se mahdollistaisi uusien tuotetyyppien lisäämisen mahdollisimman helposti. Paketin mallina on käytetty sekä builder että factory -suunnittelumalleja, ja tämän avulla uusien tuotetyyppien lisääminen onnistuu ilman isompia muutoksia. DAO-paketin tarkempi kuvaus Paketissa on käytetty sekä builder että factory suunnittelumalleja. ItemBuilder luokka toimii sekä builderina että factorynä. DAO käyttää J2EE-ympäristön tarjoamaa yhteysvarantoa (connection pool) tietokantayhteyden luomiseen. Paketin 4 of 18 04/05/ :08 PM

5 toimintoja käytetään ShopDAO-rajapinnasta, josta saadaan halutunlainen DAOTypes-luokan tyyppien mukainen DAO-instanssi. ShopDAO:n finditems() -metodi hakee haluttujen tuotteiden tiedot tietokannasta. Sille annetaan argumenttina valmiit SQL where- ja order by -lauseet, jotka voidaan muodostaa automaattisesti ShopDAORequestParser-luokan avulla. ShopDAO käyttää abstraktista ItemBuilder-luokasta saatavaa tiettyä tuotetyyppiä rakentavaa instanssia myytävien tuotteiden mudostamiseksi tietokannan datasta. Item-rajapinnan toteuttaville tuoteluokille voidaan antaa ennaltamääräämätön määrä attribuutteja, joten rajapintaa voidaan käyttää täysin eri tyyppisten tuotteiden kehyksenä Cart Cart-paketti toimii asiakkaan ostoskorina verkkokaupassa asioinnin aikana. Halutut tuotteet voidaan tallettaa ostoskoriin, ja kun asiakas on valmis tekemään tilauksen, niin tiedot välitetään eteenpäin Order-paketille. Ostoskoriin voi vapaasti lisätä tuotteita sekä poistaa niitä istunnon aikana. Cart-paketin tarkempi kuvaus Cart-paketti koostuu vain yhdestä luokasta. ShoppingCart-luokka sisältää metodit joilla tuotteita voidaan lisätä, poistaa, muuttaa, tyhjentää koko kori ja kysyä korissa olevien tuotteiden määrää. Tuotteiden lisääminen tai poistaminen muuttaa automaattisesti tuotteiden lukumäärätiedon, eikä asiakkaan tai kutsuvan luokan tarvitse ottaa asiaan kantaa. Korissa voi olla samaa tuotetta useampi kuin yksi kappale ja tämän tiedon tallennus on toteutettu Item-rajapinnan kautta. Cart:n hallinnoima ostoskoritieto pysyy tallessa koko käyttäjän vierailun ajan, koska valinnat säilötään sovelluspalvelimen muistiin, käyttäjää varten luotuun istuntoon. Käytännössä jokaista verkkokaupassa vierailevaa käyttäjää varten luodaan HashMap-tyyppinen olio, johon käyttäjän toivomat Item-rajapinnan toteuttavat tuotteet tallennetaan Order Order-paketti on suunniteltu builder-suunnittelumallia käyttäen. Order paketti pitää huolen asiakkaan ja tilauksen tietojen hallinasta. Order saa asiakastiedot käyttöliittymältä, josta tarkemmin kappaleessa Käyttöliittymä. Asiakastiedot tallennetaan istuntoon, josta ne välitetään eteenpäin payment-paketille. 5 of 18 04/05/ :08 PM

6 Order-paketin tarkempi kuvaus Order-paketti koostuu abstraktista CustomerBuilder-luokasta sekä sen palauttamista asiakasta kuvaavista luokista. Paketin ulkopuoliset luokat käyttävät aina CustomerBuilder-luokkaa, joka automaattisesti asettaa asiakas-tyypin oikein. Kaikki asiakasta kuvaavat luokat totetuttavat Customer-rajapinnan. CustomerBuilder mahdollistaa asiakastietojen määrittelemisen eri tavoilla. OtaShop2-projektin ensimmäisessä vaiheessa asiakastietojen määritteleminen tehdään aina HTML-formin avulla, ja CustomerBuilder palauttaa FormCustomerBuilder-luokan. Pienillä muutoksilla CustomerBuilder-luokkaan on mahdollista toteuttaa asiakastietojen hakeminen esimerkiksi tietokannasta tai evästeestä (cookie) Payment Payment-paketti huolehtii verkkomaksu-tapahtumasta. Paketti on toteutettu siten että se mahdollistaa erilaiset maksutapahtumat. Tällä hetkellä hyväksytyt ja toteutetut maksutavat ovat verkkomaksu Nordean, Leonian ja Kultarahan verkkopankeissa. Myös varmistettu verkkomaksu Visalla (Verified by Visa) on tuettu. Edellisten lisäksi sallitaan vielä laskulla maksaminen. Luokissa on käytetty template method -suunnittelumallia ja tämän johdosta uusien tapausten lisääminen on jatkossa helppoa. Paketti keskustelee Order-paketin kanssa, jolta se saa tarvittavat tiedot laskun summasta sekä maksutavasta. Näitä tietoja hyväksikäyttäen se ohjaa asiakkaan oikean pankin sivuille, josta maksu varsinaisesti suoritetaan. OtaShop2-järjestelmä siis ei suoraan käsittele asiakkaan maksutapahtumaa, vaan pankki hoitaa maksun ja välitää onnistuneesta maksusta tiedon takaisin Otashop2-järjestelmään. Tieto epäonnistuneesta tai keskeytetystä maksusta välitetään vastaavalla tavalla kauppaan. 6 of 18 04/05/ :08 PM

7 Payment-luokka on paketissa abstrakti ja eri maksutavat perivät sen. Järjestelmän muut osat käyttävät tätä abstraktia luokkaa, eivätkä joudu käsittelemään eri maksutapoja. Tämä mahdollistaa uusien maksutapojen lisäämisen, ilman että järjestelmän muita osia tarvitse muuttaa. PaymentTypes-luokka määrittelee vakiot joilla eri maksutapoja voidaan kutsua. Maksutavan määrittää kaupan asiakas, joka asiakastietojen kyselyn yhteydessä voi valita maksutavan Language Language-paketti huolehtii verkkokaupan lokaalisaatiosta, eli monikielisyydestä. 7 of 18 04/05/ :08 PM

8 Tarkempi kuvaus language-paketin luokista Language paketissa on ainoastaan yksi luokka. Se on järjestelmän apuluokka joka palauttaa halutuista teksteistä aina kielivalinnan mukaan oikean kielisen version. LanguageManager luokka on toteutettu Singleton suunnittelumallilla. Eri kielet on toteutettu XML-tiedostona, josta haetaan oikea teksti, riippuen valitusta kielestä. "languageconfig.xml"-tiedosto sisältää kaikki kaupassa käytetyt tekstit. Jokainen kieli on määritelty language-nimisessä elementissä, joka sisältää Text-tyyppisiä elementtejä. Text-elementin id määrittelee kohdan jossa tekstiä käytetään. Jokaisen tiedostossa määritellyn kielen tulisi sisältää kaikki text-elementit ja käännökset. Uusien kielten lisääminen on mahdollista muuttamalla Language-pakettia ja XML-tiedostoa. Tällä hetkellä on toteutettu kauppa suomeksi, ruotsiksi ja englanniksi Order DAO Order DAO-paketti huolehtii verkkokaupan tilausten luonnista ja tallennuksesta tietokantaan. Kaikki tilaukset luodaan tämän paketin metodeja käyttäen. 8 of 18 04/05/ :08 PM

9 9 of 18 04/05/ :08 PM

10 Tarkempi kuvaus order dao-paketin luokista Order DAO paketin tehtävä on ylläpitää data-abstraktiota kaupan ja ylläpidon välillä. Paketissa on luokat yleiseen formaattiin johon tilaukset tallennetaan (riippumatta mitä myydään). Order ja OrderItem luokat sisältävät kaiken tarvittavan datan mitä tilauksiin tarvitaan. Tilausten tallennus näihin luokkiin hoidetaan builder mallin mukaisesti Order*Builder luokilla. Builderit osaavat muodostaa data objekteja sekä kaupasta annetuista Customer, Payment ja ShoppingCart objekteista sekä tietokannan resultsetistä. OrderDAO luokkaa käyttäen voi tilauksia hakea sekä niiden tietoja päivittää kantaan Validator Validator-paketti huolehtii käyttäjän syötteiden validoinneista sellaiseen muotoon, että syötteitä on turvallista käyttää tietokantakyselyissä. Tarkempi kuvaus validator-paketin luokista Validator paketissa on ainoastaan yksi luokka. Se on järjestelmän apuluokka joka muokkaa tarvittaessa annetun tekstin turvalliseen muotoon. Kaikki tietokannan kyselyihin käytettävät käyttäjien syötteet kierrätetään tämän apuluokan läpi, jolloin niistä poistetaan kaikki haitallinen syöte. Tämä tekee erillaiset "injection"- sekä "cross-site scripting"-hyökkäykset vaikeammaksi. Hyökkäyksiä ja validointia on käsitelty tarkemmin myöhemmin, kappaleessa 6.1 Verkkokaupan tietoturva. 3.4 OS2admin tekniikka Verkkokaupan ylläpito toteutaan omana erillisenä sovelluksenaan. OS2admin sisältää kaikki järjestelmän hallintaan liittyvät toiminnot, kuten tilausten ja käyttäjätunnusten hallinnan. Admin-paketti sisältää myös mahdollisuuden nähdä ja tulostaa eri osastoille tärkeitä näkymiä, esim kaikki laboratorion tilastot tai asiakastiedot julkaisujen välittämisen. Ylläpito voidaan ajaa eri ympäristössä kuin itse verkkokauppa, joten sen voi sijoittaa kokonaan erilliselle pavelimelle. Jos sovellukset kuitenkin ajetaan samalla palvelimella, voidaan ne asentaa eri palvelinprosesseille ja näin halutessa myös eri porttiin. Tämä mahdollistaa samalla sen että pääsyä admin-osioon voidaan rajoittaa sisäisesti ip-osoitteen mukaan, sekä ulkoisesti palomuurilla. Os2admin-järjestelmä käyttää samaa tietokantapalvelinta kuin verkkokauppa. Tietokantaan lisätään tarvittavat kentät kuvaamaan tilausten ja maksujen tilaa. Tietokantaan luodaan myös omat relaatiot joilla hallitaan ylläpitojärjestelmän käyttäjä- ja ryhmätietoja. Verkkokauppa on rakennettu siten, että tilauksen yhteydessä muutetaan ja lisätään tietoja julkisiin kentiin. Admin-puolen kentät ovat käytettävissä ainoastaan ylläpidon kautta. Ylläpito on toteutettu kokonaan omana sovelluksenaan, eikä se ole suorassa yhteydessä kauppaan, muuten kuin tietokannan kautta. Ylläpitosovelluksen tietokanta on kuvattu tarkemmin seuraavassa kappaleessa. Ylläpitopuolen sovellusarkkitehtuurin perustana on käytetty Apache projektin Struts:ia. Struts toteuttaa J2EE suunnittelumalli nro 2. mukaisen MVC-kehyksen (Model, View, Controller). Käytännössä tämä siis tarkoittaa, että pyyntöjen käsittely ja ohjaus, yksittäisen näkymän logiikka sekä esityskerros ovat toisistaan eriytettynä. Tekniikan syvällinen ymmärtäminen vaatii asiaan perehtymistä. Seuraavassa on esitetty sovelluksen liittyvän toiminnot (Actions) sekä toimintojen yhteydessä siirrettävät lomakkeet (Forms). Struts Action -luokat Action Roolit Kuvaus Welcome.do * Järjestelmän etusivu OrdersLimited.do * Kirjautuneen käyttäjän vastuualueen oman tilaukset Orders.do support Näkymä kaikkiin järjestelmässä oleviin tilauksiin 10 of 18 04/05/ :08 PM

11 vieworder.do * Yksittäisen tilauksen katseleminen viewdistributedorder.do * Hajautetun tilauksen katseleminen statechange.do * Yksittäisen tilauksen tilan muuttaminen Finance.do finance Maksuliikenteeseen liittyvä etusivu refnumber.do finance Support.do support Tukitoimintojen etusivu Yksittäisen tilauksen / hajautetun tilauksen etsiminen viitenumeron perusteella ordersearch.do support Tilausten etsiminen päivämäärä- ja tilahaulla UserAdmin.do accounts Käyttäjähallinnan etusivu selectuser.do accounts Yksittäisen käyttäjän valitseminen adduser.do accounts Yksittäisen käyttäjän lisääminen modifyuser.do accounts Yksittäisen käyttäjän muokkaaminen deleteuser.do accounts Yksittäisen käyttäjän poistaminen Replication.do startrepliation.do administrator Replikoinnin etusivu administrator Replikoinnin käynnistäminen Logoff.do * Uloskirjautuminen Struts Form -luokat Form emptyform statechangeform refnumform ordersearchform selectorderform Kuvaus Geneerinen tyhjä lomake Tilauksen tilan muuttamislomake Viitenumerohaun lomake Tilausten hakeminen päivämääräväliltä Yksittäisen tilauksen valinta startreplicationform Replikoinnin apulomake selectuserform modifyuserform adduserform deleteuserform Käyttäjätiedot valittaessa Käyttäjätiedot muokatessa käyttäjätiedot lisättäessä Käyttäjän poistamiseen liittyvä lomake Sovelluspalvelimien välillä ei ole yhteistä standardia siitä, miten ajoitettuja toimintoja pitäisi suorittaa. Toki lähes jokaisessa kaupallisessa vaihtoehdossa on oma tapansa asian hoitamiseen. Projektin vaatimuksiin kuului kuitenkin riippumattomuus myös tietystä sovelluspalvelimesta, joten lähdimme etsimään asiaan ohjelmallista ratkaisua. Verkosta löysimme vapaassa jakelussa olevan Pulsar - J2EE Scheduler -nimisen vaihtoehdon. Kyseinen ajastin oli tehty lähinnä käytettäväksi IBM:n WebSphere -ympäristössä. Pienillä muokkauksilla saimme siitä tehtyä yleispätevän version projektin pienen mittakaavan tarpeisiin. Käytännössä otashop2:seen liittyviä ajoitettuja toimintoja on kaksi: julkaisutietojen replikointi ja tilausilmoitusten lähettäminen laboratorioiden vastuuhenkilöille, molemmat kerran vuorokaudessa. Käytännössä ajoitetut toiminnot konfiguroidaan os2admin:n tiedostoon schedule.xml. 3.5 Tietokantakuvaus OtaShop2-tietokantaan on talletettu kaikki pysyvä tieto. Kannan sisältö muodostuu kahdesta pääasiallisesta osasta, kirjaston olemassaolevasta järjestelmästä siirrettävät tiedot (julkaisutiedot ja laboratorioiden tiedot) sekä OtaShop2:n omat tiedot. Julkaisutiedot saadaan TKK:n kirjaston Tenttu-tietokannasta, josta ne kerran vuorokaudessa replikoidaan OtaShop2:n tietokantapalvelimelle. Kirjaston omasta tietokannasta siirretään myös laboratorioiden vastuualuekoodit ja osastotiedot. OtaShop2-järjestelmän tuottamat tilaustiedot tallennetaan tietokantaan ja niiden tilaa ylläpidetään. Tietokanta sisältää myös kaupan muita tietoja, kuten ylläpitäjien käyttäjätietoja Tietokannan tarkka kuvaus 11 of 18 04/05/ :08 PM

12 OtaShop2-tietokannan rakenne on kuvattu seuraavissa ER-kaavioissa: Julkaisut: publication-taulun kuvaus kokonaisuudessaan: Name Null? Type PUB_ID NOT NULL VARCHAR2(20) PRICE NOT NULL NUMBER(10) DOC_TYPE NOT NULL NUMBER(2) RESPONSIBLE_AUTHOR NOT NULL ALL_AUTHORS VARCHAR2(512) TITLE NOT NULL VARCHAR2(500) PUB_YEAR NOT NULL NUMBER(4) RESP_AREA_CODE NOT NULL VARCHAR2(10) DATE_SAVED NOT NULL VARCHAR2(10) DATE_ALTERED NOT NULL VARCHAR2(10) MAG_NAME VARCHAR2(300) MAG_VOLUME VARCHAR2(10) MAG_NUM VARCHAR2(10) SER_NUM VARCHAR2(10) SER_AUTHORS SER_TITLE VARCHAR2(512) EDITION PUB_PLACE PUBLISHER CONFERENCE VARCHAR2(200) PATENT PATENT_OWNER PATENT_INVENT PATENT_APPLICATION PAGE_NUMBERING KEYWORDS_ENGL VARCHAR2(300) FOREIGN_PUB VARCHAR2(4) WEIGHT_FACTOR VARCHAR2(10) PROJECT SAVER_TRIP_ID CONF_AUTHORS CONF_TITLE ELECT_AVAIL 12 of 18 04/05/ :08 PM

13 AUTH_TITLE DESCRIPTION VARCHAR2(1024) Tilaukset: Ylläpito, käyttäjät: 13 of 18 04/05/ :08 PM

14 3.6 Liitännät muihin järjestelmiin Tenttu-tietokanta OtaShop2-järjestelmä käyttää kirjaston Tenttu-tietokantaa julkaisutietojen ylläpitämiseen ja hallintaan. OtaShop2:n julkaisutietokanta replikoidaan kerran vuorokaudessa Tenttu-kannasta. Tenttu-kannasta saadaan myös laboratorioiden vastuualukoodit. Järjestelmän ylläpitäjä voi myös halutessaan käynnistää replikoinnin järjestelmän ylläpitosovelluksesta. Tietojen siirto tapahtuu Tentun Trip-http -rajapinnan kautta. Määrättyyn URL-osoitteeseen tehty http-pyyntö palauttaa Tentussa siirrettäväksi merkityt tiedot tekstimuodossa, siten että merkki (ASCII 164) tarkoittaa uuden tietueen alkua, ja merkki (ASCII 124) uuden kentän alkua tietueen sisällä. Siiron tekevä proseduuri lukee tätä tekstitiedostoa http-protokollan välityksellä merkki kerrallaan ja muotoilee datan OtaShop2:n tietokannan hyväksymään muotoon. Datan säilyttämiseksi virhetilanteissa tiedonsiirtoproseduuri hakee tiedot Tenttu-kannasta ensin väliaikaistauluihin publication_tmp ja lab_tmp, jotka ovat publication ja lab -taulujen identtiset kopiot. Kun on varmistettu, että data on siirtynyt eikä siirron aikana tapahtunut virheitä, tyhjennetään publication ja lab -taulut kokonaan, ja tiedot kopioidaan niihiin väliaikaistauluista. Näin varmistetaan ettei tietokantaan koskaan jää vanhentunutta dataa päivityksen jälkeen Verkkomaksu OtaShop2 ei itse hallitse verkkomaksutapahtumia, vaan itse maksu suoritetaan pankin omilla WWW-sivuilla. OtaShop2 välittää pankin maksujärjestelmään maksettavan summan, ja kun maksu on suoritettu saa järjestelmä tästä tiedon. Pankit ja luottokorttiyhtiöt joita tämä koskee on määritelty tarkemmin Payment java-paketin kuvauksessa. Verkkomaksun tietoturva Verkkomaksu tapahtuu siten että OtaShop2-järjestelmä välittää pankille HTML-lomakkeen johon on tallennettu kaikki maksuun liittyvät tiedot. Tietojen tarkka esitystapa vaihtelee hieman pankista toiseen, mutta tiedot ovat pääosin samat, eli asiakastiedot sekä maksun summa. Tietoihin lisätään aina kaupan oma salainen avain jolloin pankki voi yksilöidä kaupan josta maksu on lähtöisin ja varmistetaan maksun aitous. Tiedoista muodostetaan merkkijono konkatenoimalla kentät peräkkäin, ja tästä jonosta lasketaan 128-bittinen MD5-tarkistussumma, joka varmistaa ettei asiakas tai muu taho pääse muuttamaan maksun tietoja kesken maksutapahtuman. Kaupan omaa tarkistusavainta käytetään vain tarkistussumman laskemisen yhteydessä, eikä sitä välitetä salaamattomana kaupanteon missään vaiheessa. Kaupan avaimen salaisena pysyminen on ehdottoman tärkeää. Mikäli avain joskus tulisi julki olisi maksujen väärentäminen mahdollista. Sen sijaan tarkistussumma on mahdollista lukea pankille vältettävistä tiedoista. Avaimen johtaminen annetusta tarkistussummasta on kuitenkin käytänössä mahdotonta. MD5-algoritmia vastaan ei ole olemassa tehokkaita hyökkäyksiä, joten se oletetaan turvalliseksi. Hyökkäyksistä hajautusfunktioita vastaan on keskusteltu tarkemmin kappaleessa 6.2. Otashop2-järjestelmä varmistaa maksun siten että pankille välitetään tapahtuman yhteydessä paluuosoitteet joihin pankin palvelin ohjaa asiakkaan maksun jälkeen. Onnistuneelle ja epäonnistuneelle maksulle on molemille omat osoitteensa. Paluuosoitteeseen lisätään myös maksun parametrit, joten kaupassa voidaan helposti yksilöidä maksu paluuosoitteen ja parametrien perusteella. Nämä parametrit ovat osana MD5-varmistettua merkkijonoa, joten asiakas ei pääse muuttamaan näitä kesken tapahtuman. E-maksu antaa myös mahdollisuuden peruttaa jo tehtyjä maksuja, joten epäselvissä tilanteissa on mahdollista peruttaa maksu. Maksun peruutusta ei kuitenkaan ole toteutettu järjestelmään, vaan se on tehtävä manuaalisesti. Yhteys pankkiin muodostetaan käyttäen SSL-suojattua HTTPS-protokollaa. Protokollan avulla salataan kaikki liikenne joka liikkuu asiakkaan ja pankin välillä ja tekee salakuuntelun äärimmäisen vaikeaksi. SSL käyttää julkisen avaimen salausta jolla voidaan varmistua pankin "henkilöllisyydestä". Tämä tapahtuu siten että asiakaalle näytetään tieto pankin julkisesta avaimesta kun hän tulee pankin palvelimelle. Pankin avaimen tarkistaminen jää kuitenkin lopulta asiakkaan vastuulle. Otashop2-järjestelmässä ei ole mahdollisuutta autetikoida pankin palvelinta esim. spoofing- tai Man-in-the-middle-hyökkäyksen yhteydessä. Spoofing tarkoitta että joku kolmas taho väärentää pankin palvelimen, jota asiakas tietämättään käyttää oikean palvelimen sijaan. Man-in-the-middle-hyökkäys puolestaan tarkoittaa sitä että hyökkääjä tekee spoofing-hyökkäyksen sekä asiakkaan että pankin suuntaan, välittäen tiedon näiden välillä. Samalla hyökkääjä pystyy muuttamaan kaikkea tietoa mitä yhteydessä välitetään, esim tilinumeroita ja salasanoja. Kuten edellisessä kappaleessa mainittiin, niin asiakkaan maksun väärentäminen tai väärinkäyttäminen vaatisi MD5-suojaksen murtamista, joten tämä tyylinen hyökkäys ei ole suuri riski. Suurin uhka liittyy siihen että hyökkäjä saisi haltuunsa asiakkaan pankkitunnuksen ja salasanan. Tämä hyökkäys ei kuitenkaan kohdistu Otashop2:a, vaan asiakasta kohtaan. Kuten edellä on esitetty ei järjestelmä pysty takaamaan asiakkaan täydellistä turvaa. Pankkimaksujen väärinkäyttäminen on järjestelmän kannalta lähinnä teoreettinen riski, mikäli kaupan avain on pysynyt salaisena. Avaimen arvaaminen tai laskeminen vaatisi MD5-protokollan murtamista, mikä on matemaattisesti erittäin vaikeaa. Mikäli MD5-protokollaa vastaan olisi olemassa tehokkaita hyökkäyksiä ei tätä maksutapaa enää voitaisi käyttää, sillä silloin olisi mahdollista väärentää maksuja. Verkkokauppa sallii myös laskulla tilaamisen ja tässä yhteydessä tilaus välitetään jo ennen laskun maksua. Tämän maksutavan mahdollinen väärinkäyttäminen on huomattavasti helpompaa kuin verkkomaksujen väärentäminen. Voidaan kuitenkin todeta, että koska julkaisuja välitetään omakustannushintaan, eivät käsiteltävät summat ole isoja, joten saavutettu turva on riittävä. 4. Käyttöliittymä 14 of 18 04/05/ :08 PM

15 Verkkokaupan käyttöliittymä ja ulkoasu on kuvattu tarkemmin erillisessä ulkoasudokumentissa. 4.1 JSP Verkkokaupan käyttö tapahtuu normaalia WWW-selainta käyttäen. Asiakkaan normaali näkymä on OtaShop2-verkkokauppa, ja ylläpitäjät käyttävät pääosin omaa OS2admin-järjestelmää. Kaupan ja ylläpitojärjestelmän kaikki toteutetut toiminnot tulevat olemaan käytettävissä selaimen kautta. Toteutus on tehty siten että itse kauppa- ja ylläpito-osiot eriytetään mahdollisuuksien mukaan eri palvelimille. Jos mahdollisuutta eri palvelinten käyttöön ei ole, voidaan tämä toteuttaa siten että ylläpito-järjestelmä ajetaan eri J2EE-palvelimen alla kuin mitä itse kauppa. Tällä tavalla saavutetaan seuraavat edut: Virhe kaupan koodissa ei vaaranna ylläpito-osiota Kauppa ja ylläpito pyörivät eri palvelimilla, joten pääsyä ylläpito-sivustoon voidaan rajata esim. Otaniemen sisään, tai vain erikseen sallituilta koneilta. Rajaaminen tulee tehdä sekä palvelimessa että käyttäen palomuuria. Kauppa sekä sen ylläpito voidaan sammuttaa ja/tai päivittää toisistaan riippumatta. Kaupan ulkoasu on tehty yhtenäiseksi OtaShop1-verkkokaupan kanssa. OtaShop1:n ulkoasu on suunniteltu yhdessä TKK:n viestintäkeskuksen kanssa joka on myös hyväksynyt ulkoasun. OtaShop1 on toinen verkkokauppa jonka TKK:n ATK-keskus on tilannut ja jossa myydään TKK:n logotuotteita, kuten pinssejä, t-paitoja ja mukeja. OtaShop1 toteutetaan PHP-tekniikkaa käyttäen. Koska ulkoasut ovat yhtenäiset voidaan kauppoja tarpeen vaatiessa käyttää myös rinnakkain. OtaShop2 on kuitenkin alusta lähtien suunniteltu siten että se on helposti laajennettavissa myös logo-tuotteiden myyntiin soveltuvaksi. Käyttöliittymä toteutetaan Java Server Pages-teknologiaa (JSP) käyttäen. JSP mahdollistaa dynaamisesti luotavien sivujen esittämisen ja antaa mahdollisuuden toteuttaa monimutkainen toiminnallisuus normaalina Java-ohjelmakoodina. Kappaleessa Yleiskuvaus on esitetty käyttöliittymän sekä Java-pakettien keskinäiset suhteet. 5. Tekniset päätökset 5.1 Käytetyt tekniikat Postgresql Otashop2-järjestelmään päätettiin projektin loppuvaiheessa vaihtaa tietokantapalvelinta avoimeen PostgreSQL-tietokantapalvelimeen. Palvelin on kehitetty nk. Open Source projektissa, eli lähdekoodi on saatavissa ja se on julkaistu BSD-lisenssin alla. Tämä antaa käyttäjälle oikeuden käyttää, jakaa ja muokata koodia mielensä mukaan, kunhan alkuperäinen lisenssi liitetään mukaan. Käyttöoikeus sisältää myös kaikki kaupalliset tarkoitukset. Palvelin tukee SQL-92 määritystä, mutta sisältää joitain laajennettuja ominaisuuksia. Otashop2-projektissa pyritään jatkossakin välttämään valmistajakohtaisia laajennuksia, jotta kannan vaihtaminen olisi mahdollisimman helppoa Apache WWW-palvelin Apache on tällä hetkellä käytössä TKK:n ATK-keskuksessa. Muita WWW-palvelimia ei käytetä. Tästä syystä myös OtaShop2:ssa tulee käyttää Apache WWW-palvelinta. Apache on tällä hetkellä suosituin WWW-palvelin markkinoilla. Apache on helposti laajennettavissa erillaisilla lisämoduleilla ja tarvitsemamme toiminnot löytyvät jo valmiiksi. Kaiken lisäksi Apache on ilmainen ja saatavilla hyväksymällä Apachen oma lisenssi joten se soveltuu erinomaisesti projektin käyttöön Apache Tomcat Tomcat on Apache-projektin Java-sovelluspalvelin. Projektissa käytetään Apache WWW-palvelinta joten ohjelmistot on rakennettu toimimaan keskenään saumattomasti. Tämän lisäksi Apache-projektissa on useita työkaluja jotka helpottavat projektin kääntämistä ja testaamista ja toimivat yhteen Tomcat-palvelimen kanssa. Projektissa käytetään Maven-käännösympäristöä, sekä JUnit-yksikkötestausjärjestelmää. 5.2 Hylätyt tekniikat PHP Projektin alussa järjestelmän toteutusvaihtoehdoissa annettiin asiakkaan puolesta joko PHP tai J2EE. OtaShop1, on toteutettu PHP:tä käyttäen. Neuvotteluissa asiakkaan kanssa totesimme kuitenkin että J2EE on sopivampi alusta OtaShop2:n toteutukseen sillä se mahdollistaa turvallisemman ja helpommin laajennettavan järjestelmän toteuttamisen. Tämän lisäksi kaikilla projektin jäsenillä on kokemusta Java-projekteista joten J2EE:n opetteluun ei kulu ylimääräistä aikaa. Vaatimusta tarkennettiin myöhemmin siten että J2EE on nyt vaatimus asiakkaan puolesta Oracle 9i standard 15 of 18 04/05/ :08 PM

16 Oraclen tietokantapalvelin on ollut projektin käytössä aina projektin kolmanteen iteraatioon asti. Palvelin päätettiin kuitenkin tässä vaiheessa vaihtaa, sillä Oraclen lisenssi rajoittaa palvelimen käyttöä kaupallisiin tarkoituksiin. Koska saatavilla on vastaavilla toiminnoilla olevia vapaita tietokantapalvelimia päätettiin Oracle vaihtaa PostgreSQL-tietokantapalvelimeen. 6. Tietoturva Tietoturvan kannalta järjestelmän tärkein osuus on ylläpito-sivusto. Ylläpito-järjestelmän kautta tulee olla pääsy kaikkiin kaupan toimintoihin ja tilauksiin. Täten myös sen suojaaminen on ensisijaisen tärkeää. Itse kauppa-osuus ei ole yhtä kriittinen, mutta samalla sen suojaaminen on vaikeaa, sillä kaupaan tule olla pääsy kaikkialta. Seuraavassa on selvitetty tarkemmin eri osioiden tietoturvaan liittyviä seikkoja. Tietoturvan suunnittelussa ja toteuttamisessa on pyritty ottamaan huomioon tunnettuja ja yleisiä heikkouksia, joita on esitetty OWASP:in ( The Open Web-Application Security Project ) Top 10-listassa, jossa on esitetty vaarallisimmat ja yleisimmät ongelmat verkkosovellusten tietoturvassa. Seuraavassa on listattu järjestyksessä kymmenen vaarallisinta virhettä OWASP Top 10-listan mukaan: 1. Unvalidated input Syötteen validointi, eli käyttäjän antamia syötteitä ei tarkisteta ennen käyttöä 2. Broken Access Control Salasanasuojatuissa sivustoissa on usein rajoitettu mitä osia kukin käyttäjä pääsee näkemään ja muuttamaan. Monesti oikeuksien tarkistus on toteutettu siten että ne pystyy kiertämään. 3. Broken Authentication and Session Management Yleensä käyttäjän kirjautumisia ja oikeuksia seurataan käyttäen evästeitä. Mikäli evästeiden käyttö on huonosti toteutettu, voidaan niitä käyttää kiertämään valvonta. 4. Cross Site scripting Verkkosovelluksia voidaan käyttää välittämään hyökkäyksiä käyttäjän koneelle. 5. Buffer overflow Puskurin ylivuotoa voi johtaa siihen että hyökkääjä voi suorittaa haluamaansa koodia palvelimella. Yleensä tämä on läheisesti yhteydessä virheeseen Injection flaws Kun sovellukset välittävät parametreja voidaan sekaan laittaa käskyjä. Mikäli ei syötteitä ja parametreja tarkasteta ennen käyttöä voi tämä mahdollistaa koodin tai käskyjen ajamisen palvelimella. 7. Improper Error Handling Virhetapausten vääränlainen hallinta voi jopa johtaa siihen että hyökkääjä ottaa koneen haltuunsa. Yleensä virhetapauksia tai niiden antamaa informaatiota, kuten versionumeroita, voi käyttää hyväkseen muissa hyökkäyksissa. 8. Insecure storage Verkkosovellus tarvitsee yleensä tietokannan johon pysyvää tietoa tallennetaan. Mikäli tietokanta on huonosti suojattu, tai esim salasanat helposti saatavilla, tekee tämä palvelimen alttiiksi eri hyökkäyksille. 9. Denial of Service DoS tarkoittaa sitä että hyökkääjä käyttää palvelimen resursseja siinä määrin että normaali toiminta vaikeutuu tai jopa tulee mahdottomaksi. Huonosti ohjelmoidut turvamekanismit voivat helpottaa tällaisia hyökkäyksiä. 10. Insecure Configuration Management Vaikka verkkosovellus itsessään olisikin turvallinen niin se on silti alttiina hyökkäyksille, jos palvelin on suojaamaton. Tämän takia on tärkeää että palvelin on konfiguroitu oikein ja että käytetyt ohjelmistot ovat päivitetty uusimmilla tietoturvapäivityksillä. 6.1 Verkkokaupan tietoturva Kauppa-osion tietoturvasta on keskusteltu myös kappaleessa Verkkomaksu, jossa on lähinnä keskitytty maksutapahtuman turvallisuuteen. Näitä asioita ei tulla toistamaan tässä, vaan ne sivutetaan muutamalla huomautuksella. Syötteen validointi/puskurin ylivuoto OWASP-listalla on listattu tärkeimmäksi yksittäiseksi viaksi parametrien validointi, tai sen puuttuminen. Epäsuorasti myös erilaiset puskurin ylivuotoon liittyvät hyökkäykset liittyvät tähän samaan ongelmaan. OtaShop2-verkkokaupassa käyttäjä pääsee syöttämään vapaamuotoisia tietoja teoksen hakemisen yhteydessä, sekä asiakastietojen syöttämisen yhteydessä. Nämä välitetään sitten eteenpäin tietokannalle, joten mahdollinen "SQL-injection", eli tietokantakäskyjen ajaminen paramterien seassa on mahdollinen. Tästä syystä kaikki parametrit tarkistetaan ja varmistetaan että ne ovat oikeata tyyppiä ja järkevissä rajoissa ennen kuin ne tallennetaan kantaan, tai niiden mukaan tehdään haku. Varmistamalla että arvot ovat halutun kaltaisia voidaan suojatua useimpia tämän tyyppisiä virheitä vastaan, kuten esim. puskurin ylivuotoa. OtaShop2-järjestelmän syötteiden validointi on tehty siten että kaikki syötteet kulkevat validator.validate-luokan kautta, ennen kuin niitä käytetään järjestelmässä. Yhden luokan käyttäminen tekee validoinnin muuttamisen jälkeenpäin helpoksi, sillä riittää kun tätä yhtä luokkaa muuttaa. Samalla myös bugien mahdollisuus vähenee, kun kriittistä koodia on vain vähän ja kaikki löytyy samasta paikka. Validate-luokka tarkastaa annetun stringin ja siinä olevat merkit. Sallittuja merkkejä ovat alfanumeeriset merkit, sekä muutamat erikoismerkit, jotka saattavat esiintyä nimissä. Tällaisia merkkejä ovat seuraavat merkit "@,.-_?&/". Sulkuja, puolipistettä tai lainausmerkkejä ei sallita, sillä niitä on mahdollista käyttää esim, SQL-injection hyökkäykseen. Validate lukee annetun stringin ja tarkastaa sen säännöllisen lausekkeen avulla. Mikäli merkkijono sisältää muita kuin sallittuja merkkejä, katkaistaan se tämän kohdalta ja palautetaan merkkiä edeltävä osa. Jos ensimmäinen merkki on kielletty 16 of 18 04/05/ :08 PM

17 palautetaan "null". Merkkijonon alun palauttaminen voi helpottaa toimintaa virhetilanteissa, jos esim asiakkaan nimessä on erikoisia merkkejä. Tämä mahdollistaa myös sen että jälkeenpäin voidaan mahdollisesti tarkastaa minkä tyyppinen hyökkäys on ollut kyseessä. Validate suojaa järjestelmää myös puskurin ylivuodolta. Perinteisesti puskurin ylivuoto on ollut ongelma kielissä jossa ei ole puskurien tarkistusta, eli käytänössä C ja C++. Javassa tätä ongelmaa ei esiinny, joten tältä ei erikseen tarvitse suojautua. Kuitenkin jo edellä esitetyt tarkistukset auttavat osaltaan samalla suojaamaan järjestelmää virhetilanteilta ja mahdollisilta ylivuodoilta. 6.2 Ylläpito-osuuden tietoturva Ylläpito-sivusto toteutetaan siten että tärkeisiin toimintoihin pääsy vaati salasanatarkistusta. Tärkeää on myös että järjestelmään toteutetaan mahdollisuus erillaisiin käyttäjäprofiileihin. Täten voidaan antaa kullekin laboratoriolle pääsy vain näiden omiin tietoihin, eikä muiden laboratorioiden tilauksia pääse näkemään tai muuttamaan. Ylläpitojärjestelmässä ei syötteitä erikseen tarkisteta. Tämä lähstymistapa on sovittu yhdessä asiakkaan kanssa. Tarkastukselle ei ole nähty tarvetta, sillä ylläpidon käyttäjät ovat kaikki osastojen tai laboratorioiden henkilökuntaa, ja näin ollen luotettuja henkilöitä. Os2admin järjestelmään tulisi rajoittaa pääsyä myös esim. palomuurin avulla ja tämä pienentää mahdollisuutta että ulkopuoliset pääsevt järjestelmään entisestään. Mikäli validointi jossain vaiheessa haluttaisiin lisätä järjestelmään, olisi tämä mahdollista ja melko helppoa käyttäen esim. instanssia samasta Validate-luokkasta jota verkkokaupassa käytetään. Ylläpito järjestelmä käyttää samaa tietokantaa kuin kauppa, mutta ei muuten ole suorassa yhteydessä kauppaan. Ylläpito voidaan siten tarpeen vaatiessa sijoittaa eri palvelimelle kuin itse kauppa. Kuten kappalleessa 4.1 jo mainittiin, niin tällä tavalla voidan varmistua siitä että mahdollinen turva-aukko kaupassa ei suoraan vaaranna ylläpidon toimintaa. Käyttäjien autentikointi Koska järjestelmään tulee runsaasti eri käyttäjiä on näiden hallinta tärkeässä roolissa. OtaShop2-järjestelmässä on käyttäjien autentikointi suoritettu J2EE-standardin mukaan. Käyttäjien autentikointi suoritetaan käyttäen tunnus/salasana-paria. Käyttäjien tunnukset ovat käytänössä julkista tietoa, sillä ne pyritään tekemään samaan muotoon kuin tunnukset muissa TKK:n järjestelmissä. Täten salasana on varsinainen autentikointiväline. Salasanat tulee tästä syystä tallentaa paikkaan jossa niihin ei ole pääsy kuin erikseen sallituilla tahoilla, kuten esim. järjestelmän ylläpitäjällä. Samalla vaatimuksena on että järjestelmää ajetaan ympäristössä jossa käyttäjien autentikointi suoritetaan SSL-suojattua yhteyttä käyttäen. Muussa tapauksessa salasanan voi salakuunnella joko palvelimen tai asiakkaan lähiverkosta. Os2admin voidaan tarvittaessa suorittaa SSL-suojatulla yhteydellä. Tunnusten hallinta Järjestelmä mahdollistaa käyttäjien lisäämisen, mutta myös heidän poistamisen. Täten voidaan poistaa käyttäjät jotka eivät enää tarvitse tunnuksiaan. Samasta syystä käyttäjille luodaan henkilökohtaiset tunnukset, jolloin tämä henkilö voidaan poistaa ilman että tämä vaikuttaisi muiden tunnusten toimintaan. Eri tunnuksia ja niiden oikeuksia hallitaan roolien avulla. Jokainen tunnus voi saada yhden tai useamman roolin. Kulkuluvat annetaan rooleille, joten henkilö joka kuuluu tiettyyn rooliin saa kaikki siihen kuuluvat oikeudet. Roolit on tehty hienojakoisiksi, jotta oikeuksien hallinta olisi mahdollisimman tarkkaa. Käyttäjien lisääminen ja tietojen hallinta tedään omalla admin-roolilla. Admin toimii samoin kuin muut roolit, mutta ylläpitäjällä on mahdollisuus lisätä uusia rooleja ja käyttäjiä, sekä muuttaa pääsyoikeuksia näille. Käyttäjät on myös ryhmitelty laboratorion mukaan, joten käyttäjillä ei ole mahdollisuutta päästä käsiksi muiden kuin oman laboratorion tilaustietokantaan. 7. Käyttöönoton valmistelu Ennen järjestelmän käyttöönottoa on osa järjestelmästä konfiguroitava oikeilla tiedoilla. Esimerkiksi käytetyt e-maksu tunnukset on asetettava kauppaan. 7.1 Pankkiyhteyksien asennus Ennen kaupan käyttöönottoa on maksun hoitaviin luokkiin annettava oikeat e-maksujen asetukset. Jokaiselle e-maksuja käyttävä verkkokauppa saa yksilöivät tiedot pankista. Näitä ovat yleisesti ainakin kauppiaan tunnus ja kauppiaan salainen avain jota käytetään varmistuksen laskemiseen. Kaikki maksun ja pankkipalvelun tiedot löytyvät otashop2.payment paketista. Eri maksuvaihtoehtoja varten löytyvät luokat BillPayment, LeoniaPayment, NordeaPayment, OkoPayment ja VisaPayment. Näistä kaikkiin muihin paitsi BillPayment luokkaan (laskulla maksu) täytyy laittaa oikeat tiedot. Tällä hetkellä järjestelmään on jätetty käyttöön testitunnukset joilla maksutapahtumia voi testata. Alla olevassa taulukossa on tiedot muutettavista arvoista. Arvot ovat joko luokan alussa olevia muuttujia tai prevalues mappiin tallennettavia arvoja. Esimerkki luokan alussa olevasta muuttujasta: private final static String sellersecretkey = "testi"; Esimerkki prevalues mappiin tallennettavasta arvosta (huomaa kommentti): 17 of 18 04/05/ :08 PM

18 // parameter value for testing only prevalues.put("knro", " "); Luokka LeoniaPayment NordeaPayment OkoPayment VisaPayment Muutettavat muuttujat/arvot Muuttuja: sellersecretkey - Myyjän salainen avain Prevalues arvo: KNRO - Myyjän e-maksu tunnus Muuttuja: sellersecretkey - Myyjän salainen avain Prevalues arvo: SOLOPMT_RCV_ID - Myyjän e-maksu tunnus Prevalues arvo: SOLOPMT_RCV_ACCOUNT - Myyjän tili (mikäli tilinä käytetään oletustiliä niin arvon voi kommentoida pois) Muuttuja: sellersecretkey - Myyjän salainen avain Prevalues arvo: MYYJA - Myyjän e-maksu tunnus Muuttuja: sellersecretkey - Myyjän salainen avain Prevalues arvo: merchant_rn - Myyjän e-maksu tunnus Mikäli verkkomaksuissa tulee jotain muita muutoksia, kuten pankkipalvelun osoite muuttuu, on muutokset tehtävä samoihin luokkiin. Nämä ovat kuitenkin epätodennäköisiä. 8. Lähteet Asiakirjan nimi OtaShop2 vaatimusmäärittely OtaShop2 projektisuunnitelma Design Patterns OtaShop2 ulkoasudokumentti OWASP Top 10 of 2004 OWASP Guide to Building Secure Web Applications Cryptography: Theory and Practice, 2nd Edition Pankkien elektroonisen maksun dokumentit PostgreSQL Open Source tietokantapalvelin Lyhyt kuvaus asiakirjan sisällöstä OtaShop2-projektin vaatimusmäärittely dokumentti OtaShop2-projektin suunitelma Henkilökohtainen tehtävä: Design patterns, Matti Kosunen OtaShop2:n ulkoasun määrtelmä ja kuvaus OWASP Top 10 lista tietoturvaongelmista OWASP ohjeet verkkosovellusten kehittäjille Douglas Stinson, Chapman & Hall/CRC Nordean, Leonian ja OKO:n verkkomaksudokumentit 18 of 18 04/05/ :08 PM