INNEHÅLL 1 INLEDNING... 15

Transkript

1 INNEHÅLL 1 INLEDNING BAKGRUNDSINFORMATION Linux och öppen programvara Apache och PHP SSL och PKI Certifikat och elektroniska signaturer MySQL XML Tidstämpling Elektronisk arkivering Internet Explorer och SmartTrust Personal KRAVSPECIFIKATION Arcadas ekonomiska reglemente Datasäkerhet Flexibilitet, kompabilitet och integrering Vidareutveckling Användarvänlighet Dokumentering FAKTURAHANTERINGSSYSTEMET Autentisering Åtkomstbegränsning Grupphierarki Specialfunktioner Sessionshantering Uppladdning av filbilagor Databasplanering Databaseffektivitet Modularitet och flyttbarhet Signaturhantering Skapandet av elektroniska signaturer med WebSigner Extrahering av signeringscertifikat ur en PKCS#7-signatur Verifiering av elektroniska signaturer Konvertering mellan olika format och kodningar Datalagring Datatypen TEXT och BLOB Användningen av XML för datalagring Databastabeller Flexibilitet och självservice Återanvändning av programkod Automatiska servicefunktioner Databashantering Administration Konfigurering av administratörer och applikationsanvändare Underhåll av användarinformation... 81

2 Underhåll av grupper Underhåll av avdelningar Hanteringslogistik Inmatningsfasen Cirkulationsfasen Signeringsfasen Utbetalningsfasen Arkiveringsfasen Papperskorgen Filbilagor Kommentarer Den personliga fakturakön E-posthantering Loggning INSTALLATION OCH KONFIGURATION Installation Konfiguration TESTNING UTVECKLINGSPERSPEKTIV Databasplanering Moduler Tidstämpling Arkivet Loggning Gränssnitt för revisorer Sökningar och rapporter Validering av inmatade data Felkontroll med JavaScript Felkontroll med PHP Begränsningar i databasen Certifikat- och signaturhantering Arkivering av certifikat Hantering av multipla användarcertifikat Förbättring av signaturverifiering Hantering av strukturerade signaturer SLUTSATSER LITTERATUR BILAGA: KÄLLKODSDOKUMENTATION

3 FIGURER Figur 1. Exekvering av ett OpenSSL-kommando i ett PHP-skript Figur 2. Det elektroniska ID-kortet för finländare Figur 3. PKCS#7-formatet Figur 4. Filhuvud för S/MIME-formatet Figur 5. PKCS#7-formaterad signatur i PEM-kodning Figur 6. Signering av XML-post med SmartTrust Websigner Figur 7. PKI-autentisering i Internet Explorer Figur 8. Grupphierarkin i fakturasystemet Figur 9. Exempel på filnamn för en sessionsfil Figur 10. SQL-kod för generering av ett nytt unikt fakturanummer Figur 11. Databasens design och en del av dess relationer Figur 12. Beräkning av ett MD5-extrakt för en fil Figur 13. Buffertarkitekturen Figur 14. Exempel på en databaskonfigurationsfil för fakturasystemet Figur 15. Textbox med XML-data för signering Figur 16. HTML-kod för inbäddning av WebSigner-komponenten Figur 17. Dialogfönster för inmatning av signaturcertifikatets PIN-kod Figur 18. JavaScript för aktivering av WebSigner-komponenten Figur 19. Extrahering av signeringscertifikatet ur en PKCS#7-signatur Figur 20. Verifiering av elektronisk signatur i PHP Figur 21. Kedjade tidstämplar Figur 22. Gränssnitt för granskning av signerad faktura Figur 23. Konvertering av DER-kodad spärrlista till PEM-kodad spärrlista Figur 24. Rutin för avkodning av hexadecimala koder i teckensträngar Figur 25. Teckensträngar i X.509-certifikat före avkodning och efter avkodning Figur 26. XML-formulär för lagring av fakturauppgifter Figur 27. XML-formulär för lagring av delbeslut (kommentarer) Figur 28. Webbformulär för insamling av data till XML-formulär Figur 29. Funktion för sammanfogning av tabell och tomt XML-formulär Figur 30. Funktion för utplockning av information ur XML-formulär Figur 31. Fullständig XML-post för lagring av fakturauppgifter och filbilagor Figur 32. Automatiskt påminnelsebrev per e-post Figur 33. Innehållet i indextabellen i databasen Figur 34. Information om den inloggade användaren Figur 35. Konfiguration av användare och åtkomstbegränsningar för webbservern Figur 36. Applikationsanvändare samt deras gruppmedlemskap Figur 37. Gränssnitt för underhåll av signeringsrättigheter Figur 38. Grupper och grupprelationer lagrade i databasen Figur 39. Gränssnitt för underhåll av grupper Figur 40. Gränssnitt för underhåll av grupprelationer Figur 41. Gränssnitt för underhåll av avdelningar Figur 42. Cirkulationsförloppet för fakturor i fakturahanteringssystemet Figur 43. Innehållet i tabellen Paminnelser i databasen Figur 44. Gränssnitt för utskickning och editering av manuella påminnelsebrev Figur 45. Loggdata i systemloggen vid inloggning Figur 46. Utdrag ur httpd.conf (Apache-konfigurationsfil) Figur 47. Bash-skript för kompilering av PHP och externa moduler Figur 48. Utdrag ur php.ini (konfigurationsfil för PHP 4.3.2)

4 Figur 49. Utdrag ur mod_ssl.conf Figur 50. Inställningar i files.inc Figur 51. Direktlänk för hämtning av spärrlista via HTTP Figur 52. Uppdatering av spärrlista via LDAP-sökning med OpenLDAP Figur 53. Utdrag ur my.cnf (konfigurationsfil för MySQL) Figur 54. Fil- och funktionsträd TABELLER Tabell 1. SSL-variabler i bläddrarens globala miljö. (Hästbacka, 2002) Tabell 2. Funktioner för olika typer av åtkomstkontroll Tabell 3. Variabler för databaskonfigurering Tabell 4. Funktioner för sessionsvariabelshantering Tabell 5. Filinformation för uppladdade filbilagor Tabell 6. Konfigurationsinställningar för PHP-modulen Tabell 7. Konfigurationsinställningar för MySQL Tabell 8. Databastabeller Tabell 9. Funktionsbibliotek Tabell 10. Metoder för inställning av de vanligaste egenskaperna hos WebSigner Tabell 11. Databastabeller för lagring av fakturor

5 FÖRKORTNINGAR ASCII American Standard Code for Information Interchange. Alfanumerisk teckenkod som används för att representera alla tecken med siffror. Finns i både 7-bitars och 8-bitars versioner. ASP Active Server Pages. En teknik framtagen av Microsoft för programmering av dynamiska webbsidor med Visual Basic-skript eller JScript. BLOB Binary Large Object. Datatyp som används i databaser för lagring av binär information. CA Certification Authority. Utgivare av certifikat. CN Common Name. Fält som ingår i ett certifikat som innehåller certifikatägarens namn. CRL Certificate Revocation List. Förteckning över certifikat som spärrats. DER Distinguished Encoding Rules. Ett kodningssystem som ingår i ASN.1- formatet. Används bland annat för att koda kryptografisk information. DOM Document Object Model. DPI Dotch Per Inch. En måttenhet för pixeltäthet, punkter per tum. DTD Document Type Definition. Formatmall för dokument kodade enligt SGML eller XML. GNU GNU is Not Unix. En rekursiv ordlek som namnger en del projekt med öppen källkod. 10

6 GPL General Public License. Licensavtal som omfattar öppen källkod. HTML HyperText Markup Language. Språk för att strukturera information för visning på webben. HTTP Hypertext Transfer Protocol. Protokoll som används på Internet för kommunikation mellan webbservrar och webbläsare. HTTPS Secure HTTP. Ett tillägg till HTTP för att skydda kommunikationen. ISO International Organization for Standardization. Europeisk organisation som standardiserar gränssnitt, teckenkoder m.m. ITU International Telecommunications Union. Europeisk organisation som ansvarar för standarder inom telekommunikationsområdet. JPG Joint Photographic Expert Group. Standard för komprimering av data, i första hand fotografier och andra bilder som innehåller många färger. Standarden orsakar förluster proportionellt mot komprimeringsgraden. LDAP Lightweight Directory Access Protocol. Protokoll för bläddring i katalogtjänster på Internet. MD5 Message Digest #5. Algoritm för beräkning av matematiska extrakt. PEM Privacy Enhanced Mail. En kodningsteknik som används för kryptografisk information. PHP Hypertext Preprocessor. Programmeringsspråk för dynamiska webbsidor i alla miljöer. Följer syntaxen för C-språket. 11

7 PIN Personal Identification Number. Kod som används tillsammans med smartkort, bankkort och andra identifieringssystem. PKCS #11 Allmän standard för gränssnitten mot kryptografisk hårdvara. Utfärdad av RSA Laboratories. PKCS #7 Allmän standard för hantering av information anknuten till kryptografi. Utfärdad av RSA Laboratories. PKI Public Key Infrastructure. Infrastruktur för hantering och distribution av kryptografiska nycklar. RAID Redundant Array of Independent Disks. Metod för att öka säkerheten i lagringen hos ett hårddisksystem. Stöder datafördelning och dataspegling. S/MIME Secure Multipurpose Internet Mail Extension. Utökad version av MIME med stöd för kryptering. Med MIME-kodning kan binär information överföras via e-post på Internet. SGML Standard Generalized Markup Language. Format för strukturerad text, standardiserat med ISO Texten kodas och kan med hjälp av olika typer av dokumentmallar formateras för olika typer av media. SMTP Simple Mail Transfer Protocol. Protokoll för överföring av meddelanden mellan datorer på Internet. SQL Structured Query Language. Standardiserat frågespråk för kommunikation med databaser. SSH Secure Shell. Program för fjärrinloggning på en annan dator. Kan även användas för att köra program på en annan dator och för att flytta filer mellan datorer. Har hög säkerhet. 12

8 SSL Secure Sockets Layer. Metod för att skydda kommunikation. TCP/IP Transmission Control Protocol / Internet Protocol. Standardprotokollet i Internet som används för kommunikation mellan noderna i nätet. Består av flera delprotokoll som alla behövs för kommunikation på Internet. TLS Transport Layer Security. Säkerhetssystem för kommunikation. TSP Time Stamp Protokoll. Del av X.509-standarden som definierar elektroniska tidstämplar. URL Uniform Resource Locator. Systemet för adresskoder i Internet. UTF Universal Transformation Format. Metod för konvertering av tecken i Unicode som är 16-bitar till tecken med 7 eller 8 bitar. X.509 Standard för digitala certifikat. Rekommendation från ITU. XML Extensible Markup Language. Förenklad version av SGML som kan strukturera information och användas för produktion av plattformsoberoende databassystem. 13

9 FÖRORD Detta examensarbete har utförts inom ramarna för forskningsprojektet Hantering och arkivering av digitala fakturor på Institutionen för IT och Elektronik, Arcada Nylands svenska yrkeshögskola. Min studieinriktning har varit datateknik inom utbildningsprogrammet informationsteknik. I examensarbetet presenteras hur man med hjälp av programpaket med öppen källkod kan bygga ett system för certifierad elektronisk dokumenthantering. Examensarbetet visar även med många exempel hur man hanterar olika typer av kryptografisk information. Som bilaga till rapporten finns dokumentation för den källkod som använts inom forskningsprojektet. Projektet är uppdelat i flera delar och detta examensarbete omfattar den tekniska uppbyggnaden av den fakturahanteringsmodell som forskningsprojektet har tagit fram. Modellen är en generell plattform som även kan utnyttjas för andra ändamål än elektronisk fakturahantering. Det första examensarbetet inom samma projekt skrevs av min kollega Peik Åström. I Peiks examensarbete behandlas bland annat den applikation, som i detta examensarbete beskrivs i detalj, mera allmänt. Jag vill passa på att tacka min numera forna kollega Peik Åström för det grupparbete och för det resultat vi tillsammans har uppnått. Jag vill även tacka min handledare, och forskningsprojektets ledare, Göran Pulkkis för den enorma expertis och entusiasm som han har bidragit med, men framför allt för det tålamod han har visat med färdigställandet av denna rapport. Helsingfors Krister Karlström 14

10 1 INLEDNING Det papperslösa kontoret har redan under en längre tid förblivit en vision och förhållandevis få ärenden sköts idag helt elektroniskt. Kanske har det varit den omfattande tekniska infrastrukturen som saknats eller brist på kunskap som har bromsat upp utvecklingen. Idag har informationstekniken och datatekniken utvecklats till den grad att en smidig övergång är möjlig. Elektroniska signaturer är legaliserade och Finlands befolkning erbjuds elektroniska ID-kort. Dessutom utvecklas öppna applikationer för hantering av dessa. Målet med detta projekt har varit att visa hur man med hjälp av öppen programvara och standarder kan bygga upp en infrastruktur för elektronisk dokumenthantering. Resultatet blev en intranätportal för hantering av elektroniska fakturor, skräddarsydd för ekonomiadministrationen i Arcada. Arbetet utgör även en god grund för fortsatt utveckling av portaler för elektronisk dokumenthantering. Projektet är utfört som ett IT-forskningsprojekt vid Institutionen för IT och Elektronik vid Arcada Nylands svenska yrkeshögskola. Projektet omfattar fakturahantering med elektroniska digitala signaturer för godkännande av fakturor. För att den lösning som presenteras i detta examensarbete skall kunna tas i bruk krävs ännu att ett elektroniskt arkiv görs. Uppbyggnaden av arkivet faller dock utanför ramarna för detta examensarbete. Rapporten är en teknisk beskrivning av uppbyggnaden av systemet och är avsedd som en teknisk dokumentation för programkoden. I rapporten beskrivs i detalj hur elektroniska signaturer och certifikat kan hanteras med hjälp av standardiserad öppen programvara och hur dessa kan användas i elektronisk dokumenthantering. Hypotesen för detta examensarbete är: Hur kan öppen programvara användas för elektronisk fakturahantering? Examensarbetet ger ett av flera svar på denna hypotes. Läsaren förutsätts ha grundkunskaper inom datateknik, programmering och kryptografi. 15

11 2 BAKGRUNDSINFORMATION I detta kapitel sammanfattas i korthet bakgrundsinformation till de flesta verktyg, metoder, tekniker och komponenter som använts i projektet. 2.1 Linux och öppen programvara En av projektets målsättningar är att ta fram en lösning som så långt som möjligt utnyttjar programvara med öppen källkod. Denna typ av programvara omfattas av GPLlicensen och får fritt användas och distribueras. De komponenter och verktyg som använts är alla, förutom en enda, programvaror som omfattas av GPL-licensen. Slackware Bland servrar på Internet har Linux blivit mycket populärt. Tre starka argument för Linux är säkerhet, prestanda och pris. Även i Arcada har Linux blivit standard-operativsystem för de flesta servrar. Linux förekommer i ett hundratal olika distributioner med olika spridningsgrad, vissa mera kända distributioner och många små okända distributioner. I Arcada används en mycket känd och välutvecklad distribution för servrar, nämligen Slackware. Distributionen är mycket populär för nätverksservrar och har i Arcada blivit en de facto standard. Valet av operativsystem och distribution för projektets server gjordes i enlighet med IT-Centralens riktlinje. Projektet är byggt och testat på Slackware 9.0 med Linux kernel I ett senare skede har även kernel använts utan problem. (Slackware, 2004). GNU General Public License (GPL) GNU General Public License är ett licensavtal som de flesta projekt med öppen källkod omfattar. Licensavtalet tillåter fri användning och distribuering. (GPL). Om man använder GNU-licenserad programvara och modifierar denna enligt eget behov är man också skyldig att erbjuda andra personer den modifierade programvaran. 16

12 2.2 Apache och PHP Detta projekt är uppbyggt som en webbportal för ett intranät. Projektet är utformat för att köras på en Apache webbserver under Linux med stöd för skriptspråket PHP. För konstruktion av dynamiska webbsidor är kombinationen PHP och Apache en utmärkt kombination. Bägge komponenterna är projekt med öppen källkod och utvecklingen fortgår kontinuerligt. (Apache, 2004). Detta projekt är byggt och testat på Apache och PHP under Slackware 9.0. Efter ett fåtal förändringar i källkoden fungerar systemet felfritt även med PHP (PHP, 2004). 2.3 SSL och PKI Elektronisk dokumenthantering kan inte utföras utan att involvera kryptografi. Med Public Key Infrastructure (PKI) autentiseras information och användare. Likväl måste datakommunikationen skyddas och det utförs enklast med hjälp av Secure Socket Layer (SSL). Förbindelser skyddade med SSL stöds av alla webbläsare. På webbservern måste SSL aktiveras i serverns konfiguration och dessutom behövs ett servercertifikat. OpenSSL I PHP ingår en mängd färdiga funktioner för att utföra olika SSL-operationer. Funktionsbiblioteket i PHP är i dagens läge dock långt ifrån komplett. Åtminstone detta projekt behöver för både certifikat och signaturer sådana hanteringsfunktioner som inte ingår som standard i PHP. För dessa ändamål används programpaketet OpenSSL, vilket är ett projekt med öppen källkod. Funktioner som ingår i OpenSSL kan med ett systemanrop köras i ett PHP-skript, information förmedlas då enklast via tillfälliga filer (se Figur 1). 17

13 passthru("openssl x509 -subject -issuer -dates -noout -inform PEM -in certfile > $outfile"); Figur 1. Exekvering av ett OpenSSL-kommando i ett PHP-skript. Med OpenSSL kan man bland annat hantera certifikat, signaturer och spärrlistor. (OpenSSL, 2004). PKI PKI är en förkortning för Public Key Infrastructure (PKI-Forum, 2004). Tekniken bygger på så kallade nyckelpar där den ena nyckeln är hemlig och den andra är offentlig. Nycklarna är av naturen sådana att ingen känd lätthanterlig matematisk härledning finns mellan dem men tillsammans kan de användas för att kryptera och avkryptera information. Nycklarna kompletterar på så sätt varandra och så länge den privata nyckeln hålls hemlig kan den krypterade informationen anses vara säker. FINEID-kort innehållande nyckelpar används i detta projekt både vid autentisering (inloggning) och signering (elektronisk underskrift). Nycklarna finns sparade på det elektroniska identitetskortet, dessutom finns de publika nycklarna publicerade i Befolkningsregistercentralens katalogtjänst. Detta projekt utnyttjar FINEID-korten och har enbart blivit testat med dessa kort. FINEID-kortet I Finland är det sedan år 1999 möjligt att skaffa ett elektroniskt ID-kort. Kortet innehåller två PKI-nyckelpar, ett för autentisering och ett för signering. Kortet utfärdas av Befolkningsregistercentralen och de praktiska arrangemangen sköts av polisen. De publika certifikat som finns ombord på kortet är elektroniskt signerade av Befolkningsregistercentralen och certifikaten finns offentligt tillgängliga i en katalogtjänst på Internet. Den privata nyckeln som behövs vid säker kommunikation finns enbart i kortet. Det elektroniska ID-kortet har i början haft en giltighetstid på tre år, men nu ges ID-kort ut för fem år. I detta projekt har ID-kortet med tre års giltighetstid använts. I praktiken är den enda skillnaden mellan 3- och 5-årskort den att certifikaten har en längre giltighetstid och att 5-årskorten är undertecknade med ett annat CA-certifikat för 18

14 5-åriga kort. I Figur 2 visas ett elektroniskt identitetskort för finländare. (FINEID, 2004). Figur 2. Det elektroniska ID-kortet för finländare. Modulen mod_ssl för Apache För att skydda datakommunikationen mellan Apache och användarens webbläddrare används modulen mod_ssl. Modulen kompileras ihop med Apache och därefter måste Apache startas med kommandot apachectl startssl för att SSL-servern skall starta. För en lyckad uppstart av mod_ssl krävs att modulen är korrekt konfigurerad och att ett servercertifikat finns angivet i konfigurationsfilen. Modulen levereras oftast färdigt kompilerad tillsammans med Apache webbservern. Projektet är byggt och testat på mod_ssl (mod_ssl, 2004). 2.4 Certifikat och elektroniska signaturer I detta projekt används många olika standarder och kodningsmetoder för olika typer av kryptografisk information. X.509-standarden Certifikat är i allmänhet konstruerade enligt X.509-standarden (X.509, 2004). De certifikat som förekommer i detta projekt är alla X.509v3-certifikat. Utbudet på certifikathanteringsfunktioner i PHP är mycket begränsat och certifikaten hanteras i detta projekt främst med OpenSSL. 19

15 PKCS#7-standarden PKCS#7 är standaren för Cryptographic Message Syntax Standard (PKCS #7, 2004). Standarden beskriver en generell syntax för information kopplad till kryptografi. De signaturer som skapas i detta projekt följer denna standard enligt version 1.5. Standarden stöder rekursivitet, d.v.s. kedjor av signaturer. I detta projekt förekommer dock inte signaturer i flera nivåer. Information kodad enligt PKCS#7-standaren känns igen genom att informationsblocket börjar med -----BEGIN PKCS7---- och slutar med -----END PKCS Informationen där emellan är uppbruten till rader om 64 tecken. I Figur 3 visas PKCS#7-formatet BEGIN PKCS XXXXX...XXXXX XXXXX...XXXXX XXXXX...XXXXX -----END PKCS Figur 3. PKCS#7-formatet. S/MIME-standarden S/MIME är en standard som beskriver hur MIME kodad information kan knytas till kryptografi. En del operationer i detta projekt använder S/MIME istället för PKCS#7. I Figur 4 visas huvudet för en S/MIME-post. (S/MIME, 2004). MIME-Version 1.0 Content-Disposition: attachment; filename= smime.p7m Content-Type: application/x-pkcs7-mime; name= smime.p7m Content-Transfer-Encoding: base64 Figur 4. Filhuvud för S/MIME-formatet. PEM- och DER-kodning För kodning av kryptografiska poster används två olika format. Med kryptografiska poster avses i detta projekt både signaturer, certifikat och tidstämplar. 20

16 PEM-kodningen är lätthanterlig eftersom den resulterar i enbart läsbara ASCII-tecken och lämpar sig därför för lagring i databaser. Eftersom kodningen enbart består av läsbara ASCII-tecken kan hela signaturen enkelt representeras med hjälp av en teckensträng. I Figur 5 visas en signatur i PKCS#7-format. DER-kodningen resulterar i ett kompaktare format och sparar därmed diskutrymme men är mycket svårhanterlig, eftersom kodningen är binär och signaturen kan inte lika enkelt representeras med en teckensträng. I detta projekt används PEM-kodning. Ibland förekommer dock DER-kodad information. Spärrlistan som Befolkningsregistercentralen ger ut är ett exempel på DERkodad information BEGIN PKCS MIIFfwYJKoZIhvcNAQcCoIIFcDCCBWwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCA5owggOWMIICfqADAgECAgMAnmYwDQYJKoZIhvcNAQEFBQAwTDELMAkG A1UEBhMCRkkxHDAaBgNVBAoUE1ZSSy1GSU5TSUdOIEdvdi4gQ0ExHzAdBgNVBAMU FkZJTlNJR04gQ0EgZm9yIENpdGl6ZW4wHhcNMDIxMjA5MjM1OTU5WhcNMDUxMjA1 MjM1OTU5WjBlMQswCQYDVQQGEwJGSTEQMA4GA1UEBBQHUFVMS0tJUzEOMAwGA1UE KhQFR9ZSQU4xIDAeBgNVBAMUF1BVTEtLSVMgR9ZSQU4gMTAwMDA5MjdKMRIwEAYD VQQFEwkxMDAwMDkyN0owgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMKNB4ga G7UseIoK/ZG140N+KeW1bh2JX/L75BLlKXFr1L6PX52lIUThbLRXGF9NpdaFbcxJ PSm07h8JxmT3N2YnHon7zgNAyaRz7sSvfp4iP4WvKKpvPffmkP+AFBjWoqbIbzxx fphlokbekd3su27poeosptmxlnviatnpv40vagmbaagjgeswgegweqydvr0obaoe CEte1qZrYDbTMBQGA1UdIAQNMAswCQYHKoF2hAUBATATBgNVHSMEDDAKgAhGSU5D QUswMTAOBgNVHQ8BAf8EBAMCBLAwgZcGA1UdHwSBjzCBjDCBiaCBhqCBg4aBgGxk YXA6Ly8xOTMuMjI5LjAuMjEwOjM4OS9jbj1maW5zaWduJTIwY2ElMjBmb3IlMjBj axrpemvulg89dnjrlwzpbnnpz24lmjbnb3yujtiwy2eszg1kbmftzt1maw5lawqs Yz1GST9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0MA0GCSqGSIb3DQEBBQUAA4IB AQBssYrbaKVbPQ0A4XmMYdOPMTvt3wY3z31r7es+Z0BnS5np/OK3F6zvxouqSyCF Tn5agdOaHERFFK7UZTC/62WzRmc4VVaxIrJi+CS8NdvoMgPl+Qi6dY/pxbYkluy/ um5lkzjgktw+lj3e5nv7i68klmjvvppji+b6cnjwg59onjjqtowhiohtnrlo/gur YolNEtM/6J2wdVCdIefSAd3aoHp6UNAvFktjFyCFEodXxdLdZ1zSVP2MhFDbflrF HPg3cRsEKxBB2IU7Aq3N143eSPz4642BTr5B0V1C+nna1QSSLfj0h9+KMWVodLK8 jihb2e36ed/jpjnno7mzgpvfmyibrtccaakcaqewuzbmmqswcqydvqqgewjgstec MBoGA1UEChQTVlJLLUZJTlNJR04gR292LiBDQTEfMB0GA1UEAxQWRklOU0lHTiBD QSBmb3IgQ2l0aXplbgIDAJ5mMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwNTEzMTQ1MDAxWjAjBgkqhkiG 9w0BCQQxFgQU4OYKtTH6vY7AN/mxqK9XSkCadUcwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC AUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAjNs9UQBReqpSSWSjI Fdg2yI1qLGYrq6RGz6LTXXq5jS0rp7oOWb62QBs5reVNHSgxCjoh5EvaQvWEV3a1 XkCiwGdbduOj72XpmYEeEUXm3uoCKS3R/m40Z3Yu3iE8O5W7xZkaxeUXSNTEMR78 LznwGMJuo65ITdNzWcHDKHu78A== -----END PKCS Figur 5. PKCS#7-formaterad signatur i PEM-kodning. 21

17 Signaturkategorien Elektroniska signaturer kan indelas i två kategorier, signaturer som enbart innehåller ett extraktvärde ( detached signature ) och signaturer som innehåller hela klartexten ( attached signature ). Eftersom den post som signeras i detta projekt är liten används signaturer som innehåller hela posten i klartext. 2.5 MySQL En mycket populär databashanterare på Internet är MySQL. MySQL är relativt effektiv och enkel att använda och har vunnit stor spridning under de senaste åren. En nackdel är dock att MySQL inte ännu stöder SQL-standarden fullt ut. Nya versioner kommer dock ut hela tiden. MySQL ägs nu av ett svenskt företag grundat av upphovsmännen själva, MySQL AB, men utvecklingen har fortsatt med öppen källkod under GPL-licensavtalet. För kommersiellt bruk krävs dock licens. MySQL förekommer ofta tillsammans med PHP och Apache. Detta projekt är byggt och testat på MySQL , under projektets början användes version (MySQL, 2004). 2.6 XML XML står för Extended Markup Language och är ett notationsspråk. Med hjälp av XML kan man enkelt bygga upp mallar för att lagra strukturerad information. I PHP finns tillräckligt med stöd för detta projekt för att hantera information lagrad som XMLposter. Genom att lagra information i XML-format kan informationen hanteras och lagras som ett allmänt datapaket utan att hänsyn behöver tas till hurudan information ingår i datapaketet. XML passar utmärkt för datalagringen i detta projekt. Detta projekt är utvecklat för PHP och använder ett flertal av de XMLfunktioner som är definierade i den API:n. Under andra halvan av år 2004 utges PHP version 5 där bland annat hela XML-komponenten är utbytt till en helt annan. Detta medför troligen att XML-hanteringen i detta system måste programmeras om för att 22

18 fakturasystemet skall fungera på PHP 5. Detta öppnar i sin tur nya möjligheter att vidareutveckla användningen av XML i systemet. (XML, 2004). 2.7 Tidstämpling För att kunna bevisa när en signering har utförts behövs någon form av bevisbar tid. En tidstämpel innehåller en tidsangivelse som tillsammans med ett extrakt av ett dokument är signerad av en trovärdig tidstämplingsmyndighet. Tidstämpeln bildar tillsammans med det elektroniskt signerade dokumentet en komplett helhet. Tidstämpling har inte skapats än i detta projekt. (TSP, 2003). 2.8 Elektronisk arkivering Den elektroniska dokumenthanteringen innebär att inga fysiska papper behöver arkiveras i mappar, hyllmeter efter hyllmeter. Det elektroniska arkivet erbjuder flexiblare sökmöjligheter och sparar mycket fysiskt utrymme. Givetvis ställs det mycket höga krav på ett elektroniskt arkiv av denna typ, såsom integritetskontroll, säkerhetskopiering och skydd mot mediedegeneration. Även arkiveringsrutinerna är annorlunda. Om den arkiverade informationen dessutom är tidstämplad föråldras tidstämplarna. Tidstämplarna måste förnyas varje gång tidstämplingsmyndigheten ger ut ett nytt CAcertifikat. Allt detta kan byggas upp med den teknik som idag existerar. Det elektroniska arkivet och de rutiner som krävs har inte skapats än i detta projekt. 2.9 Internet Explorer och SmartTrust Personal De elektroniska signaturerna som skapas i detta projekt genereras av en programvara inköpt från SmartTrust, nämligen produkten SmartTrust Personal (SmartTrust, 2004) och ActiveX-komponenten WebSigner. Eftersom WebSigner är en ActiveX-komponent (ActiveX, 2004) fungerar projektets signeringsgränssnitt enbart med Microsoft Internet Explorer. ActiveX är en teknik för bl.a. insticksprogram för Internet Explorer framtagen och utvecklad av Microsoft. I Figur 6 visas dialogfönstret för skapandet av en elektronisk signatur med WebSigner-komponenten i SmartTrust Personal. 23

19 SmartTrust Personal är den enda licensbelagda programvaran som använts, om man frånser Microsoft Internet Explorer. Detta projekt är byggt och testat på SmartTrust Personal och Internet Explorer 6.0 (version ). Figur 6. Signering av XML-post med SmartTrust Websigner. 24

20 3 KRAVSPECIFIKATION Kravspecifikationen har tagits fram i en iterativ process med ekonomibyrån. Oftast har kraven specificerats för en modul åt gången och på så sätt har programmeringen och planeringen alternerat med varandra. Inom programmeringstekniken finns en utvecklingsmodell som allmänt kallas för Spiralmodellen. Detta projekt har ganska långt utförts enligt den modellen. Till grund för kravspecifikationen ligger Arcadas ekonomiska reglemente. 3.1 Arcadas ekonomiska reglemente Det ekonomiska reglementet ligger till grund för ekonomiadministrationens funktion. I reglementet specificeras hanteringen av fakturor, namnteckningsrätt (signeringsrätt), hur man gör inköp, skillnaden på kostnader och investeringar samt attesteringsrättigheter. (Ekonomiskt reglemente, 2002). 3.2 Datasäkerhet Vid utformningen av en applikation av den här typen finns det givetvis stora krav på datasäkerheten. Förbindelserna måste vara säkrade mot avlyssning och informationen i systemet skall enbart nås av behöriga användare. Hårdvaran måste vara pålitlig och den fysiska tillgången till servern begränsad. Servern utsätts även för hårda systemsäkerhetskrav. Även ett effektivt skydd mot mediedegenerering (dataförlust) behövs. HTTPS För att säkra kommunikationen över nätverket används ett skyddat protokoll, HTTPS. Protokollet är en SSL-utökning av det vanliga HTTP-protokollet vilket används vid överföring av webbsidor på Internet. Protokollet stöds av både Apache och webbbläddraren Internet Explorer och förbindelsen mellan dessa två är skyddad av SSL. 25

21 För upprättandet av en förbindelse krävs att klienten accepterar ett servercertifikat, som är utgivet och undertecknat av Arcadas egen CA-auktoritet. Under utvecklingen av detta system användes dock ett självgenererat servercertifikat skapat med programvaran OpenSSL. Säkerhetskopiering Eftersom ett system av denna karaktär kommer att innehålla mängder av viktig information är det ytterst viktigt att en dataförlust aldrig inträffar. Regelbunden säkerhetskopiering bör utföras och i minst två kopior varje gång varav den ena kopian bör förvaras i en annan byggnad eller åtminstone i en annan del av byggnaden. Säkerhetskopior bör dessutom alltid förvaras i ett brandsäkert utrymme. Säkerhetskopiering kan utföras på flera olika sätt. Som exempel kan nämnas på magnetband, på cd eller på en annan hårddisk. Skydd mot mediedegenerering Detta system är ett långsiktigt system och det elektroniska arkivet förväntas existera väldigt länge, betydligt längre än vad någon hårdvara håller. Förr eller senare kommer t.ex. en hårddisk att gå sönder i servern och då är det viktigt att det finns ett effektivt skydd mot en dataförlust. Säkerhetskopior garanterar att informationen inte går förlorad. Att installera en ny hårddisk och överföra informationen från t.ex. ett databand tar dock lång tid. Med hjälp av speglade hårddiskar (RAID-teknik) kan man försäkra sig om att systemet inte lider av för lång downtime. Fastän den ena hårddisken går sönder märker inte användarna någonting så länge den andra fungerar. Efter att den trasiga hårddisken bytts ut speglas den igen med informationen från den hela hårddisken. På så vis är sannolikheten mycket stor för att en fungerande hårddisk med korrekt information alltid kan nås av servern. 26

