HTML5+PHP: Manipulere localStorage og sessionStorage

Nej, for det er klientbaserede data. Det er javascript du skal bruge til sådan noget. PHP - eller et vilkårligt serversidesprog - er tilfældigvis serverside og kan derfor ikke tilgå clientside.

Tak. Jeg havde fået den opfattelse, at localStorage og sessionStorage er skabt for at eliminere cookies og de tilsyneladende kringlede nuværende implementationer af sessions - men det er måske helt forkert...?

Det er lidt svært at svare på dit spørgsmål med et ja eller nej.

PHP sessions og cookies er to forskellige ting; Med cookies gemmer du al din data hos klienten; med sessions gemmer du typisk kun en streng hos klienten i form af en cookie til at identificere den aktuelle session. Dine data forbliver på serveren.

Jeg er ikke helt sikker på hvorfor du synes det er kringlet med session og cookies? Personligt synes jeg det er en meget bedre løsning end at skulle få dit javascript til at kommunikere med PHP - f.eks. til logins... og når det alligevel er klienten der skal skal afvikle koden, bestemmer klienten jo også selv hvilke data han vil give dig/gemme hos sig selv.

Jeg tror at HTML5 Storage er rettet mod frontendkodere - ikke så meget programmørerne som laver alt det serverside.

Tak.

"PHP sessions og cookies er to forskellige ting; Med cookies gemmer du al din data hos klienten; med sessions gemmer du typisk kun en streng hos klienten i form af en cookie til at identificere den aktuelle session."
Jeps, det ved jeg.

"Jeg er ikke helt sikker på hvorfor du synes det er kringlet med session og cookies?"
Jeg mente, at implementationen af sessions, hvad jeg ved af, er mindre end ideel. Det er dog ikke sagens kerne :)

"Jeg tror at HTML5 Storage er rettet mod frontendkodere - ikke så meget programmørerne som laver alt det serverside."
Så data primært håndteret af backend bør fortsat associeres med frontend via de nuværende cookies og sessions - og ikke HTML5's nye Storage?

"Jeg mente, at implementationen af sessions, hvad jeg ved af, er mindre end ideel. Det er dog ikke sagens kerne :)"
Ikke forstået? Du kan jo lave dine egne implementeringer hvis du er 'utilfreds' med måden det fungerer på nu? For mange var sessions jo PHP's frelse - cookies var ufleksible og utilstrækkelige; men med introduktionen af de superglobale sessions blev PHP i sig selv mere anvendt og tilgængeligheden for nye udviklere var klart bedre da det eneste du faktisk behøvede at vide var at session_start() skal ud før alt andet...

"Så data primært håndteret af backend bør fortsat associeres med frontend via de nuværende cookies og sessions - og ikke HTML5's nye Storage?"
Jeg kan ikke se hvilken fordel du kan drage ved at anvende klienten til at opbevare følsomme data? Som sagt er alt hvad klienten har magt over, noget du aldrig selv ville kunne have magt over.
Som udgangspunkt er der ikke én løsning der er korrekt - der er ikke kun et facit; hvis du synes det er meget smartere at anvende Web Storage fremfor PHP sessions og cookies, så fred være med det - din indgangsvinkel til emnet var baseret på nogle forkerte præmisser: hvad kan serverside gøre på klienten? Ingenting - det må være den logiske konklusion ved adskillelse af serverside og clientside.

Takker.

"Du kan jo lave dine egne implementeringer hvis du er 'utilfreds' med måden det fungerer på nu?"
Det skal nok passe - jeg mindes bare at være stødt på en del negative bemærkninger om systemet, men jeg har ikke selv rodet nok med det til at kunne sige mere om det. Men så igen, det er ikke så vigtigt her.

"Jeg kan ikke se hvilken fordel du kan drage ved at anvende klienten til at opbevare følsomme data?"
Jeg prøver lige at være lidt mere specifik :)
Helt præcist er der tale om brugernavn, password og evt. en liste over mål eller anden begrænset misc. data - således at backend for hver request kan tjekke credentials og melde fejl ved mismatch. Ganske enkelt!

Men lad mig lige se, om jeg har forstået det rigtigt: Den nuværende cookie-funktionalitet bibeholdes indefinitely og anvendes fortsat af backend til styring af sessions, således at HTML5's Storage intet ændrer for f.eks. PHP, korrekt?

"Helt præcist er der tale om brugernavn, password og evt. en liste over mål eller anden begrænset misc. data - således at backend for hver request kan tjekke credentials og melde fejl ved mismatch. Ganske enkelt!"
Ja, det lyder jo ret simpelt... Men ikke noget som er nemmest løst med PHP sessions.

"Men lad mig lige se, om jeg har forstået det rigtigt: Den nuværende cookie-funktionalitet bibeholdes indefinitely og anvendes fortsat af backend til styring af sessions, således at HTML5's Storage intet ændrer for f.eks. PHP, korrekt?"
Vi snakker ikke samme sprog/teknologi. Web Storage har ikke noget med cookies at gøre; det er en funktionalitet som giver dig mulighed for at gemme nogle oplysninger hos klienten - se det som en primitiv database til at opbevare oplysninger, ligesom i en database eller en midlertidig fil. At sammenligne Web Storage med PHP's session og cookie funktionalitet er som at sammenligne tomater med kartofler - jovist er begge dele da grønt, men de har ikke samme anvendelighed.

Du bliver nød til at lave en større opdeling over teknologiernes forskel, før det giver mening:

Web Storage er klientbaseret og administreret data som er tilgængelig kun gennem klienten. Skal dataene kommunikere med serveren, må du sende dem gennem synkrone eller asynkrone kald. Men hvad er så formålet med klientbaseret data, hvis du alligevel skal sende dem til serveren?

PHP sessions og cookies anvendes til at identificere en pågældende session/klient og associere data til den specifikke session eller klient.

Så adskillelsen af de to ting bør komme langt før det du portrætterer.

Tak, det besvarede vist spørgsmålet :)

Sidespor:
"'Helt præcist er der tale om brugernavn, password og evt. en liste over mål eller anden begrænset misc. data - således at backend for hver request kan tjekke credentials og melde fejl ved mismatch. Ganske enkelt!'
Ja, det lyder jo ret simpelt... Men ikke noget som er nemmest løst med PHP sessions."
Hvorledes så? Hvis jeg skal opretholde en fornuftig sikkerhed, er jeg vel nødt til at tjekke credentials ved hvert request, og så skal et brugernavn og password på en eller anden måde associeres med klienten - helst uden at opbevares der. Det ligger vel ret tydeligt op til anvendelsen af sessions?

Den simple måde er jo netop at logge brugeren ind og sætte en session der indikerer om brugeren er logget ind eller ej.

login.php


beskyttet_side.php


logout.php


Uhyre simpelt...

Jeg har lavet et færdigt brugersystem som er lavet til at skulle implementeres i eksisterende systemer uden for meget gøjl - sikkerhed er i højsædet - du kan hente det på http://catalystcode.net/

Kig koden igennem, så kan du se hvordan jeg mener at et sikkert login kan se ud...

Problemet ved at lære noget arbitrært og ikke lineært fra bunden og op bliver pludseligt ret så indlysende...
Da jeg oprindeligt lærte PHP og først beskæftigede mig med grundlæggende sikkerhed vidste jeg intet om, hvordan sessions var realiseret, og jeg antog derfor, at enhver værdi gemt i en sessionvariabel var direkte tilgængelig for brugeren - hvilket givetvis ville medføre, at det ikke er muligt blot at gemme en variabel for login som bekræftelse. Jeg er selvfølgeligt blevet klogere i mellemtiden, men hvad hjælper det, når jeg fortsat bygger nye antagelser på gamle fejlagtige? :)

Anyhow, kort sagt: Tak, du har selvfølgelig ret. Der er dog noget, der stadigt bekymrer mig en smule: Hvor længe gemmer PHP informationer om sessions? Hvad sker der, hvis klienten ikke formår at sikre, at session-cookie'n bliver slettet efter sessionens afslutning - kan en vilkårlig bruger så genoptage sessionen under identitet som forgængeren?

Leve-tiden af en session er defineret i konfigurationen af det webhotel/server sitet ligger på. Jeg mener den normale tid er 30 min., men det kan være forskelligt afhængigt af din host.

Typisk vil du ikke opleve at en bruger kan overtage en anden brugers session. Session ID kan genereres gennem en række tilfældige tal/bogstav kombinationer som bliver kørt gennem en md5() hash funktion. Det giver teoretisk 4,3 mia. forskellige kombinationer.

Der er dog forskellige sikkerhedsudfordringer man skal være opmærksom på, som gælder både i PHP og andre server-side sprog. Det er ikke i en svaghed i PHP, men blot ting man skal være opmærksom på.

Du kan læse lidt om dem her hvis du har lyst:
http://shiflett.org/articles/session-fixation
http://shiflett.org/articles/session-hijacking
http://shiflett.org/articles/cross-site-request-forgeries

#10
Det er en naturlig indlæringsproces at tage fejl indimellem.

En typisk session er ikke længere tilknyttet klienten så snart klienten enten har lukket sin browser eller slettet domænets cookies. Uden brugeraktivitet i en bestemt session timer sessionen ud, som #11 siger, efter en rum tid - 42 minutter i det standardopsæt jeg har.

De artikler som #11 henviser til, fremhæver naturligvis nogle åbenlyse problematikker - dog, selvom artiklerne får koncepterne bag session hijacking og fixation til at virke utroligt simple, skal man huske på at en given applikation sjældent er identisk med en anden. Det er mere kompliceret at gøre de nævnte ting, end det faktisk bliver portrætteret idét forskellige udviklere implementerer forskellige løsninger.

Naturligvis skal man være opmærksom på sårbarheder i sine systemer - men ofte er langt de fleste problemer ikke session hijacking - det er SQL injections og cross-site scripting.

Tak for svarene og beklager drejningen mod sikkerhed.

Jeg udførte nogle tests som beskrevet i den første artikel, men ingen af dem resulterede i uautoriseret adgang til sessionen; kan det passe, at det kun virker, hvis sessionsmekanismen er GET-query-baseret?

#13
Nej, ikke helt - der er andre tekniske muligheder, men som jeg allerede har nævnt er det teknisk kompliceret at udføre; mange gange er eksemplerne jo også baseret på kode som er kendt i forvejen - usikkerhederne er derfor åbenlyse for skribenterne og fanden kan blive malet på væggen.

Naturligvis skal sikkerheden ikke undervurderes, men lad nu være med at gå i panik over noget unødigt, når nu det er teknikker der anvendes dagligt og flere steder.

Godt så - tak for hjælpen og tak for bidraget til intenz.

Kan jeg få dig til at smide et svar, repox?

Du fik et svar her.

Bliver nødt til at kommentere...

Jeg læste alle svar og spørgsmål igennem, og syntes der skal gives stor klap på skuldrene for den meget informative forklaring af alle spørgsmål i denne tråd...