Understøttelse af sessions med SP2

sessions understøttes altid, men det kan være at du på serveren skal sætte den til at køre cookieless hvis, da det kræver et SessionID at kunne skelne de forskellige sessions fra hinanden. Normalt bliver det gemt i en cookie, men ved at køre cookieless bliver id'et appendet til url'en.

Jeg har ikke mulighed for at bruge cookieless session på det pågældende site. Kun ved at hjemmelave den gennem ApplicationCache.

Kan jeg ændre på serverens indstillinger så almindelige cookie sessions fungerer?

det er ikke serverens problem om klientent vil acceptere session cookies..

Men hvorfor har du ikke mulighed for "sessionless cookies"?

Jeg skal kunne bruge Page.Session-objektet direkte som det er, og der må ikke laves noget om i applikationen noget sted - såsom en querystring variabel eller et hidden field.

Jeg ved godt der er alternativer til .NET's standard session cookies, men det er ikke det dette spørgsmål handler om.

sessionless virker ved at IIS sætter sessionID ind i URLen på exp (denne side) ville det blive noget ala www.experten.dk/$aspsession=a5a6b6h66e/spm/591986

IIS'en tager sig af det

og du burde IKKE skulle lave noget om på din applikation for at implementere det.

Men det er jo nemt at afprøve

Jeg sætter meget stor pris på al den kreativitet og velvilje, men det har desværre ingen interesse. Selvom IIS'en tager sig af det, er der nogle ganske specielle forhold i applikationen der gør, at det ikke kan lade sig gøre med den slags variabler.

Det er derfor jeg ikke er interesseret i alternativer til cookie sessions. Jeg ville bare høre om det virkelig kunne passe at standard-indstillingerne i SP2 gør at almindelige cookie sessions ikke fungerer.

"variabler"?

det er ikke en querystring det er et "ekstra" directory, der bliver tilføjet og fjernet, inden din applikation...

Det kan være at du godt ved det, men alligevel...

IE's standardindstillinger er IKKE at gemme cookies der er unikke, i længere tid en browseren er åben (f.eks. userID), jeg tror ikke at SP2 er nogen forskel men, den opgradere browseren, og tit "nulstiller" opdateringer bl.a. sikkerhedsindstillinger.
IE vil dog godt acceptere "session" cookies dvs. cookies der ikke bliver GEMT på din computer, medmindre du laver en w3c policy...

;o)

Ja, jeg ved godt i store træk hvordan det virker med cookieless session.

Vi roder lidt rundt med begreberne session cookie og cookie session. De "sessions" du snakker om her til sidst, er det dem som er som standard i ASP.NET når man tilgår Session-objektet?

nielsbrinch>> der er ikke noget der hedder cookiesessions. En cookie er en cookie, længe er den ikke. Og og cookie slået fra i browseren, så er cookie slået fra... end of deal, slut prut finale, badabim badabum, finito... du får ikke mere får den 25 øre.

Og hvis det er tilfældet, og du ikke vil bruge cookieless sessions, så er du rimelig meget på skideren, på herrens mark, left on your own.

<sessionState mode="InProc" cookieless="true" timeout="20" />

Ovenstående i din web.config, og du er kørende... men det er op til dig.

Jeg kan desværre ikke bruge cookieless. Min definition af cookie sessions er en session hvor den unikke nøgle til denne session, gemmes i en cookie på brugerens computer.

Er cookie slået fra i browseren som udgangspunkt, ved en ren installation af Windows XP SP2 og Internet Explorer 6?

cyberfessor -> IE har en indstilling der hedder vedvarende bruger data, dvs. GEMTE cookies..
Hvis du i asp gør flg
response.cookies("test") = "1"

har du en cookie så langtid du har din browser åben
men hvis du skriver
response.cookies("test") = "1"
response.cookies("test").Expires = "2010-01-01"

vil den først blive slettet fra din hd i år 2010

Der står her i min IE (som default)

Blocks third-party cookies that do not have a compact privacy policy
Blocks third-party cookies that use peronally identifiable information without your implicit consent
Restrict forst-pary cookies that use personally identifiaable information without implicit consent

Om den blokerer en den cookie der skal bruges for at session kan fungere har jeg  ikke selv haft problemer med, men det skulle da ikke undre mig at den kunne finde på det.

a1>> og ?

hvis cookie slet ikke er tilladte vil hverken det første eller andet eksempel virke.

lader forresten til at de har indført ordet Session Cookie i IE6. Under privacy>advanced kan man sætte et flueben i "Always allow session cookies"

og deres definition af det er "a temporary cookie that is deleted when your internet explorer is closed". Det er jo også rigtig nok, men hvorfor ikke bare kalde det en cookie, som det jo er.

Men never the less tror jeg nu nok vi allesammen er nogenlunde enige om hvad der bliver snakket om her. Jeg kan dog ikke forstå, hvorfor at spørgsmålet ikke er blevet stillet i Internet Explorer-kategorien (http://www.eksperten.dk/spm/Programmer/Browsere/Internet-Explorer/), når det tydeligvis intet har med programmering at gøre, og at niels heller ikke er åben for løsningen på session-problemet når clientet ikke godtager cookies.

vedvarende brugerdata (på dansk) ? ? ? ? ?

;o)