22 3.3 Flexibilitet, kompabilitet och integrering Vid utvecklingen av detta system sattes stor vikt på att göra systemet flexibelt och kompatibelt mot andra ekonomisystem. Kompabiliteten är i dagens läge ännu inte särskilt mycket utbyggd. Systemets flexibla uppbyggnad möjliggör dock utveckling av kompatibla gränssnitt mot andra ekonomisystem. Systemet består av flera moduler, vilka alla använder delade funktioner samlade i funktionsbibliotek, grupperade enligt kategori. Funktionsbibliotek Systemets kärnfunktioner finns samlade i en mängd funktionsbibliotek. Det finns skilda bibliotek för funktioner av olika typer. Funktionerna är indelade enligt: Minnesbufferthantering (cache) Databashantering Fakturahantering Filhantering Grupphantering Mappningsfunktioner (index) Påminnelser Signaturhantering Användarhantering XML funktioner Integrering mot andra system Vid planeringen av detta system togs även i beaktande möjligheterna att skapa gränssnitt mot andra externa ekonomisystem. Exempel på sådana system är inköpsreskontran och digitala fakturor, d.v.s. sådana fakturor som inte anländer i pappersform utan enbart helt elektroniskt per exempelvis e-post. Stöd för sådana gränssnitt är möjligt att utveckla som en ny modul med nya funktioner i ett eget funktionsbibliotek. Generellt sett kan man importera och exportera vilken typ av information som helst bara man känner till dataformaten och protokollen. 27

23 3.4 Vidareutveckling Systemet har hittills enbart genomgått den inledande utvecklingsfasen. Detta projekt kommer utan tvekan att leva vidare och vidareutvecklas hela tiden. Listan över behövliga åtgärder är redan relativt lång. Med tanke på projektets fortlevande är det viktigt att programkoden är uppbyggd enligt modulprincipen och att projektet är väl dokumenterat. Detta system kan anses uppfylla de välkända modularitetskraven eftersom varje moment i fakturahanteringen fungerar som en självständig komponent. Däremot delar många moduler på samma programkod. Detta är möjligt tack vare att ett automatiskt lokaliseringssystem för fakturor i databasen har skapats. Ett exempel på ett gränssnitt som används av flera moduler är gränssnittet för att visa och spara en faktura. 3.5 Användarvänlighet En målsättning för projektet har även varit att producera användarvänliga gränssnitt och att presentera tekniskt komplicerade funktioner på ett enkelt och lätthanterligt sätt. Det bör vara lätt för användaren att få en överblick av systemet och att hitta hjälpfunktioner där de behövs. Gränssnitt Gränssnitten är fritt planerade, dock med Arcadas grafiska profil i tanken (Grafisk profil, 2002). Färgerna som använts är Arcadas färger. Genom att använda färger och typsnitt som från tidigare är bekanta från övriga informationssystem i Arcada känner sig användaren hemma redan vid första kontakten med det nya systemet. Gränssnitten erbjuder många länkar till andra gränssnitt och det är lätt att finna den funktion man söker. Många gränssnitt återkommer i flera olika situationer. I grund och botten är antalet olika gränssnitt som en användare behöver bekanta sig med, litet. 28

24 Hjälpfunktioner För att vägleda användaren vid användningen av gränssnitten bör hjälpfunktioner inprogrammeras. I dagsläget existerar knappt någon hjälpinformation i systemet, förutom några få gråa boxar som informerar om vad som visas på gränssnittet. Målet är att varje gränssnitt skall ha en länk till en hjälpfil, som ger utförlig stödinformation, både på svenska och på engelska. Ifall och när systemet tas i bruk bör även en användarmanual skrivas. 3.6 Dokumentering Projektets dokumentering är ytterst viktig för att det skall finnas förutsättningar att jobba vidare med utvecklingen av detta projekt. Programkoden och funktionerna bör dokumenteras på ett sådant sätt att någon annan kan ta över utvecklingen av systemet. Denna dokumentering består av dokumentfiler och kommentarer i programkoden. Dokumentationsmodell Som grund till dokumentationsmodellen används en allmän modell för modulbeskrivning (Eklund, 1998). Modellen beskriver hur en modul skall dokumenteras utgående från följande sex informationspunkter: Modulens namn Modulens funktion Modulens parametrar Beskrivning av indata Beskrivning av utdata Beskrivning av sidoeffekter 29

25 Utöver detta ges även en kort verbal beskrivning av modulens, alternativt funktionens, funktionalitet. Dokumentationen går även in på en djupare detaljnivå än vad som föreslås i boken. Noteras bör att denna modell använts för att dokumentera både moduler, filer och funktioner. Dokumentationen finns som bilaga till denna rapport. Kommentarer i programkoden Utöver den fristående dokumentationen är det viktigt med kommentarer i programkoden. Kommentarer i programkoden finns på sådana ställen där det anses att ett förtydligande behövs. Dessutom inleds varje funktion med en kort verbal beskrivning över vad funktionen utför, till vilken modul den hör samt vilka parametrar den tar emot och vilka returvärden den skapar. 30

26 4 FAKTURAHANTERINGSSYSTEMET I detta kapitel presenteras de lösningar som tagits fram samt motiveringar till dessa. Någon komplett programkod ingår inte utan enbart väsentliga utdrag ur programkoden presenteras. Även brister och vidareutvecklingsbehov påtalas. 4.1 Autentisering För att uppnå ett av de viktigaste datasäkerhetskraven på detta system behövs ett tillförlitligt autentiseringssystem. Lösningen till detta problem är PKI-autentisering. PKIautentiseringen sker med hjälp av elektroniska identitetskort och modulen mod_ssl för Apache-webbservern. I Figur 7 visas dialogfönstret för val av certifikat vid PKIautentisering. Figur 7. PKI-autentisering i Internet Explorer. PKI-autentisering med Apache och mod_ssl PKI-autentiseringen aktiveras genom direkt konfiguration av mod_ssl-modulen, någon annan konfiguration behövs egentligen inte. Den SSL-skyddade webbplatsen är en Virtual Host i Apache med SSLEngine on. För att en SSL-förbindelse skall vara möjlig måste servern ha ett servercertifikat. Servercertifikatet pekas ut i mod_ssl- 31

27 modulens konfigurationsfil. Dessutom behöver mod_ssl-modulen känna till CAcertifikatet för de klientcertifikat som används samt en spärrlista över spärrade klientcertifikat. Det är viktigt att spärrlistan uppdateras regelbundet, så att inga ogiltiga identitetskort kan användas. Uppdateringen kan utföras med ett skript som körs som ett cron-jobb. Konfigurationen presenteras närmare i kapitel 5. SSL-variabler Efter att en SSL-förbindelse satts upp definieras en mängd med så kallade SSLvariabler i bläddrarprogrammets omgivningstabell. Dessa variabler utnyttjas av de olika skripten för att identifiera användarna. De viktigaste variablerna som används i detta projekt visas i Tabell 1. Tabell 1. SSL-variabler i bläddrarens globala miljö. (Hästbacka, 2002). Variabel SSL_CLIENT_I_DN SSL_CLIENT_S_DN SSL_CLIENT_S_DN_CN SSL_CLIENT_V_START SSL_CLIENT_V_END Beskrivning Utfärdarens DN i klientcertifikatet. Användarens DN i klientcertifikatet. Användarens efternamn, förnamn samt elektronisk kommunikationskod i klientcertifikatet. Klientcertifikatets giltighetstid (start). Klientcertifikatets giltighetstid (slut). Information i databasen är oftast öronmärkt med SSL_CLIENT_S_DN_CN-fältet eller med motsvarande användar-id för användaren. 4.2 Åtkomstbegränsning Systemet innehåller en omfattande infrastruktur för åtkomstbegränsning. För varje operation en användare försöker göra utförs en åtkomstkontroll för informationen i fråga. För utförande av denna åtkomstkontroll finns ett flertal servicefunktioner i funktionsbiblioteket (faktura.inc, users.inc) för fakturahantering och användarhantering (se Tabell 2). Eftersom åtkomstkontrollen utförs före varje databasläsning eller operation kan oåtkomlig information inte heller nås via så kallad URL-manipulation. Om användaren försöker utföra en operation som denne inte är behörig till svarar servern med ett standardiserat felmeddelande. 32

28 Tabell 2. Funktioner för olika typer av åtkomstkontroll. Funktion Beskrivning getfakturalist() Returnerar en lista på fakturor i den personliga fakturakön. checkfakturaaccess($fakturanummer) Kontrollerar åtkomsten till en given faktura. checkuserstatus() Kontrollerar om användaren är medlem i en lövgrupp. checkuserisrootlevel() Kontrollerar om användaren är medlem i grupp nummer ett (ekonomiadministrationen). checkuserstatuslevel($anvandare) Jämför den aktuella användaren mot en annan användare och berättar vem som har högre status. checksigningaccess($summa) Kontrollerar om användaren kan signera en faktura på den givna summan Grupphierarki Vilken information en användare kan nå bestäms av användarens position i det hierarkiska användargruppsträdet. Trädet kan i nuläget bestå av högst tre olika nivåer, men detta är ingen slutgiltig begränsning. En användare som är medlem i en grupp som sitter på lövnivå i trädet (inga undergrupper) kan enbart nå personlig information. Däremot kan en användare som är medlem i gruppen ovanför denna nå all information som finns nedanför den gruppen i trädhierarkin. Denna funktionalitet erbjuder enhetscheferna en möjlighet att övervaka, och hantera, fakturacirkulationen inom den egna enheten. I systemet finns en statisk grupp definierad. Ekonomiadministrationen finns alltid på högsta nivå och kan inte raderas. Medlemmar i ekonomiadministrationen har full kontroll över hela organisationens fakturacirkulation och erbjuds därmed ett större utbud av special- och servicefunktioner. I Figur 8 presenteras den uppbyggda och använda grupphierarkin. 33

29 Ekonomiförvaltning Förman Personal Förman Personal Förman Personal Förman Personal Figur 8. Grupphierarkin i fakturasystemet Specialfunktioner Systemet genererar vid inloggning automatiskt en lämplig funktionsmeny för varje användare. Enhetschefer (medlemmar i grupper på andra nivån i trädet) erhåller endast en specialfunktion som vanliga användare inte har. Med gränssnittet Andra fakturor kan enhetscheferna följa med fakturacirkulationen inom den egna enheten. Ekonomiadministrationen erbjuds ytterligare specialfunktioner. I deras funktionsmeny ingår länkar till gränssnitten Signerade fakturor, Betalda fakturor samt Papperskorgen. Gränssnittet Arkiv saknas tills vidare ännu. Menyerna byggs upp på basis av de resultat servicefunktionerna checkuserstatus() och checkuserisrootlevel() ger. 4.3 Sessionshantering Sessioner används för att lagra personlig information för varje användare under tiden de är inloggade. Vid varje inloggning skapas en ny session med en ny sessionsnyckel. Vid utloggning raderas sessionen. Sessionsdata lagras fysiskt på servern i /tmp katalogen. 34

30 Sessionen innehåller alltid åtminstone information om databasservern. Sådana sessionsvariabler för databasen, vilka alltid är registrerade, visas i Tabell 3. Tabell 3. Variabler för databaskonfigurering. Variabel $host $database $user $pass Beskrivning Databasserverns namn (DNS namn) Databasens namn Användarnamn till databasen Användarens lösenord Variablernas värden läses ur en konfigurationsfil på servern. Filen är placerad och namngiven på ett sådant vis att den inte kan nås via HTTP eller HTTPS. Användandet av en konfigurationsfil gör det enkelt att flytta databasen utan att behöva programmera om gränssnitten. Sessionsdata lagras i klartext i /tmp katalogen i en sessionsfil (se Figur 9). Varje session har en egen sessionsfil med ett unikt filnamn bestående av bl.a. sessionsnyckeln. sess_2f845bcc669cfcdcfa3e450b42de937b Figur 9. Exempel på filnamn för en sessionsfil. Eftersom sessionsfilen innehåller data i klartext (bland annat användarnamn och lösenord till databasservern) är det mycket viktigt att ingen annan än serverns systemadministrator kan logga in lokalt eller via SSH på servern. Det är ändå betydligt säkrare att lagra denna typ av information som sessionsvariabler istället för vanliga variabler direkt i skripten, eftersom dessa kan nås via webbservern. Variabler registrerade i sessionen nås av programkoden på samma sätt som globala variabler. Sessionsinitialisering En session skapas eller initialiseras med funktionen session_start(). Beroende på hur PHP-modulen är kompilerad kan sessioner identifieras på två olika sätt. Antingen är programmeraren skyldig att alltid förmedla variabeln PHPSESSID via URL:en eller så 35

31 förmedlas variabeln automatisk i bakgrunden. Den testserver som detta projekt är utvecklat på förmedlar sessionsnyckeln automatiskt till alla webbsidor, men även programkoden ser till att sessionsnyckeln förmedlas som parameter via URL:en. På så sätt kan man vara säker på att rätt session alltid initialiseras oberoende av hur PHPmodulen är kompilerad. Registrering och avregistrering av sessionsvariabler Sessionsvariabler kan registreras och avregistreras med enkla funktionsanrop (se Tabell 4). En del variabler (såsom databaskonfigurationsvariabler) är alltid registrerade i sessionen medan andra variabler registreras vid behov. Tabell 4. Funktioner för sessionsvariabelshantering. Funktion session_register() session_unregister() session_unset() Beskrivning Registrerar en variabel som medlem i den aktuella sessionen. Avregistrerar en variabel ur den aktuella sessionen. Avregistrerar samtliga registrerade variabler i den aktuella sessionen. Minnesbuffertar Systemet utnyttjar sessionsdata för att skapa minnesbuffertar för databasförfrågningar. Redan i ett tidigt skede i systemets utveckling identifierades ett behov av att begränsa antalet databasförfrågningar med minnesbuffertar för ofta begärd information. Genom att placera minnesbuffertarna i sessionen erhåller varje användare en personlig buffertmiljö innehållande enbart sådan statisk information som denne ofta söker fram. Minnesbuffertarna är oftast vanliga tabeller med nyckel-värde par. Avslutning av session En session kan avslutas och raderas med funktionsanropet session_destroy(). Om inte sessionen putsas bort med funktionsanropet blir sessionsfilen kvar i serverns /tmp katalog och tar upp utrymme. Det är därför viktigt att användaren loggar korrekt ut ur systemet genom att klicka på länken Logga ut. Gamla sessionsfiler kan automatiskt städas bort av webbservern när de har blivit äldre än vad serverns konfiguration tillåter. 36

32 4.4 Uppladdning av filbilagor Till varje faktura skall åtminstone en filbilaga bifogas. Filbilagorna är inskanningar av pappersfakturan samt alla eventuella bilagor som hör till fakturan. Den inskannade pappersfakturan måste bifogas med den elektroniska inmatade fakturan som ett bevis på att fakturan är autentisk och att den verkligen har anlänt till organisationen. Samtidigt möjliggör detta att orginalfakturan kan förstöras, eftersom en inskannade kopiorna kommer att arkiveras elektroniskt tillsammans med godkännandet. Filbilagorna till en inmatad faktura kan vara hur många som helst, dock kan endast en fil laddas upp åt gången vid varje uppdatering av fakturaposterna. Uppladdningen av filbilagorna sker med vanlig HTTP_POST-funktionalitet. Efter att filen laddats upp till serverns hårddisk återfinns filen i /tmp katalogen med ett slumpmässigt och unikt genererat filnamn. Filens orginalegenskaper kan hämtas ur tabellen $_FILES vilken är en två-dimensionell tabell. Tabellens innehåll visas i Tabell 5. Tabell 5. Filinformation för uppladdade filbilagor. Variabel $_FILES[ Bilaga ][ name ] $_FILES[ Bilaga ][ size ] $_FILES[ Bilaga ][ tmp_name ] Beskrivning Orginalfilens filnamn. Storleken på filen. Det temporära filnamnet på servern. Filen lagras i databasen med servicefunktionen attachfiletofaktura(). För hantering av uppladdade filer erbjuder PHP dessutom två servicefunktioner: is_uploaded_file() och move_uploaded_file() (PHP, 2004, kapitel 18). Buffertar och begränsningar I PHP och MySQL finns flera olika inställningar som påverkar uppladdningen av filbilagor med metoden HTTP-POST. Främst är det begränsningar av datamängden som inverkar, men även exekveringstiden för skripten behöver möjligen ändras om stora filer skall laddas upp över långsamma förbindelser. I PHP-modulen finns åtskilliga inställningar som kan påverka filuppladdningen (ingår i /etc/apache/php.ini). Inställningarna sammanställs i Tabell 6. 37

33 Tabell 6. Konfigurationsinställningar för PHP-modulen. Variabel Beskrivning Inställning file_uploads Måste ha värdet On för att filuppladdning skall vara möjlig. On upload_tmp_dir Fullständig sökstig till den katalog uppladdade filer skall /tmp placeras i. Den maximala filstorleken på filer upload_max_filesize som tas emot. 3M post_max_size Den maximala totala datamängden som kan tas emot med metoden HTTP POST. 8M max_execution_time Den maximala körningstiden för ett skript. 30 max_input_time Den maximala tiden ett skript kan använda för att hantera och tolka begärda data. 60 I MySQL måste man kontrollera inställningen i Tabell 7 (ingår i /etc/my.cnf). Tabell 7. Konfigurationsinställningar för MySQL. Variabel Beskrivning Inställning Den maximala datastorleken på en [mysqld] enda databasförfrågan. Påverkar max_allowed_packet speciellt vid skrivning och läsning 4M med datatypen BLOB. Uppladdning över HTTPS Filuppladdning sker på samma sätt över en HTTP- och en HTTPS-förbindelse. SSLmodulen krypterar överföringen helt transparent och ingenting speciellt behöver beaktas för att ladda upp filer över HTTPS. 4.5 Databasplanering All information om fakturor, användare, påminnelser osv. lagras i en relationsdatabas. Databasen är en enkel MySQL-databas utan extra finesser så som referensintegritet. Tabellerna är i MySQL:s egna format, MyISAM-tabeller. Referensintegriteten har lämnats bort eftersom olika versioner av MySQL hanterar den på mycket olika sätt. Projektet använder tills vidare enbart en databas, men det är planerat att arkivet skall flyttas ut till en fristående databas. 38

34 Skillnader mellan MySQL och MySQL Vid övergången från version till version noterades bl.a. att hanteringen av AUTO_INCREMENT-kolumner ändrades. Den äldre versionen genererade ett nytt värde utgående från de andra värdena som fanns i tabellen. Om tabellen tömdes på all data startade numreringen således om på nytt. Den nyare versionen kommer däremot ihåg vilket värde har senast genererats. Även om tabellen töms på all data genereras ett nytt nummer som fortsättning på samma serie. Den nyare versionen fungerar såsom de flesta väntar sig. På grund av att utvecklingen påbörjades med den äldre versionen innehåller genereringen av fakturanummer en speciallösning för att kringgå detta problem. Ett nytt fakturanummer genereras med hjälp av en självprogrammerad transaktion. Det är ytterst viktigt att varje inmatad faktura tilldelas en unik intern fakturanummer som används av systemet för fakturaidentifiering. Eftersom en faktura kommer att flyttas mellan flera olika till synes identiska tabeller kan inte AUTO_INCREMENT-kolumner användas för detta ändamål. Dessutom bibehåller fakturorna samma fakturanummer även i arkivet som kan bestå av en fristående databas. För att lösa dessa problem används tabellen COUNTER för att hålla reda på den senaste utdelade fakturanummern. Tabellen består av enbart en kolumn med enbart en rad. Eftersom ingen annan information ingår i denna tabell kan hela tabellen låsas vid uppdatering av senaste utdelade fakturanummer. Om tabellen inte låses finns det risk för att systemet inte fungerar korrekt för flera samtidiga användare och samma nummer kan då utdelas flera gånger. En situation där två fakturor internt representeras av samma fakturanummer ger upphov till inkonsekvens i systemet och ett index med motstridiga uppgifter. Detta i sin tur skulle troligen innebära att webbgränssnitten inte visar rätt information och att en eventuell uppdatering av ena fakturans information även skulle skriva över den andra fakturan. Detta skräckscenario undviks genom tabellåsningar. 39

35 Lösningen för alla krav var transaktioner. Ett försök att utnyttja transaktionsstödet i MySQL utfördes. MySQL stöder transaktioner från och med versionsfamilj 4. Version stöder inte transaktioner och detta var orsaken till att databashanterarens version uppgraderades medan projektet pågick. Efter några utförliga tester uppdagades dock att den installerade versionen nog förstod syntaxen för transaktionerna, men någon egentlig fysisk låsning av de data som i transaktionen modifieras utfördes inte. Tabellens värden gick att manipulera trots att en annan användare nyss hade startat en transaktion på just den tabellen. Problemet visade sig senare vara MySQL-servern som vid installationsskedet inte hade byggts med stöd för Berkeley-databaser. Dessutom hade projektets databas redan skapats som MyISAM-tabeller och inte som InnoDBtabeller. Eftersom transaktionsstödet trots allt den här gången uteblev programmerades en egen transaktion med hjälp av manuella LOCK- och UNLOCK-satser. Källkoden för denna transaktion visas i Figur 10. LOCK TABLES Counter WRITE; UPDATE Counter SET cnt = cnt + 1; SELECT cnt FROM Counter; UNLOCK TABLES; Figur 10. SQL-kod för generering av ett nytt unikt fakturanummer. Optionen WRITE i låsningskommandot innebär att tabellen Counter låses både för läs- och skrivoperationer för alla andra servertrådar. Övriga trådar som försöker komma åt den låsta tabellen förblir i vänteläge tills tabellen låses upp. Låsningsoperationen i Figur 10 är testad och konstaterad fungerande både i MySQL och MyISAM- och InnoDB-tabeller MySQL stöder olika typer av databastabeller. Valet av tabelltyp påverkar inte nämnvärt applikationsprogrammeringen, men databashanteraren jobbar på olika sätt med olika tabelltyper. Varje tabelltyp har olika egenskaper och valet av tabelltyp måste göras i ett tidigt skede i projektplaneringen. 40

36 Detta projekt byggdes från början med MyISAM-tabeller. Senare erfarenheter visade dock att InnoDB troligen skulle ha varit ett bättre val. För att transaktionshantering skall fungera i MySQL krävs att databasen är byggd med InnoDB-tabeller vilket i sin tur kräver att MySQL kompileras med stöd för Berkeley-databaser. Bristen av en fungerande transaktionshantering på databashanteringsnivå gav upphov till flera speciallösningar som kunde ha undvikits genom valet av InnoDB-tabeller. Databasdiagram I Figur 11 visas databasen och en del av relationerna. I figuren finns inte alla relationer med, eftersom tabellen Fakturor i princip kan bytas ut mot någon av de fyra tabellerna längst mot höger. Tabellen Anvandare relateras till alltid när en användare avses, så som kolumnerna mottagare, avsandare eller agare i fakturatabellerna och i kommentar- och påminnelsetabellen. I diagrammet i figur 11 ingår arkivet ännu som en tabell i samma databas. Tabellen Avdelningar används enbart för att skapa dynamiska listningar över tillgängliga betalare och kopplas aldrig ihop med någon annan tabell. Figur 11. Databasens design och en del av dess relationer. 41

37 Filbilagor De filbilagor som bifogas till en faktura lagras i tabellen Filer. Filerna lagras som dataobjekt av datatypen MEDIUMBLOB vars maximala datastorlek är 16 MB. Av praktiska skäl bör en enskild filbilaga till en faktura inte vara större än några hundra kilobyte. Filstorleken beror på kvaliteten hos den inskannade bilagan. Bilagorna bör givetvis skannas in med en så pass bra kvalitet att bilagorna är läsbara, men inte med för hög kvalitet för då blir filstorleken alldeles för stor. En lämplig upplösning för att skanna en A4-sida bestående främst av text är dpi. Om skanningen dessutom utförs med enbart gråskalor och därefter komprimeras till en JPG-bild kan filstorleken vara några hundra kilobyte och ändå vara fullkomligt tydlig och läsbar. Förutom själva filen lagras i tabellen Filer även orginalfilens filnamn, filstorlek samt datum och klockslag när filen har bifogats till fakturan. För att filen skall kunna associeras med en faktura lagras den avsedda fakturans fakturanummer. Trots att en faktura kan byta tabell flera gånger under dess livscykel förblir filbilagorna hela tiden i samma tabell. En faktura kan ha ett obegränsat antal filbilagor och gränssnittet erbjuder ett bekvämt sätt att bläddra igenom filbilagorna. För att snabbt kunna upptäcka eventuella datafel och relationsfel lagras även ett MD5- extrakt av filen när filen sparas i tabellen. MD5-filextraktet består av en 32 tecken lång hexadecimal teckensträng och beräknas av funktionen mhash(), som är en funktion som inte ingår som standard i en PHP-distribution (se Figur 12). Funktionen har manuellts kompilerats in i PHP-modulen. Vid bläddring bland filbilagorna verifieras alltid MD5- extraktet genom att beräkna ett nytt extrakt och jämföra det med det som beräknades vid filens lagringsögonblick. Om en fil har skadats eller om en fil har av någon orsak blandats ihop med någon annan fil upptäcks detta snabbt tack vare denna kontroll. Dessutom kontrolleras att filstorleken stämmer överrens varje gång filen återskapas på webbserverutrymmet ur databasen. $md5hash = bin2hex(mhash(mhash_md5, $fildata)); Figur 12. Beräkning av ett MD5-extrakt för en fil. 42

38 Begränsningar Eftersom MySQL stöder referensintegritet mycket dåligt används sådana begränsningar inte. Däremot används NOT NULL -begränsningar för sådana fält som inte får lämnas tomma. Begränsningar och kontroller utförs också i programkoden, till exempel före radering av information. Fakturaindex För att hålla reda på i vilka tabeller fakturorna för tillfället finns lagrade i behövs ett index. Tabellen Karta är en tabell som består av två kolumner där ett fakturanummer kopplas ihop med namnet på den fakturatabell där ifrågavarande faktura för tillfället finns sparad. Varje gång en faktura byter tabell måste indexet också uppdateras och när en faktura raderas skall även indexposten raderas. Indexet bidrar till att webbgränssnitten kan bli mera självständiga. Samma gränssnitt kan då användas oberoende av i vilken tabell fakturan finns sparad i. Databasspecifikation Till näst följer en fullständig specifikation för den databas som används för fakturahanteringssystemet (se Tabell 8). Tabellerna presenteras i alfabetisk ordning. Tabell 8A. Användare. Tabell: Anvandare Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt anvandarid INT 4 Nej PK Räknare anvandarnamn VARCHAR 100 Nej epost VARCHAR 100 Ja Null grupp INT 4 Ja FK Grupper Null inloggad DATETIME Ja Null sigbelopp INT 4 Ja Null 43

39 Tabell 8B. Arkiv. Tabell: Arkiv Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde fakturaid INT 4 Nej PK data TEXT Nej signatur TEXT Nej tidsstampel TEXT Nej inskrivnings- DATETIME Nej datum arkiverings- DATETIME Nej datum forfallodag DATE Nej betalnings- DATE Ja Null datum tillaggsdata TEXT Ja Null rubrik VARCHAR 100 Ja Null Övrigt Tabell 8C. Avdelningar. Tabell: Avdelningar Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt avdid INT 4 Nej PK Räknare avdnamn VARCHAR 100 Nej Tabell 8D. Betalda. Tabell: Betalda Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde fakturaid INT 4 Nej PK data TEXT Nej signatur TEXT Ja Null tidsstampel TEXT Ja Null agare INT 4 Nej FK Anvandare 0 mottagare INT 4 Nej FK Anvandare 0 avsandare INT 4 Nej FK Anvandare 0 inskrivnings- DATETIME Nej datum forfallodag DATE Ja betalnings- DATE Ja Null datum tillaggsdata TEXT Ja Null rubrik VARCHAR 100 Ja Null Övrigt 44

40 Tabell 8E. Certifikat. Tabell: Certifikat Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt certifikatid INT 4 Nej PK Räknare certnamn VARCHAR 100 Ja Null data TEXT Nej Tabell 8F. Counter. Tabell: Counter Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt cnt INT 4 Nej Tabell 8G. Fakturor. Tabell: Fakturor Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt fakturaid INT 4 Nej PK data TEXT Nej signatur TEXT Ja Null tidsstampel TEXT Ja Null agare INT 4 Nej FK Anvandare 0 mottagare INT 4 Nej FK Anvandare 0 avsandare INT 4 Nej FK Anvandare 0 inskrivnings- DATETIME Nej datum forfallodag DATE Ja betalnings- DATE Ja Null datum tillaggsdata TEXT Ja Null rubrik VARCHAR 100 Ja Null Tabell 8H. Filer. Tabell: Filer Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt filid INT 4 Nej PK Räknare filnamn VARCHAR 100 Nej filstorlek INT 4 Ja Null bifogad DATETIME Ja Null faktura INT 4 Nej FK Fakturor 0 md5hash VARCHAR 48 Ja Null fil MBLOB Nej 45

41 Tabell 8I. Grupper. Tabell: Grupper Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt gruppid INT 4 Nej PK Räknare gruppnamn VARCHAR 100 Nej Tabell 8J. Gruppstatus. Tabell: Gruppstatus Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde grupp INT 4 Nej FK Grupper ser INT 4 Nej FK Grupper Övrigt Tabell 8K. Karta. Tabell: Karta Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde fakturaid INT 4 Nej PK tabell VARCHAR 24 Nej Övrigt Tabell 8L. Kommentarer. Tabell: Kommentarer Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde Övrigt komid INT 4 Nej PK Räknare faktura INT 4 Nej FK Fakturor anvandare VARCHAR 100 Nej datum DATETIME Nej data TEXT Ja Null beslut TINYINT 1 Ja Null Tabell 8M. Påminnelser. Tabell: Paminnelser Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde fakturaid INT 4 Nej FK Fakturor datum DATETIME Nej person INT 4 Nej FK Anvandare Övrigt 46

42 Tabell 8N. Papperskorg. Tabell: Papperskorg Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde fakturaid INT 4 Nej PK data TEXT Nej signatur TEXT Ja Null tidsstampel TEXT Ja Null agare INT 4 Nej FK Anvandare 0 mottagare INT 4 Nej FK Anvandare 0 avsandare INT 4 Nej FK Anvandare 0 inskrivnings- DATETIME Nej datum forfallodag DATE Ja betalnings- DATE Ja Null datum tillaggsdata TEXT Ja Null rubrik VARCHAR 100 Ja Null Övrigt Tabell 8O. Signerade. Tabell: Signerade Fältnamn Datatyp Storlek Null Nyckel Måltabell Förhandsvärde fakturaid INT 4 Nej PK data TEXT Nej signatur TEXT Ja Null tidsstampel TEXT Ja Null agare INT 4 Nej FK Anvandare 0 mottagare INT 4 Nej FK Anvandare 0 avsandare INT 4 Nej FK Anvandare 0 inskrivnings- DATETIME Nej datum forfallodag DATE Ja betalnings- DATE Ja Null datum tillaggsdata TEXT Ja Null Rubrik VARCHAR 100 Ja Null Övrigt 47

43 4.6 Databaseffektivitet Ett system som används av många användare samtidigt dagligen kan snabbt drabbas av prestandaproblem om applikationen inte är förnuftigt programmerad. Detta system hanterar dessutom relativt stora databasposter på grund av de filbilagor som är sparade i databasen. Under utvecklingsskedet är det svårt att uppskatta och att testa systemets prestanda under hård belastning. Hög databasprestanda uppnås genom att programmera smarta databasförfrågningar och genom att effektivt utnyttja alla kända detaljer i databashanterarens exekveringsplanerare. Optimering av SQL-satser beskrivs detaljerat i den utmärkta boken SQL Performance Tuning (Gulutzan, 2002). Databasprestanda och modulflexibilitet finns ofta i var sin vågskål. Om självständiga moduler skall programmeras innebär det oftast också att en mindre mängd data förmedlas mellan modulerna. Detta gäller speciellt för databasapplikationer där varje modul har tillgång till den underliggande databasen. Redundans uppstår när en modul hämtar data som föregående modul redan hade hämtat. Speciellt all typ av åtkomstinformation lider av detta problem när programmeraren till varje pris vill förhindra en användare att nå sådan information som denne inte borde nå. I detta projekt är det just den här typen av information som ofta läses från databasen. Åtkomsträttigheterna för information förknippad med en faktura ändras ofta vart efter den cirkulerar inom organisationen. Därför måste varje modul själv alltid börja med att kontrollera informationens behörighet. Olika moduler och delmoduler anropas ofta efter varandra i en tät kedja. När varje modul kontrollerar samma behörighet uppstår lätt redundans i databasförfrågningarna. Databashanteraren utför i och för sig väldigt snabbt en identisk databasförfrågning som nyss har utförts eftersom den redan har en förkompilerad exekveringsplan för förfrågningen. Hur som helst orsakar de överflödiga databasförfrågningarna onödig nätverkstrafik om databasservern är installerad på en annan server än själva webbservern. En annan typ av information som väldigt ofta läses flera gånger under samma webbserveroperation är fakturaindexinformationen. Eftersom de flesta gränssnitt är programmerade så att de flexibelt kan hantera fakturorna oberoende av vilket skede en 48

