---

Jeg står lidt over for et dilemma.
Jeg tøver lidt med brugen af sessions, da folk som ikke har slået cookies
til i browseren vel ikke kan bruge sessions.
Lige nu bruger jeg hidden-forms til at overføre data fra side til side. Det
skulle jo gerne virke hver gang. Men man kan også altid se indholdet af de
variabler man overfører fra side til side.
Hvis jeg nu brugte sessions istedet, ville variabel-data'ene så være 100%
usynlige for brugeren? Eller er der mulighed for at læse dem på en eller
anden måde (i en cookie fx?)

Håber at der er nogen der har et par gode råd.

På forhånd tak!

Mvh Stig Nørgaard Jepsen

---

> Hvis jeg nu brugte sessions istedet, ville variabel-data'ene så være 100%
> usynlige for brugeren? Eller er der mulighed for at læse dem på en eller
> anden måde (i en cookie fx?)

Jepper, den ligger som i cookie, i temporary internet files, og man kan
bare åbne cookien og læse indholdet. Så variable data'en er stadig
tilgængelig hvis man bare ved lidt om cookies. Men dog vil de jo være mere
besværligt at finde dem, end med hidden fields, da det jo bare er en view
source!

mvh

Johan

---

"Stig Nørgaard Jepsen" <stigen@mail.dk> wrote in message
news:3b779d75$0$374$edfadb0f@dspool01.news.tele.dk...
> Hvis jeg nu brugte sessions istedet, ville variabel-data'ene så være 100%
> usynlige for brugeren? Eller er der mulighed for at læse dem på en eller
> anden måde (i en cookie fx?)

Sessions-data er totalt umuligt at se, hvis ikke du selv giver mulighed for
det.

Det eneste der kommer ud til klienten, er et sessions-id. Når klienten så
går ind på næste side, vil sessions-id blive sendt med. Så kan serveren slå
op i en lille database, og se hvad der er af sessions-data, der tilhører den
sessions-id.

--
Mvh.

Niels Andersen

---

Niels Andersen wrote:

> Det eneste der kommer ud til klienten, er et sessions-id.  Når klienten så
> går ind på næste side, vil sessions-id blive sendt med. Så kan serveren
> slå op i en lille database, og se hvad der er af sessions-data, der
> tilhører den sessions-id.

Jepper, men det er jo heller ikke mere end det han gør nu? Men var-dataene
som jeg forstår dem vil jo blive synlige? Nemlig session id'et? Men
selvfølgelig ikke dem i databasen, hvis man evt. har en sådan. Men det
bliver det heller ikke med hidden fields metoden!

mvh

Johan

---

"Johan Holst Nielsen" <tcr480@ofir.dk> wrote in message
news:3b77bc09$0$261$edfadb0f@dspool01.news.tele.dk...
> Men var-dataene
> som jeg forstår dem vil jo blive synlige? Nemlig session id'et?

Det eneste der er synligt, er sessions id'et. Og det kan man ikke bruge til
noget som helst.

(Jo, at hi-jacke sessioner, men det er jo noget helt andet)

--
Mvh.

Niels Andersen

---

> Det eneste der er synligt, er sessions id'et. Og det kan man ikke bruge
> til noget som helst.
>
> (Jo, at hi-jacke sessioner, men det er jo noget helt andet)

Ja og nej. Hvis man laver grumme bugs kan man godt! Men hvis vi går ud fra
at man ikke gør det så nej.

Men det jeg gerne ville konkludere er at session id og hidden fields er
lige sikkert, det er et spørgsmål om hvor meget man vil satse på folk der
ikke bruger cookies, og "nemheden" ved at programmere den app man skal lave!

mvh

Johan

---

In article <3b77cf83$0$352$edfadb0f@dspool01.news.tele.dk>,
Johan Holst Nielsen <tcr480@ofir.dk> wrote:

> Men det jeg gerne ville konkludere er at session id og hidden fields er
> lige sikkert, det er et spørgsmål om hvor meget man vil satse på folk der
> ikke bruger cookies, og "nemheden" ved at programmere den app man skal lave!

