Emnet lagring af information er tidligere blevet beskrevet i denne bog. Persistent lagring af information er gennemgået i form af filer og databaser. Dette kapitel omhandler midlertidig lagring af information. Emnet er strejfet i tidligere kapitler – i dette kapitel bliver hele emnet imidlertid gennemgået fuldstændigt.

Alt efter situationen kan man ønske at lagre information på forskellige måder. Nogle oplysninger har lang gyldighed – eksempelvis en brugers navn. Andre oplysninger har kortere levetid – eksempelvis oplysninger om applikationens tilstand. Der er også oplysninger, som kun har interesse indenfor en enkelt session – det kan for eksempel være de valg, brugeren foretager på et web-sted.

I ASP findes der tre forskellige måder at lagre information på. Det er applikations- og sessionsvariable samt cookies. Mens applikations- og sessionsvariable er serverorienterede, bliver cookies opbevaret på klienten. Cookies er også den eneste af de lagringsmetoder, der bliver beskrevet i dette kapitel, som kan være persistente – browseren giver mulighed for at opbevare cookies på brugerens harddisk.

Sessionsbaseret lagring

Der er mange fordele ved at anvende den sessionsbaserede lagring. Når web-serveren selv håndterer sessionerne, er det en let måde at styre de oplysninger, der kun er gyldige inden for en session. Et typisk eksempel på dette er indkøbskurven på et e-handelssted. Her kan forskellige web-sider hver tilføje varer til den samme indkøbskurv. Samtidigt sikres det, at flere forskellige brugere kan tilgå web-stedet på samme tid uden at se hinandens indkøbskurv.

Der er imidlertid også en række ulemper ved den sessionsbaserede lagring. Den væsentligste er ironisk nok det, som i det ovenstående blev karakteriseret som en fordel. Det drejer sig om den automatiske håndtering af sessionerne. Web-serveren gør naturligvis sit bedste for at håndtere sessioner korrekt, men det er en særdeles vanskelig opgave. Som nævnt tidligere er HTTP-protokollen som udgangspunkt ikke sessionsbaseret. Det vil sige, at det er op til web-serveren selv at finde ud af det. Web-serveren har imidlertid ikke alle de oplysninger, der er nødvendige, for at kunne foretage en fuldstændig korrekt beslutning – derfor bliver den nogle gange nødt til at foretage et kvalificeret gæt.

Problemet er, at det er svært at sige, hvornår en session er afsluttet. Web-serveren får naturligvis besked, når der bliver hentet en side fra web-stedet – når det sker, er det sikkert, at sessionen ikke er afsluttet. Til gengæld får web-serven intet at vide, når der ikke længere bliver hentet sider – og af god grund. Hvis brugeren slukker for sit modem, når han har hentet den sidste side, er det svært for web-serveren at få at vide, at sessionen er afsluttet. I stedet bruger web-serveren det, der hedder timeout. Ved timeout definerer man et tidsrum, som brugeren skal være aktiv indenfor. Det kan eksempelvis være tyve minutter. Hvis der går mere end tyve minutter fra det tidspunkt, brugeren hentede den sidste side, bliver det bestemt, at sessionen er udløbet. Ulempen ved denne fremgangsmåde er, at det ikke er sikkert, at sessionen er afsluttet, blot fordi der er gået tyve minutter. Hvis brugeren arbejder på sin computer imens, kan der sagtens gå lang tid mellem sideforespørgslerne. Man kan også forestille sig, at brugeren er blevet forstyrret af gæster, telefonopringninger eller toiletbesøg.

Som det blev beskrevet tidligere, kan man i opsætningen af IIS angive, hvor stort timeout-intervallet skal være. Angiver man et for lille interval, risikerer man, at gyldige sessioner bliver ramt af timeout, selv om de reelt ikke er afsluttede, men sætter man derimod et stort interval, får man mange samtidige sessioner, da sessioner har lang varighed, og da det bruger en del hukommelse at opbevare alle sessionerne, belaster et stort timeout-interval serveren en del.

Implementering i ASP

Sessionsbaseret lagring af information foregår i ASP ved hjælp af de såkaldte sessionsvariable. Der findes i ASP et Session-objekt som indeholder sessionsvariablerne. Man sætter en sessionsvariabel ved at skrive

 

Session(“navn“) = værdi;

 

Hvis man i stedet vil læse værdien af sessionsvariablen, skriver man blot

 

Session(“navn“);

 

Hvis man således vil udskrive værdien af sessionsvariablen count, behøver man blot at skrive

 

<%=Session(“count”);%>

 

Applikationsbaseret lagring