44 faktura befinner sig i behövs ett välfungerande fakturaindex. Med fakturaindexet kan ett fakturanummer länkas till en viss tabell i databasen. Många operationer i modulerna måste läsa indexet. Eftersom en faktura inte flyttar sig mitt under en pågående operation uppstår även här redundanta databasförfrågningar. Minnesbufferthantering För att undvika överflödiga databasförfrågningar programmerades en omfattande arkitektur för hantering av minnesbuffertar. Minnesbuffertarna är av två typer: buffertar som består under hela den tid en användare är inloggad och buffertar som enbart existerar inom den barnprocess av webbservern som betjänar klienten under utförandet av en enda webbserveroperation. Den första varianten kallas härefter för sessionsbuffert och den andra för tillfällig buffert. Oberoende av hurudana buffertar används har de två gemensamma egenskaper: En buffert är alltid personlig och påverkar inte andra inloggade användare. En buffert förhindrar samma databasförfrågning att utföras flera gånger. En buffert är ett minnesområde i webbservern eller en fil på webbserverns hårddisk. Oavsett om bufferten finnes i systemminnet eller på hårddisken returneras eftersökta data snabbt och direkt från bufferten utan att en kontakt till databasservern måste upprättas. Att upprätta TCP/IP-förbindelser kan vara tidskrävande (relativt sett) om nätverket är hårt belastat eller om databasservern befinner sig på ett fysiskt långt avstånd. Mest av allt är buffertarna i detta projekt till för att bli av med flera likadana databasförfrågningar som den höga modulariteten ger upphov till. Databasserverns prestanda förbättras när antalet databasförfrågningar minskar. Sessionsbuffertar kan vara tidsbegränsade eller icke tidsbegränsade. Exempel på sessionsbuffertar som inte är tidsbegränsade är buffertar som innehåller hämtad information om användare och grupper samt information om den inloggade användarens position och befogenheter i organisationen. Denna typ av information behöver ingen tidsbegränsning eftersom informationen inte ändras ofta. För icke tidsbegränsade 49

45 sessionsbuffertar räcker det med att bufferten existerar enbart den tid som användaren är inloggad. För information som troligtvis ändras under den tid som en användare är inloggad används tidsbegränsningar. Exempel på en sessionsbuffert med tidsbegränsning är åtkomstinformationen för fakturor. När en användare beviljats åtkomst till en faktura i systemet sparas åtkomstinformationen i en sessionsbuffert med en tidsbegränsning på 60 sekunder. Under dessa 60 sekunder behövs inga nya databasförfrågningar utföras för att kontrollera om en användare har behörighet till samma faktura. Tidsbegränsningen är nödvändig eftersom en faktura kan cirkulera både upp och ner i organisationens hierarki, vilket kan påverka användarens behörighet till fakturan. Av säkerhetsskäl utförs även en spolning av denna buffert efter att användaren skickat iväg fakturan till en annan mottagare. En sessionsbuffert är, som namnet avslöjar, data som lagras i en tabell i användarens sessionsdata. Dessa data är tillgängliga under hela den tid användaren är inloggad och är fysiskt lagrat i en fil på webbserverns hårddisk. Operativsystemets filhantering och webbserverns sessionshantering hjälper dessutom till med att mellanlagra sessionsdata i systemminnet. Data sparad i sessionstabellen är nåbar mycket snabbt och någon negativ effekt av att informationen egentligen finns sparad i en fil på hårddisken märks inte. Tillfälliga buffertar existerar enbart i den barnprocess av webbservern som betjänar klienten vid en enda webbserveroperation. Dessa används för sådan information som kan ändras i princip när som helst. Buffertens livstid är alltså enbart den bråkdels sekund det tar för webbservern att slutföra en operation. De tillfälliga buffertarna är uppbyggda av statiska variabler i modulerna. Den skapade och använda buffertarkitekturen presenteras i Figur

46 APPLIKATIONS -SERVER B U F F E R T DATABAS- SERVER DATABAS Figur 13. Buffertarkitekturen. Efter att buffertarna implementerats i systemet minskade det totala antalet databasförfrågningar med ungefär en tredjedel. Efter att alla delsystem är färdiga kan inbesparingarna tack vare buffertarna vara ännu större. Dessutom möjliggör dessa buffertar att självständiga moduler med strikt åtkomstkontroll kan programmeras utan att den strikta kontrollen inverkar på databasens prestanda. De extra databasförfrågningarna som fakturaindexet orsakar kan dessutom minimeras till en enda för varje webbserveroperation. 4.7 Modularitet och flyttbarhet Systemet är byggt så att det skall vara enkelt och snabbt att sätta upp och att flytta. Systemet är dessutom lätt att bygga vidare på eftersom det är byggt som flera självständiga moduler och består av ett organiserat funktionsbibliotek för att utföra allmänt förekommande operationer och uppgifter. Funktionsbibliotek Biblioteksfilerna innehållande självständiga funktioner är 10 till antalet. Funktionerna är grupperade enligt kategori till motsvarande biblioteksfil. Genom att programmera allmänna funktioner som anropas från webbgränssnitten blir det lätt att bygga vidare på detta projekt. Dessutom medför denna arkitektur att om en principiell ändring utförs i en funktion fungerar de gamla webbgränssnitten fortfarande som förut, oavsett av hur många olika ställen funktionen anropas ifrån. Att bryta upp applikationen till en samling funktioner minskar avsevärt på den arbetsmängd som behövs för att programmera om systemet. 51

47 Funktionsbibliotek sparas med filextensionen.inc. Webbservern bör konfigureras så att det inte är tillåtet att över HTTP-protokollet hämta biblioteksfilerna. I regel är varje Apache-server som kör PHP konfigurerad på detta vis, eftersom inkluderingsfilerna kan innehålla känslig information som är avsedd enbart för webbservern, exempelvis användarnamn och lösenord till en databasserver som behövs. Tabell 9 sammanfattar de tio biblioteksfilerna. I bilaga 1 presenteras de i detalj. Tabell 9. Funktionsbibliotek. cache.inc Innehåller funktioner för att hantera och kontrollera samtliga sessionsbuffertar. Består i princip av en samling set och get funktioner för att läsa och skriva buffertarna. Dessa funktioner anropas transparent från de egentliga funktionerna som kan läsa och skriva data i databasen. Om en get -funktion returnerar eftersökta data behöver inte den underliggande funktionen läsas samma data från databasen. Däremot om get -funktionen inte kan returnera samma eftersökta data hämtas informationen från databasen och därefter utförs en set - operation för att spara hämtade data i bufferten. db_mysql.inc Består av en samlig allmänna databasfunktioner för kommunikation med databasservern. Funktionerna gör källkoden för webbgränssnitten överskådligare genom att de skalar bort lite källkod som har med databaskontakten att göra. Dessutom automatiserar de vissa processer genom att till exempel direkt ta kontakt med databasservern själv genom att läsa kontaktinformationen från användarens sessionsdata (som ursprungligen har lästs från en konfigurationsfil i inloggningsögonblicket). Dessutom innehåller denna fil den självprogrammerade transaktionen för generering av nya interna fakturanummror. faktura.inc Innehåller funktioner för hantering av fakturor samt den information som en faktura består av. Exempel på sådana funktioner är funktioner för att kontrollera behörighet och funktioner för cirkulation av fakturor. En faktura kan sparas i tabellerna Fakturor, Signerade, Betalda, Arkiv eller Papperskorg (dock endast i en tabell i gången). 52

48 files.inc groups.inc map.inc paminn.inc Innehåller filhanteringsoperationer för exempelvis bifogning av filbihang till fakturor och verifiering av filintegritet. Eftersom en bifogad fil sparas som en BLOB i databasen måste filen när den skall skickas till en klient först läsas ur databasen och sparas på webbserverns hårddisk innan den kan skickas till klienten. För att klara av detta finns ett flertal funktioner i detta bibliotek. De bifogade filerna sparas i tabellen Filer. Består av funktioner för hantering av grupphierarkier. Här finns funktioner som berättar vilka grupper finns både ovan och under användare i organisationen. Informationen behövs för att systemet skall kunna avgöra behörigheten till en faktura. Exempelvis kan en förman nå samtliga fakturor som cirkulerar inom den egna avdelningen medan en vanlig arbetstagare enbart har kontroll över sina egna fakturor. Grupperna är definierade i tabellen Grupper och hierarkin mellan dessa är definierad i tabellen Gruppstatus. Funktioner för automatisk lokalisering av fakturor (även kallat fakturaindex). Databasen består av flere tabeller där varje tabell representerar ett visst skede i en cirkulerande fakturas livscykel. Systemet är programmerat så att samma gränssnitt alltid kan användas oberoende av i vilken tabell i databasen en faktura fysiskt finns sparad. Funktionerna i denna biblioteksfil tar hand om den lokalisering som behövs för att ett gränssnitt skall kunna öppna en faktura. Fakturaindexet består av tabellen Karta i databasen i vilken varje faktura har en indexpost. Systemet har stöd för automatiska påminnelsebrev per e-post. Meddelandena skickas ut för att påminna och aktivera en fakturamottagare när en fakturas förfallodag närmar sig samt när förfallodagen överskridits. Denna biblioteksfil innehåller funktioner som har kontroll över när påminnelser per e-post skall skickas. Funktionerna garanterar att högst ett e-postbrev per faktura per dygn per användare skickas ut. Information om när en påminnelse senast har skickats ut sparas i tabellen Paminnelser. 53

49 signatur.inc users.inc xml.inc Innehåller signaturfunktioner för bland annat verifiering av signaturer och funktioner för hantering av användarcertifikat. Alla certifikat som används för autentisering och signering sparas i databasen i tabellen Certifikat. I denna biblioteksfil finns även en funktion som kan plocka fram det väsentliga ur ett certifikat för presentation. Innehåller funktioner för hantering av användare samt information som berör dessa. En användare behöver inte skapas skilt i systemet utan det räcker med att användaren får åtkomst till webbservern. Därefter sätts användaren automatiskt med i systemet med hjälp av funktioner i denna fil när användaren loggar in för första gången. Här finns även funktioner som kontrollerar en användares behörigheter i organisationen. Användarna finns sparade i tabellen Anvandare. Fakturornas data sparas som XML-metadata som i sin tur sparas som en BLOB i databasen. Denna biblioteksfil innehåller funktioner för att plocka ut information ur XML-poster samt funktioner för att skapa XML-poster. Databaslokalisering Databasoperationerna som finns samlade i filen db_mysql.inc tar automatiskt kontakt till databasservern om kontakt saknas. Information om var databasen finns samt användarnamn och lösenord finns sparat i systemets globala konfigurationsfil. Tack vare att all information som är systemberoende finns samlad i en fil är det lätt att flytta portalen från en webbserver till en annan. Lika lätt kan systemet styras om till en annan databasserver. Den information som finns samlad i konfigurationsfilen läses in och sparas i användarens sessionsdata när denne loggar in. Därefter kan alla funktioner nå denna information och till exempel ta kontakt till databasservern när det behövs. Figur 14 visar ett exempel på hur konfigurationsfilen kan se ut. 54

50 [HOST] localhost [DATABASE] fakturor [USER] fakturauser [PASS] fakturapasswd Figur 14. Exempel på en databaskonfigurationsfil för fakturasystemet. Parameterns namn anges inom klamrar och dess värde följer strax därefter på nästa rad. Alla tomma rader ignoreras. Parametrarna kommer att lagras som globala variabler och nås genom nyckelordet global vid deklaration (om register_globals är aktiverat i PHP) eller via sessionsdatatabellen $_SESSION. 4.8 Signaturhantering Skapandet av elektroniska signaturer med WebSigner Skapandet av de elektroniska signaturerna sköts av WebSigner, som är en del av programvaran SmartTrust Personal. WebSigner stöder två olika signaturprofiler: standardprofilen och Identrus-profilen. Bägge är användbara för webbapplikationer. Detta projekt använder standardprofilen. Formatet på den resulterande signaturen skiljer sig något hos identrus-profilen jämfört med standardprofilen. Identrus-profilen kan man även använda för Java-applikationer. WebSigner är en ActiveX komponent som bäddas in i en webbsida som visas i Internet Explorer. I praktiken är det mycket enkelt att aktivera WebSigner och att skapa signaturen. Informationen som signeras skall vara tillgänglig via webbsidans DOM (Document Object Model) så att ett JavaScript kan hämta information och förmedla den till WebSigner. En komponent i ett webbformulär är lämplig för detta och i projektet används en <TEXTAREA> vilken har som fördel att då kan även användaren se den information som skall signeras i exakt den formen som den där. I textboxen syns den aktuella fakturans verkliga XML-data eftersom hela XML-datapaketet skall ingå i 55

51 signaturen. Figur 15 visar textboxen och webbformulärknappen som aktiverar JavaScriptet som i sin tur aktiverar ActiveX-komponenten WebSigner. Figur 15. Textbox med XML-data för signering. ActiveX-komponenten bäddas in i HTML/PHP-koden med en <OBJECT>- tag. Källkoden för komponentinbäddningen visas i Figur 16. <object id="signer" width=0 height=0 classid="clsid:d9542fc2-817f-4c45-8a02-279d9d705d46"> <param name="type" value="text/x-text-to-sign"> </object> Figur 16. HTML-kod för inbäddning av WebSigner-komponenten. Ett JavaScript kallar på den inbäddade WebSigner-komponenten och ställer in egenskaper för komponenten med hjälp av metoder implementerade i WebSigner. Bland annat bestäms om signaturen skall innehålla alla signerade data eller enbart ett matematiskt extrakt av signerade data samt både datakälla och URL dit signaturen skall skickas. Dessutom definieras ett par andra egenskaper innan den inbyggda funktionen Sign() i WebSigner aktiveras. Funktionen Sign() aktiverar en dialog (se Figur 6) där användaren kan förhandsgranska de data som kommer att signeras när OK -knappen trycks. Dessutom ger dialogen en möjlighet att spara visade rådata till en fil på användarens lokala hårddisk. Efter att informationen har accepterats för signering ombedes användaren ge sin hemliga PIN-kod för aktivering av signeringscertifikatet som behövs vid elektronisk signering. Dialogen för inmatning av PIN-koden för signeringscertifikatet visas i Figur 17 och i Figur 18 visas det JavaScript som aktiverar WebSigner-komponenten. 56

52 Figur 17. Dialogfönster för inmatning av signaturcertifikatets PIN-kod. <script language= JavaScript > function sign() { document.signer.setmimetype("text/plain"); document.signer.setexpectedversion("310"); document.signer.setposturl(" fakturabehandling/circ/spara_signatur.php"); document.signer.setdatatobesigned(document.siginfo.data.value); document.signer.setformat("pkcs7signed_attached"); document.signer.setfilename("faktura_data.txt"); document.signer.setwindowname("_self"); document.signer.setsignreturnname("signeddata"); document.signer.setdatareturnname("data"); document.signer.setbase64("true"); document.signer.setviewdata("true"); rv = document.signer.sign(); } return rv; </script> Figur 18. JavaScript för aktivering av WebSigner-komponenten. JavaScriptet i Figur 18 innehåller enbart ett minimum av de egenskaper som måste definieras för att en signeringsoperation skall kunna utföras. De egenskaper som ingår i skriptet är de viktigaste och flera behövs egentligen inte definieras. Övriga möjliga egenskaper finns dokumenterade i den tekniska beskrivningen av SmartTrust Personal (SmartTrust Technical Description, 2003). I Tabell 10 sammanfattas de nödvändigaste egenskaperna. 57

53 Tabell 10. Metoder för inställning av de vanligaste egenskaperna hos WebSigner. Egenskap/metod Förklaring Type Egenskap som måste definieras som parameter till <OBJECT>. Skall alltid vara text/x-text-tosign och kan inte uteslutas. Övriga egenskaper kan initialiseras av ett JavaScript med hjälp av set()-metoder. SetMimeType() Formatet på de data som skall signeras. För data i ASCII form används text/plain och för signering av en annan signatur (kedja av signaturer) används application/pkcs7- signature. SetExpectedVersion() Minimikrav på versionen hos SmartTrust Personal (versionsnummer multiplicerat med 100, version = 310). SetPostURL() URL för den webbsida dit WebSigner skickar resultatet av operationen (signaturen och orginaldata). Informationen skickas med POST - metoden. SetDataToBeSigned() De data som skall signeras i URL kodat format. SetFormat() Formatet på signaturen. Kan vara PKCS7SIGNED_Attached eller PKCS7SIGNED_Detached. Attached resulterar i en signatur som även innehåller rådata medan Detached resulterar i en signatur som endast innehåller ett matematiskt extrakt av rådatat. SetFileName() Förinställt filnamn då rådata sparas på hårddisken. SetWindowName() Namnet på det bläddrarfönster i vilket webbsidan som tar emot signaturen skall öppnas. SetSignReturnName() Önskat variabelnamn för variabeln som innehåller signaturen i URL-kodat format. SetDataReturnName() Önskat variabelnamn för den variabel som innehåller orginalinformationen (rådata). SetBase64() Transportkodning enligt Base64 formatet. Kan vara true eller false. Base64 kodning utförs före URL-kodning. SetViewData() Definierar hurudan dialog som skall visas vid signeringen. Värdet true ger en dialog där rådata visas medan false ger en mindre dialog utan rådata. IncludeCaCert() Definierar om signaturen skall innehålla hela kedjan av CA-certifikat. Kan vara true eller false. IncludeRootCaCert() Definierar om signaturen skall innehålla Root- CA-certifikatet. Kan vara true eller false Extrahering av signeringscertifikat ur en PKCS#7-signatur I databasen upprätthålls ett arkiv över alla certifikat som använts vid signeringsoperationer samt deras CA-certifikat om det är möjligt att nå dem. Det är viktigt att arkivera alla certifikat så att de alltid finns till hands vid verifieringar av signaturer, obero- 58

54 ende av hur gammal en signatur är och om certifikatet som användes vid signeringen har gått ut. Det certifikat som användes vid signeringen ingår som en del av den PKCS#7-signatur som skapades och om man vill lagra certifikatet skilt från signaturen måste certifikatet kopieras ut ur signaturen. I PHP finns ingen färdig funktion för att utföra enbart denna operation, men OpenSSL kan göra detta. Eftersom den skapade signaturen är en lång URL-kodad teckensträng måste den förbehandlas innan den kan läsas av OpenSSL. Teckensträngen måste delas upp i rader om 64 tecken och PKCS#7-huvudet måste tillfogas. Kommunikationen mellan Apache/PHP och OpenSSL sköts enklast med temporära filer som putsas bort när certifikatet har lästs och placerats i databasen. Figur 19 visar den PHP-kod som kan kopiera ut ett certifikat ur en PKCS#7-signatur. $signatur = chunk_split($signatur, 64); $signatur = "-----BEGIN PKCS7-----\n".$signatur."-----END PKCS7-----"; $infile = tempnam("/tmp", "SIG"); $outfile = tempnam("/tmp", "CERT"); $fp = fopen($infile, "w"); fwrite($fp, $signatur); fclose($fp); passthru("openssl pkcs7 -inform PEM -in $infile -print_certs -outform PEM -out $outfile"); Figur 19. Extrahering av signeringscertifikatet ur en PKCS#7-signatur. Funktionen tempnam() som används i figur 19 skapar ett unikt filnamn som börjar med de tecken som ges som andra parameter. Första parameter är filens katalogstig. Den erhållna URL-kodade signaturen i variabeln $signatur sparas i filen vars namn börjar med SIG och det resulterande certifikatet kommer att återfinnas i filen vars namn börjar med CERT. OpenSSL-operationen utförs av funktionen passthru() och efter att certifikatet lästs in och sparats i databasen kan de temporära filerna raderas med funktionen unlink(filnamn). Som option till OpenSSL ges -print_certs vilken är en funktion i PKCS#7-biblioteket i OpenSSL. Formatet på indata och utdata är PEM. 59

55 När de extraherade certifikaten sparas i databasen bör de identifieras på något lämpligt sätt. I dagsläge sparas de tillsammans med användarens CN-fält (Common Name) som nyckel. CN-fältet består av förnamn och efternamn samt den elektroniska kommunikationskoden. Detta medför att enbart ett certifikat per användare kan sparas, vilket inte är hållbart i längden. Ytterligare någon form av räknarkolumn måste tillfogas till den tabell som innehåller certifikatet så att varje certifikat i databasen kan pekas ut unikt Verifiering av elektroniska signaturer De signaturer som är skapade med standardprofilen hos WebSigner kan verifieras med funktionen openssl_pkcs7_verify() som är en standardfunktion i PHP API. Funktionen kräver att signaturen även innehåller den signerade informationen i klartext och att den är given i S/MIME-format. S/MIME-formatet uppnås genom att först bryta signaturen till rader om 64 tecken och därefter tillfoga S/MIME-huvudet. Signaturtypen är PKCS7_BINARY och ges som andra parameter till openssl_pkcs7_verify(). Signaturen skall vara sparad i en fil och filnamnet ges som första parameter. För verifieringen behövs även CA-certifikatet för signeringscertifikatet och detta skall vara sparat i en fil vars filnamn ges som fjärde parameter. Om verifieringen av signaturen lyckades sparades signeringscertifikatet i den fil vars filnamn gavs som tredje parameter. I Figur 20 visas den PHP-kod som utför verifieringen av signaturer. $signatur = chunk_split($signatur, 64); $signatur = "MIME-Version: 1.0\nContent-Disposition: attachment; filename=\"smime.p7m\"\ncontent-type: application/x-pkcs7-mime; name=\"smime.p7m\"\ncontent-transfer-encoding: base64\n\n".$signatur; $ca = Array(); $ca[0] = "/etc/apache/ssl.crt"; $tmpfname = tempnam("/tmp", "SIG"); $fp = fopen($tmpfname, "w"); fwrite($fp, $signatur); fclose($fp); $checkstatus = openssl_pkcs7_verify($tmpfname, PKCS7_BINARY, $outfile, $ca); unlink($tmpfname); Figur 20. Verifiering av elektronisk signatur i PHP. 60

56 Lösningen i Figur 20 är inte hållbar i längden. Signeringscertifikatens CA-certifikat skall hämtas ur databasens certifikatarkiv och inte från Apache-serverns certifikatkatalog, vilket är fallet i dagsläget. CA-certifikaten kan vara flera till antalet och därför sparas de i en tabell som i sin tur ges som parameter till openssl_pkcs7_verify(). Signaturen som skall verifieras (finns i variabeln $signatur) sparas i en temporär fil som raderas bort efter att operationen utförts. Variabeln $checkstatus kommer efter utförd verifiering att ha värdet true eller false, det vill säga 1 eller 0. Om verifieringen lyckades kommer dessutom filen $outfile att innehålla det signeringscertifikat som användes vid signeringen. Verifieringsoperationen som visas i figur 20 är inte tillräcklig för att uppnå alla de krav som ställs i detta projekt. Verifieringen bör kunna utföras mot ett certifikat som hämtas ur databasens certifikatarkiv och ges som parameter och inte alltid mot det signeringscertifikat som ingår i signaturen. Dessutom borde verifieringsoperationen klara av att verifiera mot en given klartext och inte alltid mot den klartext som ingår i signaturen, eftersom den klartexten aldrig i praktiken används av webbgränssnitten. Det sistnämnda kravet kan uppnås genom att utföra en extra jämförelse mellan den inbakade klartexten i signaturen och den XML-metadatapost som representerar fakturorna. Eftersom det inte ännu finns någon funktion som kommer åt den inbakade klartexten i signaturen kan detta inte utföras. Därtill borde tiden vara en parameter till verifieringsoperationen, eftersom verifieringar av signaturer gjorda med sådana certifikat vars giltighetstid har gått ut garanterat kommer att behöva utföras. Den i PHP inbyggda funktionen openssl_pkcs7_verify() är inte ens nära de krav som ställs på en verifieringsoperation i detta projekt. Det finns heller inga funktioner för att verifiera kedjade signaturer. Detta projekt är planerat på sådant sätt att för fakturornas del behövs inga kedjade signaturer, eftersom det officiella godkännandet av en faktura (kostnad) slutligen tas av en enda person. Vid uppbyggnaden av tidstämplingsfunktionen uppstår ett behov av verifiering av kedjade signaturer, eftersom de skall förnyas med jämna mellanrum. I Figur 21 visas hur kedjan med tidstämplar byggs upp. 61

57 Figur 21. Kedjade tidstämplar. I Figur 22 visas gränssnittet för granskning av en signerad faktura. Gränssnittet använder funktionen i Figur 20. I figuren framkommer att både verifieringen av den elektroniska signaturen och integritetskontrollen av filbilagan har lyckats. Figur 22. Gränssnitt för granskning av signerad faktura. 62

58 4.8.4 Konvertering mellan olika format och kodningar För att utföra alla delmoment av signaturhanteringen behövs konverteringar mellan olika signaturformat. OpenSSL tenderar att föredra signaturer med PKCS#7-huvud, medan de inbyggda funktionerna i PHP föredrar signaturer med S/MIME-huvud. Bägge skall dock alltid vara PEM-kodade och uppbrutna till rader med 64 tecken. På grund av dessa skillnader i format sparas signaturerna i databasen i exakt den form som WebSigner levererar dem i, det vill säga som en enda lång URL-kodad teckensträng utan huvud. Överlag används PEM-kodningen mest, eftersom den är lättast att hantera när den kan representeras med teckensträngar i ASCII-format. DER-kodning påträffas i detta projekt endast för den spärrlista som ges ut av Befolkningsregistercentralen. Spärrlistan måste först omvandlas från DER-kodning till PEM-kodning innan Apache-servern kan läsa den. Konvertering mellan DER- och PEM-kodning görs enkelt med OpenSSL. Figur 23 visar ett exempel på konvertering av en spärrlista. openssl crl inform DER in sulkulista.crl outform PEM out sulkulista_pem.crl Figur 23. Konvertering av DER-kodad spärrlista till PEM-kodad spärrlista. Teckensträngar i X.509-certifikat innehåller enbart tecken som kan representeras med 7 bitar. Tecken med ASCII-koder på 8 bitar ersätts med en hexadecimal kod som inleds med teckenparet \x tätt följt av två hexadecimala tecken. Det skandinaviska tecknet Ö representeras i certifikatsträngar av koden \xd6 och Å representeras av \xc5. För att teckensträngarna skall bli läsbara behövs en avkodning av de hexadecimala koderna. I Figur 24 visas ett exempel på hur detta kan utföras i PHP. while($pos = strpos($input, "\x")) { $prev = substr($input, 0, $pos); $esc = substr($input, $pos, $pos + 4); $hexsum = hexdec($esc[2].$esc[3]); $input = $prev.chr($hexsum).substr($input, $pos + 4); } Figur 24. Rutin för avkodning av hexadecimala koder i teckensträngar. 63

59 Variabeln $input innehåller den teckensträng som skall avkodas. Rutinen fortsätter tills inga flera hexadecimala koder finns kvar i teckensträngen. Resultatet blir att variabeln $input kommer att innehålla den avkodade teckensträngen inklusive alla 8-bitars tecken, såsom alla skandinaviska bokstäver. I Figur 25 visas två exempel på teckensträngar före avkodning och efter avkodning (teckensträngarna är SUBJECT-fältet i de X.509- certifikat som sparade i FINEID-korten). FÖRE AVKODNING /C=FI/SN=KARLSTR\xD6M/GN=KRISTER/CN=KARLSTR\xD6M KRISTER /serialNumber= /C=FI/SN=\xC5STR\xD6M/GN=PEIK/CN=\xC5STR\xD6M PEIK U/serialNumber= U EFTER AVKODNING /C=FI/SN=KARLSTRÖM/GN=KRISTER/CN=KARLSTRÖM KRISTER /serialNumber= /C=FI/SN=ÅSTRÖM/GN=PEIK/CN=ÅSTRÖM PEIK U/serialNumber= U Figur 25. Teckensträngar i X.509-certifikat före avkodning och efter avkodning. 4.9 Datalagring All information sparas i en relationsdatabas som kan fysiskt vara placerad i princip var som helst på Internet, bara den är nåbar från webbservern. I detta projekt har allt installerats på en enda serverdator. Databasen består totalt av 15 tabeller och webbservern har skrivrättigheter till hela databasen inklusive samtliga tabeller eftersom det är meningen att all information skall kunna manipuleras via webbgränssnitt. Webbservern kommunicerar med databasservern med hjälp av SQL-språket. De flesta kolumner i tabellerna är vanliga text- och heltalskolumner. Därtill finns några kolumner som är datumkolumner eller sant/falskt-kolumner. Fakturor och kommentarer sparas med XML i kolumner av datatypen TEXT som är en datatyp med så gott som obegränsad lagringskapacitet. 64

60 4.9.1 Datatypen TEXT och BLOB Binära stora objekt, eller BLOB, är en lämplig datatyp när man inte på förhand vet hur mycket information skall sparas eller av vilken typ eller format informationen är. I praktiken sparas fysiskt enbart ett pekarvärde i kolumnen och själva informationen sparas utanför tabellen men dock i samma databas. Datatypen har ingen standardiserad storleksbegränsning utan dess maximala storlek bestäms av databashanteraren. I MySQL är en TEXT eller BLOB begränsad till 64 kb medan MEDIUM BLOB är begränsad till 16 MB. I praktiken är det ingen större skillnad på TEXT och BLOB. Största skillnaden är att BLOB är helt binär (8 bitar) och kan skilja på stora och små bokstäver vid jämförelser. Om man skall lagra binära filer är det absolut nödvändigt att använda BLOB och inte TEXT. Datatypen TEXT skall enbart användas för text och den skiljer inte på små och stora bokstäver vid jämförelser. För fakturor, kommentarer och certifikat används i detta projekt datatypen TEXT och för lagring av bifogade filer används datatypen MEDIUM BLOB. Tack vare att alla uppgifter finns sparade i ett enda XML-paket går det lätt att uppdatera en faktura i databasen genom att helt enkelt bara spara XML-paketet till en TEXT-kolumn i någon av fakturatabellerna Användningen av XML för datalagring För strukturering och lagring av fakturauppgifter passar XML utmärkt. Användningen av XML gör gränssnittsprogrammeringen enkel. För att klara av hanteringen av XMLdata har två egna funktioner programmerats. Den ena funktionen kan utgående från en tabell med fakturauppgifter och en XML-mall skapa en fullständig XML-post och den andra funktionen kan utgående från denna post återskapa den tabell som innehöll fakturans uppgifter. Principerna är enkla. Det webbformulär som samlar in och presenterar fakturan har komponenter som alla hör till samma tabell. De identifieras med hjälp av ett nyckelnamn i tabellen som är identiskt med motsvarande XML- tag. Därefter kan den egen- 65

61 programmerade funktionen sätta ihop datatabellen med ett på förhand definierat XMLformulär. XML-formuläret finns sparad i websajtkatalogen på webbserverns hårddisk i underkatalogen /xml. Formuläret innehåller inga data utan enbart tomma XML-komponenter. Funktionen hittar taggar och nycklar som har samma namn och fogar in informationen i XML-komponenten. Ordningsföljden på nyckelnamnen behöver inte vara den samma som hos XML-komponenterna i XML-formuläret. XML-formuläret använder ingen DTD-fil som beskriver vilka datatyper och begränsningar en viss komponent i XML-formuläret har. Istället infogas en datatypkonvertering runt om all information som lagras i XML-formuläret. En bättre lösning vore att använda en DTD-fil för att beskriva XML-filens dataformat. XML-formuläret följer standarden XML 1.0 och teckenkodningen är UTF-8. Vid tolkning av XML-formuläret återskapas orginaltabellen med fakturauppgifter. Därefter kan samma webbformulär enkelt fyllas i med fakturauppgifterna. Man kan alltså hantera alla typer av information och ha hur många olika fält som helst. Ända kravet är att webbformulärkomponenternas namn skall stämma exakt överrens med namnen på XML-formulärets komponenter. Därefter kan alla typer av information cirkuleras, signeras och arkiveras. Figur 26 visar stommen av det XML-formulär som används för att spara en faktura och i Figur 27 visas stommen av XML-formuläret för lagring av ett delbeslut (kommentar). <FAKTURA> <LEVERANTORNR></LEVERANTORNR> <FAKTURANR></FAKTURANR> <LEVERANTORNAMN></LEVERANTORNAMN> <FAKTURADATUM></FAKTURADATUM> <FORFALLODAG></FORFALLODAG> <BANKKONTO> <BANK></BANK> <KONTO></KONTO> </BANKKONTO> <REFERENS></REFERENS> <MEDDELANDE></MEDDELANDE> <KONTAKTPERSON></KONTAKTPERSON> <BETALARE></BETALARE> <EUR></EUR> </FAKTURA> Figur 26. XML-formulär för lagring av fakturauppgifter. 66

