| Contact: | evalg-drift@usit.uio.no |
|---|---|
| Date: | Sist oppdatert 2006-10-12 |
Løsningen består grovt sett av tre komponenter:
Her ligger all informasjon som trengs for å gjennomføre et valg. Dette inkluderer informasjon om de enkelte valg, samt deres mantall. Det ligger også informasjon om hvem som har stemt, men ikke hva de har stemt.
Se createdb.sql
Selve tjenesten distribueres som en war fil som deployes i en servletcontainer (ved UiO benyttes Resin, men Tomcat vil også fungere).
Både admin-grensesnitt og bruker-grensesnitt er definert i den samme war filen.
Her ligger informasjon om hva det er stemt på, men ikke hvem som har levert stemmen.
Vi gir her et par eksempler på dataflyt for å illustrere hvordan komponentene henger sammen.
(se også avsnittet "Anonymitet")
Det er viktig å sikre at valget er hemmelig, dvs. at det ikke skal være mulig å finne ut hvem som har stemt hva. Applikasjonen tillater imidlertid at man stemmer flere ganger, og det må derfor være mulig å finne igjen en persons stemmer.
For å løse dette, tildeles alle mottatte stemmer et unikt løpenummer. Dette løpenummeret lagres i databaseserveren, sammen med informasjon om hvem som har levert stemmen (delA). I tillegg lagres løpenummeret sammen med selve stemmen i stemmelageret (delB). Dersom man kobler sammen delA og delB, vil man kunne finne ut hvem som har stemt hva. Vi har lagret delA og delB på en slik måte at sammenkobling blir vanskelig. Dette kan enten gjøres ved å lagre de på to separate systemer, eller man kan gjøre en av dem uleselig. Vi har valgt å lagre delB av stemmen som en XML fil der navnet inneholder løpenummeret. Vi har gjort den uleselig ved å kryptere den med gpg (asymmetrisk kryptering m/2048-bits nøkkel, der den hemmelige nøkkelen ikke ligger på valg.uio.no (den hemmelige nøkkelen skal kun befinne seg på maskinen der valgopptellingen skal foregå, når den skal foregå. Stemmene er kryptert inntil de havner på den maskinen)).
Vi tillater admin å bruke html i beskrivelser. Det åpner for XSS (cross-site-scripting) problematikk. Dog vises disse sidene kun i /user/ delen, så de kan ikke bli noen annen admin.
Det skal kun kjøres en instans av war fila i samme JVM. Dermed trenger ikke servletContext benyttes for å finne configvariable o.l. Slike configvariabler kan aksesseres via statiske metoder i no.uio.valg.ValgConfig som ved oppstart leser parametere fra configfiler (den er definert som en plugin i struts-config.xml).
Koden er laget for å kjøre med JDK1.5 fra Sun. struts-1.2.9 benyttes for servlet håndtering. Database-access skjer via JDBC. Feide-koblingen krever axis, mens Suns JavaMail API benyttes for mailsending.
Samtlige sider er basert på java servlets. De er implementert ved å override execute metoden i subklasser til org.apache.struts.action.Action. En enkelt Action klasse håndterer en enkelt URL, og dermed typisk en enkelt web-side. For formsbaserte sider betyr det både laging av nye entries, modifisering av eksisterende, samt lagring. Alle disse klassene er samlet i no.uio.valg.actions* hierarkiet.
War filen bygges fra eclipse (Export -> WAR file).
Følgende packages er definert:
no.uio.valg
no.uio.valg.utils
no.uio.valg.actions
no.uio.valg.actions.admin
no.uio.valg.actions.user
no.uio.valg.auth
no.uio.valg.data
no.uio.valg.exceptions
no.uio.valg.vote
Alle klasser som trenger å prate med databasen benytter no.uio.valg.ValgFactory for å få et databasekoblings objekt. De returnerte objektene er basert på prinsippet for DAO patterns, dvs. de tilbyr metoder som skjuler de faktiske databasekallene med metoder for å gjøre de enkelte operasjoner. Dette gjør at resten av applikasjonen ikke trenger å vite noe om hvordan informasjonen lagres.
Klassen ValgDB benyttes når valg administreres, samt for uthenting av informasjon om valg, mens VoteLister og VoteReceiver benyttes for håndtere ting som har med stemmer å gjøre. Vi ønsker å holde metoder og klasser for håndtering av stemmer klart adskilt fra øvrig kode av sikkerhetsmessige årsaker.
Jsp sidene har kun logikk for visning av data servert av de forskjellige Actions. Det er dermed ufarlig å kalle den enkelte jsp direkte, men det vil høst sannsynlig resultere i en ufarlig stack-trace.
Deler av applikasjonen er tospråklig. Til dette benyttes src/MessageResources.properties* filen, samt <bean:message/> tag'en.
Tiles (fra Struts) benyttes for layout. Dette gjøres ved at tiles-defs.xml definerer kobling til jsp sider, og ActionForward objektene returnert av våre Action.execute metoder peker på den aktuelle tile.
All kommunikasjon med feide er overlatt til no.uio.valg.auth.FeideUtils klassen. Denne benytter autogenererte stubber (laget med wsdl2java) som befinner seg i feide_stubs.jar. Se cvs-modulen feide_stubs for detaljer.
URLene er bygget opp med tanke på at det skal være enkelt å splitte admin og user grensesnittene i to separate war filer. Et argument for å gjøre dette kan være at det kan anses å gi bedre sikkerhet.
Første del av URLen er /valg/. Under her ligger URLer for login/logout/locale (sistnevnte er endring av språk) som vil være tilgjengelig for alle brukere.
Alle admin sider befinner seg under /valg/admin/, mens alle bruker sider befinner seg under /valg/user/.
Alle admin-URLer sjekker rettigheter, men som en ekstra sikkerhets-sjekk, vil filteret no.uio.valg.CharsetFilter (referert i en <filter> seksjon i web.xml) stoppe vanlige brukere fra å nå admin sider.
Om du har behov for assistanse eller ikke forstår noe kan du sende en e-post til evalg-drift@usit.uio.no