Ik wil de laadtijden op mijn websites verkorten door alle cookies naar lokale opslag te verplaatsen, aangezien ze dezelfde functionaliteit lijken te hebben. Zijn er voor- en nadelen (vooral qua prestaties) bij het gebruik van lokale opslag om de cookiefunctionaliteit te vervangen, behalve de duidelijke compatibiliteitsproblemen?

Antwoord 1, autoriteit 100%

Cookies en lokale opslag hebben verschillende doelen. Cookies zijn voornamelijk bedoeld voor het lezen van server-side, lokale opslag kan alleen worden gelezen door de client-side. Dus de vraag is, in uw app, wie deze gegevens nodig heeft – de client of de server?

Als het uw client is (uw JavaScript), schakel dan zeker over. U verspilt bandbreedte door alle gegevens in elke HTTP-header te verzenden.

Als het uw server is, is lokale opslag niet zo handig omdat u de gegevens op de een of andere manier zou moeten doorsturen (met Ajax of verborgen formuliervelden of zoiets). Dit kan in orde zijn als de server slechts een kleine subset van de totale gegevens nodig heeft voor elk verzoek.

U wilt uw sessiecookie hoe dan ook als een cookie achterlaten.

Volgens het technische verschil, en ook mijn begrip:

1. Behalve dat het een oude manier is om gegevens op te slaan, geven cookies je een limiet van 4096bytes (4095, eigenlijk) — het is per cookie. Lokale opslag is zo groot als 5 MB per domein— SO Vraag vermeldt het ook.

2. localStorageis een implementatie van de Storage-interface. Het slaat gegevens op met geen vervaldatum, en wordt alleengewist via JavaScript, of het wissen van de browsercache/lokaal opgeslagen gegevens — in tegenstelling tot de vervaldatum van cookies.

Antwoord 2, autoriteit 19%