62 <KOMMENTAR> <PERSON></PERSON> <TEXT></TEXT> <BESLUT></BESLUT> </KOMMENTAR> Figur 27. XML-formulär för lagring av delbeslut (kommentarer). De XML-formulärsmallar som på förhand finns definierade saknar XML-huvudet, enbart de enskilda XML-komponenterna är definierade i mallen. När den fullständiga XML-posten skapas sätts XML-huvudet till. Dessutom infogas konverteringsoperatorn![cdata[information]] runtom den egentliga informationen för att tvinga XMLtolkaren till att tolka informationen som teckensträngar (CDATA = Character Data). För att informationen från fakturan skall gå att sätta ihop med XML-formuläret skall som sagt webbformulärskomponenterna ha samma nyckelnamn som motsvarande XML-komponenter. Ett förkortat exempel på ett sådant webbformulär visas i Figur 28. <form name= faktura_form action= spara.php method= post enctype= multipart/form-data > <input type= text size= 10 name= Faktura[LEVERANTORNR] > <input type= text size= 10 name= Faktura[FAKTURANR] > <textarea name= Faktura[LEVERANTORNAMN] cols=20 rows=5></textarea> <input type= text size= 10 name= Faktura[FAKTURADATUM] >... <input type= submit name= spara_knapp value= Spara Faktura > </form> Figur 28. Webbformulär för insamling av data till XML-formulär. Formuläret använder kodningen multipart/form-data för att även kunna ladda upp filer. Text och filer postas sedan till spara.php som har till uppgift att skapa den kompletta XML-posten och att spara uppladdade filer i databasen (i detta projekt heter den filen update_faktura.php). Formuläret kan automatiskt fyllas i, om informationen finns tillgänglig, genom att ge förhandsinställda värden med hjälp av attributet value. All inmatad information kommer efter postning att finnas sparad i tabellvariabeln $Faktura som är en tabell bestående av (nyckel, värde)-par. Nyckelnamnet är den teckensträng 67

63 som är given inom de hårda klamrarna [] och värdet blir det värde som webbformulärskomponenten har. När nyckelnamnen i tabellen är de samma som XML-komponenternas namn kan funktionen i Figur 29 sammanfoga XML-formuläret (definierat i en fil) och det önskade innehållet (postat från webbformuläret). function create_xml_string($xml_file, $data) { $fp = fopen($xml_file, "r"); $xml_string = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n"; if($fp) { while(!feof($fp)) { $buffer = fgets($fp, 4096); $xml_rad = $buffer; $buffer = str_replace("<", "", $buffer); $buffer = str_replace(">", "", $buffer); $buffer = ltrim($buffer); $pos = strpos($buffer, '/'); if($pos > 1) { $xml_tag = substr($buffer, 0, $pos); if(!array_key_exists($xml_tag, $data)) { $data[$xml_tag] = ""; } $insert_value_pos = strpos($xml_rad, '/') - 1; $xml_final_rad = substr_replace($xml_rad, "<![CDATA[".$data[$xml_tag]."]]>", $insert_value_pos, 0); $xml_string.= $xml_final_rad; } else { $xml_string.= $xml_rad; } } } fclose($fp); } return trim($xml_string); Figur 29. Funktion för sammanfogning av tabell och tomt XML-formulär. 68

64 Funktionen i Figur 29 läser det tomma XML-formuläret (ges som första parameter) och infogar information från tabellen med fakturauppgifterna (ges som andra parameter). Funktionen infogar datatypkonverteringsoperatorn![cdata[]] runtom själva informationen för att tvinga XML-tolkaren att hantera informationen som teckensträngar. Ifall en DTD-fil skulle ha använts skulle denna operator kunna uteslutas, eftersom DTD-filen då skulle berätta till XML-tolkaren att det är fråga om en teckensträng. Om DTD-fil används ges sökstigen till filen som parameter i XML-huvudet. För att tolka och läsa ut information ur en komplett XML-post kan funktionen som visas i Figur 30 användas. Funktionen skapar en tabell innehållande nyckel-värde par med nyckelnamn identiska med de XML-komponenters namn som existerar i XML-formuläret. Funktionen kan inte hantera eventuella dubbla XML-poster med samma namn. Det är möjligt att både funktionerna i Figur 29 och 30 kunde ersättas med grundfunktioner för XML-hantering som ingår i PHP-standardbiblioteket. Funktionen i Figur 30 tar som enda parameter det fullständiga XML-formuläret innehållande all information, datakonverteringsoperatorer samt XML-huvudet. Utgående från XML-komponenternas namn byggs en tabell upp med nyckel-värde par. På grund av detta tillvägagångssätt stöder funktionen inte XML-formulär som innehåller flera instanser av samma komponenter, det vill säga taggar med samma namn. Ifall sådana påträffas kommer den ena av dem att skrivas över den andra i det slutgiltiga resultatet. Själva XML-standarden är uppbyggd att stöda flera instanser av samma komponenter och man kan till och med säga att detta är en av grundidéerna i XML. I detta projekt används dock aldrig i samma XML-formulär flera instanser av XML-poster med samma namn, men till exempel kommentarerna (delbesluten) kunde lagras inom samma XMLformulär som fakturan genom att för varje kommentar infoga en ny XML-post för motsvarande kommentar. Detta skulle då kräva att funktionen i Figur 29 programmeras om för att klara av att hantera flera XML-komponenter med samma namn i samma XMLformulär. Istället för detta lagras kommentarerna i tabellen Kommentarer i databasen. Varje kommentar blir en egen rad i tabellen. Själva kommentarerna kunde vara sparade i XML, men i dagsläge är de lagrade som ren text separerad till olika kolumner. 69

65 function parse_xml_string($xml_data) { $pos = strpos($xml_data, ">") + 1; $meta_xml = trim(substr($xml_data, 0, $pos))."<metadata>".trim(substr($xml_data, $pos))."</metadata>"; $parser = xml_parser_create(); xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, 0); xml_parse_into_struct($parser,$meta_xml,$vals,$index); xml_parser_free($parser); $faktura_data = Array(); reset($faktura_data); foreach($index as $indexkey => $indexval) { do { $row = $vals[current($indexval)]; $complete = 0; foreach($row as $key => $value) { switch($key) { case "type": if($value == "complete") $complete = 1; break; case "value": $tagvalue = $value; break; } } default: $tagvalue = ""; break; } if($complete) { if(array_key_exists($indexkey, $faktura_data)) { if(is_array($faktura_data["$indexkey"])) { array_push($faktura_data["$indexkey"], $tagvalue); } else { $oldvalue = $faktura_data["$indexkey"]; $faktura_data["$indexkey"] = Array(); array_push($faktura_data["$indexkey"], $oldvalue); array_push($faktura_data["$indexkey"], $tagvalue); } } else $faktura_data["$indexkey"] = $tagvalue; } } while(next($indexval)); } return $faktura_data; Figur 30. Funktion för utplockning av information ur XML-formulär. 70

66 I Figur 31 visas ett exempel på en fullständig XML-post för en faktura, en filbilaga samt den tilläggsinformation som behövs för bokföringen. FAKTURA OCH FILBILAGA <?xml version="1.0" encoding="utf-8"?> <FAKTURA> <LEVERANTORNR><![CDATA[7853]]></LEVERANTORNR> <FAKTURANR><![CDATA[133423]]></FAKTURANR> <LEVERANTORNAMN><![CDATA[Mikromafia OY]]></LEVERANTORNAMN> <FAKTURADATUM><![CDATA[ ]]></FAKTURADATUM> <FORFALLODAG><![CDATA[ ]]></FORFALLODAG> <BANKKONTO> <BANK><![CDATA[Nordea]]></BANK> <KONTO><![CDATA[ ]]></KONTO> </BANKKONTO> <REFERENS><![CDATA[ ]]></REFERENS> <MEDDELANDE><![CDATA[Datorer till Hanse.]]></MEDDELANDE> <KONTAKTPERSON><![CDATA[Fredrik Finnberg]]></KONTAKTPERSON> <BETALARE><![CDATA[IT-centralen]]></BETALARE> <EUR><![CDATA[3470]]></EUR> </FAKTURA> <FIL> <ID><![CDATA[9]]></ID> <FILNAMN><![CDATA[faktura.jpg]]></FILNAMN> <MD5HASH><![CDATA[d22410ec0eba0e462666dd711a6c7f83]]></MD5HASH> </FIL> TILLÄGGSINFORMATION <?xml version="1.0" encoding="utf-8"?> <TILLAGSINFORMATION> <TILI><![CDATA[2580]]></TILI> <KS><![CDATA[23]]></KS> <PROJ><![CDATA[479]]></PROJ> <PERS><![CDATA[14]]></PERS> <RESKONTRA><![CDATA[125235]]></RESKONTRA> <VERIFIKAT><![CDATA[IF355]]></VERIFIKAT> <KOSTNAD><![CDATA[Investering]]></KOSTNAD> </TILLAGSINFORMATION> Figur 31. Fullständig XML-post för lagring av fakturauppgifter och filbilagor. Utnyttjandet av XML för informationsrepresentation behöver ännu utvecklas och utvidgas. Flexiblare lösningar uppnås genom användningen av XML-poster istället för den traditionella metoden att spara varje värde i en egen kolumn i en relationsdatabastabell. Dessutom möjliggör XML att informationen lätt kan exporteras till andra system som stöder XML. De flesta moderna program kan numera läsa och skriva data i XML-format och formatet är även lämpligt för långsiktig arkivering eftersom informationen i grund och botten är lagrad som renodlad text. 71

67 Under systemutvecklingen underlättar användningen av XML förändringar av informationsmodellen. Om webbformulärskomponenter läggs till eller tas bort är fortfarande den äldre XML-informationen kompatibel med det nya webbformuläret. Nya fält förblir då tomma och borttagna fält visas inte trots att de ingår i XML-informationen. Man kan likna händelseförloppet med en JOIN i databassammanhang, d.v.s. att resultatet blir en förening av två tabeller där enbart de rader som i den ena tabellen har en motsvarande rad i den andra tabellen tas med Databastabeller En faktura är fysiskt sparad i olika tabeller i databasen beroende på i vilket skede av cirkulationen den befinner sig i. Det finns fem möjligheter. Dessutom finns en tabell för indexet över fakturorna. Fakturatabellerna sammanställs av översikten i Tabell 11. Tabell 11. Databastabeller för lagring av fakturor. Tabellnamn Fakturor Signerade Betalda Arkiv Beskrivning Här sparas fakturorna när de matas in och så länge som de fortfarande cirkulerar runt för delbeslut. Efter att det slutgiltiga godkännandet har utförts och fakturan har signerats elektroniskt flyttas den till denna tabell. Tabellen nås enbart av ekonomiadministrationen. När ekonomiadministrationen betalt fakturan flyttas den över till denna tabell för att ligga i karantän en tid innan den slutligen långtidsarkiveras. Karantänen behövs ifall en betalning annulleras, eftersom arkivet enbart skall enbart ta emot fakturor fakturor skall inte raderas ur arkivet. Tabell för arkivet. Kunde också vara en skild databas (då behövs flera tabeller för bl.a. filer och kommentarer). Används i dagsläget inte alls ännu. Papperskorg När en faktura raderas av någon användare placeras den i papperskorgen. Papperskorgen kan tömmas av ekonomiadministrationen och fakturor kan även försättas på nytt i cirkulation från papperskorgen. Papperskorgen är inte synlig för andra än ekonomiadministrationen. Karta Tabell som enbart består av två kolumner. Berättar i vilken tabell en given faktura hittas på basis av internt fakturanummer. Övriga databastabeller som innehåller fakturarelaterad information är Kommentarer, Filer och Certifikat. 72

68 4.10 Flexibilitet och självservice Detta system är flexibelt uppbyggt och det torde vara enkelt att bygga vidare på koden. Stor vikt har lagts vid strukturering och planering av källkoden och alla källkodsdelar som kan användas gemensamt av flera gränssnitt har programmerats som funktioner grupperade till bibliotek enligt kategori. Dessutom har många automatiska finesser för underhållning av systemet programmerats in för att hålla administratorns arbete på en minimal nivå Återanvändning av programkod För att undvika att programmera liknande funktionalitet flera gånger har flera gränssnitt planerats så att de kan fungera korrekt oavsett varifrån de länkas och med vilken faktura de skall fungera tillsammans med. Grundpelaren som möjliggör detta är det centrala fakturaindexet som håller reda på i vilka tabeller fakturorna för tillfället är sparade i. Detta gör att exempelvis edit_faktura.php alltid kan öppna en faktura oavsett varifrån sidan länkas och oavsett i vilken databastabell fakturan finns lagrad. Samma gäller även gränssnitten för granskning av signaturer och för bläddring bland filbilagor till fakturor, samt flera andra gränssnitt Automatiska servicefunktioner Det finns ett flertal funktioner som automatiskt själva utför arbetsuppgifter som till exempel en administrator kan hamna att utföra. Detta bidrar till att minska underhållsarbetet av systemet till en minimal nivå. Dessa funktioner triggas till exempel vid inloggning medan andra kan triggas av att användaren utför en viss operation. Radering av temporära filer Vid flera tillfällen används temporära filer. De används regelbundet av systemet vid hantering av certifikat och signaturer. Dessa filer raderas dock bort automatiskt av samma funktion som skapade dem för att hårdskivan inte skall fyllas upp av gamla tillfälliga filer. 73

69 Sessionsdata lagras också i filer på webbserverns hårddisk. Dessa kan bli relativt sett ganska stora (flera kilobyte), eftersom de kan innehålla en ansenlig mängd med buffertdata. Sessionsfilerna ligger kvar i webbserverns /tmp katalog tills sessionen har blivit för gammal (inställning i php.ini) eller tills den avslutas med funktionsanropet session_destroy(). Sessionen avslutas på användarens begäran via länken Logga ut som finns längst ned på menyn i vänster marginal. Därför rekommenderas att man alltid loggar ut via Logga ut -länken när man lämnar systemet. Vid bläddring bland bifogade filer till fakturor används också temporära filer. Själva filbilagorna lagras i databasen i tabellen Filer, men för att användaren skall kunna titta på dem i sin webbläddrare måste webbklienten kunna hämta dem via HTTPS-protokollet. Detta kräver att filen finns publicerad på webbservern i det ögonblick som användarens webbläddrare hämtar bilden via en <img>- tag. Filer publiceras ur databasen på webbserverns filområde av funktionen getfilefromdb(). De filer som publicerats ur databasen på webbserverområdet tillåts ligga kvar en stund på webbserverområdet ifall de skulle behövas laddas på nytt till klienten eller till en annan klient. På detta vis kan man spara in en aning på relativt resurskrävande operationer som att läsa stora filer (från flera hundra kilobyte upp till ca en megabyte) ur databasen och skriva ner dessa på webbserverns hårddisk. Den funktion som publicerar filer ur databasen till webbserverområdet kontrollerar alltid först ifall filen redan är publicerad, i så fall returneras dess URL direkt utan att någon databasoperation behöver utföras. De publicerade filbilagorna raderas bort från webbserverområdet varje gång den tillhörande fakturan cirkuleras i systemet med hjälp av funktionen deletepublishedattachments(). Funktionen tar som enda parameter ett internt fakturanummer och raderar därefter alla filbilagor som publicerats från den fakturan. De publicerade filbilagorna placeras i /tmp katalogen som finns i roten på webbserverområdet, en katalog där även webbservern har skrivrättigheter. Filbilagorna får tillfälliga filnamn som är filbilagans interna nummer efterföljt av extensionen.jpg. När en faktura raderas ur systemet utförs även samma operation. Om däremot enbart en filbilaga raderas, raderas även en eventuell publiceringskopia med funktionsanropet deletefile() där filbilagans interna filnummer ges som parameter. 74

70 Utskickning av påminnelsebrev per e-post För att man inte skall behöva betala en massa förseningsavgifter och räntor i onödan är det viktigt att fakturorna betalas i tid. I en stor organisation kan den manuella cirkulationen via den interna posten vara tidskrävande och en faktura kan redan ha förfallit till betalning innan den ens når fram till ekonomiavdelningen. Den elektroniska cirkulationen förkortar avsevärt den tid som behövs för att en faktura skall vandra runt i organisationen och fram till ekonomiavdelningen för betalning. Det nya problemet som eventuellt kan uppstå i den elektroniska cirkulationen är att systemanvändarna inte besöker sin elektroniska postlåda för fakturor tillräckligt ofta för att upptäcka och behandla köande fakturor. Speciellt skadligt blir detta ifall en köande faktura är nära förfallodagen och användaren inte vet om den eftersom denne inte varit inloggad sedan fakturan anlänt till den personliga fakturakön (postlådan). Förmännen har möjlighet att övervaka detta inom den egna avdelningen, och kan på så vis påminna en kollega muntligt om att åtgärda en viss faktura, eller ta saken i egna händer och behandla den. För att göra det dagliga arbetet smidigare har systemet stöd för att automatiskt påminna användare per e-post om obehandlade fakturor som närmar sig sin förfallodag. Funktionen som skickar ut breven behöver triggas av någon annan händelse i systemet och denna triggning utförs varje gång någon loggar in i systemet (åtminstone ekonomiavdelningen loggar in dagligen i fakturasystemet). Funktionen söker därefter fram alla fakturor som förfaller inom fyra dagar och skickar ett e-post brev till de användare som har en sådan faktura i sin personliga fakturakö. En förutsättning för att påminnelsebrevet skall kunna skickas är att användaren har meddelat systemet sin e-post adress via Inställningar i systemet. För att systemets automatiska utskick av e-post inte skall upplevas som störande skickas för varje faktura i riskzonen högst ett brev per användare per dag. Ifall samma användare mottar samma faktura på nytt samma dag kan ett andra brev skickas, eftersom fakturan då troligtvis behöver brådskande behandling. Påminnelsebrev per e-post kan även skickas manuellt av en förman eller medlem i ekonomiavdelningen. Då har även avsändaren en chans att manuellt formulera brevet innan det skickas. Ett mottaget automatiskt påminnelsebrev visas i Figur

71 Figur 32. Automatiskt påminnelsebrev per e-post. Självbyggande fakturaindex Alla gränssnitt som öppnar och behandlar fakturor behöver kunna lokalisera en faktura bland databasens alla tabeller. Varje skede i en fakturas livscykel representeras av en skild tabell i databasen och för att ha en överblick över dessa används en indextabell. Indextabellen håller reda på i vilken tabell en viss faktura för tillfället finns sparad. Detta index byggs upp automatiskt efter hand som användarna jobbar med fakturorna. Varje gränssnitt som läser in en faktura från databasen börjar med att lokalisera fakturan med funktionsanropet getmap() där intern fakturanummer ges som parameter. Denna funktion slår upp fakturan i indextabellen och returnerar det korrekta tabellnamnet. Om fakturan saknar indexpost söker funktionen systematiskt genom alla tabellalternativ tills den hittar den efterfrågade fakturan. Tabellerna prövas i den ordning det är mest sannolikt att fakturan hittas i. Därefter skapas ett indexvärde för fakturan i indextabellen. Dessutom använder funktionen getmap() en statisk tabell som minnesbuffert för att snabba upp efterföljande indexförfrågningar av samma barnprocess av Apache-servern. Minnesbufferten är väldigt nyttig, eftersom många separata funktioner kan efter varandra utföra samma indexförfrågan. 76

72 När en faktura cirkuleras uppdateras även indextabellen med funktionen setmap() som kan antingen infoga ett nytt indexvärde eller uppdatera ett befintligt indexvärde. Funktionen väljer mellan att utföra en insert eller en update på basis av resultatet av en select-förfrågan. Nya indexvärden kan infogas manuellt med funktionen insertmap() och raderas med funktionen deletemap(). Figur 33 visar hur en indextabell kan se ut i databasen. mysql> select * from Karta; fakturaid tabell Betalda 3 Betalda 4 Betalda 5 Betalda 7 Betalda 21 Fakturor 10 Fakturor 18 Signerade 12 Betalda 20 Fakturor 14 Betalda rows in set (0.01 sec) Figur 33. Innehållet i indextabellen i databasen. Insättning av nya användare i systemet När en användare loggar in för första gången till fakturasystemet kontrollerar systemet om användaren är definierad i systemet. Ifall användaren inte finns med i användartabellen sätts användaren in i tabellen av funktionen insertuser(). Denna procedur utförs av funktionen checkforuser() som triggas vid inloggningen. Någon validering av åtkomsträttigheter till systemet behövs inte eftersom mod_ssl-modulen redan har tagit hand om den saken. Om en användare kan komma åt fakturasystemets filer är denne även behörig och konfigurerad på webbservern som användare. Funktionen checkforuser() behövs alltså enbart för att på applikationsnivå definiera användaren så att denne kan hantera och cirkulera fakturor som en del av organisationen. En på applikationsnivå nydefinierad användare saknar medlemskap i någon grupp tills systemadministratorn har upptäckt den nya användaren och valt en grupp. 77

73 Uppföljning av senaste inloggning för användare Vid varje inloggning loggas inloggningstidpunkten och uppdateras i användartabellen. Tidpunkten för senaste inloggning visas under användarens namn och avdelning högst uppe på skärmen i högra kanten (se Figur 34). Förmännen kan följa med och se när deras anställda senast har varit inloggade i fakturasystemet. Inloggningsögonblicket loggas och uppdateras med funktionen updateuserlogintime(). Figur 34. Information om den inloggade användaren. Minnesbuffertar med tidsbegränsning för åtkomstinformation Minnesbufferten för funktionen checkfakturaaccess(), som är en mycket central och viktigt del av auktoriseringen i fakturasystemet, är en buffert som är tidsbegränsad till 60 sekunder. Eftersom funktionen utgör hjärtat av all auktorisering av fakturor behöver funktionen anropas av varje funktion som behandlar en faktura. Detta orsakar lätt många upprepningar av samma kontroller och minnesbufferten avlastar då både databasservern och webbservern. När en faktura cirkulerar inom organisationen kan åtkomsten till den ändras och begränsas för vissa användare. Därför har denna minnesbuffert en giltighetstid på högst 60 sekunder för varje post i bufferten varefter en post måste förnyas via en ny åtkomstprövning mot databasen. Varje post i minnesbufferten har en egen tidstämpel som håller reda på när posten inte mera är giltig. Inom giltighetstiden kan en användare beviljas åtkomst till en faktura oberoende av vart i systemet fakturan har flyttat sig ifall användaren hade åtkomst till den när posten i minnesbufferten skapades. Det är dock föga troligt att en faktura skulle behandlas så pass snabbt att den hinner byta åtkomstnivå under den kommande minuten sedan fakturan hämtades för första gången. Det är värt att notera att minnesbufferten innehåller information om åtkomsten till behandlade fakturor, vilket kan vara både positiva och negativa poster (1 = åtkomst beviljad, 0 = åtkomst nekad). När användaren själv skickar iväg en faktura för cirkulation anropas funktionen flushaccesscache() som tömmer hela 78

74 åtkomstbufferten, vilket orsakar att användaren kan direkt bli nekad åtkomst till fakturor som skickades upp i organisationen. All ovannämnd funktionalitet utförs tillsammans av biblioteksfunktionerna checkfakturaaccess(), setaccesscache(), getaccesscache() och flushaccesscache(). Förnyelse av tidstämplar Elektroniska handlingar som har signerats och tidstämplats elektroniskt lider av dilemmat att tidstämplingsmyndighetens certifikat löper ut under den tid som de arkiveras. För att inte förtroendet för de certifierade tidstämplarna skall tappas, måste tidstämplarna förnyas genom att signeras på nytt med det nya certifikatet för tidstämplingsmyndigheten innan det gamla certifikatet löper ut. På så vis skapas en kedja med bevisbara tidstämplar där varje tidstämpel kan verifieras. Denna process måste triggas varje gång tidstämplingsmyndigheten ger ut ett nytt certifikat. Alternativt kan systemet byggas så att det triggar ett meddelande till systemadministratorn som startar förnyelseprocessen manuellt (kan vara en god idé att ta en säkerhetskopia innan förnyelseprocessen startas). Hela denna process saknas ännu i detta projekt, liksom hela det elektroniska arkivet som kommer att innehålla all den information vars tidstämplar skall förnyas Databashantering Alla funktioner som hanterar databasförfrågningar är inkapslade i egna funktioner så att själva webbgränssnitten inte behöver anropa någon specifik databashanterares APIfunktioner. Detta gör det enkelt att byta databashanterare genom att enbart behöva programmera ett nytt funktionsbibliotek som erbjuder samma funktioner för den nya databashanteraren som för den gamla. Sedan inkluderas den nya biblioteksfilen istället för den gamla och alla gränssnitt förblir intakta Administration Det finns två olika typer av administrationsbehov. Webbservern behöver en systemadministrator som har skrivrätt till webbserverns konfigurationsfiler och fakturacirku- 79

75 lationsapplikationen behöver en administrator som kan konfigurera applikationen. Dessutom måste ju också databasen och operativsystemen på servrarna skötas om, säkerhetskopiering skall utföras etc. Troligtvis är det oftast samma administratör som i praktiken då också sköter om konfigurationen av webbservern. Denna systemadministratör behöver inte nödvändigtvis vara samma person som konfigurerar applikationen. Däremot måste webbserveradministrator konfigurera webbservern så att den kan identifiera personer som är applikationsadministratörer Konfigurering av administratörer och applikationsanvändare Underhåll av applikationsanvändare och applikationsadministratörer utförs egentligen på samma sätt. I bägge fallen måste man direkt editera webbserverns konfigurationsfiler på webbserverns hårddisk. De delar som behöver ändras är <LOCATION>-inställningarna i mod_ssl-modulens konfigurationsfil, som kan vara antingen en skild fil som länkas eller ingå i webbserverns konfigurationsfil. I detta fall har mod_ssl-modulen en skild konfigurationsfil (mod_ssl.conf) och den länkas då till webbserverns konfigurationsfil (httpd.conf) med ett Include-direktiv. Varje applikationsanvändare och applikationsadministrator behöver en egen rad i konfigurationsfilen. Raderna är nästintill identiska, det enda som skiljer dem åt är att de alla innehåller olika elektroniska kommunikationskoder. Användare sätts alltså till systemet enbart genom att spara deras elektroniska kommunikationskod i mod_ssl-modulens konfigurationsfil. Tillsammans utgör alla kommunikationskoder ett långt villkor till SSLRequire-parametern där kommunikationskoderna kontrolleras samt att certifikatutgivaren är den korrekta. Applikationsanvändarna skall begränsas från och med webbrotkatalogen (<LOCATION />) ifall fakturacirkulationsapplikationen ligger direkt i rotkatalogen. Annars kan man aktivera begränsningen enbart från och med installationskatalogen för applikationen (i detta fall /fakturabehandling). Från och med administrationskatalogen sätts striktare åtkomst för enbart administratörerna genom att definiera en ny <LOCATION>-parameter (i detta fall /fakturabehandling/admin). I Figur 35 visas den åtkomstkonfigurering som använts i detta projekt. 80

76 <Location /> SSLVerifyClient require SSLVerifyDepth 5 SSLOptions -FakeBasicAuth SSLRequire ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= / and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= u/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= j/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= l/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= n/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= s/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= n/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= d/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= u/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= w/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) </Location> <Location /fakturabehandling/admin> SSLVerifyClient require SSLVerifyDepth 8 SSLOptions -FakeBasicAuth SSLRequire ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= / and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= u/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) </Location> Figur 35. Konfiguration av användare och åtkomstbegränsningar för webbservern Underhåll av användarinformation Efter att användarna har definierats på webbservernivå behövs ingen ytterligare konfigurering för att de skall kunna använda systemet. Användaren kommer vid den första inloggningen automatiskt att infogas i applikationens användartabell. Därefter kan en applikationsadministratör sätta med den nya användaren som medlem i en viss grupp eller tilldela användaren signeringsrättigheter (godkänningsrätt för fakturor) upp till en viss summa. Användaren kan själv meddela systemet sin e-postadress ifall användaren samtycker till att motta påminnelsebrev från systemet. Applikationsadministratorn kan även radera en användares uppgifter, men det hindrar inte användaren från att fortfarande logga in till systemet. Ifall administratorn har för avsikt att blockera användaren måste användarens elektroniska kommunikationskod uteslutas ur mod_ssl-modulens konfiguration. En användares uppgifter i användar- 81

77 tabellen försvinner aldrig automatiskt trots att användaren blockeras av systemadministratorn genom att uteslutas ur konfigurationsfilen. Av historiska och statistiska skäl är det egentligen onödigt att någonsin radera användarinformation för borttagna användare eftersom personalomsättningen för ett fakturacirkulationssystem ändå aldrig i praktiken är särskilt stor. Oftast räcker det med att plocka bort användaren från webbserverns konfiguration samt att på applikationsnivå upplösa ett eventuellt gruppmedlemskap. Figur 36 visar underhållsgränssnittet för användarinformation och Figur 37 visar underhållsgränssnittet för signeringsrättigheter. Figur 36. Applikationsanvändare samt deras gruppmedlemskap. Figur 37. Gränssnitt för underhåll av signeringsrättigheter. 82

78 Underhåll av grupper Grupper kan skapas och raderas via ett administrationsgrässnitt tillgängligt för applikationsadministratorn. Med samma gränssnitt kan man även definiera relationer mellan grupper, det vill säga ställa upp dem i en hierarkisk ordning. Relationerna lagras i en tabell med enbart två kolumner i databasen. Grupperna är också lagrade i en tvåkolumners tabell. En grupp har inga andra egenskaper än dess namn och en relation definieras som en enkelriktad koppling mellan två grupper. Två grupper kan relateras till varandra via en tredje mellangrupp. Systemet stöder dock inte mera är tre nivåer. Även de PHP-funktioner som har utvecklats för att hantera grupprelationer klarar enbart av tre nivåer. Genom att utveckla de iterativa funktionerna till rekursiva funktioner skulle man klara av hur många nivåer som helst. Det finns en specialgrupp som inte kan raderas och det är grupp nummer ett, som i detta projekt kallas för Ekonomiadministration. Detta är rotgruppen som alltid skall sitta på topp i grupphierarkin och som alltid har gruppnummer ett. Medlemmarna i grupp nummer ett kommer att ha tillgång till mera funktioner än medlemmar i andra grupper. Till denna grupp skall höra samtliga användare som ansvarar för någon del inom ekonomiadministrationen, inga andra. Dessa användare kommer då att ha total kontroll över samtliga fakturor i systemet förutom arkivet som är lite speciellt. I Figur 38 visas ett exempel på hur grupperna samt deras relationer kan vara definierade och hur de då lagras i databasen. mysql> select * from Grupper; gruppid gruppnamn Ekonomiadministration 10 Grupp A Personal 19 Grupp B Personal 12 Grupp A Chef 13 Grupp B Chef rows in set (0.00 sec) mysql> select * from Gruppstatus; grupp ser rows in set (0.00 sec) Figur 38. Grupper och grupprelationer lagrade i databasen. Figur 39 visar gränssnittet för underhåll av grupper och Figur 40 visar gränssnittet för att skapa, ändra och radera relationer mellan grupper. 83

79 Figur 39. Gränssnitt för underhåll av grupper. Figur 40. Gränssnitt för underhåll av grupprelationer Underhåll av avdelningar En faktura skall förknippas med en betalande avdelning. De tillgängliga avdelningarna finns sparade i en två kolumners tabell i databasen. En avdelning har inga andra egenskaper än dess namn. Avdelningarna används enbart för att öronmärka en faktura med en viss avdelning. Eftersom avdelningar kan blir flera eller färre finns det ett gränssnitt för underhåll av avdelningsnamn. Gränssnittet visas i Figur

80 Figur 41. Gränssnitt för underhåll av avdelningar Hanteringslogistik I detta delkapitel presenteras cirkulationskonceptet i korthet. Utförligare beskrivning av applikationens funktionalitet finns i Peik Åströms examensarbete som beskriver detta projekt på applikationsnivå (Åström, 2003). Det finns fem grundläggande faser i en fakturas levnadscykel och fem definierade roller hos användarna i detta system. De olika faserna och de olika rollerna gås igenom i den ordning de utförs när en faktura cirkulerar inom organisationen. För att representera de olika faserna används en mängd olika databastabeller. Fakturorna flyttas mellan dessa tabeller med funktionen movefaktura() och en faktura cirkuleras till en mottagare via skriptet skicka_faktura.php. Samtliga filer som utför delar av cirkulationslogistiken finns samlade i katalogen /circ direkt i webbserverkatalogen. De olika faserna som systematiskt beskrivs kan åskådliggöras i Figur

81 Figur 42. Cirkulationsförloppet för fakturor i fakturahanteringssystemet (publicerad med tillstånd av Peik Åström) Inmatningsfasen Alla användare kan mata in en ny faktura för cirkulation via länken Ny faktura i menyn. Vid inmatningen kan även en eller flera filbilagor bifogas. Rollen benämns inmatare och en inmatare kan även föreslå bokföringskonto, kostnadsställe, projektkod och personnummer. När en ny faktura har matats in och sparats placeras den i inmatarens personliga fakturakö, varefter den befinner sig i cirkulationsfasen. En ny faktura matas in från gränssnittet ny_faktura.php och sparas i databasen av skriptet create_faktura.php Cirkulationsfasen Alla användare kan behandla fakturor som de är behöriga till under cirkulationsfasen. Behörig är en användare om fakturan befinner sig i användarens fakturakö eller om användaren är förman för den person i vars kö fakturan befinner sig. Medlemmar i ekonomiadministrationen är behöriga till samtliga fakturor inom organisationen. Cirkulationsfasen nås via länken Mina fakturor i menyn. I cirkulationsfasen kan fakturans uppgifter ändras (edit_faktura.php), filbilagor kan tillfogas eller tas bort och den bokföringstekniska informationen kan ändras och kompletteras med reskontra- 86