Man kan også vælge at lagre information på applikationsbasis. Oplysninger, der  lagres på denne måde, vil være tilgængelige hele applikationens levetid. De oplysninger, man vælger at opbevare på denne måde, er typisk indstillinger om applikationen. Det kan eksempelvis være databaseadresser og anden opsætning.

Fordelen ved applikationsbaseret lagring er, at man kan nøjes med at opbevare oplysninger et sted, hvor de kan tilgås af ASP-programmer i alle sessioner. Ved kun at opbevare dataene et sted, sparer man hukommelse på web-serveren – plads som man i stedet kan bruge til at håndtere flere sessioner samtidigt og derved give brugerne kortere svartider.

Selv om en af de store fordele ved applikationsbaseret lagring således er, at dataene opbevares et sted, er dette også en af de største ulemper. Hvis man har mange aktive sessioner samtidigt, risikerer man, at sessionerne læser og ændrer applikationsvariablerne samtidigt. Man kan eksempelvis forestille sig nedenstående ASP-dokument, der bliver udført i to sessioner samtidigt.

 

Læs applikationsvariablen A

Læg en til applikationsvariablen A

Gem værdien i applikationsvariablen A

 

Da web-servere sjældent har ligeså mange processorer, som der er samtidige sessioner, bliver ASP-kode fra flere sessioner afviklet på samme tid. Det betyder, at man ikke kan være sikker på, at en session bliver afviklet færdig, før den næste bliver afviklet. Hvis ASP-programmet fra ovenstående eksempel bliver hentet i to forskellige sessioner på samme tid, kan programlinierne blive afviklet i nedenstående rækkefølge. Det antages, at applikationsvariablen A ved start har værdien 2.

 

Session 1: Læs applikationsvariablen A (A er 2)

Session 2: Læs applikationsvariablen A (A er 2)

Session 2: Læg 1 til applikationsvariablen A (hvilket giver værdien 3)

Session 2: Gem værdien i applikationsvariablen A (A er nu 3)

Session 1: Læg 1 til applikationsvariablen A (Session 1 har tidligere læst A til at være 2, og resultatet af denne beregning er derfor 3)

Session 1: Gem værdien i applikationsvariablen A (A er nu 3)

 

Resultatet af de 2 sessioner er således, at applikationsvariablen A får værdien 3, selv om det jo er tydeligt, at den skulle have haft værdien 4.

Dette problem kaldes en race condition. En race condition opstår, når to eller flere sessioner forsøger at ændre de samme variabler samtidigt, og resultatet kommer an på den rækkefølge, sessionerne blev afviklet i. Som det ses, skal race conditions undgås.

I ASP er der mekanismer til at undgå disse problemer. Man kan låse applikationsvariablerne, så man forhindrer andre sessioner i at tilgå dem samtidigt. Når der kun er en session, som kan ændre variablerne ad gangen, er der ingen problemer. Man er således sikker på den rækkefølge sessionerne bliver afviklet i. Nedenstående eksempel viser, hvilken rækkefølge man er garanteret, at ovenstående eksempel bliver afviklet i.

 

Session 1: Lås applikationsvariablerne

Session 1: Læs applikationsvariablen A (A er 2)

Session 1: Læg 1 til applikationsvariablen A (hvilket giver værdien 3)

Session 1: Gem værdien i applikationsvariablen A (A er nu 3)

Session 1: Frigiv applikationsvariablerne

Session 2: Lås applikationsvariablerne

Session 2: Læs applikationsvariablen A (A er 3)

Session 2: Læg 1 til applikationsvariablen A (hvilket giver værdien 4)

Session 2: Gem værdien i applikationsvariablen A (A er nu 4)

Session 2: Frigiv applikationsvariablerne

 

Som det ses, får A nu den rigtige værdi: 4.

Man skal dog være påpasselig med at låse applikationsvariablerne. Når de er låst, er det ikke muligt for andre sessioner at tilgå dem, og man kan derfor risikere, at en lang række sessioner ikke kan afsluttes, fordi en session har låst applikationsvariablerne. Man skal derfor aldrig låse applikationsvariablerne i længere tid end højst nødvendigt. Hvis programmet tillader det, kan man med fordel lægge alle sine referencer til applikationsvariablerne i samme blok, og derved nøjes med at låse dem en gang.

Implementering i ASP

Applikationsvariabler håndteres på stort set samme måde som sessionsvariabler. I stedet for at skrive Session(“navn“) skriver man blot Application(“navn“). Det betyder, at man kan sætte en applikationsvariabels værdi ved at skrive

 

Application(“navn“) = værdi;

 

Ligeledes kan man læse en applikationsvariabels værdi ved at skrive

 

Application(“navn“);

 

En forskel fra sessionsvariablerne er det dog, at man har mulighed for at låse applikationsvariablerne, som det blev beskrevet i forrige afsnit. For at låse applikationsvariablerne skriver man

 

