TILBUD PÅ UDVIKLING OG HOSTING AF WEBSCANNER. OS2 Offentligt Digitaliseringsfællesskab

Transkript

1 TILBUD PÅ UDVIKLING OG HOSTING AF WEBSCANNER OS2 Offentligt Digitaliseringsfællesskab Copyright 2014

2 INDHOLDSFORTEGNELSE 1 Indledning Ejerskab og Git Funktionalitet og brugergrænseflade Udvikling af grundlæggende funktionalitet Login-adgang Oprettelse og redigering af domæner Regler Scannere Rapporter Test og efterfølgende justeringer Projektledelse, møder og kommunikation Optioner Option: Autentifikation med SAML Option: Selenium-baseret crawler Option: Selenium-baseret scanning af specifikke sider Option: Spring tidligere scannet indhold over via et Last-Modified check Option: WebService til scanning af enkelte URL'er eller dokumenter Opsummering Grundfunktionalitet Pris Tidsplan Optioner Hosting Opsætning Månedligt vedligehold Oprettelse og abonnement på CPRdata Opsummering på hostingopgaven..14

3 1 INDLEDNING I forbindelse med specifikationen af opgaven har primært to løsningsmodeller været nævnt: 1. Serverafviklet løsning 2. Hostet webcrawlerløsning I vores tilbud har vi valgt den sidste model, en hostet webcrawlerløsning, fordi det efter vores opfattelse er den mest fleksible model, og den vil give værdi til alle kommuner, uanset hvilket CMS man måtte benytte. Kort om løsningen Crawlerløsningen sørger for periodisk eller efter bestilling at gennemløbe et samlet site eller subsite med henblik på at undersøger de forskellige sider og dokumenter på sitet. Der er tale om en hostet og webbaseret løsning, der giver brugerne mulighed login-adgang til et web-baseret administrationssystem, hvor brugeren kan konfigurere og starte en scanning af det eller de valgte domæner. Løsningen giver mulighed for at definere forskellige domæner og regler for scanning efter følsomme opløsninger og at kombinere disse i forskellige scannings-opsætninger, der enten kan afvikles manuelt eller automatisk med et defineret tidsinterval. Når en scanning sættes i gang, vil den afvikles i baggrunden på serveren, og når scanningen er udført, vil der blive sendt en mail til den bruger, der forespurgte scanningen. Denne mail vil indeholde et link, der gør det muligt for brugeren at logge ind og download scannings-rapporten. De data, der er blevet hentet under scanningen, bliver slettet, efter at rapporten er genereret. Det er vigtigt at understrege, at der er omfattende adgangskontrol i forhold til, hvem der må scanne hvilke websites. Samtlige krav er adresseret og opfyldt. Dette gælder også optioner. Integration til CPR Broker Løsningen vil endvidere omfatte en integration til CPR-Broker, der vil gøre det muligt at kontrollere, om fundne CPR-numre rent faktisk er rigtige CPR-numre. Tilbuddet er opdelt i udvikling hhv, hosting af webscanneren efter OS2's ønske beskrevet i udbuddet 1 på OS2 Offentligt digitaliseringsfællesskab (OS2) samt de tilhørende kravspecifikationer beliggende på OS2's opgavestyringsværktøj 2 (JIRA). Hostingtilbuddet er tilpasset udviklingsopgaven beskrevet i dette dokument og vil derfor skulle revurderes, hvis der vælges en anden løsning. I tilbuddet henvises til punkterne på JIRA i følgende format: (WEBSCAN-XX), hvor XX er det nummer, som punktet er tildelt på JIRA Linket er fra udbudsmaterialet.

4 Maksimalpristilbud Tilbuddet, der er et maksimalpristilbud, er opdelt i grundfunktionalitet og optioner. Grundfunktionerne beløber sig, inkl. projektledelse, møder og test, til 189 timer, i alt DKK Optionerne kan tilvælges efter behov og ønske indtil 12 måneder efter idriftsættelsen. Ønsker en kommune at etablere sin egen installation af webscanneren, er dette også muligt jf.afsnittet nedenfor om ejerskab. Magenta assisterer gerne med at etablere lokale installationer. 1.1 Ejerskab og Git Magenta forpligter sig til at placere koden i et repository henvist af OS2 (WEBSCAN-24). Det fulde ejerskab til den udviklede kode, herunder ophavsretten, overdrages til OS2 under en Mozilla Public License 2.0 (WEBSCAN-26). Der vil efter OS2's ønske benyttes Git samt Git-flow. Magenta benytter i forvejen Git og Git-flow, og det fungerer godt til en agil udviklingsmetode med en højt involveret kunde (WEBSCAN-25).