82 nummer och verifikatnummer. Därtill kan alla användare som mottar fakturan bidra med sitt delbeslut i form av en fritt formulerad kommentar och ett godkännande respektive förkastande. En faktura uppdateras i databasen av skriptet update_faktura.php. En förman har översikt och kontroll över fakturorna som rör sig inom den egna avdelningen genom länken Andra fakturor (overview_xxx.php), som enbart visas för förmän och ekonomiavdelningen. För kontrollering om användaren är en förman används funktionerna checkuserstatus() och checkuserstatuslevel(). Funktionen checkuserisrootlevel() upptäcker om användaren är gruppmedlem i ekonomiadministrationen. En del av funktionerna utnyttjar minnesbuffertar för att höja systemets prestanda. De roller som omfattas av cirkulationsfasen kallas för mottagare, sakgranskare och attesterare. Mottagare är alla som mottar en faktura av en annan användare. Mottagaren kan även vara sakgranskare eller till och med attesterare ifall mottagaren är befullmäktigad för att godkänna ifrågavarande faktura för betalning. Sakgranskaren är den som kontrollerar att fakturan är korrekt och att summor och varumängd är korrekt uppgivna. Attesteraren är den som slutligen placerar sin elektroniska signatur på fakturan och på så vis godkänner den för utbetalning. Ibland kan två attesterare behövas ifall den första attesteraren inte är befullmäktigad att godkänna fakturans slutsumma och då kallas den första attesteraren istället för sakgranskare och kan enbart ge sitt delbeslut vidare till den andra attesteraren. Attesterarna deltar även i cirkulationsfasen eftersom de kan cirkulera tillbaka en faktura för vidare komplettering ned i organisationen. En faktura kan även raderas när som helst under cirkulationsfasen, men den raderas inte slutligen utan placeras istället i en papperskorg som ekonomiadministrationen kontrollerar. Ekonomiadministrationen kan försätta fakturor åter i cirkulation från papperskorgen eller tömma hela papperskorgen. En faktura raderas ur cirkulationen och flyttas till papperskorgen av skriptet radera_faktura.php. 87

83 Signeringsfasen Den elektroniska signaturen skapas i signeringsfasen av en attesterare. Attesteraren är befullmäktigad att godkänna fakturor upp till en viss slutsumma. Attesteraren behöver tekniskt sett inte vara en förman men är oftast ändå det i praktiken. Attesteraren ansvarar för den bokföringstekniska informationen så att fakturan kan bokföras korrekt. Den elektroniska signaturen skapas via knappen Spara & Signera som finns i knappmenyn under fakturans slut. Ifall den användare som agerar attesterare inte har rätt att godkänna fakturan på grund av slutsummans storlek måste fakturan cirkuleras vidare till en attesterare med större beslutsrätt. Användaren förblir då enbart sakgranskare för fakturan ifråga och skall då bidra med sitt delgodkännande genom att bifoga en kommentar och ett beslut. Signeringsrätten för en given faktura testas med funktionen checksigningaccess(). Efter att fakturan signerats elektroniskt skickas den automatiskt vidare till ekonomiavdelningen för utbetalning och bokföring. Signaturen skapas med gränssnittet signera.php och den elektroniska signaturen sparas i databasen av skriptet spara_signatur.php. Den som har skapat signaturen kan även radera signaturen, ifall samma användare mottar fakturan på nytt. En signatur raderas ur databasen av skriptet radera_signatur.php Utbetalningsfasen En användare på ekonomiavdelningen agerar utbetalare och bokförare. Rollerna kan även vara uppdelade på flera personer, eftersom hela ekonomiavdelningen har full åtkomst till alla signerade fakturor. De signerade fakturorna nås via länken Signerade fakturor i menyn, som enbart är synlig för ekonomiadministrationen. Gränssnittet som visar den signerade fakturorna finns i filen signed_queue.php. Därifrån kan besluten granskas och signaturerna verifieras med hjälp av gränssnittet view_signatur.php. Fakturans uppgifter kan inte ändras så länge som den är signerad, den kan heller inte signeras på nytt. Endast den bokföringstekniska informationen kan ändras och nya del- 88

84 beslut kan tillfogas. Eventuella filbilagor kan kontrolleras normalt med gränssnittet view_bilaga.php. Om någon annan information, såsom fakturauppgifter eller filbilagor, behöver ändras måste fakturan först cirkuleras tillbaka till attesteraren så att denne kan ta bort sin signatur. Därefter kan fakturan fritt ändras igen enligt samma principer som tidigare. Bokföraren ansvarar för det slutgiltiga valet av bokföringskonto och utbetalaren ansvarar för att fakturan införs i reskontran och att reskontrapostens nummer och verifikatets nummer antecknas på fakturan. När fakturan är utbetald kan utbetalaren komplettera fakturan med utbetalningsdatum och kvittera den som betald, varefter den förflyttas till en karantänkö till arkivet. Detta utförs av skriptet betala.php Arkiveringsfasen Efter att en faktura har bokförts och utbetalats ligger den en kort tid i karantän under rubriken Betalda fakturor. Gränssnittet som visar de betalda fakturorna finns i filen betalda_queue.php. Karantänen nås endast av ekonomiadministrationen. Under denna tid är det ännu möjligt att annullera en faktura och radera den ur systemet, vilket behöver utföras ifall en bankbetalning skulle annulleras. Karantänen behövs eftersom arkivet, som är det slutgiltiga målet för samtliga fakturor, endast kan läsas och ingenting kan raderas ur det (i alla fall ingenting som fortfarande enligt bokföringslagen måste arkiveras). När det är säkert att en faktura inte mera behöver annulleras kan den förflyttas till arkivet av bokföraren genom att denne kvitterar fakturan för arkivering. Den sista fasen, arkiveringsfasen, finns programmerad fram tills dess när bokföraren skall kvittera fakturorna för arkivering. Därefter finns ingen funktionalitet som skulle flytta fakturan till arkivet. 89

85 Papperskorgen När en användare raderar en faktura raderas den inte totalt utan istället omplaceras den i papperskorgen. Papperskorgen kontrolleras av ekonomiadministrationen, som kan försätta bortslängda fakturor på nytt i cirkulation eller tömma hela papperskorgen. På grund av systemets flexibla uppbyggnad kan även de flesta funktioner som normalt kan utföras under cirkulationen utföras även när en faktura befinner sig i papperskorgen. Egentligen är papperskorgen helt enkelt en extra fas definierad som en del av cirkulationsförloppet. Om en person i ekonomiadministrationen väljer att återskapa en faktura utförs detta genom att fakturan cirkuleras från papperskorgen till användarens personliga fakturakö. Papperskorgen är uppbyggd kring tre gränssnitt: view_papperskorg.php som visar innehållet i papperskorgen, empty.php som tömmer hela papperskorgen och undo.php som kan återskapa en faktura ur papperskorgen. Filerna är placerade i en egen katalog /papperskorg direkt i webbserverkatalogen. Därtill länkar view_papperskorg.php samma funktioner som övriga fakturaköer stöder Filbilagor Inskannade fakturor och bilagor till dessa kan när som helst under cirkulationsfasen tillfogas en faktura. Ifall fakturan är signerad kan inga ändringar göras. Av planeringsmässiga skäl kan endast en filbilaga tillfogas varje gång fakturan sparas. Detta medför att om en faktura har många filbilagor måste dessa laddas upp en åt gången. Alternativet till detta är att webbformuläret redigeras så att flera filer kan väljas på en gång och att motsvarande ändringar utförs i den funktion som sparar de uppladdade filerna till databasen. En uppladdad filbilaga tillfogas en faktura med funktionen attachfiletofaktura(), som sparar filen i databasen och beräknar ett MD5-extrakt för filen. Filbilagorna kan bläddras i av alla användare som är behöriga till fakturan. Gränssnittet för detta finns i filen view_bilaga.php. Gränssnittet kontrollerar integriteten hos den hämtade filen genom att beräkna ett nytt MD5-extrakt och jämföra det med det extrakt 90

86 som beräknades vid uppladdningsögonblicket. Verifikationen utförs av funktionen verifyhash(). En bifogad filbilaga kan när som helst raderas av en användare som har åtkomst till den tillhörande fakturan förutom om fakturan är signerad. En filbilaga raderas med skriptet radera_bilaga.php Kommentarer Kommentarer, eller delbeslut som de också kan kallas, kan bifogas när som helst under en fakturas aktiva livscykel. Kommentarerna behövs för att attesteraren skall kunna ta del av sakgranskarens och eventuellt även inmatarens synkpunkt på fakturan. Ingenting hindrar att även attesteraren själv bifogar en fritt formulerad kommentar till fakturan när attesteraren godkänner fakturan genom att elektroniskt signera den. Även ekonomiavdelningen kan bifoga sina personliga kommentarer och synpunkter till fakturan i samband med att den utbetalas och bokförs. Först när fakturan är arkiverad är det för sent att tillfoga nya kommentarer. Eftersom kommentarerna endast är inofficiella delbeslut kan kommentarerna raderas när som helst enbart av den som har skrivit kommentaren. Kommentarerna kan alltså raderas även efter att fakturan har signerats, ifall den skulle hamna tillbaka hos kommenteraren själv vilket tekniskt sett är möjligt via cirkulationen. Signaturen är inget hinder för att en faktura kan cirkulera dess uppgifter kan dock inte ändras. En kommentar raderas med skriptet radera_kommentar.php Den personliga fakturakön De fakturor som visas när användaren väljer Mina fakturor filtreras fram från tabellen Fakturor i databasen. Alla fakturor i denna tabell är alltid öronmärkta för en viss mottagare. Funktionen getfakturalist() bygger upp en tabell som innehåller fakturanummer på samtliga fakturor som skall visas i användarens personliga fakturakö. Gränssnittet som visar den personliga fakturakön finns i filen queue.php. 91

87 Cirkulationen utförs genom att helt enkelt byta öronmärke på den faktura som skall skickas till mottagarens användar-id. Därefter dyker den upp i mottagarens fakturakö nästa gång den hämtas. Cirkulationen aktiveras från gränssnittet i filen cirkulera.php där mottagaren först väljes och därefter skickas fakturan slutligen av skriptet i filen skicka_faktura.php. En nyinmatad faktura placeras i inmatarens fakturakö genom att öronmärka den med inmatarens användar-id. Användarens interna användar-id kan hämtas från databasen med funktionen getuserid() och ett användar-id kan konverteras till ett användarnamn med funktionen getusername(). Bägge funktionerna utnyttjar minnesbuffertar för att höja systemets prestanda E-posthantering Systemet skickar påminnelsebrev per e-post via en lokalt installerad serverprocess sendmail. PHP kan även konfigureras så att mail()-funktionen kan kontakta en SMTPserver på en annan dator än den lokala datorn. I detta projekt valdes dock att installera en e-postserver lokalt på webbservern för att få en bättre överblick av e-postköerna under utveckling och programmering. All e-post skickas som renodlad text (contenttype: text/plain). Automatiska påminnelser Funktionsprincipen för de automatiska utskicken av påminnelsebrev per e-post beskrivs redan i kapitel Här beskrivs den tekniska uppbyggnaden av funktionen. När en automatisk påminnelse skickats lagras en post för den påminnelsen i tabellen Paminnelser. De värden som lagras för varje post är fakturanummer, datum och användare. Innan en påminnelse skickas utförs en kontroll mot denna tabell att inte samma användare redan har mottagit en påminnelse för samma faktura samma dag. När en användare cirkulerar en faktura vidare raderas en eventuell påminnelsepost, vilket möjliggör ytterligare påminnelser för samma faktura samma dag ifall samma användare mottar samma faktura på nytt samma dag. 92

88 Utskickningen av de automatiska påminnelsebreven triggas när någon loggar in till fakturasystemet. Själva processen inleds med att påminnelsetabellen putsas från gamla påminnelseposter. En påminnelsepost är gammal när den inte är inskriven i påminnelsetabellen samma dag. Efter putsningen eftersöks de fakturor som ligger inom riskzonen, som är definierad inom fyra dagar till förfallodatum. Påminnelsebrev skickas till de användare som har någon av dessa fakturor i sin personliga fakturakö. Ifall användaren inte givit sitt samtycke till mottagning av automatiska påminnelser skickas givetvis ingen påminnelse. Hela denna process utförs av funktionen dopaminnelser() som ingår i funktionsbiblioteket paminn.inc. Den text som skickas ut hämtas från textfilen paminn_autotext.txt som finns i katalogen /config på webbserverutrymmet. Därtill tillfogas information om vilken faktura det är frågan om och när den förfaller till betalning. Avsändaren och övrig information som ingår i brevets huvud kan editeras i funktionen skickapaminnelse(). Figur 43 visar vad tabellen Paminnelser innehåller efter att dopaminnelser() har utförts och tre påminnelsebrev har skickats. mysql> select * from Paminnelser; fakturaid datum person :15: :01: :01: rows in set (0.00 sec) Figur 43. Innehållet i tabellen Paminnelser i databasen. Manuella påminnelser En förman eller en medlem av ekonomiavdelningen kan när som helst skicka ut manuella påminnelser till användare som inte har uppmärksammat en brådskande faktura. Gränssnittet för detta nås från länken Andra fakturor, där varje faktura har en egen knapp Påminn. Avsändaren har en möjlighet att ändra den föreslagna automatiska texten eller formulera sig helt fritt till mottagaren. Det finns ingen begränsning 93

89 på hur många manuella påminnelsebrev som kan skickas för samma faktura under en dag. Figur 44 visar gränssnittet för formulering och utskickning av ett manuellt påminnelsebrev. Figur 44. Gränssnitt för utskickning och editering av manuella påminnelsebrev Loggning Vid systemutveckling är loggar ovärderliga. I loggfiler kan man samla all information om vad som händer i systemet. Vid felsökningen är loggarna till oerhört stor hjälp för att snabbt kunna spåra felet. Desto mera information man loggar desto enklare och snabbare kan man finna problemet. I detta projekt loggas databasoperationer, minnesbuffertar, filhantering och autentisering via serverns systemlogg. Loggningen är inbyggd i till exempel databashanteringsbiblioteket och kan stängas av genom att kommentera ut de syslog-anrop som utförs. I Figur 45 visas ett exempel på hur loggningen kan se ut när en användare loggar in i systemet och går till sin personliga fakturakö. 94

90 Jun 5 13:59:36 bruno httpd: KARLSTRÖM KRISTER logged on Jun 5 13:59:36 bruno httpd: 1 -> select anvandarid from Anvandare where anvandarnamn = "KARLSTRÖM KRISTER "; Jun 5 13:59:36 bruno httpd: 2 -> update Anvandare set inloggad = NOW() where anvandarnamn = "KARLSTRÖM KRISTER "; Jun 5 13:59:36 bruno httpd: 3 -> select fakturaid, rubrik, mottagare, forfallodag from Fakturor where DATE_ADD(CURRENT_DATE, INTERVAL 4 DAY) >= forfallodag; Jun 5 13:59:36 bruno httpd: 4 -> select DATE_SUB( NOW(), INTERVAL 1 DAY) as olddate; Jun 5 13:59:36 bruno httpd: 5 -> delete from Paminnelser where datum < " :59:36"; Jun 5 13:59:36 bruno httpd: 6 -> select fakturaid, person from Paminnelser where fakturaid = 10 and person = 2; Jun 5 13:59:36 bruno httpd: 7 -> select fakturaid, person from Paminnelser where fakturaid = 20 and person = 2; Jun 5 13:59:36 bruno httpd: 8 -> select fakturaid, person from Paminnelser where fakturaid = 21 and person = 1; Jun 5 13:59:36 bruno httpd: 9 -> select fakturaid, person from Paminnelser where fakturaid = 22 and person = 1; Jun 5 13:59:36 bruno httpd: 10 -> select epost from Anvandare where anvandarid = 1; Jun 5 13:59:36 bruno httpd: 11 -> insert into Paminnelser (fakturaid, datum, person) values (22, NOW(), 1); Jun 5 13:59:36 bruno httpd: 1 -> select Grupper.gruppnamn as grupp from Grupper left join Anvandare on Anvandare.grupp = Grupper.gruppid where Anvandare.anvandarnamn = "KARLSTRÖM KRISTER "; Jun 5 13:59:36 bruno httpd: Cache miss on getuserid() Jun 5 13:59:36 bruno httpd: 1 -> select anvandarid from Anvandare where anvandarnamn = "KARLSTRÖM KRISTER "; Jun 5 13:59:36 bruno httpd: 2 -> select fakturaid from Fakturor where mottagare = 1 order by forfallodag; Jun 5 13:59:36 bruno httpd: 3 -> select rubrik, avsandare, forfallodag, signatur from Fakturor where fakturaid = 22; Jun 5 13:59:36 bruno httpd: 4 -> select rubrik, avsandare, forfallodag, signatur from Fakturor where fakturaid = 21; Jun 5 13:59:38 bruno httpd: Cache miss on checkuserstatus() Jun 5 13:59:38 bruno httpd: 1 -> select anvandarid, grupp from Anvandare where anvandarnamn = "KARLSTRÖM KRISTER "; Jun 5 13:59:38 bruno httpd: 2 -> select ser from Gruppstatus where grupp = 1; Jun 5 13:59:38 bruno httpd: Cache miss on checkuserisrootlevel() Jun 5 13:59:38 bruno httpd: 3 -> select anvandarid, grupp from Anvandare where anvandarnamn = "KARLSTRÖM KRISTER "; Jun 5 13:59:38 bruno httpd: 4 -> select count(fakturaid) as antal from Papperskorg; Figur 45. Loggdata i systemloggen vid inloggning. 95

91 5 INSTALLATION OCH KONFIGURATION 5.1 Installation För att installera och sätta upp det presenterade fakturahanteringssystemet behövs följande komponenter för servern: En Linuxdator (gärna med Slackware) Webbservern Apache med tilläggsmodulen mod_ssl Programvarupaketet OpenSSL PHP (Version 4.3.x) med tilläggsmodulen Mhash Databashanteraren MySQL (Version 4) E-postservern Sendmail (alternativt konfigureras en SMTP server för PHP) Befolkningsregistercentralens CA-certifikat för privatpersoner samt en färsk certifikatspärrlista Ett servercertifikat för webbservern Dessutom behövs följande komponenter för klienterna: PC-datorer med Windows 2000 eller Windows XP Internet Explorer (Version 6 eller nyare) SmartTrust Personal inklusive ActiveX-komponenten WebSigner för Internet Explorer Smartkortsläsare Elektroniskt identitetskort för samtliga användare (FINEID-kort) Installationen för samtliga komponenter, både hos servern och hos klienterna, är standardinstallationer förutom PHP som har kompilerats med några extra direktiv. Kompileringsdirektiven för PHP visas i Figur 47. På serversidan duger det bra med de installationspaket som följer med till exempel Slackware-distributionen. Om paketens källkod laddas ned skilt för sig duger det bra med standardkompileringen configure, make och make install. 96

92 På klientsidan räcker det med att en smartkortsläsare och smartkortshanteringsprogramvara installeras, vilket torde vara tämligen enkelt i Windows 2000 eller Windows XP. För de flesta modeller av kortläsare behövs ingen extra drivrutin, utan Windows har oftast en inbyggd drivrutin som fungerar. Smartkortstjänsten i Windows brukar aktiveras automatiskt efter att en smartkortsläsare har installerats. Därefter kan programvaran för hantering av smartkort installeras som i detta projekt är bundet till SmartTrust Personal. Installationen är en standard installation. På serversidan skall de installerade komponenterna konfigureras. En hel del hjälp fås från respektive komponents webbsida på Internet och enbart konfiguration som är specifik för detta projekt presenteras i kapitel 5.2. Det lönar sig speciellt att bekanta sig med installationsmanualerna för Apache och MySQL. Speciellt knepigt kan det vara att få SSL-servern att fungera i Apache, men efter att servercertifikaten installerats och hashlänkar i certifikatkatalogen har skapats skall nog även den fungera. Vid installationen av MySQL skall man komma ihåg att ge användaren mysql fullständiga rättigheter till katalogen data. Enklast utförs detta genom att helt byta ägare och grupp på katalogen data, samt underliggande filer, till mysql och därefter tilldela katalogen och de underliggande filerna åtkomstmasken till Konfiguration Konfiguration av webbservern Apache Apache-serverns konfiguration är till stor del den föreslagna konfigurationsfilen som distribueras med Apache. Några få ändringar och tillägg har gjorts och ett kort utdrag ur konfigurationsfilen där ändringarna ingår presenteras i Figur 46. Det är värt att notera att testservern som användes för projektet körde två webbtjänster, en oskyddad på port 80 och en SSL-skyddad på port 443. Flera webbtjänster kan köras samtidigt på en enda Apache-server med hjälp av <VIRTUAL>-direktivet. Dessa Virtual-direktiv definieras i konfigurationsfilen för mod_ssl. 97

93 Port 80 User nobody Group nobody ServerAdmin ServerName bruno.arcada.fi DocumentRoot "/var/www/https" <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory "/var/www/htdocs"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order deny,allow Allow from all </Directory> <IfModule mod_userdir.c> UserDir public_html </IfModule> <IfModule mod_dir.c> DirectoryIndex index.html index.php </IfModule> <Files ~ "\.inc"> Order allow,deny Deny from all </Files> NameVirtualHost * Include /etc/apache/mod_php.conf Include /etc/apache/mod_ssl.conf Figur 46. Utdrag ur httpd.conf (Apache-konfigurationsfil). Kompilering av PHP med externa moduler För att beräkna MD5-extrakt har en extern modul till PHP kompilerats och installerats. Modulen som använts heter Mhash och den använda versionen är Källkoden kan laddas ned från och kompileras med förhandsinställda inställningar (Mhash, 2004). På testservern har även libiconv inkompilerats i PHP-modulen, främst på grund av testbehov under utvecklingen, men den borde inte behövas i den slutgiltiga versionen. 98

94 Moduler som kompilerats och installerats på systemet måste också inkluderas i PHPmodulen som laddas av Apache-servern. I Figur 47 visas det skript och de parametrar som gavs till configure för att bygga den nya PHP-modulen för PHP #!/bin/sh EXTENSION_DIR=/usr/lib/php/extensions \ CFLAGS="-O2 -march=i386 -mcpu=i686" \./configure --prefix=/usr \ --with-apxs=/usr/sbin/apxs \ --enable-discard-path \ --with-config-file-path=/etc/apache \ --enable-safe-mode \ --with-openssl \ --enable-bcmath \ --with-bz2 \ --with-pic \ --with-mhash=/usr/local/lib \ --with-iconv=/usr/local/lib \ --enable-calendar \ --enable-ctype \ --with-gdbm \ --with-db3 \ --enable-dbase \ --enable-ftp \ --with-gd \ --enable-gd-native-ttf \ --with-jpeg-dir=/usr \ --with-png \ --with-gmp \ --with-mysql \ --with-xml=shared,/usr \ --with-gettext=shared,/usr \ --with-mm=/usr \ --enable-trans-sid \ --enable-shmop \ --enable-sockets \ --with-regex=php \ --enable-sysvsem \ --enable-sysvshm \ --enable-yp \ --enable-memory-limit \ --with-tsrm-pthreads \ --enable-shared \ --disable-debug \ --with-zlib=/usr Figur 47. Bash-skript för kompilering av PHP och externa moduler. 99

95 Konfiguration av PHP Det är inte mycket som har ändrats i den grundkonfiguration som följer med PHP. Ett par inställningar ändrades för att underlätta utvecklingsarbetet. Figur 48 sammanfattar de inställningar som har givits ett annat värde än standardinställningen. Dessutom visar figuren en del av standardinställningarna för MySQL och sessionshanteringen. max_execution_time = 30 max_input_time = 60 memory_limit = 8M error_reporting = E_ALL display_errors = on display_startup_errors = Off log_errors = On register_globals = on post_max_size = 8M include_path = ".:/php/includes:/usr/lib/php" doc_root = /var/www/https extension_dir = /usr/lib/php/extensions/ enable_dl = On file_uploads = On upload_tmp_dir = /tmp upload_max_filesize = 3M mysql.allow_persistent = On mysql.max_persistent = -1 mysql.max_links = -1 session.save_handler = files session.save_path = /tmp session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 1 session.cookie_lifetime = 0 session.cookie_path = / session.serialize_handler = php session.gc_maxlifetime = 1440 session.use_trans_sid = 0 Figur 48. Utdrag ur php.ini (konfigurationsfil för PHP 4.3.2). 100

96 Konfiguration av mod_ssl för SSL och PKI-autentisering På testservern kördes två separata webbsajter. Den ena var en vanlig renodlad HTTPserver (dock med stöd för PHP) medan den andra kör SSL för kommunikation via HTTPS. Dessa två webbsajter konfigurerades som två virtuella domäner, betjänade av samma webbserver. I Figur 49 visas ett utdrag ur filen mod_ssl.conf där de virtuella webbsajterna definieras och SSL-skyddet aktiveras. LoadModule ssl_module libexec/libssl.so AddModule mod_ssl.c <IfDefine SSL> Listen 80 Listen 443 </IfDefine> <IfDefine SSL> AddType application/x-x509-ca-cert.crt AddType application/x-pkcs7-crl.crl </IfDefine> <IfModule mod_ssl.c> SSLPassPhraseDialog builtin SSLSessionCache dbm:/var/log/apache/ssl_scache SSLSessionCacheTimeout 300 SSLMutex file:/var/log/apache/ssl_mutex SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLLog /var/log/apache/ssl_engine_log SSLLogLevel info </IfModule> <IfDefine SSL> <VirtualHost _default_:80> DocumentRoot "/var/www/http" ServerName bruno.arcada.fi ServerAdmin [email protected] ErrorLog /var/log/apache/error_log TransferLog /var/log/apache/access_log SSLEngine off <Files ~ "\.(cgi shtml html htm php phtml php3?)$"> SSLOptions +StdEnvVars </Files> </VirtualHost> <VirtualHost _default_:443> DocumentRoot "/var/www/https" ServerName bruno.arcada.fi ServerAdmin [email protected] ErrorLog /var/log/apache/error_log TransferLog /var/log/apache/access_log SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/apache/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache/ssl.key/server.key SSLCertificateChainFile /etc/apache/ssl.crt/ca.crt SSLCACertificatePath /etc/apache/ssl.crt/ SSLCARevocationPath /etc/apache/ssl.crl <Files ~ "\.(cgi shtml html htm php phtml php3?)$"> SSLOptions +StdEnvVars +ExportCertData </Files> Figur 49A. Utdrag ur mod_ssl.conf. 101

97 <Location /> SSLVerifyClient require SSLVerifyDepth 5 SSLOptions -FakeBasicAuth SSLRequire ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= / and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= u/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= j/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= l/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= n/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= s/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= n/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= d/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= u/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= w/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) </Location> <Location /fakturabehandling/admin> SSLVerifyClient require SSLVerifyDepth 8 SSLOptions -FakeBasicAuth SSLRequire ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= / and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) \ or ( %{SSL_CLIENT_S_DN} =~ m/c=fi.*= u/ and %{SSL_CLIENT_I_DN} eq "/C=FI/O=VRK-FINSIGN Gov. CA/CN=FINSIGN CA for Citizen" ) </Location> <Directory "/var/www/cgi-bin"> SSLOptions +StdEnvVars </Directory> CustomLog /var/log/apache/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x %{SSL_CLIENT_S_DN}x %{SSL_CLIENT_VERIFY}x %{SSL_CLIENT_I_DN}x \"%r\" %b" </VirtualHost> </IfDefine> Figur 49B. Utdrag ur mod_ssl.conf fortsättning. För att certifikatet på smartkortet skall kunna användas så måste webbläddraren vara korrekt konfigurerad för SmartTrust Personal. Vid installationen av autentikatorklienten sköts detta automatiskt för åtminstone Internet Explorer. I övriga webbläddrare kan man vara tvungen att manuellt konfigurera in PCKS#11-modulen. Eftersom detta projekt ändå enbart fungerar med Internet Explorer behöver denna procedur inte beskrivas här. Konfigurering av webbsajten Det finns på ett par ställen sökstigar som måste manuellt ställas in till korrekta värden ifall webbsajten flyttas till en annan server eller om exempelvis webbserverkatalogen flyttas. I filen files.inc måste den kompletta sökstigen till katalogen /tmp i webbserverns katalog anges och motsvarande URL. Inställningarna visas i Figur

98 $imgroot = "/var/www/https/fakturabehandling/tmp/"; $urlroot = " Figur 50. Inställningar i files.inc. Dessutom skall kontaktinformation till databasservern anges i filen /config/config.inc, som är lokaliserad i webbserverns katalog men som inte kan laddas via HTTP eftersom det finns en regel i httpd.conf som förhindrar åtkomst till filer med extensionen.inc. Även sökstigar till XML-mallarna ingår som hårdkodade variabler i ett flertal gränssnitt. Om webbserverkatalogen flyttas måste sökstigarna uppdateras. Även dessa inställningar följer samma mönster som inställningarna i Figur 50. Inställningarna finns i filerna update_faktura.php och create_faktura.php. Javascriptet i filen signera.php har också en manuell inställning som anger vart den skapade signaturen skall postas. I övrigt används relativa sökstigar. Uppdatering av spärrlista Befolkningsregistercentralen publicerar spärrlistor via sin katalogtjänst på Internet. Fyra olika spärrlistor publiceras. För detta projekt skall spärrlistan för FINSIGN CA for Citizen laddas ner. Spärrlistorna kan laddas ner via HTTP eller sökas via LDAP. Vill man hämta spärrlistan via HTTP kan man göra det från och länkarna Ladattavat tiedostot VRK:n varmennehakupalvelu Hae sulkulista. Spärrlistan kan också hämtas via direktlänken som visas i Figur 51. Sidan är ett ASPskript och kan leverera certifikat och spärrlistor enligt de givna parametrarna. &issuercn=finsign%20ca%20for%20citizen Figur 51. Direktlänk för hämtning av spärrlista via HTTP. För att automatiskt uppdatera webbserverns spärrlista lämpar sig LDAP-metoden bättre. Katalogtjänsten finns på servern ldap.fineid.fi. Eftersom uppdateringen består av ett 103

99 flertal funktioner uppdateras spärrlistan enklast via ett shell-skript. Shell-skriptet kan sedan konfigureras att köras regelbundet som ett cron-jobb. Ett exempel på ett sådant shell-skript visas i Hästbacka, 2002, s För att kunna uppdatera spärrlistan via LDAP måste först OpenLDAP installeras (OpenLDAP, 2004). Därefter kan spärrlistan hämtas med ldapsearch och konverteras från DER-kodning till PEM-kodning med OpenSSL. För att inte konverteringen skall beakta gamla spärrlistor skall de raderas först. Till sist måste Apache-webbservern startas om för att den nya spärrlistan skall tas i bruk. Operationerna, som gärna kan göras till ett shell-skript, visas i Figur 52 (Hästbacka, 2002). Ifall spärrlistan är för gammal kan det hända, beroende på webbserverkonfigurationen, att inga certifikat alls accepteras eftersom det inte går entydigt att försäkra att det använda certifikatet inte finns på spärrlistan. rm f ldapsearch-certificaterevocationlist* ldapsearch T /etc/apache/ssl.crl t h ldap.fineid.fi x b cn=finsign ca for citizen,o=vrk-finsign gov. ca,dmdname=fineid,c=fi certificaterevocationlist openssl crl -inform DER -outform PEM -in ldapsearch-certificaterevocationlist* -out stoppade.crl apachectl restart Figur 52. Uppdatering av spärrlista via LDAP-sökning med OpenLDAP. Konfiguration av sendmail Sendmail har byggts med konfigurationsfilen generic-linux.mc och inga specialinställningar har använts. Installationen har utförts enligt de instruktioner som medföljer sendmail. Versionen som användes var version (Sendmail, 2004). Sendmail behöver inte installeras och köras lokalt på servern om PHP-modulen istället konfigureras för att använda en extern SMTP-server. 104

100 Konfiguration av databashanteraren MySQL Som utgångsläge har exempelkonfigurationen medium använts, som följer med MySQL-paketet. En del inställningar har justerats, bl.a. buffertstorlekar för att kunna ta emot större filer. I Figur 53 sammanfattas de inställningar som påverkar buffertar och paketstorlekar. [mysqld] set-variable set-variable set-variable set-variable set-variable = max_allowed_packet=4m = table_cache=64 = sort_buffer=512k = net_buffer_length=8k = myisam_sort_buffer_size=8m Figur 53. Utdrag ur my.cnf (konfigurationsfil för MySQL). Konfiguration av användare i MySQL MySQL har tre huvudsakliga tabeller för att konfigurera vilka användare får ta kontakt (user), vilka databaser kan en användare använda (db) och varifrån kan användare ta kontakt (host). Därtill finns två tabeller för konfigurering av åtkomst på tabellnivå (tables_priv) och kolumnnivå (columns_priv). Ifall databasen finns på samma server som webbservern räcker det ifall localhost kan ta kontakt, annars måste webbservern ges rättigheter att ta kontakt till databashanteraren. Webbservern måste ta kontakt som en namngiven användare med ett giltigt lösenord och det rekommenderas att en skild användare för fakturasystemet skapas och att den användaren enbart får ta kontakt till fakturasystemets databaser. Dessutom är det bra ifall webbserveranvändaren endast tillåts ta kontakt från webbserverns IP-adress. Efter att man ändrat på åtkomstinformationen i databasen mysql (masterdatabasen som innehåller all information om användarna och de andra databaserna) skall man komma ihåg att ta i bruk de nya inställningarna genom att köra SQL-kommandot flush privileges. 105