Application.Lock();

 

mens man for at frigive dem skriver

 

Application.Unlock();

 

Et eksempel, der viser, hvordan man optæller og udskriver en applikationsvariabel, kan altså se således ud:

 

Application.Lock();

tal = Application(“Tal”);

tal++;

Application(“Tal”) = tal;

Application.Unlock();

Cookies

Den sidste form for lagring af oplysninger, der bliver beskrevet i dette kapitel, er cookies. Cookies er udviklet af Netscape og er en teknologi, der gør det muligt at opbevare oplysninger på brugerens computer. Når man anvender ASP, som er server-baseret, kan det virke underligt, at man skal opbevare oplysninger på brugerens computer, men selv om der kan være mange uhensigtsmæssigheder ved at anvende cookies, giver de også nogle muligheder, man ellers ikke har.

Anvendelse af cookies består af to opgaver. At sætte cookien og at læse cookien. Når man sætter en cookie, tildeler man den en værdi, og man gemmer den på brugerens harddisk. Når man læser en cookie, læser man værdien af en cookie, der tidligere er sat. Har man sat en cookie på en brugers harddisk, bliver denne automatisk sendt af browseren, når brugeren igen besøger det samme web-sted. Det skal bemærkes, at et web-sted kun får tilsendt de cookies, det selv har sat – man kan altså ikke se de oplysninger, andre web-steder har sat.

Som nævnt gør cookies det muligt at gemme oplysninger på brugerens computer. Ved at gemme en unik identificering af brugeren i en cookie på dennes computer, kan man – ved at læse cookien igen – genkende brugeren. Dette kan man bruge til at lave en forholdsvis avanceret profil af brugeren. Man kender måske ikke brugerens navn eller e-mail-adresse, men ved at holde øje med, hvilke sider brugeren besøger på web-stedet, kan man danne sig et indtryk af, hvilke interesser vedkommende har. Driver man eksempelvis en søgemaskine eller en online-avis, kan man lære mange ting om en bruger ved henholdsvis at studere, hvilke ord, brugeren søger på, og hvilke artikler brugeren læser. Denne fremgangsmåde er meget anvendt indenfor markedsføring, og blandt andet bannerreklamevirksomheden DoubleClick anvender den.

Der findes imidlertid også en lang række andre anvendelser for cookies. Hvis man eksempelvis tilbyder e-handel på sit web-sted, kan det være interessant at give brugeren mulighed for at gemme sin indkøbskurv lokalt, så de valgte varer også vil være valgt næste gang, brugeren besøger web-stedet. Man kan også give brugeren mulighed for at gemme nogle indstillinger, så man eksempelvis er fri for at vælge mellem forskellige sprog, frames og lignende hver gang siden besøges.

Selv om mulighederne ved cookies således er mange, skal man dog være opmærksom på ulemperne. Både Internet Explorer og Netscape Navigator understøtter cookies – og endda på samme måde – så man skulle tro, at man roligt kunne bruge dem i sikker forvisning om, at de blev accepteret af browseren. Sådan er det imidlertid ikke. Begge browsere giver brugeren mulighed for at slå cookies fra, hvilket vil betyde, at en side, der anvender cookies ikke vil virke. Man kan sagtens sætte cookies, men de bliver ikke gemt på brugerens computer, hvilket betyder, at de ikke bliver sendt, når siden igen besøges. Dette medfører, at cookien ikke kan læses.

Det er ikke helt klart, hvor mange brugere der har slået cookie-muligheden fra i deres browser, og tallet varierer meget. Med jævne mellemrum dukker der en historie op om, at cookies udgør en sikkerhedsrisiko, og at alle ansvarlige Internet-brugere derfor bør slå dem fra. Sådan er sandheden imidlertid ikke. Cookies er en lille mængde data, som et web-sted kan bede browseren opbevare på brugerens harddisk. Det er browseren, der bestemmer placeringen af dataene, ligesom det er browseren, der bestemmer navnet på den fil, oplysningerne gemmes i. Derudover bliver dataene blot gemt – de bliver ikke udført, og det er således ikke muligt at overføre virus gennem en cookie. Når cookien sendes til web-stedet igen, er det browseren, der sender cookien. Det vil sige, at det udelukkende er browseren, der bestemmer, hvilke oplysninger der sendes til web-stedet. Cookies kan altså heller ikke bruges til at tappe oplysninger fra en brugers computer. Der er således ingen grund til at frygte cookies eller at slå funktionen fra i sin browser.

Set i lyset af ovenstående er det – som altid – en god ide at fortælle brugeren, hvad man gør. Anvender man cookies, bør man derfor have en sektion på sit web-sted, der beskriver, hvad man bruger cookies til – og måske også, hvad man ikke bruger dem til.