In de context van JWTS , stormpad heeft een vrij nuttig artikel geschreven waarin mogelijke manieren zijn om ze op te slaan, en de (districtsvoordelen met betrekking tot elke methode.

Het heeft ook een kort overzicht van XSS en CSRF-aanvallen en hoe u ze kunt bestrijden.

Ik heb een aantal korte fragmenten van het onderstaande artikel bijgevoegd, in het geval dat hun artikel offline / hun site daalt.

Lokale opslag

Problemen:

Webopslag (localstorage / sessionstorage) is toegankelijk via Javascript op hetzelfde domein. Dit betekent dat elk JavaScript op uw site toegang heeft tot webopslag, en hierdoor kan we kwetsbaar zijn voor scripts (XSS) van cross-site (XSS). XSS in een notendop is een soort kwetsbaarheid waarbij een aanvaller javascript kan injecteren die op uw pagina wordt uitgevoerd. Basic XSS-aanvallen proberen Javascript te injecteren via formulierinvoer, waar de aanvaller alert wordt geplaatst (‘U bent gehackt’); in een formulier om te zien of het wordt gerund door de browser en kan worden bekeken door andere gebruikers.

preventie:

Om XSS te voorkomen, is het gemeenschappelijke antwoord om te ontsnappen en alle niet-vertrouwde gegevens te coderen. Maar dit is ver van het volledige verhaal. In 2015 gebruiken moderne web-apps Javascript gehost op CDNS of buiteninfrastructuur. Moderne web-apps omvatten 3RD-partij JavaScript-bibliotheken voor A / B-test, trechter- / marktanalyse en advertenties. We gebruiken pakketmanagers zoals Bower om de code van andere mensen in onze apps te importeren.

Wat als slechts een van de scripts die u gebruikt is aangetast? Kwaadaardig
Javascript kan worden ingesloten op de pagina en webopslag is
gecompromitteerd. Dit soort XSS-aanvallen kunnen ieders webopslag krijgen
dat bezoekt uw site, zonder hun kennis. Dit is waarschijnlijk een
Bos van organisaties adviseren om niets van waarde of vertrouwen op te slaan
alle informatie in webopslag. Dit omvat session-ID’s en
tokens.

Als opslagmechanisme is webopslag niet beveiligd
normen tijdens de overdracht. Wie webopslag leest en gebruikt, het moet
Doe hun due diligence om ervoor te zorgen dat ze altijd de JWT over https sturen
en nooit http.

Cookies

Problemen:

Cookies, bij gebruik met de htponly cookie-vlag, zijn niet toegankelijk via JavaScript en zijn immuun voor XSS. U kunt ook de Secure Cookie-vlag instellen om te garanderen dat de cookie alleen via HTTPS wordt verzonden. Dit is een van de belangrijkste redenen die cookies in het verleden zijn gebruikt om tokens of sessiegegevens op te slaan. Moderne ontwikkelaars zijn aarzelend om cookies te gebruiken, omdat ze traditioneel de vereiste toestand vereisen die op de server moeten worden opgeslagen, waardoor de rustgevende best practices zal breken. Cookies als opslagmechanisme vereisen geen status die op de server moet worden opgeslagen als u een JWT in de cookie opbergt. Dit komt omdat het JWT alles inkapselt dat de server het verzoek moet dienen.

Cookies zijn echter kwetsbaar voor een ander type aanval:
Cross-site aanvraagvervalsing (CSRF). Een CSRF-aanval is een type aanval
dat gebeurt wanneer een kwaadwillende website, e-mail of blog veroorzaakt een gebruiker
Webbrowser om een ​​ongewenste actie uit te voeren op een vertrouwde site waarop
De gebruiker is momenteel geverifieerd. Dit is een exploitatie van hoe de
Browser behandelt koekjes. Een cookie kan alleen naar de domeinen worden verzonden
die het is toegestaan. Standaard is dit het domein dat oorspronkelijk
Stel de cookie in. De cookie wordt voor een verzoek verzonden, ongeacht
Of je nu op sterrenstelsels.com of hahagonnahackyou.com bent.

preventie:

Moderne browsers ondersteunen de SameSiteflag, naast HttpOnlyen Secure. Het doel van deze vlag is om te voorkomen dat de cookie wordt verzonden in cross-site-verzoeken, waardoor vele soorten CSRF-aanvallen worden voorkomen.

Voor browsers die SameSiteniet ondersteunen, kan CSRF worden voorkomen door gesynchroniseerde tokenpatronen te gebruiken. Dit
klinkt ingewikkeld, maar alle moderne webframeworks hebben ondersteuning voor:
dit.

AngularJS heeft bijvoorbeeld een oplossing om te valideren dat de cookie is
alleen toegankelijk via uw domein. Rechtstreeks uit AngularJS-documenten:

Bij het uitvoeren van XHR-verzoeken leest de $http-service een token van a
cookie (standaard XSRF-TOKEN) en stelt deze in als een HTTP-header
(X-XSRF-TOKEN). Omdat alleen JavaScript dat op uw domein draait, kan
lees de cookie, uw server kan er zeker van zijn dat de XHR afkomstig is
JavaScript draait op uw domein. U kunt deze CSRF-bescherming maken
staatloos door een xsrfTokenJWT-claim op te nemen:

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "[email protected]",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

Door gebruik te maken van de CSRF-beveiliging van uw webapp-framework zijn cookies geweldig
solide voor het opslaan van een JWT. CSRF kan ook gedeeltelijk worden voorkomen door:
het controleren van de HTTP-verwijzer en Origin-header van uw API. CSRF
aanvallen hebben Referer- en Origin-headers die niets te maken hebben met:
uw aanvraag.

Het volledige artikel is hier te vinden:
https://stormpath.com/ blog/waar-je-jwts-cookies-vs-html5-web-storage-opslaan/

Ze hebben ook een nuttig artikel over hoe je JWT’s het beste kunt ontwerpen en implementeren, met betrekking tot de structuur van het token zelf:
https://stormpath.com/blog/jwt-the-right-way/

Antwoord 3, autoriteit 7%

Met localStoragekunnen webapplicaties gegevens lokaal opslaan in de browser van de gebruiker. Vóór HTML5 moesten applicatiegegevens worden opgeslagen in cookies, opgenomen in elk serververzoek. Grote hoeveelheden gegevens kunnen lokaal worden opgeslagen, zonder dat de prestaties van de website worden beïnvloed. Hoewel localStoragemoderner is, zijn er enkele voor- en nadelen aan beide technieken.

Cookies

Pluspunten

• Verouderde ondersteuning (het bestaat al altijd)
• Persistente gegevens
• Vervaldatums

Nadelen

• Elk domein slaat al zijn cookies op in een enkele string, waardoor
  gegevens ontleden moeilijk
• Gegevens zijn niet-versleuteld, wat een probleem wordt omdat… … hoewel
  klein van formaat, cookies worden bij elk HTTP-verzoek verzonden Beperkte grootte
  (4KB)
• SQL-injectie kan worden uitgevoerd vanuit een cookie

Lokale opslag

Pluspunten

• Ondersteund door de meeste moderne browsers
• Persistente gegevens die rechtstreeks in de browser worden opgeslagen
• Regels van dezelfde oorsprong zijn van toepassing op lokale opslaggegevens
• Wordt niet bij elk HTTP-verzoek verzonden
• ~5 MB opslagruimte per domein (dat is 5120 KB)

Nadelen

• Niet eerder ondersteund door: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Als de server opgeslagen klantinformatie nodig heeft die u met opzet hebt
  om het te verzenden.

Het gebruik van

localStorageis bijna identiek aan dat van een sessie. Ze hebben vrijwel exacte methoden, dus overschakelen van sessie naar localStorageis echt kinderspel. Als opgeslagen gegevens echter echt cruciaal zijn voor uw toepassing, zult u waarschijnlijk cookies gebruiken als back-up voor het geval localStorageniet beschikbaar is. Als u browserondersteuning voor localStoragewilt controleren, hoeft u alleen maar dit eenvoudige script uit te voeren:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}
/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