101 Uppsättning av databasen Databasen har skapats med ett SQL-skript. Det kompletta skriptet ser ut enligt följande: CREATE TABLE Certifikat (certifikatid INT AUTO_INCREMENT PRIMARY KEY, certnamn VARCHAR(100) NULL, data TEXT NOT NULL); CREATE TABLE Counter (cnt INT NOT NULL); CREATE TABLE Fakturor (fakturaid INT PRIMARY KEY, data TEXT NOT NULL, signatur TEXT NULL, tidsstampel TEXT NULL, agare INT NOT NULL, mottagare INT NOT NULL, avsandare INT NOT NULL, inskrivningsdatum DATETIME NOT NULL, forfallodag DATE NULL, betalningsdatum DATE NULL, tillaggsdata TEXT NULL, rubrik VARCHAR(100)); CREATE TABLE Signerade (fakturaid INT PRIMARY KEY, data TEXT NOT NULL, signatur TEXT NULL, tidsstampel TEXT NULL, agare INT NOT NULL, mottagare INT NOT NULL, avsandare INT NOT NULL, inskrivningsdatum DATETIME NOT NULL, forfallodag DATE NULL, betalningsdatum DATE NULL, tillaggsdata TEXT NULL, rubrik VARCHAR(100)); CREATE TABLE Betalda (fakturaid INT PRIMARY KEY, data TEXT NOT NULL, signatur TEXT NULL, tidsstampel TEXT NULL, agare INT NOT NULL, mottagare INT NOT NULL, avsandare INT NOT NULL, inskrivningsdatum DATETIME NOT NULL, forfallodag DATE NULL, betalningsdatum DATE NULL, tillaggsdata TEXT NULL, rubrik VARCHAR(100)); CREATE TABLE Papperskorg (fakturaid INT PRIMARY KEY, data TEXT NOT NULL, signatur TEXT NULL, tidsstampel TEXT NULL, agare INT NOT NULL, mottagare INT NOT NULL, avsandare INT NOT NULL, inskrivningsdatum DATETIME NOT NULL, forfallodag DATE NULL, betalningsdatum DATE NULL, tillaggsdata TEXT NULL, rubrik VARCHAR(100)); 106

102 CREATE TABLE Arkiv (fakturaid INT PRIMARY KEY, data TEXT NOT NULL, signatur TEXT NOT NULL, tidsstampel TEXT NOT NULL, inskrivningsdatum DATETIME NOT NULL, arkiveringsdatum DATETIME NOT NULL, forfallodag DATE NOT NULL, betalningsdatum DATE NULL, tillaggsdata TEXT NULL, rubrik VARCHAR(100)); CREATE TABLE Grupper (gruppid INT AUTO_INCREMENT PRIMARY KEY, gruppnamn VARCHAR(100) NOT NULL); CREATE TABLE Anvandare (anvandarid INT AUTO_INCREMENT PRIMARY KEY, anvandarnamn VARCHAR(100) NOT NULL, epost VARCHAR(100) NULL, grupp INT NULL, inloggad DATETIME NULL, sigbelopp INT NULL DEFAULT 0); CREATE TABLE Gruppstatus (grupp INT NOT NULL, ser INT NOT NULL); CREATE TABLE Filer (filid INT AUTO_INCREMENT PRIMARY KEY, filnamn VARCHAR(100) NOT NULL, filstorlek INT NULL, bifogad DATETIME NULL, faktura INT NOT NULL, md5hash VARCHAR(48) NULL, fil MEDIUMBLOB NOT NULL); CREATE TABLE Avdelningar (avdid INT AUTO_INCREMENT PRIMARY KEY, avdnamn VARCHAR(100) NOT NULL); CREATE TABLE Kommentarer (komid INT AUTO_INCREMENT PRIMARY KEY, faktura INT NOT NULL, anvandare VARCHAR(100) NOT NULL, beslut BOOL NULL, datum DATETIME NOT NULL, data TEXT NULL); CREATE TABLE Karta (fakturaid INT NOT NULL PRIMARY KEY, tabell VARCHAR(24) NOT NULL); CREATE TABLE Paminnelser (fakturaid INT NOT NULL, datum DATETIME NOT NULL, person INT NOT NULL); 107

103 6 TESTNING Som mest deltog 7-10 personer som testanvändare vid testningen som utfördes under ett par veckor. Någon omfattande testning utfördes inte, men gränssnittens användarvänlighet utvärderades och funktionaliteten verifierades mot projektplanen. Ett flertal ändringar i gränssnittet utfördes på användarnas begäran. Att lägga till nya användare fungerade enligt specifikationen. Det räckte med att användarens elektroniska kommunikationskod sattes med som ett godtagbart villkor i mod_ssl-modulens konfigurationsfil. Därefter fick användaren åtkomst till systemet och infogades i fakturasystemets användardatabas helt automatiskt. De behövliga elektroniska kommunikationskoderna söktes fram via Befolkningsregistercentralens katalogtjänst på Internet (Väestörekisterikeskus, 2004). Däremot var den stränga syntaxen på konfigurationsfilen besvärlig när man måste editera ett långt villkor som består av flera OR-satser och texten bryts upp över flera rader. Ett bättre gränssnitt för konfigurering av användare på systemnivå är önskbart, men kan vara svårt att uppfylla när det är frågan om en systemkonfigurationsfil med begränsad åtkomst i rent textformat. Inga riktiga fakturor skannades. Således kunde inte olika upplösningar testas fram för att hitta den optimala upplösningen för minimal filstorlek. Lämplig upplösning torde ändå vara ca dpi och då borde filstorleken hållas inom rimliga gränser. När uppladdning av stora filbilagor testades uppdagades de stramt förhandsinställda storlekarna på olika buffertar i MySQL. Begränsningen orsakade att fakturan inte sparades eftersom datapaketet till MySQL-servern blev för stort. Buffertstorleken höjdes och därefter kunde samma faktura med samma filbilaga sparas. De inställningar som presenteras i denna rapport är de nya förhöjda inställningarna. Cirkulation, editering, kommentering och signering fungerade felfritt och inga fel uppdagades heller vid verifiering av signaturer och bläddring bland filbilagor. Filbilagor som publicerats ur databasen på webbserverutrymmet på hårddisken raderas automatiskt enligt planerna. Den automatiska utskickningen av påminnelsebrev per e-post fungerade också och all typ av åtkomstbegränsning utfördes enligt planerna. Inga större fel upp- 108

104 täcktes, endast små skrivfel, till exempel variabelnamn orsakade problem. Småfelen korrigerades snabbt och därefter fungerade allt som det skulle. Ett programfel på högre nivå som beror på kombinationen Internet Explorer och mod_ssl upptäcktes utan att någon lösning hittades. Ibland hände det (speciellt när en faktura sparades genom att den postades till webbservern) att SSL-kontakten förlorades och webbläddraren visade istället ett felmeddelande som berättade att webbservern inte kunde nås. När man försökte på nytt lyckades det oftast. Efter en analys av mod_sslmodulens loggfiler visade det sig att felet ligger i handskakningen i SSL/TLSprotokollet. En snabb sökning på Internet visade att problemet är allmänt förekommande och någon lösning på problemet kunde inte hittas. Felet inträffar relativt sällan och fakturasystemet kan nog användas trots att felet uppstår ibland. För att testa pålitligheten hos olika skapade integritetskontroller manipulerades data i databasen manuellt. Testet visade att de kontroller som utförs fungerar och kan upptäcka alla manipulerade data. Integritetskontrollen för uppladdade filbilagor upptäckte fel i filstorleken och fel i bitmönstret. Verifieringen av en signatur misslyckades efter att fakturans data manipulerats samt efter att själva signaturen manipulerats. Utskickningen av automatiska påminnelsebrev per e-post förhindrades genom att stoppa sendmail-processen, men när den startades på nytt levererades de brev som skapats under tiden kön för utgående brev fungerade. Uppdatering av certifikatspärrlistan för Apache-servern var inte automatiserad och uppdateringen måste således skötas manuellt. När spärrlistan blev föråldrad vägrade fakturasystemet att släppa in någon användare över huvudtaget. I mod_ssl-modulens loggfil (ssl_engine_log) kom följande felmeddelande: Found CRL is expired revoking all certificates until you get updated CRL. Webbservern godtog alltså inga certifikat alls när spärrlistan inte var tillräckligt färsk. Efter uppdatering av spärrlistan fungerade systemet igen. När man anmäler sin e-postadress via Inställningar -menyn för att kunna ta emot påminnelsebrev per e-post utförs en kontroll som upptäcker ifall inmatad adress inte är en riktig e-postadress. Detta leder till att ifall man vill ta bort sin e-postadress kan man inte 109

105 göra det genom att tömma fältet och spara, eftersom då ingriper kontrollen och blockerar adressuppdateringen. För bortplockning av e-postadressen måste en skild funktion programmeras eller kontrollfunktionen måste omprogrammeras så att den tilllåter blanka teckensträngar. De minnesbuffertar för databasförfrågningar som inprogrammerats fungerade felfritt och systemloggen visar varje gång en buffertträff eller buffertmiss uppstår. Under testningen framgick också att den resulterande storleken på alla buffertar är liten och väl hanterbar. Flera försök att kringgå åtkomstkontrollen via URL-manipulation utfördes också, men eftersom alla gränssnitt validerar mottagna data och utför åtkomstkontroller själva så misslyckades försöken. Testet visade att åtkomstkontrollen fungerade och var tillräcklig för att begränsa åtkomsten till information i systemet. Samtidig användning med tre användare testades. Inga konflikter och bekymmer uppstod i systemet. Den använda datamängden var dock relativt liten. Hur många samtidiga användare systemet klarar av är främst beroende på hårdvaran och storleken på de inskannade fakturorna som skall hanteras. 110

106 7 UTVECKLINGSPERSPEKTIV Detta projekt var ett första försök att ta fram en portal för hantering av certifierad digital information. Under projektets gång noterades flera saker som kunde göras bättre. 7.1 Databasplanering Databasen kunde i sin helhet revideras och optimeras så att den är bättre anpassad till MySQL:s filosofier. Begränsningar och referensintegritet borde införas. Om datamängden blir stor och belastningen hög skulle nog systemet också dra nytta av ett index i databasen. Index har i detta skede inte alls över huvudtaget beaktats och för- och nackdelarna med dessa måste utvärderas innan de skapas. InnoDB-tabeller För att kunna utnyttja transaktioner borde systemet byggas om till att använda InnoDBtabeller. Transaktionerna låser inte data på lika hög nivå som vanliga LOCK-funktioner som med MyISAM-tabeller låser en hel tabell. Om systemet får en relativt hög belastning kommer LOCK-funktionerna att kännas av märkbart som längre väntetid för användarna. Filbihang Databaser är från början inte egentligen anpassade för att lagra stora filer. Alla moderna databashanterare stöder dock idag lagring av stora filer. Operationerna är dock både tidskrävande och utrymmeskrävande. I det uppbyggda fakturahanteringssystemet uppstår dessutom onödigt mycket hantering av de i databasen lagrade filerna när webbbläddraren skall hämta filerna. För att filen skall kunna hämtas över HTTPS krävs först att den sparas i webbserverutrymmet. Därefter kan den hämtas med ett vanligt HTTPkommando. Av säkerhetsskäl raderas filen från webbserverutrymmet när användaren är färdig med fakturans hantering. När nästa användare som mottar fakturan vill se på filbilagan upprepas samma procedur igen. Denna onödiga överbelastning kunde undvikas på två olika sätt: 111

107 Filerna lagras i organiserade katalogträd istället för i själva databasen. I databasen skulle då enbart länkar till filerna lagras. Av säkerhetsskäl vill man inte att katalogträdet hela tiden skulle vara tillgängligt via webbservern och därför måste katalogträdet med filbilagorna sparas på ett annat ställe på serverns hårddisk. När en användare behöver nå en filbilaga skulle sökstigen till filbilagan hämtas ur databasen och därefter skulle en symbolisk länk till den önskade filbilagan placeras på webbserverns skivutrymme. Via den symboliska och mjuka länken kan användaren då nå en filbilaga direkt över filsystemet utan att behöva hämta filen ur databasen. Detta skulle även utföras snabbare än att hämta hela filen ur databasen. I PHP är det möjligt att med hjälp av strömmar skicka data direkt från databasen till webbläddraren. Webbläddraren kan alltså motta en dataström och visa den som ett bildobjekt. Detta vore prestandamässigt en bra lösning eftersom detta inte medför någon extra hårddiskaktivitet med temporära filer, men filbilagorna lagras fortfarande i själva databasen. Ur säkerhetssynvinkel är detta en perfekt lösning eftersom filbilagorna hämtas rakt ur databasen direkt till webbläddraren. I detta projekt används dock ännu den traditionella metoden med temporära filer. 7.2 Moduler Programkoden kan göras mera överskådlig och strukturerad genom att ytterligare strukturera källkoden till mera funktioner indelade i flera biblioteksfiler. Exempelvis kunde ett bibliotek med funktioner för läs- och skrivoperationer för fakturahanteringen sammanställas. Funktioner som utför autentisering och auktorisering kunde effektiveras genom att sammanslås till ett strukturerat funktionsbibliotek. Många operationer kunde förbättras och förenklas genom att programmera om dessa till klasser med egenskaper och metoder. Databashanteringen är ett utmärkt exempel på kärnfunktioner som kunde programmeras objektorienterat. En faktura kunde också representeras av ett objekt. 112

108 7.3 Tidstämpling För att det skall vara möjligt att bevisa när en elektronisk signatur är skapad behövs certifierade tidstämplar. När detta projekt utfördes fanns inga lämpliga samarbetspartner i Finland som levererade certifierade tidstämplar, och de som erbjuder tjänsten utomlands var alldeles för dyra. Med detta som bakgrund lämnades tidstämplingen utanför ramarna för detta projekt. För att kunna ta i bruk elektronisk fakturahantering är certifierade tidstämplar dock ett krav som inte kan undgås. Tidstämplingsservern Tidstämpling utförs genom att ett extrakt av den digitala signaturen skickas från klienten till en tidstämplingsserver, som upprätthålls av en tillförlitlig tidstämplingsmyndighet. Tidstämplingsservern fogar till en korrekt datum- och tidstämpel och signerar detta elektroniskt. Det resulterande paketet skickas tillbaka till klienten och fogas därefter till det elektroniskt signerade dokumentet. Därefter är det möjligt att bevisa att dokumentets digitala signatur existerade vid tidstämpelns tidpunkt. Förnyelse av tidstämplar En tidstämpel måste förnyas innan giltighetstiden för tidstämplingsmyndighetens certifikat går ut. Annars är det inte längre bevisbart när tidstämpeln är skapad. Förnyelsen utförs genom att ett extrakt av föregående tidstämpel skickas från klienten till samma tidstämplingsserver, som redan har tagit det nya certifikatet i bruk. Det behövs alltså en överlappningslucka där både det gamla och det nya certifikatet samtidigt är i kraft för att kunna förnya en tidstämpel gjord med det äldre certifikatet. Till det mottagna extraktet av den föregående tidstämpel tillfogas en ny tidstämpel som därefter signeras elektroniskt. Det nya paketet skickas tillbaka till klienten som fogar den nya certifierade tidstämpel till samma dokument. På detta sätt skapas en kedja av tidstämplar via vilken man kan bevisa giltigheten steg-för-steg genom kedjan, ända upp till den första tidstämpeln vilken visar tidpunkten när dokumentet hade en giltig signatur. 113

109 7.4 Arkivet Konstrueringen av det elektroniska långtidsarkivet föll utanför ramarna för detta projekt. För att systemet skall kunna tas i bruk på riktigt krävs ett väl utvecklat, pålitligt, robust och väl testat elektroniskt arkiv. Enklaste lösningen är säkert att placera arkivdatabasen på en server med speglade hårddiskar i RAID-koppling. Rutiner för integritetskontroll av arkivdata förnyelse av tidstämplar mediamigration måste utarbetas. Gränssnitt för arkivhantering För att ha någon praktisk nytta av det elektroniska arkivet behövs någon form av gränssnitt för sökning i arkivet. Samtidigt behövs rutiner för att verifiera både elektroniska signaturer och certifierade tidstämplar. Gränssnittet bör skyddas så att enbart behöriga personer når det, på liknande sätt som administrationsgränssnittet för fakturahanteringen. Verifiering av signaturer vars certifikat har gått ut I ett långsiktigt elektroniskt arkiv uppstår förr eller senare situationer där elektroniska signaturer behöver verifieras, men certifikaten har gått ut. Det behövs alltså funktioner som kan verifiera signaturer fastän giltighetstiden för de använda certifikaten har gått ut. Detta har inte alls testats ännu, eftersom de funktioner som fanns till förfogande när detta projekt utfördes inte accepterade som parameter ett certifikat vars giltighetstid hade gått ut. Dessutom är det svårt att i utvecklingsskedet testa detta på riktigt när giltighetstiden för de certifikat som används i FINEID-korten är 3 eller 5 år. Den bästa lösningen vore att kunna använda den tid som den certifierade tidstämpeln innehåller när dokumentets elektroniska signaturer skall verifieras. 114

110 7.5 Loggning Under systemutvecklingen förenklas verifieringen och felsökningen av koden avsevärt om systemet skapar olika typer av informativa loggar. I det skapade systemet finns enbart en kombinerad logg som skrivs till systemets syslog. På servern är syslog konfigurerad så att den i realtid visas på tty12. Därmed är det enkelt att följa med vad som inträffar i systemets kärnkomponenter. Loggningen kunde med fördel delas upp i tre separata loggar, d.v.s. SQL-loggar, personliga loggar och systemloggar. SQL-loggar Alla SQL-operationer som skickas till databashanteraren kunde sparas i en loggfil på serverns hårddisk. Resultatet blir då en databashistorik i kronologisk ordning som kan vara viktig vid felsökning ifall data har blivit korrupterad. Loggfilen fungerar samtidigt som en primitiv säkerhetskopia. Någon fullständig säkerhetskopia kan den dock inte bli, eftersom man åtminstone av prestandaskäl måste låta bli att logga filbilagor som skickas till databashanteraren. Personliga loggar För att effektivt kunna följa upp ett händelseförlopp vid en felsituation skulle loggar på personlig nivå underlätta. Man kunde även tänka sig att användarna själva kan se sina personliga loggfiler via ett webbgränssnitt så att de kan följa med vad som egentligen händer. Detta skulle samtidigt bli en bra källa för att snabbt kontrollera ifall ett visst ärende har klarats upp eller inte, exempelvis ifall användaren inte kommer ihåg om han har mottagit en faktura som saknas eller inte. Systemloggar Systemloggen skulle i stora drag förbli som den är med undantag för det som flyttas över till SQL-loggarna och de personliga loggarna. I systemloggen syns inloggningar, auktoriseringar, läs- och skrivoperationer, utskick av e-postbrev, signatur- och certifikatoperationer samt allt annat som ingår i systemets kärnfunktionalitet. 115

111 7.6 Gränssnitt för revisorer När boksluten skall revideras vore det behändigt med webbgränssnitt för revisorerna där de kan kontrollera verifikat. Det är inte bara behändigt, det är ett verkligt krav ifall alla handlingar som bokföringen baserar sig på enbart är arkiverade i elektronisk form. Gränssnitten bör anpassas för revisorerna så att de snabbt och effektivt kan hämta verifikat på basis av verifikatnummer från databasen. Revisorportalen skulle vara en del av fakturahanteringsportalen och autentiseringen skulle fungera på samma sätt med elektroniska identitetskort. På så sätt är det enkelt att tillfälligt under revideringsperioden ge revisorerna åtkomst till verifikatdatabasen. Revisorerna har inget behov av att nå andra delar av systemet. 7.7 Sökningar och rapporter För att en förman i praktiken skall kunna sköta sina uppgifter som övervakare av fakturacirkulationen behövs ett effektivt verktyg för att söka efter och för att spåra fakturor under cirkulationsförloppet. Alla användare behöver ha tillgång till verktyget, men fakturornas synlighet bör beaktas vid sökningen. Lämpliga sökkriterier vore exempelvis fakturans rubrik, leverantör, fakturanummer eller förfallodag. Sökkriterierna bör anpassas till organisationens behov. För att effektivt kunna sammanställa rapporter över till exempel behandlade fakturor behövs någon form av rapporteringsverktyg. Även rapporterna bör anpassas efter organisationens behov. I detta projekt har inga rapportfunktioner ännu skapats. 7.8 Validering av inmatade data För att minimera risken för felaktiga data i systemet är det viktigt att man så fort som möjligt kan upptäcka felaktiga data eller data i fel form. I detta projekt finns knappt någon felkontroll alls inbyggd ännu. Databasen sätter klara fysiska gränser för vad som är accepterbart, men när data redan har skickats till databasen är det oftast för sent för att ändra det och då blir resultatet ofta en misslyckad databasoperation varvid indata förloras. I praktiken är alltså det uppbyggda fakturahanteringssystemet väldigt sårbart för felaktiga data och det rekommenderas att felkontroller integreras för samtliga nivåer. 116

112 Validering och kontroll av dataintegritet kan i fakturahanteringssystemet utföras på tre nivåer: i webbläddraren med JavaScript, på webbservern med PHP och av databashanteraren med kolumnspecifika begränsningar Felkontroll med JavaScript Den första kontrollen skall utföras av webbläddraren genast när användaren försöker skicka iväg ett formulär med data. Kontrollen utförs av ett JavaScript som kan aktiveras antingen via onsubmit-händelsehanteraren eller via en vanlig tryckknapp med en onclick-händelse definierad. Kontrollen skall framförallt upptäcka obligatoriska data som saknas. Dessutom kan den göra en snabb valideringskontroll där det granskas att inmatade data är vettiga. Därefter kan kontrollfunktionen skicka iväg formuläret med submit() funktionen Felkontroll med PHP När det sända formuläret mottagits av webbservern erbjuder PHP betydligt effektivare metoder för att validera och kontrollera mottagna data. Fel som inte upptäckts av webbläddraren skall senast upptäckas här. Felkontrollen bör sträva efter att när data skickas till databashanteraren skall de vara felfria och i sådant format att databashanteraren garanterat kan spara mottagna data i databasen. Givetvis kan allt inte upptäckas på förhand och framförallt inte när det är frågan om ett fleranvändarsystem Begränsningar i databasen Databashanterarna erbjuder många olika typer av begränsningar för datakolumner. Hos MySQL är utbudet inte lika stort som hos konkurrenterna och i detta projekt finns inga andra begränsningar är de som medföljer egenskaperna för primärnyckeln och NOT NULL-begränsningar. Utbudet av begränsningsmöjligheter är större hos MySQL version 4. Eftersom detta projekt från början baserade sig på version 3 har inga av dessa begränsningar tagits i bruk. Detta medför att databashanteraren inte har effektiva verktyg i bruk för att validera de data som den mottar från användarna. Därför vore det viktigt att integrera kontroller både i webbläddraren (JavaScript) och i webbservern 117

113 (PHP). Det rekommenderas även, att databasen förses med mera omfattande begränsningar. 7.9 Certifikat- och signaturhantering Det finns en hel del att förbättra inom certifikat- och signaturhanteringen. I dagsläget tillfredsställer de utarbetade metoderna inte det behov och de krav som ställs på ett fullfjädrat elektroniskt dokumenthanteringssystem. När det gäller fakturahantering, som ligger till grund för bokföring, ställs det dessutom krav från lagens sida. I det elektroniska arkivet måste all information som använts för att till exempel skapa en elektronisk signatur sparas. Detta betyder i praktiken att även alla användarcertifikat måste arkiveras, samt de CA-certifikat som använts Arkivering av certifikat I dagsläget arkiveras enbart det certifikat som användes vid signeringen av fakturan. Signeringscertifikatets CA-certifikat arkiveras inte alls. Istället används vid verifiering samma CA-certifikat som webbservern använder, eftersom autentiseringscertifikatet och signeringscertifikatet på FINEID-kortet bägge är signerade med samma CA-certifikat. Detta är en enkel och mycket kortsiktig lösning och detta tillvägagångssätt blir totalt obrukbart direkt som ett nytt CA-certifikat för FINEID-korten ges ut. De certifikat som kommer att användas för tidstämpling skall också arkiveras när tidstämplingen tas i bruk Hantering av multipla användarcertifikat Ett certifikat på ett FINEID-kort är i kraft enbart i 3 eller 5 år, beroende på när identitetskortet är skaffat. En person kommer med andra ord att under sin karriär ha haft ett flertal certifikat. Det elektroniska certifikatarkivet måste då formas så att en person kan ha flera arkiverade certifikat och dessa måste märkas i arkivet på sådant sätt att det är lätt och klart för verifieringsoperationer vilket certifikat som skall användas. 118

114 I det enkla certifikatarkiv som skapades under detta projekt kan en person enbart lagra ett enda certifikat, vilket inte är hållbart i längden Förbättring av signaturverifiering För att verifiera elektroniska signaturer på ett säkert och tillförlitligt sätt behövs bättre metoder än de utarbetade metoderna. I de enkla verifieringsoperationer som utförs i detta projekt finns ett flertal klara brister som alla måste åtgärdas innan fakturahanteringssystemet kan tas i bruk. Vid verifieringen av en elektronisk signatur skall signeringscertifikatets CA-certifikat ges som parameter till verifieringsfunktionen. I detta projekt har det CA-certifikat som används av webbservern använts, eftersom certifikatet har använts för att signera bägge användarcertifikaten på FINEID-korten. Detta görs på grund av att CA-certifikatet inte alls har funnits i certifikatarkivet och för att det CA-certifikat som använts av webbservern färdigt finns i en fil på serverns hårddisk (CA-certifikatet ges som parameter via en fil). Det certifikat som använts vid signeringen borde också kunna hämtas ur certifikatarkivet och ges som indata till verifieringsoperationen, liksom den klartext som användes. Dessutom måste verifieringsoperationen kunna hantera verifieringssituationer där certifikatens giltighetstid har gått ut Hantering av strukturerade signaturer För att uppfylla syftet i detta projekt räcker det med en enda elektronisk signatur per dokument. För att kunna utnyttja denna portal för andra ändamål än fakturahantering kan det behövas metoder för hantering av strukturerade (kedjade) signaturer. Med strukturerade signaturer avses flera signaturer för samma dokument. Den programvara för hantering av smartkort som har använts (SmartTrust och WebSigner) har stöd för strukturerade signaturer. I WebSigner kallas detta för counter signing och funktionen aktiveras genom att ange application/pkcs7-signature som Mime-type istället för text/plain. 119

115 8 SLUTSATSER Detta projekt visar att det i hög grad är fullt möjligt att med hjälp av öppen programvara bygga informationssystem för hantering av certifierad elektronisk information. Även om detta projekt inte har löst alla problem som uppdagats har det ändå blivit en god grund för framtida experiment och forskning kring certifierad elektronisk information och öppen programvara. Den modell och de metoder som utarbetats i detta projekt kan användas som grund för utveckling av andra liknande system, så som certifierade elektroniska intyg av olika slag, ansökningar, reseräkningar eller betyg. Om metoder för hantering av strukturerade signaturer ännu tas fram kan systemet användas som grundplattform för nästan all hantering av certifierad elektronisk information. I projektet har framgångsrikt testats olika metoder för hantering av certifierad digital information och utbudet av öppna kryptografiska funktioner har granskats och testats. Utvecklingsbehov och brister hos en del av dessa funktioner har påvisats. En stor utmaning i projektet var att på elektronisk väg skapa den logistiska fakturahanteringsmodellen som idag existerar i Arcada så att den blir enkel att använda men ändå följer de riktlinjer som ges i det ekonomiska reglementet. Resultatet blev ett system med enkla webbgränssnitt men ändå en avancerad åtkomst- och behörighetskontroll. Ett tidskrävande arbetsmoment i projektet var att ta fram fungerande metoder för kommunikation med det elektroniska identitetskortet. Därtill skulle ett koncept för hantering av elektroniska signaturer och certifikat definieras och metoder för hantering av dessa skulle utarbetas. Resultatet visade sig bli en uppsjö av olika standarder och kodningsmetoder för kryptografisk information. Metoder för hantering av XML-data utarbetades. XML-hanteringen kan säkert förbättras genom att man i högre grad utnyttjar de XML-funktioner som ingår i PHP och framför allt genom att definiera DTD-mallar. 120

116 Projektet visade även att en noggrann planering och utveckling av den underliggande databasen är viktig. Det är svårt att göra ändringar under drift, eftersom detta kan ge upphov till situationer där äldre data blir svårhanterliga. Genom en god planering av databasen kan man även minimera antalet databasförfrågningar som behöver utföras för en viss operation. I detta projekt steg antalet databasförfrågningar oroväckande snabbt i förhållande till antalet samtidiga användare. De självutvecklade minnesbuffertarna mildrade dock belastningen på databashanteraren, men det är svårt att realistiskt kunna uppskatta hur stor belastningen på databasservern blir utgående från de få användare som systemet testades med. 121

117 LITTERATUR ActiveX, ActiveX Controls Microsoft Papers, Presentations, Web Sites, and Books, for ActiveX Controls [www]. Hämtat Apache. The Apache Software Foundation [www]. Hämtat Eklund, Sven & Fernlund, Hans, Programkonstruktion med kvalitet - projekthantering och ISO 9000, s Studentlitteratur. ISBN Ekonomiskt reglemente, Ekonomiskt reglemente. Arcada Nylands svenska yrkeshögskola, 5 s. FINEID. Väestörekisterikeskus Yleistä henkilökortti [www]. Hämtat GPL. The GNU General Public License [www]. Hämtat Grafisk profil, Grafisk profil. Arcada Nylands svenska yrkeshögskola, 14 s. Gulutzan, Peter & Pelzer, Trudy, SQL Performance Tuning. Addison-Wesley, 528 s. ISBN Hästbacka, Ronnie FINEID-identifiering med Apache och SSL- protokollet. Esbo: Arcada Nylands svenska yrkeshögskola, 72 s. Mhash. Mhash [www]. Hämtat mod_ssl. mod_ssl: The Apache Interface to OpenSSL [www]. Hämtat

118 MySQL. MySQL: The World s Most Popular Open Source Database [www]. Hämtat OpenLDAP. OpenLDAP [www]. Hämtat OpenSSL. The Open Source toolkit for SSL/TLS [www]. Hämtat PHP. PHP: Hypertext Preprocessor [www]. Hämtat PKCS #7. PKCS #/7: Cryptographic Message Syntax Standard [www]. Hämtat ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc PKI-Forum. Scandinavian PKI Forum [www]. Hämtat Sendmail. Sendmail [www]. Hämtat Slackware. The Slackware Linux Project [www]. Hämtat SmartTrust, SmartTrust Personal [www]. Hämtat &sub2=digital&advert=sakrade SmartTrust Technical Description, SmartTrust Personal Technical Description Rev Document number: TD-PE WIN-ENG-100, 128 s. S/MIME, S/MIME Mail Security [www]. Hämtat TSP, Internet X.509 Public Key Infrastructure Time-Stamp Protocol TSP [www]. Hämtat

119 Väestörekisterikeskus. Väestörekisterikeskus; Henkilökortti Varmennehakupalvelu [www]. Hämtat X.509, Public-Key Infrastructure X.509 [www]. Hämtat XML. XML.com: XML from the Inside Out XML development, XML resources, XML specifications [www]. Hämtat Åström, Peik Elektronisk dokumenthantering i Arcada Nylands svenska yrkeshögskolas ekonomiadministration, s Esbo: Arcada Nylands svenska yrkeshögskola, 138 s. 124

120 BILAGA: KÄLLKODSDOKUMENTATION Fil- och funktionsstruktur I Figur 54 visas en trädstruktur över kataloger, filer och funktioner. /var/www/https/fakturabehandling/ index.php frameset.php installningar.php logout.php menuwindow.php topwindow.php style_1.css admin/ index.php admin_frameset.php admin_mainwindow.php admin_menuwindow.php admin_topwindow.php anvandare/ admin_anvandare.php admin_anvandare_andra_grupp.php admin_anvandare_radera.php avdelningar/ admin_avdelningar_radera.php admin_avdelningar.php admin_ny_avdelning.php grupper/ admin_grupp_hierarki_radera.php admin_grupp_hierarki_tillsatt.php admin_grupp_radera.php admin_grupper.php admin_ny_grupp.php signeringsbelopp/ admin_signeringsbelopp.php admin_uppdatera_signeringsbeloppen.php archive/ config/ config.inc paminn_autotext.txt error/ access_denied.html images/ arcada_logo_eng.gif lock.gif papperskorg_full.gif papperskorg_tom.gif smallkey.gif Figur 54A. Fil- och funktionsträd. 125

121 126 /var/www/https/fakturabehandling circ/ arkivera.php betala.php betalda_queue.php cirkulera.php create_faktura.php edit_faktura.php ny_faktura.php overview_forfallodag.php overview_mottagare.php overview_rubrik.php paminn_om_faktura.php queue.php radera_bilaga.php radera_faktura.php radera_kommentar.php radera_signatur.php signed_queue.php signera.php skicka_faktura.php spara_signatur.php update_faktura.php view_bilaga.php view_signatur.php libs/ cache.inc setaccesscache() getaccesscache() flushaccesscache() setstatuscache() getstatuscache() setrootcache() getrootcache() setuseridcache() getuseridcache() setusernamecache() getusernamecache() setgroupnamecache() getgroupnamecache() setsigbeloppcache() getsigbeloppcache() db_mysql.inc connecttodb() exec_query() res_num_rows() res_affected_rows() res_fetch_object() update_counter() sql_error() db_last_insert_id() res_data_seek() faktura.inc getfakturalist() checkfakturaaccess() issigned() createfullmetadata() movefaktura() Figur 54B. Fil- och funktionsträd.

