07. juli 2003 - 09:34Der er
18 kommentarer og 2 løsninger
Session, cookie eller andet til fastholdelse af valg af portal
Hi, Et website er opdelt i to afdelinger (portaler) alt efter om man er studerende eller underviser. Nogle af funktionerne på sitet er fælles for de to portaler (søgefunktion, bestillinsformular, kontaktformular, visse db udtræk) for at undgå redundans i systemet. Valget af portal påvirker hele menusystemet og i nogle tilfælde også hvilke records der skal trækkes ud af db tabellerne.
Jeg har overvejet hvilken metode er den bedste til at fastholde portalen.
Umiddelbart synes det fordelagtigt at anvende session objektet, men en afgørende ulempe ved denne er timeout - hvis man 'timer out' på en af de fælles sider vil der hurtigt kunne opstå forvirring, da menusystem og db udtræk pludselig ændrer sig (og vender tilbage til nogle default værdier). Man kan selvfølgelig angive en urimelig lang timeout tid, men det giver en unødig belastning af serveren.
En anden mulighed er naturligvis cookies, og så lade en evt. cookie afgøre hvilken portal man havner i. Det er dog heller ikke optimal, da brugere der fravælger cookies ikke rigtig får så meget ud af siderne ;-) Desuden kan det give en lidt uhensigtsmæssig oplevelse hvis man som underviser anvender en PC hvorpå der ligger en 'studenter-småkage'.
Er der nogen der kan udtænke en bedre plan. En betingelse er naturligvis at siderne virker hvis man linker til specifikke sider i enten den ene eller den anden portal?
Knock yourself out. Da dette ikke er et specifik problem, men måske kan løses på forskellig vis vil et hvert konstruktiv svar belønnes med lidt point fra kassen ;-)
AI bliver først for alvor en del af arbejdet, når teknologien integreres i den måde, vi arbejder på. At have adgang til AI betyder ikke nødvendigvis, at medarbejderne er klar til at bruge den.
Jeg ville bruge cookies. Hvis cookies ikke er slået til, vil sessions alligevel ikke virke hos den bruger alligevel.
Hvis du lader være med at sætte en expires værdi til cookien, vil den slette sig selv igen så snart browser vinduet lukkes.
En anden og måske bedre idé er at bruge querystringen... smid et &sidetype=student i alle dine links, og brug request.querystring("sidetype") til at checke hvad for en side brugeren leder efter. dette vil være ret optimalt, da dataene altid gemmes, men aldrig bliver der til læreren :p
cesil: Nu er der ingen loginside da det hele er offentlig, men ja, jeg kunne redirecte til index siden, hvor der naturligvis er mulighed for at vælge portal (og hvor det bliver forklaret hvorfor der er to portaler). Men hvis der ingen cookie er og man henter en specifik side i et af systemerne vil man blive redirected til index siden og systemet opfører sig således ikke som brugeren forventer.
tuctoh: cookie modellen lyder tiltalende - jeg havde ikke lige tænkt over at cookien jo bliver slettet når brugeren lukker browseren ned. Så på hver side tjekker man om der er en cookie og hvis der ikke er oprettes en alt efter hvilken portal man er inde på. Går man direkte ind på en side der er fælles for de to portaler får man blot default menuen med default db udtræk (og man får muligheden for at vælge portal. Men der er stadig et problem ift. brugere der fravælger cookies (som jeg fx gør nogle gang). IE brugere har jo muligheden for at tillade session cookies som default men blive adviseret om fil cookies. Sådan er mit system sat op - deraf tanken om at kombinere de to modeller.
Querystring modellen vil jeg helst undgå - jeg kan ikke fordrage grimme URL'er ;-) Desuden synes jeg det er lidt bøvlet at skulle give en querystring til samtlig url'er i systemet.
cesil: det er begge dele rigtigt, men jeg skal stadig påsætte en qs i hvert eneste link i systemet. Hvorvidt der skal tjekkes for en cookie, en session eller en qs betyder ikke det helt store.
Men ja, metoden er rimelig bulletproof. Jeg vil veje den op imod cookie modellen (eller måske kombinere de to).
tuctoh og cesil: TAK for kommentarerne - det var bestemt brugbart! Jeg lader nu lige spørgsmålet stå åbent resten af dagen i fald der skulle være flere der vil byde ind (eller I har flere kommentarer). /Lars
tuctoh: hvis man ikke sætter nogen expires, opfattes den pågældende cookie så ikke som en session cookie? Og vil den først expire i det øjeblik browseren lukkes eller er der en standardtid på den lige som det "almindelig" Session() objekt?
tuctoh: hm, min browser er sat op til at prompte hvis der kommer en småkage flyvende, men den fanger ikke den her - med mindre jeg sætter expires, så får jeg en prompt! Så det er heller ikke en normal cookie...?
nej, det er ikke en helt normal cookie... men det er heller ikke en direkte session.
Men prøv da selv, sæt noget data i cookien, og lad vinduet være åbent... se en time efter, og dataene er der stadig. Hvis du lukker vinduet ned, og åbner det igen er dateene væk.
Det er nu ikke fordi jeg ikke tror på det du skriver er sandt - beklager hvis jeg har har givet det indtryk. Jeg forsøger blot at finde ud af hvordan denne type cookie opfører sig. /Lars
tuctoh: jeg fornemmer en vis kompetence om ASP programmering fra din side - kig engang på spm. 374140 - der er flere gode points at hente ;-) /Lars
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