5 2 FUNKTIONALITET OG BRUGERGRÆNSEFLADE 2.1 Udvikling af grundlæggende funktionalitet 8 timer Magenta har baseret sit tilbud på udvikling af OS2webscanner på Scrapy 3, der er et webcrawling framework skrevet i Python. Fordelen ved at vælge en webcrawler-løsning frem for en serverafviklet løsning er, at den vil fungere med et vilkårligt offentligt tilgængeligt site. (WEBSCAN-10, WEBSCAN-30). Brugergrænsefladen bliver udviklet i Django 4, et framework som Magenta har omfattende og positiv erfaring med fra bl.a. BibOS-projektet 5. Udviklingen vil følge den stil-guide og de kode konventioner (PEP 8, PEP ), der er anbefalet til et Python projekt. Herudover vil der benyttes Ding Code Guidelines (WEBSCAN-45), samtidig med at der tages hensyn til de forskelle, der er mellem et PHP- og et Python-projekt. I brugergrænsefladen vil der være følgende koncepter. Domæner, der er tilknyttet brugeren Regler, der kan scannes efter Scannere, der kan afvikles på brugerens domæner Oprettelse, benyttelse og administration af domæner, regler og scannere er beskrevet i det følgende. Generelt for dem alle er, at de har almindelig CRUD 7 funktionalitet (Create, Read, Update, Delete). 2.2 Login-adgang 5 timer Brugeradministration er en vedligeholdelsesopgave i forbindelse med hosting. Der er tale om et begrænset antal brugere, og ved at placere denne del i tilknytning til hostingopgaven reduceres opgaven, samtidig med at der er stærk kontrol med, hvilke bruger der har adgang til hvilke services samt deres tilhørsforhold

6 Adgang til systemet opnås ved klassisk brugernavn og kodeord-kombination. (WEBSCAN-9) Vi tilbyder også en option på en single-sign-on-løsning baseret på djangosaml2 8, der laver autentifikation med SAML 2.0 (WEBSCAN-37) Optionen er på 14 timer 2.3 Oprettelse og redigering af domæner 44 timer For hvert domæne er det muligt at angive en række regler for URL'er, der ikke skal scannes. Disse regler kan udtrykkes enten som del-strenge, der ikke må optræde i URL'erne, eller som regulære udtryk der frasorterer de URL'er, de matcher Der kunne for eksempel være tale om et website, der på alle sider linker til en printvenlig udgave ved at sende en ekstra parameter til samme url, eksempelvis: <nuværende url>?print=1. I dette tilfælde vil det ikke være ønskeligt at scanne alle de printvenlige sider, da de har samme indhold som de ikke-printvenlige sider. Print-siderne vil kunne ekskluderes ved at oprette regler, der matcher alle sider med printparametren på URL'en. Dette kan gøres enten ved at matche del-strengene "?print=1" og "&print=1" eller ved at bruge det regulære udtryk "[?&]print=1". Systemet foretager en kontrol af, om den pågældende bruger må tilføje domænet. En bruger må ikke scanne andre domæner end brugerens egne (inkl. subdomæner), og der foretages en kontrol af dette. Domæner vises i en liste, og brugeren vil kunne tilføje domæner herfra med følgende arbejdsgang: 1. Brugeren tilføjer domænet i brugergrænsefladen. 2. Brugeren indtaster evt. ekskluderingsregler, som regulære udtryk separeret af ny linje. 3. For at kunne foretage kontrollen giver systemet brugeren følgende tre muligheder, der også fremgår af illustrationen på næste side: a) Tilføjelse af en unikt defineret linje i domænets Robots.txt b) Tilføjelse af en unikt defineret html-fil i roden af domænet c) Tilføjelse af et unikt meta-tag i den side, der returneres ved tilgang til roden af domænet 4. Brugeren vælger en af overstående muligheder og tilføjer det til domænet 5. Brugeren har nu mulighed for at uploade sitemap.xml for domænet. (WEBSCAN-12) 6. Brugeren trykker på validering, hvorefter første tjek gennemføres. 8 Djangosaml2:

7 Den valgte valideringsmetode vil blive kørt før hver scanning. (WEBSCAN-28) 2.4 Regler 23 timer En regel definerer, hvad der scannes efter. Der vil blive udviklet tre regelsystemer. To systemer er fast definerede: CPR-reglen og Navne-reglen. Det sidste regelsystem er baseret på regulære udtryk og giver brugeren mulighed for at definere egne scanningsparametre CPR-reglen Der søges efter mønstre med regulære udtryk 9 i teksten specifikt udarbejdet til at finde CPRnumre. Ved potentielle resultater laves der ekstra kontrol, der afsluttes af et kald til CPR Broker. Ved at lave en integration til CPR Broker er det muligt at lave en online kontrol af, om der er tale om et reelt CPR-nummer. Det fundne CPR-nummer rangeres efter, hvilken type dokument CPRnummeret er fundet i. (WEBSCAN-14, WEBSCAN-40) Navnereglen Der søges efter mønstre i teksten med regulære udtryk. Ved matches kontrolleres der op imod en positivliste af fornavne og efternavne fra Danmarks Statistik. Denne liste benyttes samtidig til at give matchet en højere rangering, så de navne, der forekommer på Danmarks Statistiks liste rangerer højere end de matches, der muligvis er navne. 9

8 Under navnereglen er det muligt at tilføje godkendte navne i en whitelist, der godt må optræde i indholdet og dermed ikke er klassificeret som sensitive. Det kan være byrådsmedlemmer eller medlemmer af direktionen, som optræder på hjemmesiden. (WEBSCAN-14) Brugertilpassede regler baseret på regulære udtryk (RegEx) Det er muligt at for en bruger selv at definere regler, der er baseret på regulære udtryk og gemme disse regler. Brugeren kan lave et vilkårligt antal regler. (WEBSCAN-15, WEBSCAN-32) 2.5 Scannere 70 timer (Frontend 24 timer + Backend 46 timer) En bruger opretter en scanner, der konfigureres med et eller flere domæner samt et sæt tilhørende regler. (WEBSCAN-11) En scanner kan f.eks. konfigureres til en periodisk automatisk scanning. (WEBSCAN-31, WEBSCAN-36) Før en scanning udføres, vil der være en kontrol af, om domænet har sitemap.xml tilgængelig i roden af domænet. Hvis der både findes et sitemap på domænet, og der manuelt er etableret et sitemap, så vil en aggregeret version af de to sitemaps benyttes. Uanset sitemap vil filerne kun benyttes som reference, og hele sitet vil blive crawlet. (WEBSCAN-19) Systemet ignorerer reglerne i Robot.txt, der vil forbyde crawling af domæner eller specifikke sider. Konkret foregår scanningen ved, at der sættes gang i en crawler, der leverer data til behandling. Efter behov vil data blive konverteret til tekst, før den egentlige scanning efter følsomme oplysninger udføres.

9 Der er taget højde for løsninger til minimum følgende formater: Pdf, html, odt, xlsx, rtf, xls, ods, docx, doc, wk3, kml, csv, geojson, json SGML-baserede data såsom HTML og XML håndteres ved at fjerne markup og scanne den resterende tekst. Billeder konverteres til TIFF og efterfølgende til ren tekst via OCR-software, der er en del af løsningen. Office-formater, der kan åbnes via Libre Office 10, konverteres enten til HTML og billeder, og behandles som disse, eller til et relevant rentekst-format, (f.eks..xls til.csv) og scannes direkte. Rene tekstformater, som CSV, Javascript og json kan umiddelbart scannes Når en scanning er færdig og har dannet en rapport, så vil data, der er blevet indsamlet, slettes af sikkerhedsmæssige årsager. (WEBSCAN-8) 2.6 Rapporter 4 timer Efter en scanning vil brugeren få en underrettelsesmail, der indeholder statusoplysninger, samt et link til rapporten. Af sikkerhedshensyn anbefales det ikke at sende selve indholdet over mail. Derfor er rapporten kun tilgængelig via systemet. Det vil være muligt at gemme siden herfra samt at slette den fra serveren. (WEBSCAN-7) Rapporten vil indeholde link til indholdssider og dokumenter, hvor der har været et match (WEBSCAN-5). Rapportens enkelte punkter vil desuden være kategoriseret efter følsomhed. 2.7 Test og efterfølgende justeringer 15 timer I samarbejde med OS2 gennemføres en række test, og der foretages justeringer og rettelser. 2.8 Projektledelse, møder og kommunikation 20 timer Der afsættes som standard 10-15% af tiden til disse opgaver. Møder holdes såvidt muligt via online medier (f.eks. Skype) 10http://en.wikipedia.org/wiki/LibreOffice#Supported_file_formats