122 127 /var/www/https/fakturabehandling/ libs/ files.inc attachfiletofaktura() getfilefromdb() verifyhash() gethash() deletefile() deletepublishedattachments() groups.inc getgroupname() grouppositionup() grouppositiondown() map.inc setmap() insertmap() deletemap() getmap() paminn.inc insertpaminnelse() checkpaminnelse() cleanpaminnelser() deletepaminnelse() dopaminnelser() skickapaminnelse() signatur.inc verifysignature() checkforusercertificate() isusercertificateindb() insertusercertificate() getusercertificate() getcertinfo() decodeescapedcharacters() users.inc checkforuser() insertuser() updateuserlogintime() checkuserstatus() checkuserisrootlevel() getuserid() getusername() checkuserstatuslevel() checksigningaccess() xml.inc create_xml_string() parse_xml_string() papperskorg/ empty.php undo.php view_papperskorg.php xml/ faktura.xml filbihang.xml kommentar.xml tillaggsinformation.xml tmp/ Figur 54C. Fil- och funktionsträd.

123 Fildokumentation /var/www/https/fakturabehandling admin/ Gränssnitt för systemadministratorn. archive/ Arkivgränssnitt för bl.a. revisorer. circ/ Gränssnitt för cirkulationen. config/ Konfigurationsfiler. error/ Felmeddelanden. images/ Bilder. libs/ Funktionsbibliotek. papperskorg/ Papperskorgsgränssnitt. tmp/ Tillfälliga publicerade bilder (filbilagor) xml/ XML mallar. /var/www/https/fakturabehandling index.php Startsida. Läser in databaskonfigurationsfilen samt lagrar värden i sessionsvariabler. Triggar följande funktioner: checkforuser(), updateuserlogintime(), dopaminnelser() Styr därefter om till frameset.php. frameset.php installningar.php Länkar följande bibliotek: db_mysql.inc, users.inc, paminn.inc Skapar ramarna och laddar tre (3) dokument: topwindow.php, menuwindow.php, circ/queue.php Länkar inga bibliotek. Gränssnitt för inmatning av e-postadress. Den inmatade e-postadressen valideras med JavaScript innan den postas. Postar följande parametrar ($PHP_SELF): string $epost (e-postadress) Tar emot följande parametrar: 1. Inga 2. string epost (e-post address) logout.php menuwindow.php style_1.css topwindow.php Länkar följande bibliotek: db_mysql.inc Sidan kallar på session_destroy() och avslutar på så sätt sessionen (sessionsfilen raderas från serverns hårddisk). Länkar inga bibliotek. Bygger en dynamisk meny i vänstra ramen beroende på i vilken grupp användaren är medlem i. Använder funktionerna checkuserstatus() och userisrootlevel() för att ta reda på vilka funktionslänkar skall visas. Länkar följande bibliotek: db_mysql.inc, users.inc Global stilmall. Innehåller rubriken och Arcadalogon. I ramens högra kant skrivs användarnamnet och gruppnamn ut. Dessutom skrivs inloggningstiden ut. 128

124 top_window.php fortsättning Länkar följande bibliotek: db_mysql.inc /var/www/https/fakturabehandling/circ arkivera.php Flyttar fakturor från utbetalningskön till arkivet. Använder funktionen userisrootlevel() för att kontrollera att användaren är behörig till operationen. Använder funktionen deletepublishedattachments() för att putsa bort publicerade bilder från cirkulationen. Styr automatiskt om till betalda_queue.php. Tar emot följande parametrar: Array $arkivera (fakturanummer) betala.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, files.inc Flyttar fakturor från signeringskön till utbetalningskön. Använder funktionen userisrootlevel() för att kontrollera att användaren är behörig till operationen. Använder funktionen deletepublishedattachments() för att putsa bort publicerade bilder från cirkulationen. Flyttar fakturorna med funktionen movefaktura(). Styr automatiskt om till signed_queue.php. Tar emot följande parametrar: Array $betala (fakturanummer) Array $datum (utbetalningsdatum) betalda_queue.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, files.inc Listar alla fakturor som har kompletterats med information från reskontran (samt betalningsdatum) och som har flyttats från signeringskön till betalningskön av ekonomibyrån. Använder funktionen checkuserisrootlevel() för att kontrollera att användaren är behörig till operationen. Verifierar signaturen med verifysignature(). Postar följande parametrar (arkivera.php): Array $arkivera (fakturanummer) cirkulera.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, signatur.inc Gränssnitt för att välja mottagare vid cirkulation för en given faktura (förmedlas som parameter). Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig att cirkulera fakturan. Gränssnittet hittar automatiskt fakturan. 129

125 cirkulera.php fortsättning Gränssnittet listar användare på två olika sätt: 1. Andra användare nära en själv i organisationen 2. Alla användare i alfabetisk ordning Tar emot följande parametrar: int $fid (fakturanummer) Postar följande parametrar (skicka_faktura.php): int $fid (fakturanummer) int $mottagare (användar-id) create_faktura.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc Skapar och lagrar en ny faktura utgående från de data som mottagits via parametrar. Skapar XML-posterna med hjälp av funktionen create_xml_string(). Hämtar nästa lediga faktura id från funktionen update_counter(). Sparar en eventuell filbilaga i databasen och använder funktionen attachfiletofaktura() för att associera filbilagan med fakturan. Styr automatiskt om till queue.php. Tar emot följande parametrar: Array $Faktura (fakturans poster) Array $Tillagsinformation (tilläggsinformation) Array $Bilaga (filbilaga) edit_faktura.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, xml.inc, files.inc Öppnar och editerar en given faktura (fakturanummer förmedlas som parameter). Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig till fakturan. Tillåter editering av fakturauppgifter (om fakturan inte är signerad), tilläggsinformation, filbilagor och kommentarer. Ger användaren lämpliga funktionsknappar beroende på behörigheten. Använder följande funktioner: checkuserstatus(), checksigningaccess(), checkuserisrootlevel(). Följande funktioner kan nås från detta gränssnitt: verifiering av signatur, genomgång av filbilagor, signering, cirkulation, radering av kommentar och radering av faktura. Gränssnittet verifierar en eventuell signatur med verifysignature(). Gränssnittet hittar automatiskt fakturan. Tar emot följande parametrar: int $fid (fakturanummer) 130

126 edit_faktura.php fortsättning Postar följande parametrar (update_faktura.php): Array $Faktura (fakturans poster) Array $Tillagsinformation (tilläggsinformation) Array $Bilaga (filbilaga) Array $Kommentar (kommentar och delbeslut) int $fid (faktura-id) Postar följande parametrar (radera_kommentar.php): int $fid (faktura-id) int $komid (kommentar-id) Postar följande parametrar (radera_faktura.php): int $fid (faktura-id) int $komid (alltid noll) Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, xml.inc, faktura.inc, signatur.inc ny_faktura.php Gränssnitt för att mata in information för en ny faktura. Tillgängligt för alla användare. Postar följande parametrar (create_faktura.php): Array $Faktura (fakturans poster) Array $Tillagsinformation (tilläggsinformation) Array $Bilaga (filbilaga) Länkar följande bibliotek: db_mysql.inc overview_forfallodag.php Gränssnitt för att ge en översikt över de fakturor som cirkulerar inom den egna avdelningen. Gränssnittet kan enbart användas av avdelningschefer och ekonomiadministrationen. Använder funktionen checkuserstatus() för att kontrollera behörigheten. Dessutom kallas funktionen checkfakturaaccess() för att besluta om en faktura skall visas. Listan sorteras enligt förfallodag. Gränssnittet kontrollerar vilken sorteringsordning som valts och styr därefter om till vald översiktsfil. Tar emot följande parametrar: int $visaenligt (sorteringsordning) Postar följande parametrar ($PHP_SELF): int $visaenligt (sorteringsordning) Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc,faktura.inc 131

127 overview_mottagare.php Gränssnitt för att ge en översikt över de fakturor som cirkulerar inom den egna avdelningen. Gränssnittet kan enbart användas av avdelningschefer och ekonomiadministrationen. Använder funktionen checkuserstatus() för att kontrollera behörigheten. Dessutom kallas funktionen checkfakturaaccess() för att avgöra om en faktura skall visas. Listan grupperas enligt mottagare och sorteras i förfallodagsordning för varje mottagare. Gränssnittet ger dessutom en möjlighet att skicka en manuell påminnelse per e-post. Gränssnittet börjar med att kontrollera vilken sorteringsordning som valts och styr därefter om till vald översiktsfil. Tar emot följande parametrar: int $visaenligt (sorteringsordning) Postar följande parametrar ($PHP_SELF): int $visaenligt (sorteringsordning) Postar följande parametrar (paminn_om_faktura.php): int $fakturaid (fakturanummer) int $mottagare (mottagarens användar-id) overview_rubrik.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc Gränssnitt för att ge en översikt över de fakturor som cirkulerar inom den egna avdelningen. Gränssnittet kan enbart användas av avdelningschefer och ekonomiadministrationen. Använder funktionen checkuserstatus() för att kontrollera behörigheten. Dessutom kallas funktionen checkfakturaaccess() för att avgöra om en faktura skall visas. Listan sorteras enligt rubrik. Gränssnittet börjar med att kontrollera vilken sorteringsordning som valts och styr därefter om till vald översiktsfil. Tar emot följande parametrar: int $visaenligt (sorteringsordning) Postar följande parametrar ($PHP_SELF): int $visaenligt (sorteringsordning) paminn_om_faktura.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc Skickar en påminnelse per e-post. Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig till fakturan ifråga. Om användaren inte givit sin e-postadress kan ingen påminnelse 132

128 paminn_om_faktura.php fortsättning skickas. Styr automatiskt om till overview_mottagare.php. Tar emot följande parametrar: int $fid (fakturanummer) int $mottagare (mottagarens användar-id) Postar följande parametrar ($PHP_SELF): int $fid (fakturanummer) int $mottagare (mottagarens användar-id) queue.php radera_bilaga.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc Visar samtliga fakturor som befinner sig i användarens personliga fakturakö. Använder funktionen getfakturalist() för att hämta fakturalistan. Sorterar enligt förfallodag. Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc Raderar en given filbilaga. Filen raderas direkt ur databasen och kan inte längre återskapas. Skriptet kontrollerar att användaren är behörig till fakturan med funktionen checkfakturaaccess(). Skriptet kontrollerar även att specificerad filbilaga och faktura faktiskt hör ihop. Tar emot följande parametrar: int $fid (fakturanummer) int $filid (filbilagans nummer) radera_faktura.php radera_kommentar.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, files.inc Raderar en given faktura genom att flytta den till papperskorgen. Fakturan kan återskapas tills dess att papperskorgen töms. Skriptet kontrollerar användarens behörighet med funktionen checkfakturaaccess(). Skriptet putsar upp webbservern från eventuella publicerade filbilagor med funktionen deletepublishedattachments(). Fakturan flyttas till papperskorgen av funktionen movefaktura(). Styr automatiskt om till queue.php. Tar emot följande parametrar: int $fid (fakturanummer) Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, files.inc Raderar en given kommentar på en faktura. Skriptet kontrollerar att användaren verkligen är upphovsman till den kommentar som skall raderas. Den raderade kommentaren raderas direkt och går förlorad. Styr automatiskt om till queue.php. 133

129 Radera_kommentar.php fortsättning radera_signatur.php Tar emot följande parametrar: int $komid (kommentarnummer) Länkar följande bibliotek: db_mysql.inc Skriptet raderar en elektronisk signatur från en given faktura. Skriptet kontrollerar att användaren är densamme som gjort signaturen (informationen förmedlas via sessionen från view_signatur.php som verifierar signaturen). Efter att signaturen raderats och om fakturan befinner sig i signeringskön flyttas fakturan till användarens personliga kö. Skriptet hittar fakturan automatiskt. Tar emot följande parametrar: int $fakturaid (fakturanummer) string $signame (signeraren, förmedlas via sessionen) signed_queue.php Länkar följande bibliotek: db_mysql.inc, map.inc, users.inc, faktura.inc Listar alla fakturor som är elektroniskt signerade. Sorterar enligt förfallodag. Använder funktionen userisrootlevel() för att kontrollera att användaren är behörig till funktionen. Verifierar signaturerna med funktionen verifysignature(). Fyller automatiskt i dagens datum i utbetalningsdatumfälten. Postar följande parametrar (betala.php): Array $betala (fakturanummer) Array $datum (utbetalningsdatum) signera.php Länkar följande bibliotek: db_mysql.inc, map.inc, users.inc, faktura.inc, signatur.inc Skapar signaturen med hjälp av ActiveXkomponenten WebSigner i SmartTrust Personal. Använder ett JavaScript för att förmedla informationen från HTML-formuläret till ActiveX-komponenten. Använder funktionerna checkuserstatus(), checkfakturaaccess() och checksigningaccess() för att kontrollera att användaren är behörig att utföra en signeringsoperation för denna faktura. Skriptet tolkar XML-data med funktionen parse_xml_string() och presenterar en översikt över den information som skall signeras. Skriptet listar även alla bilagor. Skriptet skapar komplett XML-data innehållande även filbihangsinformation innan informationen signeras. Filbihangen signeras genom att ett hashvärde för varje fil ingår i signaturen. Fakturanummer förmedlas via sessionen till spara_signatur.php. Signerade data och rådata postas tillsist till skriptet 134

130 signera.php fortsättning spara_signatur.php. Tar emot följande parametrar: int $fakturaid (fakturanummer) Postar följande parametrar (spara_signatur.php): string $Data (de data som signerats) string $SignedData (signaturen) string $full_xml_data (den kompletta XML posten) int $fakturaid (fakturanummer, via sessionen) skicka_faktura.php Länkar följande bibliotek: db_mysql.inc, map.inc, users.inc, faktura.inc, xml.inc Skickar en faktura till en given mottagare som tidigare blivit vald i gränssnittet cirkulera.php. Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig att skicka fakturan. Skriptet putsar bort eventuella publicerade filbihang med funktionen deletepublishedattachments(). Skriptet hittar fakturan automatiskt och flyttar den vid behov till cirkulationskön med funktionen movefaktura(). Skriptet kallar på funktionen flushaccesscache() för att tömma åtkomstbufferten. Funktionen deletepaminnelser() exekveras för att göra det möjligt för systemet att vid behov än en gång automatiskt påminna användaren ifall denne skulle mottaga fakturan igen under samma dygn. Styr automatiskt om till queue.php. Tar emot följande parametrar: int $fid (fakturanummer) int $mottagare (mottagarens användar-id) spara_signatur.php Länkar följande bibliotek: db_mysql.inc, map.inc, users.inc, faktura.inc, files.inc, paminn.inc Sparar den av SmartTrusts WebSigner postade signaturen på given faktura (förmedlas som sessionsvariabel). Använder funktionerna checkfakturaaccess() och checkuserstatus() för att kontrollera att användaren är behörig att lagra en signaturpost tillsammans med den givna fakturan. Arkiverar signerarens signeringscertifikat med hjälp av funktionen checkforusercertificate(). Skriptet putsar bort eventuella publicerade filbihang med funktionen deletepublishedattachments(). Fakturan flyttas till signeringskön med funktionen movefaktura(). Styr automatiskt om till queue.php. 135

131 spara_signatur.php fortsättning update_faktura.php Tar emot följande parametrar: string $Data (de data som signerats) string $SignedData (signaturen) string $full_xml_data (XML-posten, via sessionen) int $fakturaid (fakturanummer, via sessionen) Länkar följande bibliotek: db_mysql.inc, map.inc, users.inc, faktura.inc, files.inc, signatur.inc Uppdaterar fysiskt en given fakturas uppgifter i databasen och sparar vid behov en filbilaga eller en kommentar. Uppgifterna postas alltid från edit_faktura.php. Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig till uppdateringsoperationen. Skriptet hittar fakturan automatiskt. Skriptet använder funktionen create_xml_string() för att skapa XML-posterna. Om fakturan är signerad sparas enbart tilläggsinformationen och en eventuell kommentar. Funktionen issigned() kontrollerar om fakturan är signerad. En bilaga har inte uppladdats om fakturan är signerad, eftersom filfältet i edit_faktura.php i så fall är disabled. Om en filbilaga laddats upp fogas denna till fakturan med funktionen attachfiletofaktura(). En eventuell postad kommentar och delbeslut sparas till fakturan. Styr om till queue.php, cirkulera.php eller signera.php beroende på vilken funktion som valdes i edit_faktura.php. Tar emot följande parametrar: int $fid (fakturanummer) Array $Faktura (fakturans poster) Array $Tillagsinformation (tilläggsinformation) Array $Bilaga (filbilaga) Array $Kommentar (kommentar och delbeslut) Postar följande parametrar (cirkulera.php): int $fid (fakturanummer) Postar följande parametrar (signera.php): int $fid (fakturanummer) view_bilaga.php Länkar följande bibliotek: db_mysql.inc, xml.inc, map.inc, users.inc, faktura.inc, files.inc Ger användaren en möjlighet att i ett separat fönster bläddra igenom alla filbilagor. Använder funktionen checkfakturaaccess() för att kontrollera att användaren har behörighet till den faktura filbilagorna tillhör. Skriptet hämtar filen ur databasen med funktionen getfilefromdb(). Skriptet visar filnamnet, filstorleken (i 136

132 view_bilaga.php fortsättning bytes, kb eller MB) och när filbihanget är fogat till fakturan. Dessutom verifieras filens MD5-hash med funktionen verifyhash(). Skriptet presenterar länkar till alla andra filbilagor så att användaren enkelt kan gå igenom samtliga bilagor. Om fakturan inte är signerad ges användaren en möjlighet att radera aktuell filbilaga. Funktionen issigned() kontrollerar om fakturan är signerad. Tar emot följande parametrar: int $filid (filbilagans nummer) Postar följande parametrar (view_bilaga.php): int $filid (filbilagans nummer) Postar följande parametrar (radera_bilaga.php): int $filid (filbilagans nummer) int $fid (fakturanummer) view_signatur.php Länkar följande bibliotek: db_mysql.inc, files.inc, map.inc, users.inc, faktura.inc Visar och verifierar en signatur för en given faktura. Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig till fakturan. Skriptet hittar fakturan automatiskt. Sidan ger en kort presentation av signerarens certifikat. Följande poster presenteras: subject-fältet, issuer-fältet, notbeforeoch notafter-fälten. Signaturen verifieras med funktionen verifysignature(). Funktionen getcertinfo plockar fram de väsentliga delarna i signeringscertifikatet för presentation. Även filbilagorna verifieras och färska hash-värden beräknas med funktionen gethash(). Signerarens namn bryts ut ur subject fältet och lagras som en sessionsvariabel (behövs om signaturen i nästa skede skall raderas). Tolkar XMLposten med parse_xml_string() (filbilagornas hashvärden behövs för verifieringen). Tar emot följande parametrar: int $fid (fakturanummer) Postar följande parametrar (radera_signatur.php): int $fakturaid (fakturanummer) Länkar följande bibliotek: db_mysql.inc, signatur.inc, users.inc, faktura.inc, xml.inc, files.inc, map.inc 137

133 /var/www/https/fakturabehandling/config config.inc Konfigurationsfil för databasen. Innehåller variablerna host, database, user och pass. paminn_autotext.txt Den text som skickas i en automatisk fakturapåminnelse. /var/www/https/fakturabehandling/error access_denied.html Felmeddelande vid nekad åtkomst. /var/www/https/fakturabehandling/images arcada_logo_eng.gif Arcadas logo lock.gif Hänglås som visas på en faktura när den är signerad och låst. Länk till view_signatur.php. papperskorg_full.gif Ikonbild för papperskorg med innehåll. Länkar till view_papperskorg.php. papperskorg_tom.gif Ikonbild för tom papperskorg. Länkar till view_papperskorg.php. smallkey.gif Nyckel som visas framför fakturanamn som en indikation på att fakturan är signerad. Länkar oftast till view_signatur.php. /var/www/https/fakturabehandling/libs cache.inc Biblioteksfil för cachehanteringsfunktioner. db_mysql.inc faktura.inc Funktioner: int setaccesscache(int $fakturaid, int $access) int getaccesscahce(int $fakturaid) int flushaccesscache() int setstatuscache(int $value) int getstatuscache() int setrootcache(int $value) int getrootcache() int setuseridcache(int $id) int getuseridcache() int setusernamecache(int $userid, string $username) string getusernamecache(int $userid) int setgroupnamecache(int $groupid, string $groupname) string getgroupnamecache(int $groupid) int setsigbeloppcache(int $belopp) int getsigbeloppcache() Biblioteksfil för databashanteringsfunktioner. Funktionerna är DBMS specifika. Funktioner: resource connecttodb() int exec_query(string $query) int res_num_rows(resource $result) int res_affected_rows() object res_fetch_object(resource $result) int update_counter() string sql_error() int db_last_insert_id() bool res_data_seek(resource &$result, int $position) Biblioteksfil för fakturahanteringsfunktioner. Funktioner: Array getfakturalist() int checkfakturaaccess(int $fakturaid) int issigned(int $fakturaid) string createfullmetadata(int $fakturaid) int movefaktura(int $fakturaid, string $destination) 138

134 files.inc Biblioteksfil för filhantering. Globala variabler: string $imgroot string $urlroot groups.inc Funktioner: int attachfiletofaktura(string $filename, int $filesize, string $tempfilename, int $fakturaid) string getfilefromdb(int $filid) int verifyhash(int $filid) string gethash(int $filid) int deletefile(int $filid) int deletepublishedattachments(int $fakturaid) Biblioteksfil för grupphantering. Länkar följande bibliotek: cache.inc map.inc paminn.inc signatur.inc users.inc Funktioner: string getgroupname(int $groupid) int grouppositionup(int $groupid) int grouppositiondown(int $groupid) Biblioteksfil för automatiska fakturalokaliseringsfunktioner. Funktioner: int setmap(int $fakturaid, string $tabell) int insertmap(int $fakturaid, string $tabell) int deletemap(int $fakturaid) string getmap(int $fakturaid) Biblioteksfil för fakturapåminnelser. Funktioner: int insertpaminnelse(int $fakturaid, int $anvandarid) int checkpaminnelse(int $fakturaid, int $anvandarid) int cleanpaminnelser() int deletepaminnelse(int $fakturaid, int $anvandarid) int dopaminnelser() int skickapaminnelse(int $fakturaid, int $anvandarid, string $forfallodag, string $rubrik) Biblioteksfil för signaturhantering. Funktioner: int verifysignature(int $filid, string $outputfile) int checkforusercertificate(string $signatur) int isusercertificateindb() int insertusercertificate(string $signatur) string getusercertificate() Array getcertinfo(string $certfilename) string decodeescapedcharacters(string $escaped_string) Biblioteksfil för hantering av användare. Länkar följande bibliotek: cache.inc Funktioner: int checkforuser() int insertuser() int updateuserlogintime() 139

135 users.inc fortsättning xml.inc int checkuserstatus() int checkuserisrootlevel() int getuserid() string getusername(int $userid) int checkuserstatuslevel(int $userid_b) int checksigningaccess(int $belopp) Biblioteksfil för XML operationer. Funktioner: string create_xml_string(string $xml_file, Array $data) Array parse_xml_string(string $xml_data) /var/www/https/fakturabehandling/admin/papperskorg empty.php Tömmer papperskorgen. Använder funktionen checkuserisrootlevel() för att kontrollera att användaren är behörig att tömma papperskorgen. Styr automatiskt om till queue.php. Tömningsprocessen för en faktura går enligt följande: - Eventuella publicerade filbilagor raderas - Filbilagor raderas ur databasen - Kommentarer raderas ur databasen - Fakturan raderas ur lokaliseringssystemet - Själva fakturaposten raderas ur databasen undo.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, files.inc Återskapar fakturor från papperskorgen till den personliga fakturakön. Använder funktionen checkuserisrootlevel() för att kontrollera att användaren är behörig att använda papperskorgen. Styr automatiskt om till queue.php. Processen för att återskapa en faktura: - Eventuella publicerade filbilagor raderas - Fakturan flyttas med funktionen movefaktura() - Fakturan placeras i användarens personliga fakturakö Tar emot följande parametrar: Array $undo (fakturanummer) view_papperskorg.php Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc, faktura.inc, files.inc Listar alla fakturor som raderats och placerats i papperskorgen. Använder funktionen checkuserisrootlevel() för att kontrollera att användaren är behörig att använda papperskorgen. Erbjuder ett gränssnitt för att återskapa en faktura. Postar följande parametrar (undo.php): Array $undo (fakturanummer) Länkar följande bibliotek: db_mysql.inc, users.inc, map.inc 140

136 /var/www/https/fakturabehandling/tmp I denna katalog publiceras filbilagor tillfälligt för bläddring över nätet. /var/www/https/fakturabehandling/archive I denna katalog kommer revisorernas arkivbläddringsgränssnitt att finnas. Är vid dagens datum ( ) ej implementerat ännu. /var/www/https/fakturabehandling/xml faktura.xml XML-mall för hur fakturans uppgifter skall lagras. filbihang.xml XML-mall för hur en filbilaga skall lagras. kommentar.xml XML-mall för hur en kommentar skall lagras. Används vid dagens datum ( ) inte, kommentarerna lagras i en skild tabell med en kolumn för varje XML-fält. tillagsinformation.xml XML-mall för hur fakturans tilläggsinformation skall lagras. /var/www/https/fakturabehandling/admin anvandare/ Administrationsgränssnitt för underhåll av användare. avdelningar/ Administrationsgränssnitt för underhåll av organisationens betalare och avdelningar. grupper/ Administrationsgränssnitt för underhåll av grupper och grupphierarkier. signeringsbelopp/ Administrationsgränssnitt för underhåll av användarnas signeringsrättigheter. /var/www/https/fakturabehandling/admin index.php Startsida för administrationsgränssnitten. Läser in databaskonfigurationsfilen samt lagrar värden i sessionsvariabler. Triggar funktionerna checkforuser() och updateuserlogintime(). Styr därefter om till admin_frameset.php. admin_frameset.php admin_mainwindow.php admin_menuwindow.php admin_topwindow.php Länkar följande bibliotek: db_mysql.inc, users.inc Skapar ramarna och laddar tre (3) dokument: admin_topwindow.php, admin_menuwindow.php, admin_mainwindow.php Länkar inga bibliotek. Introduktionssida till administrationsgränssnitten. Är vid dagens datum ( ) ej färdig. Bygger dynamiskt upp administratorn funktionsmeny. Länkar följande bibliotek: db_mysql.inc, users.inc Innehåller rubriken och Arcadalogon. I ramens högra kant skrivs användarnamnet och gruppnamn ut. Dessutom skrivs inloggningstiden ut. Länkar följande bibliotek: db_mysql.inc 141

137 /var/www/https/fakturabehandling/admin/anvandare admin_anvandare.php Listar användarna som är registrerade i systemet och databasen. Gränssnittet informerar om användarens medlemsgrupp. Gränssnittet erbjuder två olika visningsalternativ: enligt användarnamn eller enligt medlemsgrupp. Visningsalternativen skickas via parameterförmedling. Grundinställningen är enligt användarnamn. Gränssnittet innehåller även funktioner för att radera en användare ur systemet (och databasen) samt ändra medlemsgrupp. Tar emot följande parametrar: int $order (grupperingsordning) Postar följande parametrar (admin_anvandare_radera.php): int $id (användar-id) int $order (grupperingsordning) Postar följande parametrar (admin_anvandare_andra_grupp.php): int $id (användar-id) int $order (grupperingsordning) admin_anvandare_andra_grupp.php Länkar följande bibliotek: db_mysql.inc Ändrar en användares medlemsgrupp. Gränssnittet presenterar de tillgängliga grupperna ur databasen. Användarens nuvarande grupp listas inte. Uppdateringen sker av samma skript. Gränssnittet innehållet två JavaScript, det första förmedlar exekveringen tillbaka till admin_anvandare.php och det andra exekverar det första efter en fördröjning på 3 sekunder. Tar emot följande parametrar: int $id (användar-id) int $order (grupperingsordning) Postar följande parametrar ($PHP_SELF): int $ok (bekräftelsevariabel) int $order (grupperingsordning) int $andraanvandargrupp (ID på nya gruppen) int $id (användar-id) Postar följande parametrar (admin_anvandare.php): int $order (grupperingsordning) Länkar följande bibliotek: db_mysql.inc 142

138 admin_anvandare_radera.php Raderar användare ur systemet. Gränssnittet ber om en bekräftelse före raderingen utförs. Raderingen utförs av samma skript. Gränssnittet meddelar om lyckad eller misslyckad radering. Gränssnittet innehållet två JavaScript, det första förmedlar exekveringen tillbaka till admin_anvandare.php och det andra exekverar det första efter en fördröjning på 3 sekunder. Använder funktionen getusername() vid namnkonvertering. Tar emot följande parametrar: int $id (användar-id) int $order (grupperingsordning) Postar följande parametrar ($PHP_SELF): int $ok (bekräftelsevariabel) int $order (grupperingsordning) int $id (användar-id) Postar följande parametrar (admin_anvandare.php): int $order (grupperingsordning) Länkar följande bibliotek: db_mysql.inc, users.inc /var/www/https/fakturabehandling/admin/avdelningar admin_avdelning_radera.php Raderar en avdelning (och betalare) ur databasen. Gränssnittet ber om en bekräftelse före raderingen utförs. Raderingen utförs av samma skript. Gränssnittet meddelar om lyckad eller misslyckad radering. Gränssnittet innehållet två JavaScript, det första förmedlar exekveringen tillbaka till admin_avdelningar.php och det andra exekverar det första efter en fördröjning på 3 sekunder. Tar emot följande parametrar: int $id (avdelningsnummer) Postar följande parametrar ($PHP_SELF): int $ok (bekräftelsevariabel) int $id (avdelnings-id) admin_avdelningar.php Länkar följande bibliotek: db_mysql.inc Listar, raderar och infogar avdelningar i databasen. Gränssnittet presenterar alla avdelningar som finns lagrade i databasen och ger en möjlighet att radera en avdelning via en länk. Inmatning av nya avdelningar sker via ett skilt inmatningsformulär i nedre kanten av sidan. 143

139 admin_avdelningar.php fortsättning Postar följande parametrar (admin_ny_avdelning.php): string $nyavdnamn (avdelningsnamn) Postar följande parametrar (admin_avdelning_radera.php): int $id (avdelningsnummer) admin_ny_avdelning.php Länkar följande bibliotek: db_mysql.inc Lagrar en ny avdelning (och betalare) i databasen. Gränssnittet meddelar ifall lagringen lyckades eller inte. Gränssnittet innehållet tre JavaScript, det första förmedlar exekveringen tillbaka till admin_avdelningar.php, det andra exekverar det första efter en fördröjning på 0 sekunder och det tredje exekverar det första efter en fördröjning på 3 sekunder. Tar emot följande parametrar: string $nyavdnamn (avdelningsnamn) Länkar följande bibliotek: db_mysql.inc /var/www/https/fakturabehandling/admin/grupper admin_grupp_hierarki_radera.php Raderar en relation mellan två grupper. Gränssnittet ber om en bekräftelse före raderingen utförs och informerar därefter om raderingen lyckades eller misslyckades. Gränssnittet innehållet två JavaScript, det första förmedlar exekveringen tillbaka till admin_grupper.php, det andra exekverar det första efter en fördröjning på 3 sekunder. Använder funktionen getgroupname() för gruppnamnkonvertering. Tar emot följande parametrar: int $id1 (gruppnummer) int $id2 (gruppnummer) Postar följande parametrar ($PHP_SELF): int $ok (bekräftelsevariabel) int $id1 (gruppnummer) int $id2 (gruppnummer) admin_grupp_hierarki_tillsatt.php Länkar följande bibliotek: db_mysql.inc, groups.inc Skapar en hierarkisk relation mellan två grupper. Gränssnittet presenterar en lista på de grupper till vilka relationer ännu kan skapas. Efter att relationen skapats informerar gränssnittet om lyckad eller misslyckad lagring. 144

140 admin_grupp_hierarki_tillsatt.php fortsättning Gränssnittet innehåller tre JavaScript, det första förmedlar exekveringen tillbaka till admin_grupper.php, det andra exekverar det första efter en fördröjning på 0 sekunder och det tredje exekverar det första efter en fördröjning på 3 sekunder. Använder funktionen getgroupname() för gruppnamnkonvertering. Tar emot följande parametrar: int $id (gruppnummer) int $gruppposup (grupphierarki position) Postar följande parametrar ($PHP_SELF): int $ok (bekräftelsevariabel) int $id (gruppnummer) int $hierarkitillgrupp (gruppnummer) admin_grupp_radera.php Länkar följande bibliotek: db_mysql.inc, groups.inc Raderar en grupp ur databasen. Gränssnittet ber om en bekräftelse före raderingen utförs. Gränssnittet förmedlar resultatet till användaren. Före raderingen utförs kontrollerar gränssnittet att gruppen inte har några medlemmar eller relationer till andra grupper. Gränssnittet innehållet tre JavaScript, det första förmedlar exekveringen tillbaka till admin_grupper.php, det andra och det tredje exekverar det första efter en fördröjning på 3 sekunder. Använder funktionen getgroupname() för gruppnamnkonvertering. Tar emot följande parametrar: int $id (gruppnummer) Postar följande parametrar ($PHP_SELF): int $ok (bekräftelsevariabel) int $id (gruppnummer) admin_grupper.php Länkar följande bibliotek: db_mysql.inc, groups.inc Presenterar grupperna lagrade i databasen samt visar hierarkistrukturen mellan dessa. Gränssnittet presenterar grupperna enligt alfabetisk ordning och erbjuder en möjlighet att radera en grupp. Ekonomiadministrationen kan inte raderas. Gränssnittet erbjuder även inmatning av en ny grupp samt en möjlighet att definiera nya 145

