Tilstandsløs web
Når du skal programmere web-applikationer til elektronisk handel og betaling, kræver det en styring af kommunikationen med brugerne. Web-applikationen skal holde styr på, hvilke brugere der udfører hvilke handlinger fra de har logget på systemet, til deres session er afsluttet. Det er nødvendigt at sikre, at den bruger der indledningsvis identificerede sig med navn og kode, er eksakt den samme person, der senere klikker OK til en handel til mange tusinde kroner.
Andre interaktive web-applikationer forudsætter også, at web-systemet har en snor i brugerne. Serveren skal vide, hvem der sender hvad i hvilken situation, for at kunne give eksakt respons på det. Men den succesfulde web-teknologi er ikke konstrueret til denne situation, hvilket betyder at programmørerne må finde teknikker til at løse opgaven.
Før vi viser tekniske løsninger, skal vi lige gøre problemet helt klart:
Udfordringen: Tilstandsløs web-kommunikation
Internettets web-protokoller er konstrueret til distribution af informationer. Med browseren sender brugerne forespørgsler til serverne, som returnerer web-sider. Brugerne sender en URL (Uniform Resource Locator), hvor du i din aktuelle browser kan læse URL'en på denne side: http://www.pcworld.dk/Default.asp?Mode=2&ArtikelID=2050
Web-protokollen HTTP fungerer som klient-server system, hvor klient og server arbejder uafhængige af hinanden. De to programmer kommunikerer, men der er ingen binding mellem dem. Web-systemet er tilstandsløst. Det betyder, at hverken browser eller server husker kommunikationens forløb. Når web-siden her er sendt til dig som læser, da har såvel server som browser i princippet glemt, hvad der skete. Der er ikke indbygget teknologi til at huske forløbet, for så vidt lider HTTP på sigt af total hukommelsestab.
Det globale succesfulde web-system skal nu bruges til elektronisk handel. Men handel kræver kontrolleret brugeradfærd, hvorfor vi skal gøre noget ved systemets tabte hukommelse. Ellers vil samtlige kunder kunne løbe fra regningen.
Brugerstyring
Brugerstyring
Der findes en række teknikker, som programmørerne kan bruge, når der skal holdes snor i brugerne og deres browsere. Alle disse teknikker kan for eksempel programmeres på Internet Information Server (IIS) med Visual Basic.
1. Brugeren indtaster oplysninger, som sendes til serveren
Som første led i en løsning starter vi med at få brugeren til at identificere sig med navn og evt. kode. Denne oplysning kontrollerer og gemmer serveren.
2. Cookies
Cookies er en tilføjelse til web-protokollen HTTP, hvor browseren gemmer en tekststreng med oplysninger om besøget på et web-sted. Den store fordel ved cookies er, at de kan overføres sikkert uden uvedkommendes indblanding. Det vil sige, de overføres over en krypteret forbindelse mellem browser og web-server. Som systemudvikler kan du udsende cookies, og på senere tidspunkt få browseren til at returnere oplysningerne. Disse omfatter web-adresse, dato samt en oplysning (kode). Dermed kan serveren identificere brugeren og hvor vedkommende var sidst.
Ulempen ved cookies er, at der er brugere, som afviser dem, fordi det krænker privatlivets fred. Der er også brugere, som jævnligt sletter deres cookies.
3. Du bruger sessions ID-numre og sessions objekter
Når en bruger sender forespørgsel til serveren, opretter den et session ID-nummer med et tilhørende sessions objekt. Dette ID-nummer kan bruges til at holde snor i brugeren, således at du kan følge vedkommende gennem forløbet. Det vil sige, at det sikres, at den bruger der kobler sig på med identifikation er den samme bruger, som afslutter en handel. Hvorefter de to oplysninger er koblet sammen.
En server som IIS giver alle sessioner unikke numre. Men sessions objektet gemmes kun i den tid, som brugeren er koblet på og 20 minutter efter sidste henvendelse. Det betyder, at teknikken ikke umiddelbart kan bruges i det lange løb henover mange sessioner.
Ulempen ved denne metode er, at sessions ID-nummeret sendes til browseren som en cookie. Teknikken kan anvendes til sessionsstyring, men den møder samme modstand som cookies.
4. Sessionsobjekterne gemmes i en database
Du kan gemme sessions objekterne permanent i en database. Det giver mulighed for at følge brugerne mellem deres sessioner. Den kortvarige fastholdelse af sessioner bliver her opbevaret på langt sigt. Arbejder du på et stort system med mange besøgende, bliver databasen stor og kræver tilsvarende stor maskinkraft.
5. Du bruger URL'en med supplerende oplysninger
Fordelen ved denne teknik er, at den er simpel. Du kan let opbygge en styring af et interaktivt forløb med brugerne. En version af teknikken ser du på disse sider, hvor der tilføjes data i URL'en, som angiver hvilken del af artiklen, du vil læse.
Ulempen ved teknikken er, at alle kan læse og kopiere URL'erne. Fortrolige oplysninger kan kodes, så de ikke bliver umiddelbart læselige. Du kan anvende hemmelige URL'er med koder. Men stadig vil det være let for uvedkommende at lave en simpel kopiering af URL'erne og benytte dem helt efter egen interesse. Serveren vil ikke have mulighed for at se, om afsenderen har taget URL'en illegalt, når den ankommer som en forespørgsel.
6. Skjulte felter til udveksling af informationer mellem server og browser
Dette er alternativ teknik til cookies. Men den teknik har ulempen, at oplysningerne ligger læsbart på brugerens maskine. Det er derfor ikke egnet til juridisk og økonomisk forpligtende oplysninger.
Tillid er bedst
Spørgsmålet om, hvor meget information serverne gemmer om brugerne og deres adfærd på web-stedet er et kontroversielt emne på Internet. Der findes en stor gruppe erklærede cookies-hadere på Internet. Derfor er den sikreste politik overfor brugerne, at du klart meddeler, hvilken information der gemmes om dem, og hvad det bruges til.
På den anden side har du ret til at stille krav til brugerne. Du kan designe systemet, så de ikke får adgang til vitale web-sider, hvis de ikke ønsker at identificere sig. Det vil naturligvis skræmme nogen væk.
Når vi er nået hertil, er det ikke længere et spørgsmål om teknik, men diskussion af etik, moralske normer og social adfærd på Internet.