Jeg oprettede spørgsmålet i denne kategori, fordi jeg var ude efter netop den måde at håndtere session på, som .NET gør som standard. Jeg ved ikke definitivt hvad praksis er blandt alle de andre programmeringssprog - på den måde håbede jeg at undgå at der skulle blive tvivl om hvilken type session jeg mente.

Det lykkedes ikke helt :-)

Mange tak for jeres velvilje, begge to. Hyg.

cookies har ikke meget med .net at gøre det er en "http://" ting, som .net understøtter

Ja. Hvis det ellers er slået til i browseren.

mig bekendt er det standard blandt alle websprog at hver session har et unikt id, og det unikke id bliver gemt enten ved

1) en cookie i clientens browser
2) eller som en del af url'en

hvorfor man ikke bare sætter det ind som et hidden input på siden? Well, måske fordi at ikke alle sider har en form.

Ovenstående er vitterlig de eneste to måde hvorpå man kan gemme id'et mellem request, og hvis du kommer op med en tredie måde vil jeg meget gerne høre om den :)

cookies=sessions hvis vi snakker webapplikationer, og nu er spm. oprettet i asp.net
;o)

man kan sagtens have cookies uden at oprette en session, og omvendt... så hvad mener du med

cookies = sessions

?

Jeg tror det er normen at styre session ved hjælp af en cookie-variabel. Det er derfor ASP.NET understøtter det som standard.

som programmør kan man være fuldstænding hamrende fløjtende ligeglad, så jeg kan ikke se hvad du mener med at det skulle være nemmere?

Alle sprog bruger cookies som standard, da der kan være en sikkerhedsrisici ved cookieless sessions.

Hvis jeg er inde på et site hvor mit sessionid står i url'en, og jeg gerne vil vise dig den side jeg er inde på vil jeg normalt markere hele url'en og sende den til dig. Men hov, nu sender jeg dog også mit sessionid, hvilket betyder at du kan se siden med min session. Så hvis jeg nu var logget ind som admin, så vil du også være det.

Jeg har ikke skrevet noget om, hvad der er nemmest.

Men det er sikkert de sikkerhedsproblemer du beskriver, som er årsagen til at det er normen at bruge cookie sessions.

yearh, sorry.. det er bare mig der tror at normen er det samme som nemmest...

jeg kan dog ikke se hvordan man skulle kunne have en webapplikation som ikke kan benytte cookieless sessions.

Der er så tilpas mange skumle teknologier i applikationen at jeg mener der er en temmelig høj risiko for at det ikke fungerer - jeg kan desværre ikke beskrive det mere detaljeret.

Der skal bruges mange ressourcer på at teste, så jeg skal lige overveje det lidt før jeg kaster mig ud i en løsning som jeg anser for at have høj risiko. Men du skal have mange tak for hjælpen.

:) nu skal man jo aldrig sige aldrig, men det er jo lavet på en sådan måde, at man kan skifte mellem cookieless="true/false" som man lyster uden at det skal gøre ens webapplikation ubrugelig.

Jeg har i hvert fald aldrig selv har problemer med det. Asp.net sørger selv for at appende sessionid'et til ALLE dine links, så man som programmør ikke skal tænke på om det er det ene eller det andet der bruges.

Men det kan jo være der er bugs i det.

Hardkodede links i HTML, JavaScript som genererer HTML links etc.etc..

En større web applikation som ikke er testet med URL rewriting har stor sandsynelighed
for at der er et eller andet som ikke virker fordi en programmør er sprunget over hvor
gærdet er lavest.

asp.net har lavet det smarte at sessionid'et bliver en del af selve url'en og ikke som querystring

f.eks.

http://localhost/WebApplication1/(uwvgovu0hljrmdqcl1aajf2f)/WebForm1.aspx

så der burde ikke være samme typer problemer som med den måde php gør det på (querystring)

men det er rigtigt, at hvis man har links som er hardcodet som

http://localhost/WebApplication1/WebForm1.aspx

og ikke

WebForm1.aspx

virker det ikke...

men helt ærligt, så har man også selv bedt om problemer :P

Jeg tror du har ret i at nogle problemer omgås ved at den er i selve urlen i stedet for querystring. Men der er tale om applikation som i høj grad passer på den beskrivelse arne_v giver.

Det er alle absolutte URL'er som giver problemer.

Og vi kan godt blive enige om hvad man bør gøre.

Men hvis vi snakker store applikationer hvor der er mange programmører på, så følger
det af Murphys lov at mindst en af ikke er opmærksom på det eller lige skal
lave noget smart eller ...

Og hvis ikke QA tester applikationen med cookies slået fra og tvinger programmørerne
til at rette alle hovsaerne, så bliver den sat i drift uden at kunne fungere
med URL rewriting.

Jeg vil hævde det også kan være tilfældet, hvis forholdene byder det. F.eks. hvis applikationen skal være tæt integreret med andre applikationer som er ufleksible.

Jeg kunne godt forestille mig at et relativt link til en PHP side med den
URL rewriting style kunne give nogle problemer.