Der findes flere forskellige former for cookies. Man kan vælge at skelne mellem persistente og temporære cookies, men man kan også opdele cookies efter, hvilken web-sider, der modtager dem – dette bliver beskrevet senere i dette afsnit.

Forskellen på en temporær og en persistent cookie er deres levetid. En temporær cookie lever kun, mens browseren er åben – når browseren lukkes, bliver cookien slettet. Anvender man i stedet en persistent cookie, bliver cookien gemt på disk, når browseren lukkes. Persistente cookies lever dog ikke for evigt – man skal angive et udløbstidspunkt, hvorefter cookien ikke længere er gyldig. Når en cookie ikke er gyldig, vil den ikke blive sendt til web-stedet.

Som det blev antydet tidligere, kan man også angive, hvilke web-sider der skal modtage en bestemt cookie. Man kan vælge mellem at lade cookien være tilgængelig for alle sider på web-stedet eller blot for sider i et bestemt katalog på web-serveren. Med denne opdeling kan man håndtere flere seperate applikationer på det samme web-sted. Har man eksempelvis en hjemmeside på et domæne, der indeholder flere web-steder (som det for eksempel er tilfældet med de fleste private Internet-udbydere som TeleDanmark, CyberCity og lignende), er det godt at sikre, at det kun er ens egen sider, der kan læse de cookies, man sætter.

Implementering i ASP

Implementeringen af cookies i ASP afspejler de to opgaver, der blev beskrevet tidligere: at sætte en cookie og at læse en cookie. Når en cookie skal sættes, bruger man Response­-objektet, mens man bruger Request-objektet, når man vil læse en cookie. Denne opdeling er ganske naturlig, når man tænker på, at de cookies, der skal læses, bliver sendt sammen med forespørgslen til web-serveren. Derfor er det Request-objektet, som indeholder de cookies, der allerede er sat. Ligeledes skal de cookies, man vil sætte, sendes tilbage til browseren, og derfor er det logisk, at det er Response-objektet, der sørger for at sætte dem.

Begge objekter indeholder en samling ved navn Cookies. Skal man sætte en cookie, gør man det ved at skrive

 

Response.Cookies(“navn“) = værdi;

 

Navn er navnet på cookien – dette navn skal man bruge, når man en anden gang skal have cookiens værdi. Værdi er en tekststreng, der indeholder de data, der skal gemmes i cookien.

Ønsker man en persistent cookie, skal man angive et udløbstidspunkt. Det gør man ved at sætte den variabel, der hedder expires. Ethvert element i Cookies-samlingen indeholder en variabel ved navn expires, som angiver udløbstidspunktet for hver enkelt cookie. For at angive en cookies udløbstidspunkt skriver man

 

Response.Cookies(“navn“).expires = dato;

 

Det blev også beskrevet i foregående afsnit, at man kan angive, hvilke web-sider cookien skal være tilgængelig for. Det gør man med variablerne domain og path. Ligesom expires-variablen findes domain og path for alle cookies i samlingen. Domain angiver det domæne, cookien skal være tilgængelig på. Det vil typisk være adressen på web-stedet – eksempelvis www.tekniskforlag.dk. Path angiver den sti, cookien skal være tilgængelig i. Ønsker man, at cookien skal være tilgængelig for alle filer, der ligger i kataloget /bog på www.tekniskforlag.dk, skal man altså sætte Domain til tekststrengen www.tekniskforlag.dk¸ mens Path-variablen skal sættes til strengen /bog. Nedenstående eksempel viser den ASP-kode, der gør dette.

 

Response.Cookies(“mincookie”) = “test”;

Response.Cookies(“mincookie”).Path = “/bog”;

Response.Cookies(“mincookie”).Domain = “www.tekniskforlag.dk”;

 

Læsning af cookies sker som nævnt gennem Request-objektet. For at læse værdien af en cookie skriver man blot

 

Request.Cookies(“navn“);

 

Navn skal være det navn, man brugte, da cookien blev sat. Vil man udskrive værdien af cookien navn, skriver man altså blot

 

<%=Request.Cookies(“navn”);%>

Sammenfatning

I dette kapitel er forskellige former for opbevaring af data blevet gennemgået.

Gennemgangen har omfattet serverbaseret lagring af henholdsvis sessions- og applikationsbaserede oplysninger samt lagring af oplysninger på klienten ved hjælp af cookies.

Selv om sessions- og applikationsorienterede oplysninger behandles på stort set samme måde, skal man være opmærksom på, at det kan være nødvendigt at låse applikationsvariable, før de anvendes.

Klientbaseret opbevaring med cookies kan bruges til at genkende brugeren og samle oplysninger om vedkommende.