10 3 OPTIONER 3.1 Option: Autentifikation med SAML timer Vi forslår en single-sign-on-løsning baseret på SAML 2.0. Denne løsning kan bl.a. anvendes til sign-on med WAYF. 3.2 Option: Selenium-baseret crawler 50 timer Med denne option udskiftes Scrapy med et nyudviklet crawling-framework baseret på Selenium. Dette vil give mulighed for at crawle sider, hvor indholdet genereres dynamisk via javascript, for eksempel på sider der gør brug af ajax-kald til at loade dele af siden. Følgende forhold gør sig gældende ved optionen: Det er kun muligt at køre én Selenium-instans ad gangen. Requests i forbindelse med en scanning vil skulle foretages sekventielt, hvilket kan få en scanning til at tage forholdsvis lang tid. Derfor udvikles et kø-system til at sikre sekventiel afvikling af Selenium-scanninger. Hvis der ligger mange andre scanninger i kø, kan et sådant køsystem betyde, at der vil gå lang tid, før man får rapporten fra en ønsket scanning. En Selinium-løsning vil umiddelbart kun kunne finde "rigtige" links i dynamisk genereret indhold. For eksempel vil det ikke være muligt at find "links" til vinduer/sider, der genereres dynamisk via onclick-events på forskellige elementer på siden. Det er selvfølgelig en mulighed at få Selenium til automatisk at klikke på alt, der har en onclickevent. Dette kan dog have utilsigtede sideeffekter, for eksempel hvis det første element, der klikkes på, lukker browser-vinduet. Vi vil derfor som udgangspunkt ikke anbefale, at man bruger Selenium som den primære scannings-backend. Optionen er imidlertid interessant, for eksempel til scanning af mindre websites med klient-side-dynamisk indhold. 3.3 Option: Selenium-baseret scanning af specifikke sider 35 timer Forskellen på denne option og optionen ovenfor (3.2) er, at denne option giver et interface, hvor man kan angive 1-10 URL'er, der skal scannes igennem via Selenium. Scanningen vil fungere ved, at hver enkelt side besøges via Selenium, og at den resulterende HTML, inklusive eventuelle delelementer, der loades via ajax/javascript, scannes igennem for CPR-numre og navne. Når scanningen er gennemført, præsenteres en rapport i stil med den, der genereres ved en almindelig scanning. Bemærk, at scanningen ikke fungerer som en crawler: Den identificerer og følger ikke automatisk links i de valgte sider.

11 Løsningen omfatter også udvikling af et kø-system, der sætter en forespørgsel efter en scanning i kø, hvis en scanning allerede er i gang på det tidspunkt, hvor scanningen oprettes. Denne løsning kan ses som et simplere alternativ til en fuld crawler-løsning baseret på Selenium (se option 3.2). 3.4 Option: Spring tidligere scannet indhold over via et Last- Modified check 18 timer Denne option gør det muligt at springe sider over i efterfølgende scanninger, såfremt informationer om det sidste opdaterings-tidspunkt for en side forefindes. Løsningen fungerer ved at samle informationer om det sidste opdateringstidspunkt for en side op via sitemap.xml-filer og HTTP-headers. Under den første scanning vil disse last-modified værdier blive gemt i databasen sammen med lister over links, der blev fundet i den pågældende side. Efterfølgende scanningen vil så blot lave en HTTP HEAD-request til den pågældende side og derefter kun foretage en ny scanning, såfremt siden er blevet opdateret i mellemtiden. Det vil ved oprettelse af en scanning være muligt at konfigurere, om man ønsker at gøre brug af Last-Modified data eller ej. Hvis man fravælger at bruge denne funktion, vil det resultere i, hvad der svarer til en førstegangs-scanning, hvor alle sider besøges. Det vil endvidere være muligt at konfigurere, om løsningen skal gøre brug af HEAD-requests til at checke modificeringstidspunkter med, eller om der blot skal bruges GET-requets, så eventuelt indhold kan behandles uden at generere en ny request, hvis det viser sig at være opdateret. 3.5 Option: WebService til scanning af enkelte URL'er eller dokumenter 14 timer Optionen består i en XML-RPC-baseret webservice, der gør det muligt at scanne enkelte URL'er eller dokumenter for CPR-numre. I kald til webservicen angiver man enten en liste af URL'er, en liste af dokumenter eller begge dele. Webservicen vil så scanne de angivne data igennem for CPR-numre og navne og returnere en liste med eventuelle matches, deres position i indholdet samt en vurdering af deres følsomhed. Webservicen vil være adgangsbeskyttet med den samme adgangsbeskyttelse som resten af OS2webscanner-sitet. Såfremt der angives URL'er som scannings-kilde, vil disse blive checket op mod verificerede domæner for den bruger, der blev brugt til at logge ind i servicen. Hvis der ikke findes et match for alle URL'er, afvises forespørgslen om scanning med en fejl.