141 admin_grupper.php fortsättning relationer samt att radera existerande relationer. En relation kan endast skapas mellan sådana grupper som inte redan har två grupper ovanför sig i hierarkin. Postar följande parametrar (admin_grupp_radera.php): int $id (gruppnummer) Postar följande parametrar (admin_ny_grupp.php): string $nygruppnamn (gruppnamn) Postar följande parametrar (admin_grupp_hierarki_tillsatt.php): int $id (gruppnummer) int $gruppposup (grupphierarki position) Postar följande parametrar (admin_grupp_hierarki_radera.php): int $id1 (gruppnummer) int $id2 (gruppnummer) admin_ny_grupp.php Länkar följande bibliotek: db_mysql.inc Sparar en ny grupp i databasen. Gränssnittet bekräftar ifall lagringen lyckades eller inte. Gränssnittet innehållet tre JavaScript, det första förmedlar exekveringen tillbaka till admin_grupper.php, det andra exekverar det första efter en fördröjning på 0 sekunder och det tredje exekverar det första efter en fördröjning på 3 sekunder. Tar emot följande parametrar: string $nygruppnamn (gruppnamn) Länkar följande bibliotek: db_mysql.inc /var/www/https/fakturabehandling/admin/signeringsbelopp admin_signeringsbelopp.php Presenterar användarnas signeringsbefogenheter och erbjuder uppdateringsmöjligheter. Gränssnittet erbjuder några olika maximala signeringsbelopp, vilka har slagits fast av Ekonomibyrån. Signeringsbeloppen är hårdkodade i skriptet. Gränssnittet skapar två tabeller av vilka den ena innehåller de gamla värdena och den andra de nya värdena. 146

142 admin_signeringsbelopp.php fortsättning admin_uppdatera_signeringsbeloppen.php Postar följande parametrar (admin_uppdatera_signeringsbelo ppen): Array $Gamlasigbelopp (originalvärden) Array $Sigbelopp (nya värden) Länkar följande bibliotek: db_mysql.inc, users.inc Uppdaterar användarnas signeringsbelopp. Gränssnittet utnyttjar de två tabellerna, innehållande de nya och de gamla värdena, och utför en databasuppdatering enbart för de ändrade värdena. Gränssnittet informerar om lyckad eller misslyckad uppdatering. Gränssnittet innehåller två JavaScript, det första förmedlar exekveringen tillbaka till admin_signeringsbelopp.php och det andra exekverar det första efter en fördröjning på 3 sekunder. Tar emot följande parametrar: Array $Gamlasigbelopp (originalvärden) Array $Sigbelopp (nya värden) Länkar följande bibliotek: db_mysql.inc 147

143 Funktionsdokumentation Bibliotek: cache.inc int setaccesscache(int $fakturaid, int $access) Buffertminnesfunktion för att spara åtkomstinformation för funktionen checkfakturaaccess(). Funktionen arbetar med två tabeller: en för fakturaåtkomstinformation och en för varje fakturas buffertminnesgiltighetstid. Buffertminnets giltighetstid för varje faktura är förinställt till 60 sekunder (variabeln $cache_expires). Tabellerna lagras som sessionsdata. Funktionen utför session_register() om inget buffertminne ännu har skapats. Sessionsvariabler: Array $access_cache Array $cache_time Åkomstinformation för fakturor. Giltighetstiden för fakturornas buffertminne. Tar emot följande parametrar: int $fakturaid Fakturanummer. int $access Åtkomstinformation (1 eller 0). Returnerar: 1 = Åtkomstinformationen för fakturan lagrad i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. int getaccesscache(int $fakturaid) Buffertminnesfunktion för att läsa buffertminnet för funktionen checkfakturaaccess(). Funktionen läser information ur två tabeller: en för åtkomstinformationen och en för fakturans buffertminnesgiltighetstid. Giltighetstiden är den tid fram till vilken åtkomstinformationen för den givna fakturan är giltig. Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar och kontrollerar giltighetstiden för den begärda fakturan. Sessionsvariabler: Array $access_cache Array $cache_time Åkomstinformation för fakturor. Giltighetstiden för fakturornas buffertminne. Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: 1 = Åtkomst tillåten. 0 = Åtkomst nekad. -1 = Buffertmiss. (Finns ingen information om fakturan i buffertminnet eller så har informationens giltighetstid gått ut.) 148

144 int flushaccesscache() Tömmer buffertminnet för fakturaåtkomstinformationen som används i funktionen checkfakturaaccess(). Informationen töms genom att bägge sessionsvariablerna (två tabeller) raderas ur sessionen. Därefter påbörjas ett nytt buffertminne. Sessionsvariabler: Array $access_cache Array $cache_time Åkomstinformation för fakturor. Giltighetstiden för fakturornas buffertminne. Returnerar: 1 = Buffertminne raderat. 0 = Buffertminnet raderas inte. int setstatuscache(int $value) Buffertminnesfunktion för att skriva buffertminnet för funktionen checkuserstatus(). Buffertminnet utgörs av en sessionsvariabel. Funktionen utför session_register() ifall inget buffertminne har skapats ännu. Sessionsvariabler: int $stauts_cache Resultatet av checkuserstatus(). Tar emot följande parametrar: int $value Resultatet av checkuserstatus(). Returnerar: 1 = Värdet lagrat i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. int getstatuscache() Buffertminnesfunktion för att läsa buffertminnet för funktionen checkuserstatus(). Buffertminnet utgörs av en sessionsvariabel. Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar. Sessionsvariabler: int $stauts_cache Resultatet av checkuserstatus(). Returnerar: 1, 0 = Resultatet av checkuserstatus() vid inloggningsögonblicket. -1 = Buffertmiss (inget buffertminne existerade). int setrootcache(int $value) Buffertminnesfunktion för att skriva buffertminnet för funktionen userisrootlevel(). Buffertminnet utgörs av en sessionsvariabel. Funktionen utför session_register() ifall inget buffertminne har skapats ännu. Sessionsvariabler: int $root_cache Resultatet av userisrootlevel(). Tar emot följande parametrar: int $value Resultatet av userisrootlevel(). Returnerar: 1 = Värdet lagrat i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. 149

145 int getrootcache() Buffertminnesfunktion för att läsa buffertminnet för funktionen userisrootlevel(). Buffertminnet utgörs av en sessionsvariabel. Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar. Sessionsvariabler: int $root_cache Resultatet av userisrootlevel(). Returnerar: 1, 0 = Resultatet av userisrootlevel() vid inloggningsögonblicket. -1 = Buffertmiss (inget buffertminne existerade). int setuseridcache(int $id) Buffertminnesfunktion för att skriva buffertminnet för funktionen getuserid(). Buffertminnet utgörs av en sessionsvariabel. Funktionen utför session_register() ifall inget buffertminne har skapats ännu. Sessionsvariabler: int $userid_cache Användar-ID. Tar emot följande parametrar: int $id Användar-ID från getuserid(). Returnerar: 1 = Värdet lagrat i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. int getuseridcache() Buffertminnesfunktion för att läsa buffertminnet för funktionen getuserid(). Buffertminnet utgörs av en sessionsvariabel. Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar. Sessionsvariabler: int $userid_cache Användar-ID. Returnerar: > 0 = Användarens användar-id. -1 = Buffertmiss (inget buffertminne existerade). int setusernamecache(int $userid, string $username) Buffertminnesfunktion för att skriva buffertminnet för funktionen getusername(). Buffertminnet utgörs av en sessionsvariabel (tabell). Funktionen utför session_register() ifall inget buffertminne har skapats ännu. Sessionsvariabler: Array $username_cache Tabell för användar-id och användarnamn. Tar emot följande parametrar: int $userid Användar-ID. string $username Användarnamn. Returnerar: 1 = Värdet lagrat i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. 150

146 String getusernamecache(int $userid) Buffertminnesfunktion för att läsa buffertminnet för funktionen getusername(). Buffertminnet utgörs av en sessionsvariabel (tabell). Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar. Sessionsvariabler: Array $username_cache Tabell för användar-id och användarnamn. Tar emot följande parametrar: int $userid Användar-ID för den sökta användaren. Returnerar: string = Användarens användarnamn. -1 = Buffertmiss (användarnamnet fanns inte i buffertminnet). int setgroupnamecache(int $groupid, string $groupname) Buffertminnesfunktion för att skriva buffertminnet för funktionen getgroupname(). Buffertminnet utgörs av en sessionsvariabel (tabell). Funktionen utför session_register() ifall inget buffertminne har skapats ännu. Sessionsvariabler: Array $groupname_cache Tabell för gruppid och gruppnamn. Tar emot följande parametrar: int $groupid Gruppid. string $groupname Gruppnamn. Returnerar: 1 = Värdet lagrat i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. string getgroupnamecache(int $groupid) Buffertminnesfunktion för att läsa buffertminnet för funktionen getgroupname(). Buffertminnet utgörs av en sessionsvariabel (tabell). Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar. Sessionsvariabler: Array $groupname_cache Tabell för grupp-id och gruppnamn. Tar emot följande parametrar: int $groupid Grupp-ID för den sökta gruppen. Returnerar: string = Gruppens namn. -1 = Buffertmiss (gruppnamnet fanns inte i buffertminnet). 151

147 int setsigbeloppcache(int $belopp) Buffertminnesfunktion för att skriva buffertminnet för funktionen checksigningaccess(). Buffertminnet utgörs av en sessionsvariabel. Funktionen utför session_register() ifall inget buffertminne har skapats ännu. Sessionsvariabler: int $sigbelopp_cache Användarens maximala signeringsbelopp. Tar emot följande parametrar: int $belopp Användarens maximala signeringsbelopp. Returnerar: 1 = Värdet lagrat i buffertminnet. 0 = Buffertminnet kunde inte sparas som sessionsdata. int getsigbeloppcache() Buffertminnesfunktion för att läsa buffertminnet för funktionen checksigningaccess(). Buffertminnet utgörs av en sessionsvariabel. Funktionen använder session_is_registered() för att kontrollera att buffertminne existerar. Sessionsvariabler: int $sigbelopp_cache Användarens maximala signeringsbelopp. Returnerar: >= 0 = Användarens maximala signeringsbelopp. -1 = Buffertmiss (inget buffertminne existerade). Bibliotek: db_mysql.inc resource connecttodb() Tar kontakt till databasen utgående från de sessionsvariabler som lästs upp ur databaskonfigurationsfilen. Funktionen utför en mysql_pconnect() och returnerar en deskriptor för databaskontakten. Funktionen försöker inte ta kontakt om någon av de behövliga uppgifterna saknas. Sessionsvariabler: string $host string $user string $pass string $database Databasserver. Databaslogin. Lösenord. Databasnamn. Returnerar: 0 = Ingen kontakt etablerades. > 0 = Databasdeskriptor. 152

148 int exec_query(string $query) Utför en databasförfrågan mot databasservern. Funktionen tar en SQL-sats som parameter och kontrollerar att den är avslutad med ett semikolon. Om semikolon fattas tillfogas det innan förfrågningen utförs. Funktionen räknar antalet databasförfrågningar per webbserverförfrågning och loggar förfrågningens nummer tillsammans med SQL-satsen på serverns systemlogg. Funktionen utför förfrågningen med mysql_query(). Tar emot följande parametrar: string $query Databasförfrågning enligt SQL standard. Returnerar: FALSE = Förfrågningen misslyckades. TRUE = Förfrågningen utfördes felfritt. SQL förfrågningarna SELECT, SHOW, EXPLAIN och DESCRIBE returnerar en resursidentifikator. int res_num_rows(resource $result) Funktionen returnerar antalet poster i ett resultat från en SELECT-sats. Funktionen utför operationen mysql_num_rows(). Tar emot följande parametrar: resource $result En resursidentifikator från en databasförfrågan. Returnerar: Antalet poster i resultatet. int res_affected_rows() Funktionen returnerar antalet poster som fysiskt påverkades av den senaste datamodifieringsoperationen (INSERT, UPDATE, DELETE). Funktionen utför operationen mysql_affected_rows(). Returnerar: Senast antalet påverkade poster eller -1 om den senaste databasförfrågningen misslyckades. object res_fetch_object(resource $result) Skapar och returnerar ett objekt med alla egenskaper som motsvarar en rad i det per parameter förmedlade resultatet. Utför operationen mysql_fetch_object(). Tar emot följande parametrar: resource $result En resursidentifikator från en databasförfrågan. Returnerar: Ett resultatobjekt eller FALSE om resultatet inte innehåller flera poster. 153

149 int update_counter() Genererar nästa lediga faktura-id. Operationen utnyttjar en egen tabell (Counter) i databasen och använder tabellåsningsoperationer för att garantera att varje faktura får en unik ID. Returnerar: > 0 = Nästa lediga faktura-id. -1 = Ingen ID genererades. string sql_error() Returnerar det senaste SQL errormeddelandet. Utför operationen mysql_error(). Returnerar: Senaste SQL errorstring. int db_last_insert_id() Returnerar det värde en AUTO_INCREMENT-kolumn fick efter föregående INSERT-operation. Noteras bör att funktionen måste anropas direkt efter föregående INSERT-operation, annars går värdet förlorat. Utför operationen mysql_insert_id(). Returnerar: Senaste värdet för en AUTO_INCREMENT-kolumn. bool res_data_seek(resource &$result, int $position) Flyttar den interna pekaren i en resultatpost till den givna positionen. Utför operationen mysql_data_seek(). Tar emot följande parametrar: resource &$result En resursidentifikator från en databasförfrågan. int $position Den önskade positionen (0 till antalet poster -1) Returnerar: TRUE = Operationen lyckades. FALSE = Operationen utfördes inte korrekt. Bibliotek: faktura.inc Array getfakturalist() Skapar en lista över alla fakturor som användaren är mottagare till. Funktionen används i mina fakturor kön och innehåller enbart fakturor som hör dit. Returnerar: En tabell med fakturanummer eller -1 om inte listan kunde sammanställas. 154

150 int checkfakturaaccess(int $fakturaid) Funktionen kontrollerar användarens behörighet till en faktura. Resultatet sparas i en minnesbuffert som gäller i 60 sekunder. Funktionen hittar fakturan automatiskt med funktionen getmap(). En åtkomstkontroll utförs i följande ordning: 1. Mottagare till fakturan. 2. Ägare till fakturan utan någon avsändare. 3. Medlem i ekonomiadministrationen. 4. Chef för mottagarens grupp eller ägarens grupp (utan avsändare). Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: 1 = Åtkomst tillåten. 0 = Åtkomst nekad. int issigned(int $fakturaid) Funktionen kontrollerar om den givna fakturan är signerad. Funktionen hittar fakturan automatiskt med funktionen getmap(). Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: 1 = Fakturan är signerad. 0 = Fakturan är inte signerad. string createfullmetadata(int $fakturaid) Skapar den slutgiltiga XML posten, innehållande även alla filbilagor, som behövs för att kunna signera alla nödvändiga data. Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: Den kompletta XML metadataposten. int movefaktura(int $fakturaid, string $destination) Flyttar en fakturan mellan två fysiska tabeller i databasen och uppdaterar lokaliseringsregistret. Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig till fakturan. Funktionen hittar automatiskt fakturan med funktionen getmap(). Funktionen utför en säker förflyttning, d.v.s. den kontrollerar att fakturan verkligen kopierades till destinationen innan originalet raderas. Tar emot följande parametrar: int $fakturaid Fakturanummer. string $destination Destinationstabell i databasen. Returnerar: 1 = Fakturan flyttades. 0 = Flyttningen av fakturan lyckades inte. 155

151 Bibliotek: files.inc int attachfiletofaktura(string $filename, int $filesize, string $tempfilename, int $fakturaid) Sparar en filbilaga och kopplar den till den givna fakturan. Funktionen kontrollerar att filen verkligen existerar och beräknar ett MD5-hash värde av filen. Tar emot följande parametrar: string $filename Originalfilens namn. int $filesize Originalfilens storlek i bytes. string $tempfilename Den uppladdade filens temporära filnamn. int $fakturaid Fakturanummer dit filen hör. Returnerar: 1 = Bilagan sparades. 0 = Bilagan sparades inte. string getfilefromdb(int $filid) Publicerar en filbilaga ur databasen på webbservern. Den publicerade filen får filens id-nummer som filnamn (unik egenskap). Funktionen kontrollerar att antalet skrivna bytes motsvarar den registrerade filstorleken i databasen. Tar emot följande parametrar: int $filid Filens ID-nummer. Returnerar: URL till filen ( int verifyhash(int $filid) Utför en verifikationskontroll av den givna filen. Funktionen beräknar en ny MD5-hash och jämför den med den i uppladdningsögonblicket registrerade MD5-hashen. Tar emot följande parametrar: int $filid Filens ID-nummer. Returnerar: 1 = Verifikationen lyckades (Hash ok). 0 = Verifikationen misslyckades (Hash inte ok). string gethash(int $filid) Funktionen beräknar ett MD5-hashvärde för den givna filen i databasen och returnerar detta. Tar emot följande parametrar: int $filid Filens ID-nummer. Returnerar: 0 = Ingen hash kunde beräknas. string = Hashvärdet. 156

152 int deletefile(int $filid) Raderar en publicerad fil från webbserverns filsystem, filen i databasen berörs inte av operationen. Tar emot följande parametrar: int $filid Filens ID-nummer. Returnerar: 0 = Filen kunde inte raderas. 1 = Filen raderad. int deletepublishedattachments(int $fakturaid) Funktionen raderar alla eventuella publicerade filer för en given faktura från webbserverns filsystem. Filerna i databasen berörs inte av operationen. Använder funktionen checkfakturaaccess() för att kontrollera att användaren är behörig till operationen. Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: 0 = Inga filer fanns att raderas. >= 1 = Antalet raderade filer. Bibliotek: groups.inc string getgroupname(int $groupid) Returnerar gruppnamnet för den givna gruppen. Funktionen utnyttjar en minnesbuffert i sessionen. Tar emot följande parametrar: int $groupid Grupp-ID. Returnerar: En sträng innehållande gruppens namn. int grouppositionup(int $groupid) Funktionen räknar antalet grupper ovanför den givna gruppen i organisationens hierarki. Tar emot följande parametrar: int $groupid Grupp-ID. Returnerar: Antalet grupper ovanför den givna gruppen i organisationens hierarki. 157

153 int grouppositiondown(int $groupid) Funktionen räknar antalet grupper nedanför den givna gruppen i organisationens hierarki. Tar emot följande parametrar: int $groupid Grupp-ID. Returnerar: Antalet grupper nedanför den givna gruppen i organisationens hierarki. Bibliotek: map.inc int setmap(int $fakturaid, string $tabell) Funktion för att uppdatera (eller skapa) en post tillhörande den automatiska fakturalokaliseringstjänsten (fakturaindex). Funktionen anropar insertmap() om fakturan inte finns med i indexet från tidigare. Tar emot följande parametrar: int $fakturaid Fakturanummer. string $tabell Tabell där fakturan befinner sig. Returnerar: 0 = Indexet uppdaterades inte. 1 = Index uppdaterat. int insertmap(int $fakturaid, string $tabell) Sparar en ny indexpost i databasen för den givna fakturan. Tar emot följande parametrar: int $fakturaid Fakturanummer. string $tabell Tabell där fakturan befinner sig. Returnerar: 0 = Posten sparades inte. 1 = Posten sparad. int deletemap(int $fakturaid) Raderar en given fakturaindexpost ur databasen. Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: 0 = Posten raderades inte. 1 = Posten raderad. 158

154 string getmap(int $fakturaid) Funktion för att lokalisera en given faktura utgående från det index som finns i databasen. Funktionen utnyttjar en minnesbuffert som enbart existerar i den barnprocess som betjänar klienten. Detta snabbar upp flera återkommande sökningar på samma faktura utförd av olika funktioner i samma HTTP-begäran. Om posten inte hittas i minnesbufferten söks den fram ur databasen och lagras därefter i samma minnesbuffert. När fakturan eftersöks kontrolleras först minnesbufferten, därefter indexet. Om den fortfarande inte hittats går funktionen genom alla tabeller enligt följande ordning (sannolikhetsordning): 1. Fakturor 2. Signerade 3. Betalda 4. Papperskorg 5. Arkiv När fakturan till slut har lokaliserats skapas en indexpost för fakturan och dessutom lagras positionen i minnesbufferten. Tar emot följande parametrar: int $fakturaid Fakturanummer. Returnerar: En sträng innehållande tabellens namn där fakturan befinner sig. Bibliotek: paminn.inc int insertpaminnelse(int $fakturaid, int $anvandarid) Sparar information i databasen om när en påminnelse har utförts för en viss faktura och användare. Funktionen använder den aktuella systemtiden. Tar emot följande parametrar: int $fakturaid Fakturanummer. int $anvandarid Användare. Returnerar: 1 = Påminnelsen sparad. 0 = Påminnelsen sparades inte. int checkpaminnelse(int $fakturaid, int $anvandarid) Kontrollerar om den givna användaren redan har blivit påmind om den givna fakturan. Funktionen tar ingen hänsyn till tiden. Tar emot följande parametrar: int $fakturaid Fakturanummer. int $anvandarid Användare. Returnerar: 1 = Användaren är påmind om denna fakturan. 0 = Användaren är inte påmind om denna faktura. 159

155 int cleanpaminnelser() Funktionen putsar upp påminnelsetabellen genom att radera alla påminnelser som är mer än ett dygn gamla. Giltighetstiden för påminnelserna bestäms av variabeln $daysold (tiden anges i dagar). Returnerar: 1 = Påminnelser raderades. 0 = Inga påminnelser raderades. int deletepaminnelse(int $fakturaid, int $anvandarid) Funktionen raderar en given påminnelsepost ur databasen. Funktionen är användbar för att göra det möjligt att på nytt påminna en användare om samma faktura. Tar emot följande parametrar: int $fakturaid Fakturanummer. int $anvandarid Användare. Returnerar: 1 = Påminnelsen raderades. 0 = Påminnelsen raderades inte. int dopaminnelser() Funktion för att automatiskt skicka påminnelser till berörda användare för sådana fakturor som förfaller inom 4 dagar. Tiden anges direkt i SQL-satsen. Funktionen börjar med att lista alla fakturor som är inom den nämnda gränsen. Därefter anropas funktionen cleanpaminnelser() för att putsa bort gamla påminnelser. Efter detta utförs en påminnelsekontroll för varje akut faktura med funktionen checkpaminnelse(). Om användaren inte blivit påmind tidigare inom toleranstiden skickas en påminnelse med funktionen skickapaminnelse(). Returnerar: Antalet skickade påminnelser. int skickapaminnelse(int $fakturaid, int $anvandarid, string $forfallodag, string $rubrik) Skickar fysiskt en påminnelse per e-post. E-postmeddelandet innehåller den text som finns i filen /config/paminn_autotext.txt. Filnamnet kan ändras i variabeln $textfile. Om användaren inte har delat med sig sin e-postadress kan ingen påminnelse skickas. Tar emot följande parametrar: int $fakturaid Fakturanummer. int $anvandarid Användare. string $forfallodag Fakturans förfallodag. string $rubrik Fakturans rubrik. Returnerar: 1 = E-post skickad. 0 = E-post skickades inte. 160

156 Bibliotek: signatur.inc int verifysignature(int $fakturaid, string $outputfile) Verifierar signaturen för den givna fakturan och sparar signeringscertifikaten i den fil som anges som andra parameter (kan vara /dev/null ifall inte certifikatet behöver sparas). Funktionen lokaliserar fakturan automatiskt med hjälp av funktionen getmap(). Arbetar med temporära filer. Signaturen förbereds för S/MIME-format genom att delas i rader om 64 tecken med funktionen chunk_split(). Därefter tillfogas ett S/MIME-huvud, vilket krävs för att PHP-funktionen openssl_pkcs7_verify() skall fungera. Funktionen tar CA-certifikatet från Apacheserverns ssl.crt katalog. Skall korrigeras ( ): - CA certifikatet skall inte tas från webbservern utan från databasens certifikatarkiv. - Verifieringsoperationen skall kunna ta användarens signeringscertfikat som parameter och inte plocka ut det ur den givna signaturen. - Verifieringsoperationen borde verifiera mot den lagrade klartexten och inte mot den klartext som ingår i signaturen (detached istället för attached signatur). - Verifieringsoperationen borde för arkivet skull kunna verifiera i en på förhand bestämd tid (vid verifiering av signaturen är certifikaten har gått ut). Tar emot följande parametrar: int $fakturaid Fakturanummer. string $outputfile Verifieringsoperationens outputfil (certifikat). Returnerar: 1 = Signatur OK! 0 = Verifieringen misslyckades. int checkforusercertificate(string $signatur) Kontrollerar om användarens signeringscertifikat finns i certifikatarkivet. Om den inte finns så sätts den in i arkivet. Signeringscertifikatet plockas ur den bifogade signaturen. Tar emot följande parametrar: string $signatur En PEM-kodad signatursträng (obruten). Returnerar: -1 = Certifikatet fanns inte och arkiverades inte. 0 = Certifikatet fanns inte, men arkiverades nu. 1 = Certifikatet finns från tidigare i arkivet. 161

157 int isusercertificateindb() Funktionen kontrollerar om användarens signeringscertifikat finns i certifikatarkivet. Skall korrigeras ( ): - Funktionen måste klara av att hantera flera certifikat för samma användare. I dagsläge antas att en användare inte kan ha mer än ett certifikat. Certifikaten måste alltså identifieras med hjälp av någon unik egenskap. Returnerar: 0 = Certifikatet finns inte. >= 1 = Certifikat-ID för användarens certifikat i arkivet. int insertusercertificate(string $signatur) Infogar signeringscertifikatet i certifikatarkivet i databasen ur den bifogade signaturen. Funktionen PKCS7 formaterar signaturen, eftersom OpenSSL kräver det. PKCS7-formatet skapas genom att bryta upp signatursträngen i rader om 64 tecken och därefter tillfoga ett PKCS7-huvud. Arbetar med temporära filer. Funktionen exekverar en openssl process för att bryta ut certifikatet ur signaturen. Skall korrigeras ( ): - Funktionen måste identifiera certifikaten med någon unik egenskap istället för SSL_CLIENT_S_DN_CN namnet för att en användare skall kunna ha flera certifikat i arkivet. Tar emot följande parametrar: string $signatur En PEM-kodad signatursträng (obruten). Returnerar: 0 = Certifikatet infogades inte i certifikatarkivet. 1 = Certifikatet infogades i certifikatarkivet. string getusercertificate() Funktionen hämtar användarens signeringscertifikat ur certifikatarkivet i databasen och returnerar detta. Skall korrigeras ( ): - Funktionen måste klara av att hantera multipla certifikat för samma användare. Dessutom måste den returnera det aktuella certifikatet som är i kraft i hämtningsögonblicket. Certifikaten måste identifieras med någon unik egenskap. Returnerar: En sträng innehållande användarens signeringscertifikat. 162

158 Array getcertinfo(string $certfilename) Bygger en tabell innehållande några nyckeluppgifter ur det givna certifikatet. Certifikatet skall förmedlas via en fil. Funktionen kontrollerar att certifikatfilen existerar och exekverar därefter ett OpenSSL kommando för att läsa ut den behövliga informationen. Arbetar med temporära filer. Funktionen bryter om output-filen till en tabell och returnerar denna. Följande fält läses ur certifikatet och blir nycklar i tabellen: SUBJECT, ISSUER, NOTBEFORE och NOTAFTER. Funktionen kan lätt modifieras till att inkludera andra certifikategenskaper genom att OpenSSL-kommandoraden editeras. Nycklarna i tabellen får samma namn som egenskaperna i certifikatet. Tar emot följande parametrar: string $certfilename Filnamnet till certifikatet. Returnerar: En tabell (key-value pairs) innehållande information ur certifikatet. string decodeescapedcharacters(string $escaped_string) Funktion för att avkoda s.k. escaped strings. Funktionen ersätter hexkoderna med de riktiga ASCII tecknen. Tar emot följande parametrar: string $escaped_string Sträng för att avkoda. Returnerar: Den avkodade strängen. Bibliotek: users.inc int checkforuser() Kontrollerar om en användare existerar i användartabellen. Om användaren inte finns sätts denne in med funktionen insertuser(). Returnerar: 0 = Användaren fanns inte, sattes in. 1 = Användaren finns. int insertuser() Infogar fysiskt användaren i användartabellen i databasen. Användaren förblir grupplös tills dess att administratorn placerat användaren i någon grupp. Returnerar: 0 = Användaren infogades inte. 1 = Användaren infogades. 163

159 int updateuserlogintime() Uppdaterar användarens fält för senaste inloggning. Tiden tas från serverns aktuella tid. Returnerar: 0 = Inloggningstiden uppdaterades inte. 1 = Inloggningstiden uppdaterades. int checkuserstatus() Funktionen kan avgöra om användaren är medlem i en lövgrupp eller om denne har en position högre upp i organisationens hierarki. Funktionen utnyttjar en minnesbuffert i sessionen och sparar efter den första sökningen resultatet i minnesbufferten. Returnerar: 0 = Användaren är medlem i en lövgrupp längst ned i hierarkin. > 0 = Antalet grupper som är lägre ned i hierarkin än användarens grupp. int checkuserisrootlevel() Funktionen kan avgöra om användaren är medlem i den grupp högst i hierarkin. I detta system är denna grupp statisk och har alltid ID-nummer ett (1) och utgörs av ekonomiadministrationen (Ekonomibyrån). Funktionen utför kontrollen genom att kontrollera om användarens gruppnummer är ett. Funktionen utnyttjar en minnesbuffert i sessionen och sparar efter första sökningen resultatet i minnesbufferten. Returnerar: 0 = Användaren är inte medlem av ekonomiadministrationen. 1 = Användaren är medlem av ekonomiadministrationen. int getuserid() Funktionen returnerar användarens användar-id. Funktionen utnyttjar en minnesbuffert i sessionen och sparar efter första funktionsanropet användar-id:t i minnesbufferten. Returnerar: -1 = Användaren finns inte. > 0 = Användarens användar-id. string getusername(int $userid) Funktionen returnerar användarnamn för den givna användaren. Funktionen utnyttjar en minnesbuffert i sessionen. Minnesbufferten utgörs av en tabell där användar-id och användarnamn lagras som key-value pairs. Om ett användarnamn inte hittas i minnesbufferten söks det fram i databasen varefter det lagras i minnesbufferten. Returnerar: Den begärda användarens användarnamn. 164

160 int checkuserstatuslevel(int $userid_b) Funktionen kan jämföra två användares positionen i organisationens hierarki och avgöra vilken som befinner sig på en högre nivå. Jämförelsen görs alltid mot den inloggade användaren. De jämförda användarna bör befinna sig på samma gren i hierarkin och grenen får högst bestå av tre nivåer. Tar emot följande parametrar: int $userid_b Användar-ID att jämföra mot. Returnerar: 1 = Användaren är på en högre nivå än den mot vilken jämförelsen gjordes. 0 = Användaren är på en lägre nivå än den mot vilken jämförelsen gjordes. int checksigningaccess(int $belopp) Funktionen kontrollerar om användaren har rätt att signera en faktura på det givna beloppet. Funktionen utnyttjar en minnesbuffert i sessionen där användarens maximala signeringsbelopp lagras. Om beloppet ännu inte finns i minnesbufferten läses det upp ur databasen och lagras därefter i minnesbufferten. Funktionen utför kontrollen genom att jämföra beloppet med det maximala belopp (som bestäms av administratorn) som finns lagrat i databasen. Tar emot följande parametrar: int $belopp Penningbeloppet i fråga. Returnerar: 0 = Användaren får inte signera en faktura på det givna beloppet. 1 = Användaren får signera en faktura på det givna beloppet. Bibliotek: xml.inc string create_xml_string(string $xml_file, Array $data) Funktionen kan bygga upp en XML-metadatapost utgående från den XML-mall och de data som förmedlas via parametrar. Tabellen, som innehåller metadata, skall vara en tabell med key-value pairs där nycklarna har exakt samma namn som fälten i XMLmallen. Det spelar ingen roll i vilken ordning nycklarna förekommer i tabellen, resultatet blir ändå en XML-metadatapost helt i samma ordning som XML-mallen. Funktionen tillfogar automatiskt en extra tag CDATA för att varje fält skall definieras som teckendata. Kortfattat kan man säga att funktionen fyller i de data som fattas i XML-mallen från tabellen. Tar emot följande parametrar: string $xml_file XML-mallens fullständiga filnamn. Array $data Det metadata som skall komplettera XML mallen. Returnerar: En XML-post innehållande metadata ur tabellen, formaterad enligt XML-mallen. 165

161 array parse_xml_string(string $xml_data) Funktion för att tolka de XML-poster som är skapade av create_xml_string(). Funktionen behöver inte känna till XMLmallen utan plockar ut all information ur den XML-post som förmedlas som parameter. Funktionen bygger en ny tabell innehållande key-value pairs där nycklarna får samma namn som de XML-fält som innehåller metadata i XML-posten. Tar emot följande parametrar: string $xml_data XML-metadata. Returnerar: En tabell med nyckel-värde kombinationer ur XML-metadatat. Programflöde Inloggningsflöde index.php frameset.php topwindow.php menuwindow.php circ/queue.php Menylänkar menuwindow.php ny_faktura.php queue.php overview_mottagare.php signed_queue.php betalda_queue.php view_papperskorg.php installningar.php logout.php Ny faktura ny_faktura.php create_faktura.php queue.php 166

162 Fakturaflöde queue.php edit_faktura.php radera_kommentar.php update_faktura.php radera_faktura.php view_bilaga.php radera_bilaga.php signed_queue.php view_signatur.php radera_signatur.php betala.php betalda_queue.php arkivera.php view_papperskorg.php queue.php empty.php undo.php 167

163 Uppdatera faktura update_faktura.php queue.php cirkulera.php skicka_faktura.php signera.php spara_signatur.php 168