“localStorage-waarden op beveiligde (SSL)-pagina’s zijn geïsoleerd”
zoals iemand opmerkte, houd er rekening mee dat localStorage dat niet zal zijn
beschikbaar als u overschakelt van ‘http’ naar ‘https’ beveiligd protocol, waarbij:
de cookie is nog steeds toegankelijk. Dit is een beetje belangrijk om
let op als je met veilige protocollen werkt.

Antwoord 4, autoriteit 2%

Cookies:

1. Geïntroduceerd vóór HTML5.
2. Heeft een vervaldatum.
3. Wissen door JS of door Browsegegevens wissen van browser of na de vervaldatum.
4. Wordt bij elk verzoek naar de server gestuurd.
5. De capaciteit is 4 KB.
6. Alleen strings kunnen in cookies worden opgeslagen.
7. Er zijn twee soorten cookies: permanent en sessie.

Lokale opslag:

1. Geïntroduceerd met HTML5.
2. Heeft geen vervaldatum.
3. Wissen door JS of door Browsegegevens wissen van de browser.
4. U kunt selecteren wanneer de gegevens naar de server moeten worden verzonden.
5. De capaciteit is 5 MB.
6. Gegevens worden voor onbepaalde tijd opgeslagen en moeten een tekenreeks zijn.
7. Slechts één type.

Antwoord 5

Het is ook vermeldenswaard dat localStorageniet kan worden gebruikt wanneer gebruikers browsen in de “privé”-modus in sommige versies van mobiele Safari.

Geciteerd door MDN (https://developer.mozilla. org/en-US/docs/Web/API/Window/localStorage):

Opmerking: vanaf iOS 5.1 slaat Safari Mobile localStorage-gegevens op in
de cachemap, die af en toe moet worden opgeschoond, bij de
in opdracht van het besturingssysteem, meestal als er weinig ruimte is. Privé van Safari Mobile
De bladermodus voorkomt ook volledig schrijven naar localStorage.

Antwoord 6

Nou, de lokale opslagsnelheid hangt sterk af van de browser die de client gebruikt, en ook van het besturingssysteem. Chrome of Safari op een Mac kan veel sneller zijn dan Firefox op een pc, vooral met nieuwere API’s. Maar zoals altijd is testen je vriend (ik kon geen benchmarks vinden).

Ik zie echt geen groot verschil in cookie versus lokale opslag. Je zou je ook meer zorgen moeten maken over compatibiliteitsproblemen: niet alle browsers zijn zelfs begonnen de nieuwe HTML5 API’s te ondersteunen, dus cookies zijn de beste keuze voor snelheid en compatibiliteit.

Antwoord 7

Lokale opslag kan tot 5 MB offline data opslaan, terwijl sessie ook tot 5 MB data kan opslaan. Maar cookies kunnen alleen gegevens van 4 kb in tekstformaat opslaan.

LOCAl en Session-opslaggegevens in JSON-indeling, dus eenvoudig te ontleden. Maar cookiegegevens zijn in tekenreeksformaat.

Antwoord 8

Belangrijkste verschillen:

Capaciteit:

• Lokale opslag:10 MB
• Cookies:4kb

Browserondersteuning:

• Lokale opslag:HTML5
• Cookies:HTML4, HTML5

Opslaglocatie:

• Lokale opslag:alleen browser
• Cookies:Browser & Server

Verzenden met verzoek:

• Lokale opslag:Ja
• Cookies:Nee

Toegankelijk vanaf:

• Lokale opslag:elk venster
• Cookies:elk venster.

Vervaldatum:

• Lokale opslag:Verloopt nooit, totdat het klaar is met javascript.
• Cookies:Ja, hebben een vervaldatum.

Opmerking: gebruik dat, wat bij je past.