12 4 OPSUMMERING 4.1 Grundfunktionalitet Udvikling af grundlæggende funktionalitet Login-adgang Opsætning og redigering af domæner 8 timer 5 timer 44 timer Regler 23 timer Scannere Frontend Backend Rapporter Test i samarbejde med OS2, samt efterfølgende justeringer Projektledelse, møder og kommunikation Samlet, grundfunktionalitet 24 timer 46 timer 4 timer 15 timer 20 timer 189 timer 4.2 Pris Magentas normalpris er DKK 1.250/time OS2-pris er DKK 1.000/time Samlet pris, 189 timer à DKK DKK Tidsplan Magenta kan levere den samlede løsning 45 arbejdsdage efter accept af tilbuddet. 4.4 Optioner Autentifikation med SAML 2.0 Selenium-baseret crawler Selenium-baseret scanning af specifikke sider Mulighed for at springe tidligere scannet indhold over via et Last-Modified check WebService til scanning af enkelte URL'er eller dokumenter 14 timer 50 timer 35 timer 18 timer 14 timer

13 5 HOSTING Vi vil gerne understrege, at der er tale om et forhandlingsoplæg. Vi vil gerne have en drøftelse med OS2 om den praktiske løsning, herunder af hvorvidt der skal laves separate aftaler med de enkelte kommuner. Hostingpartner Lynero Vi foreslår, at Magenta påtager sig aftalen med hostingleverandøren og sørger for viderefakturering af den samlede aftale. Der pålægges ikke gebyr eller procenttillæg af den rene server- og trafikpris. Dermed betaler OS2 den rene serverpris samt pris for trafik. Magentas hosting-leverandør, Lynero, er sikkerhedsgodkendt til bl.a. PET og politiet. Den månedlige pris for 2 servere (webscanner og CPR Broker) er ca. DKK Trafikprisen er (juni 2014) DKK 800/Tbyte. Hosting af webscanner inkl. vedligeholdelse hos indbefatter: Adgang via fiberlinje Driftsgaranti Backup og restore Overvågning af serverbelastning med henblik på løbende justering af databaseopsætning og webserver-konfiguration Udbedring af driftsforstyrrende fejl i applikationen Magenta har fuld remote-adgang Udgiften til hosting afregnes via det månedlige vedligehold (se nedenfor) 5.1 Opsætning Magenta påtager sig opgaven med opsætning på serverne samt den løbende overvågning og vedligeholdelse. Der skal anvendes to servere til at hoste løsningen, der skal opsættes sikkert efter gældende regler om opbevaring af fortrolige data. Opsætning af det udviklede programmel samt CPR Broker på 2 servere hos Lynero 40 timer

14 5.2 Månedligt vedligehold De afsættes 0,5 timer pr. måned pr. kommune til vedligehold af løsningen. Dog med et minimum 5 timer/måned. Timepris for OS2 er DKK Oprettelse og abonnement på CPR-data Vi påregner at indgå aftale med CPR Kontoret. Priserne er: Abonnement DKK 500/måned Klikafgift DKK 0,45/opslag. Bemærk, at klikafgiften alene udløses, når der er behov for at hente information på et CPR-nummer og ved opdateringer. OS2 betaler naturligvis de rene priser fra CPR Kontoret 5.4 Opsummering på hostingopgaven Igen vil vi understrege, at der er tale om ca.-priser Engangsudgifter Opsætning af webscanner og CPR Broker (engangsudgift) DKK Månedlige udgifter 2 servere à DKK 1.500/måned DKK Trafik DKK 800/Tbyte vi vurderer, at én Tbyte er tilstrækkeligt DKK 800 Månedligt vedligehold (ved 10 kommuner) à DKK 500 DKK CPR-abonnement DKK 500 Klikafgifter ved anslået klik/måned à DKK 0,45 DKK 450 I alt anslået månedlige udgifter DKK 9.750

15 adresse Studiestræde 14, København K info@magenta-aps.dk telefon (+45)