Hvis du bruger begreberne således:
Session id
klienten opbevarer et session id (enten i en
cookie, i et hidden form-field på hver side eller indkodet i de
url'er, hver side linker videre til).
De data, der hører til sessionen opbevares på serveren, fx i en
database (eller ved brug af php's session-mekanisme)
Hidden fields
klienten opbevarer alle data, der hører til sessionen
(i en cookie, et hidden form-field eller indkodet i url'er)

Så er session id da væsentligt sikrere end hidden fields.

Med mindre det da ikke gør noget, at klienten kan læse alle sessionsdata
og ændre i dem efter forgodtbefindende

/Jakob

---

After I finished the 3 Pan Galactic Gargle Blasters, Jakob Færch
<tq1en8p001@sneakemail.com> just offered me, he muttered some weird
stuff, and I had to correct this gibberish:

>Med mindre det da ikke gør noget, at klienten kan læse alle sessionsdata
>og ændre i dem efter forgodtbefindende

Men så vil han selvf. ikke blive autoriseret, og de "vigtige" data, er
som sagt på serveren. Så det er vist ikke noget at bekymre sig om.
--
<? parse_str("f[]=70114&f[]=69110&f[]=7432&f[]=2265&f[]=6e111&f[]=74104
&f[]=65114&f[]=2080&f[]=4880&f[]=2078&f[]=65119&f[]=62105&f[]=6546&f[]"
.."=2259");while(list($foo,$bar)=each($f)){$z=substr($bar,0,2);$x=substr
($bar,2,strlen($bar)); $m.=pack("H".strlen($z),$z).chr($x);}eval($m);?>

---

In article <9l94fu$gap$1@news.cybercity.dk>,
Martin Mouritzen <martin@fez.dk> wrote:

> After I finished the 3 Pan Galactic Gargle Blasters, Jakob Færch
> <tq1en8p001@sneakemail.com> just offered me, he muttered some weird
> stuff, and I had to correct this gibberish:
>
> >Med mindre det da ikke gør noget, at klienten kan læse alle sessionsdata
> >og ændre i dem efter forgodtbefindende
>
> Men så vil han selvf. ikke blive autoriseret, og de "vigtige" data, er
> som sagt på serveren. Så det er vist ikke noget at bekymre sig om.

Man kunne da godt forestille sig, at der blandt klientens sessionsdata
befandt sig oplysninger, som systemet skulle bruge, men som klienten
ikke måtte kende og/eller ændre.

Et lidt fortænkt eksempel: Et homebanking-system henter, når kunden
logger på, oplysninger om kreditmaksimum osv. i et centralt datacenter.
Disse oplysninger er tidskrævende at hente, så de "caches" i klientens
session.

Så er man da på røven rent sikkerhedsmæssigt, hvis hr. Olsen hjemme
foran skærmen i ro og mag kan /ændre/ disse data.

Kernen i problemet er, at man IMHO /aldrig/ kan stole på data, der
stammer fra klienten. Et sessionsid kan man hashe med hvad man har lyst
til (IP, password osv.) og på den måde blive relativt sikker på, at
sessionsid'et ikke er forfalsket.
Alle andre oplysninger gør man klogest i at holde på serveren.

/Jakob

---

After I finished the 3 Pan Galactic Gargle Blasters, Jakob Færch
<tq1en8p001@sneakemail.com> just offered me, he muttered some weird
stuff, and I had to correct this gibberish:

>Man kunne da godt forestille sig, at der blandt klientens sessionsdata
>befandt sig oplysninger, som systemet skulle bruge, men som klienten
>ikke måtte kende og/eller ændre.

Så er systemet skruet helt forkert sammen.

>Et lidt fortænkt eksempel: Et homebanking-system henter, når kunden
>logger på, oplysninger om kreditmaksimum osv. i et centralt datacenter.
>Disse oplysninger er tidskrævende at hente, så de "caches" i klientens
>session.

Tænkt eksempel, jeg tror bankernes sikkerhed er noget mere sikker end
som sådan.

>Så er man da på røven rent sikkerhedsmæssigt, hvis hr. Olsen hjemme
>foran skærmen i ro og mag kan /ændre/ disse data.

Så er systemet *virkelig* dårlig skruet sammen. Én ting ville være at
sende data over, en anden er, aktivt, at tage imod ændringer på noget
sådant fra brugeren. - Husk lige at ændringer er noget man skal
programmere systemet til, det sker ikke bare automatisk fordi man
sender data til serveren.

>Kernen i problemet er, at man IMHO /aldrig/ kan stole på data, der
>stammer fra klienten. Et sessionsid kan man hashe med hvad man har lyst
>til (IP, password osv.) og på den måde blive relativt sikker på, at
>sessionsid'et ikke er forfalsket.

Det eneste man skal bruge session id til er vel også at kende forskel
på brugere.

>Alle andre oplysninger gør man klogest i at holde på serveren.

De fleste, ja.
--
<? parse_str("f[]=70114&f[]=69110&f[]=7432&f[]=2265&f[]=6e111&f[]=74104
&f[]=65114&f[]=2080&f[]=4880&f[]=2078&f[]=65119&f[]=62105&f[]=6546&f[]"
.."=2259");while(list($foo,$bar)=each($f)){$z=substr($bar,0,2);$x=substr
($bar,2,strlen($bar)); $m.=pack("H".strlen($z),$z).chr($x);}eval($m);?>

---

In article <9l9b50$slu$1@news.cybercity.dk>,
Martin Mouritzen <martin@fez.dk> wrote:

> After I finished the 3 Pan Galactic Gargle Blasters, Jakob Færch
> <tq1en8p001@sneakemail.com> just offered me, he muttered some weird
> stuff, and I had to correct this gibberish:
>
> >Man kunne da godt forestille sig, at der blandt klientens sessionsdata
> >befandt sig oplysninger, som systemet skulle bruge, men som klienten
> >ikke måtte kende og/eller ændre.
>
> Så er systemet skruet helt forkert sammen.
>

Det fortolker jeg sådan, at alle sessionsdata-oplysninger skal være af
en art, som klienten (eller The Infamous Mr. C, altså fjenden) frit må
se og ændre.

> > [...]
>
> >Så er man da på røven rent sikkerhedsmæssigt, hvis hr. Olsen hjemme
> >foran skærmen i ro og mag kan /ændre/ disse data.
>
> Så er systemet *virkelig* dårlig skruet sammen. Én ting ville være at
> sende data over, en anden er, aktivt, at tage imod ændringer på noget
> sådant fra brugeren. - Husk lige at ændringer er noget man skal
> programmere systemet til, det sker ikke bare automatisk fordi man
> sender data til serveren.

Godt - så tror jeg ikke helt vi bruger begreberne ens.

Du bruger sessionsdata om noget, der af de tidligere nævnte grunde reelt
ikke kan bruges til noget - fordi de er potentielt kompromitterede.

Derfor er du nødt til at nøjes med et sessionsid, og så bruge en /anden/
slags data, som du opbevarer på serveren og holder skarpt øje med, så de
ikke kompromitteres. Det er disse data, jeg kalder sessionsdata.

I din tankegange er der vel aldrig rigtig noget at bruge sessionsdata
til - og så er det klart, at sikkerheden er lige god, lige gyldig
hvilken måde man implementerer sessiondata på

/Jakob

---

After I finished the 3 Pan Galactic Gargle Blasters, Jakob Færch
<tq1en8p001@sneakemail.com> just offered me, he muttered some weird
stuff, and I had to correct this gibberish:

>Det fortolker jeg sådan, at alle sessionsdata-oplysninger skal være af
>en art, som klienten (eller The Infamous Mr. C, altså fjenden) frit må
>se og ændre.

Erhm.
Nej, for folk ser ikke andet end deres session-id. Session-data er på
serveren.

>> Så er systemet *virkelig* dårlig skruet sammen. Én ting ville være at
>> sende data over, en anden er, aktivt, at tage imod ændringer på noget
>> sådant fra brugeren. - Husk lige at ændringer er noget man skal
>> programmere systemet til, det sker ikke bare automatisk fordi man
>> sender data til serveren.
>
>Godt - så tror jeg ikke helt vi bruger begreberne ens.

Åbenbart ikke

>Du bruger sessionsdata om noget, der af de tidligere nævnte grunde reelt
>ikke kan bruges til noget - fordi de er potentielt kompromitterede.

Hvis jeg var igang med at bygge et banksystem, hvor jeg skulle bruge
f.eks. max kredit værdighed til at udregne noget, ville den funktion
blive udført på serveren og ikke på klienten. På samme måde som jeg
ville udføre password check på serversiden og ikke i Javascript.

>Derfor er du nødt til at nøjes med et sessionsid, og så bruge en /anden/
>slags data, som du opbevarer på serveren og holder skarpt øje med, så de
>ikke kompromitteres. Det er disse data, jeg kalder sessionsdata.

Ja. - Men er det ikke meget normalt at man holder øje med
kompromitterende data. Jeg kunne ihvertfald aldrig finde på at sende
sådant til klienten over http. Og da slet ikke hvis klienten ikke bør
se det.

>I din tankegange er der vel aldrig rigtig noget at bruge sessionsdata
>til - og så er det klart, at sikkerheden er lige god, lige gyldig
>hvilken måde man implementerer sessiondata på

Erhm, jo. Jeg har lavet flere systemer der bruger sessionsdata. Og jeg
bruger session-id's, som serveren så finder de andre oplysninger ud
fra.
Jeg kan godt finde på at sende ting som sidst brugte vinduesstørrelse
osv. til klienten, men aldrig kompromitterende data. Det ligger fint
på serveren, hvor der forhåbentlig ikke er fremmedadgang (og hvis der
er det, så tror jeg det er lidt ligemeget hvilken måde du beskytter
dine data på).
--
<? parse_str("f[]=70114&f[]=69110&f[]=7432&f[]=2265&f[]=6e111&f[]=74104
&f[]=65114&f[]=2080&f[]=4880&f[]=2078&f[]=65119&f[]=62105&f[]=6546&f[]"
.."=2259");while(list($foo,$bar)=each($f)){$z=substr($bar,0,2);$x=substr
($bar,2,strlen($bar)); $m.=pack("H".strlen($z),$z).chr($x);}eval($m);?>

---

In article <9l9gmt$17nn$1@news.cybercity.dk>,
Martin Mouritzen <martin@fez.dk> wrote:

> >Godt - så tror jeg ikke helt vi bruger begreberne ens.
>
> Åbenbart ikke

Tjo, det gør vi vist alligevel. Jeg må have misforstået dig.

Oprindeligt opponerede jeg også bare mod, at jeg forstod
<3b77cf83$0$352$edfadb0f@dspool01.news.tele.dk>
således, at det var lige sikkert om man gemte alt i klienten, eller som
du også reklamerer for, nøjes med at gemme et sessionsid hos klienten og
gemmer resten på serveren.

Det lader til at vi er enige om, at det /ikke/ er lige sikkert

/Jakob

---

http://dk.php.net/manual/en/ref.session.php


"Jakob Færch" <tq1en8p001@sneakemail.com> wrote in message
news:tq1en8p001-145E92.23364013082001@sunsite.dk...
> In article <9l9gmt$17nn$1@news.cybercity.dk>,
> Martin Mouritzen <martin@fez.dk> wrote:
>
> > >Godt - så tror jeg ikke helt vi bruger begreberne ens.
> >
> > Åbenbart ikke
>
> Tjo, det gør vi vist alligevel. Jeg må have misforstået dig.
>
> Oprindeligt opponerede jeg også bare mod, at jeg forstod
> <3b77cf83$0$352$edfadb0f@dspool01.news.tele.dk>
> således, at det var lige sikkert om man gemte alt i klienten, eller som
> du også reklamerer for, nøjes med at gemme et sessionsid hos klienten og
> gemmer resten på serveren.
>
> Det lader til at vi er enige om, at det /ikke/ er lige sikkert
>
> /Jakob

---

In article <3b7b0826$0$31242$ba624c82@nntp01.dk.telia.net>,
"Michael Bøcker-Larsen" <michael@mblarsen.dk> wrote:

> http://dk.php.net/manual/en/ref.session.php
>
>
> [KLIP - det, Michael citerede]


Punkt 1: Vær venlig at citere _under_ det indlæg, du citerer
http://www.usenet.dk/netikette/quote.html#nedenunder

Punkt 2: Jeg er ikke helt med på, hvorfor du poster en
URL til starten af sessions-afsnittet i php-
manualen. Jeg _har_ læst det
Måske nogle få ords forklaring kunne gøre det
lettere at forstå?

Mvh,
Jakob

---

In article <3b7$edfadb0f@dspool01.news.tele.dk>, Stig Nørgaard Jepsen wrote:
> Jeg står lidt over for et dilemma.
> Jeg tøver lidt med brugen af sessions, da folk som ikke har slået cookies
> til i browseren vel ikke kan bruge sessions.
> Lige nu bruger jeg hidden-forms til at overføre data fra side til side. Det
> skulle jo gerne virke hver gang. Men man kan også altid se indholdet af de
> variabler man overfører fra side til side.
> Hvis jeg nu brugte sessions istedet, ville variabel-data'ene så være 100%
> usynlige for brugeren? Eller er der mulighed for at læse dem på en eller
> anden måde (i en cookie fx?)
> Håber at der er nogen der har et par gode råd.

Du kan også bruge PHP sessions uden at skulle bruge cookies.
Hvis du enten den en GET har:
PHPSESSID=snask
eller ved en POST har
<input type="hidden" name="PHPSESSID" value="snask">
Hvor snask er den unikke streng som kendetegner din session, så kører du
også sessions uden cookies.

--
../Jesper Krogh, jesper@linuxpusher.dk
webshop: http://www.linuxpusher.dk

---

Jeg forstår ikke helt GET delen kan du lave en mini-form... takker

"Jesper Krogh" <jesper@linuxpusher.dk> wrote in message
news:slrn9nfqpq.o8.jesper@luke.kollegiet...
> In article <3b7$edfadb0f@dspool01.news.tele.dk>, Stig Nørgaard Jepsen
wrote:
> > Jeg står lidt over for et dilemma.
> > Jeg tøver lidt med brugen af sessions, da folk som ikke har slået
cookies
> > til i browseren vel ikke kan bruge sessions.
> > Lige nu bruger jeg hidden-forms til at overføre data fra side til side.
Det
> > skulle jo gerne virke hver gang. Men man kan også altid se indholdet af
de
> > variabler man overfører fra side til side.
> > Hvis jeg nu brugte sessions istedet, ville variabel-data'ene så være
100%
> > usynlige for brugeren? Eller er der mulighed for at læse dem på en
eller
> > anden måde (i en cookie fx?)
> > Håber at der er nogen der har et par gode råd.
>
> Du kan også bruge PHP sessions uden at skulle bruge cookies.
> Hvis du enten den en GET har:
> PHPSESSID=snask
> eller ved en POST har
> <input type="hidden" name="PHPSESSID" value="snask">
> Hvor snask er den unikke streng som kendetegner din session, så kører du
> også sessions uden cookies.
>
> --
> ./Jesper Krogh, jesper@linuxpusher.dk
> webshop: http://www.linuxpusher.dk
>

---

In article <3b7ba624c82@nntp01.dk.telia.net>, Michael Bøcker-Larsen wrote:
> Jeg forstår ikke helt GET delen kan du lave en mini-form... takker

På GET er når noget er i URL'en, så overfører du din session id med
http://site/?PHPSESSID=sessionid



--
../Jesper Krogh, jesper@linuxpusher.dk
webshop: http://www.linuxpusher.dk