Ik ben een paar maanden geleden begonnen met het gebruik van PHP. Om een inlogsysteem voor mijn website te maken, heb ik gelezen over cookies en sessies en hun verschillen (cookies worden opgeslagen in de browser van de gebruiker en sessies op de server). In die tijd gaf ik de voorkeur aan cookies (en wie houdt er niet van cookies?!) mijn bachelor afstudeerproject. Echter, nadat ik het grootste deel van mijn app had gedaan, hoorde ik dat voor het specifieke geval van het opslaan van de gebruikers-ID, sessies geschikter zijn. Dus ik begon na te denken over wat ik zou zeggen als de jury me vraagt waarom je cookies hebt gebruikt in plaats van sessies? Ik heb precies die reden (dat ik geen interne informatie over de gebruiker hoef op te slaan). Is dat voldoende als reden? of is het meer dan dat?

Kunt u mij vertellen over de voordelen/nadelen van het gebruik van cookies voor het bewaren van de gebruikers-ID?

Bedankt voor jullie allemaal in StackOverflow!

Antwoord 1, autoriteit 100%

Het concept is het opslaan van permanente gegevens over het laden van pagina’s voor een webbezoeker. Cookies slaan het direct op bij de klant. Sessies gebruiken een cookie als een soort sleutel om te associëren met de gegevens die op de server zijn opgeslagen.

Het heeft de voorkeur om sessies te gebruiken omdat de werkelijke waarden voor de client verborgen zijn en u bepaalt wanneer de gegevens verlopen en ongeldig worden. Als het allemaal op cookies was gebaseerd, zou een gebruiker (of hacker) hun cookiegegevens kunnen manipuleren en vervolgens verzoeken naar uw site kunnen afspelen.

Bewerken: ik denk niet dat het gebruik van cookies enig voordeel heeft, behalve eenvoud. Bekijk het op deze manier… Heeft de gebruiker een reden om zijn ID# te weten? Normaal gesproken zou ik nee zeggen, de gebruiker heeft deze informatie niet nodig. Het verstrekken van informatie moet worden beperkt op een ‘need to know’-basis. Wat als de gebruiker zijn cookie wijzigt om een andere ID te hebben, hoe reageert uw applicatie dan? Het is een veiligheidsrisico.

Voordat sessies een rage waren, had ik eigenlijk mijn eigen implementatie. Ik heb een unieke cookiewaarde op de client opgeslagen en mijn permanente gegevens samen met die cookiewaarde in de database opgeslagen. Vervolgens koppelde ik op paginaverzoeken die waarden en had ik mijn persistente gegevens zonder de klant te laten bepalen wat dat was.

Antwoord 2, autoriteit 48%

Basisideeën om onderscheid te maken tussen deze twee.

Sessie:

1. IDU wordt opgeslagen op de server (d.w.z. aan de serverzijde)
2. Veiliger (vanwege 1)
3. Vervaldatum kan niet worden ingesteld, sessievariabelen verlopen wanneer gebruikers de browser sluiten. (tegenwoordig wordt het standaard 24 minuten bewaard in php)

Cookies:

1. IDU wordt opgeslagen in de webbrowser (d.w.z. aan de clientzijde)
2. Niet erg veilig, omdat hackers uw informatie kunnen bereiken en verkrijgen (vanwege 1)
3. Vervaldatum kan worden ingesteld (zie setcookies()voor meer informatie)

Sessie heeft de voorkeur wanneer u informatie/waarden voor de korte termijn moet opslaan, zoals variabelen voor berekenen, meten, opvragen enz.

Cookies hebben de voorkeur wanneer u informatie/waarden voor de lange termijn moet opslaan, zoals het account van de gebruiker (zodat zelfs wanneer ze de computer 2 dagen afsluiten, hun account nog steeds is ingelogd). Ik kan niet veel voorbeelden bedenken voor cookies, omdat het in de meeste situaties niet wordt toegepast.

Antwoord 3, autoriteit 19%

SESSIONS ENDS WHEN USER CLOSES THEIR BROWSER,
COOKIES END DEPENDING ON THE LIFETIME YOU SET FOR IT. SO THEY CAN LAST FOR YEARS

Dit is het grote verschil in uw keuze,

Als je wilt dat de id lang wordt onthouden, dan moet je cookies gebruiken; anders als u alleen wilt dat de website de gebruiker alleen voor dit bezoek herkent, dan zijn sessies de juiste keuze.

Sessies worden opgeslagen in een bestand dat uw php-server zal genereren. Om te onthouden welk bestand voor welke gebruiker is, zal php ook een cookie plaatsen in de browser van de gebruiker die dit sessiebestands-ID bevat, zodat php bij hun volgende bezoek dit bestand zal lezen en de sessie opnieuw zal laden.

Nu wist php standaard sessies elk interval, en ook de naamgevingsconventie van de sessie zorgt ervoor dat deze automatisch verloopt. Ook zullen browsers de cookie die de sessie-ID bevat niet bewaren zodra de browser is gesloten of de geschiedenis is gewist.

Het is belangrijk op te merken dat browsers tegenwoordig ook een ander soort opslag-engines ondersteunen, zoals LocalStorage, SessionStorage en andere webdb-engines die javascript-code kan gebruiken om gegevens op uw computer op te slaan om u te onthouden. Als u bijvoorbeeld de javascript-console in Facebook opent en ‘localStorage’ typt, ziet u alle variabelen die Facebook gebruikt om u te onthouden zonder cookies.

Antwoord 4, autoriteit 12%

Kort antwoord

Regels gerangschikt op prioriteit:

• Regel 1. Vertrouw nooit gebruikersinvoer: cookies zijn niet veilig. Gebruik sessies voor gevoelige gegevens.
• Regel 2. Als er permanente gegevens moeten blijven wanneer de gebruiker de browser sluit, gebruik dan cookies.
• Regel 3. Als er geen permanente gegevens hoeven te blijven wanneer de gebruiker de browser sluit, gebruik dan sessies.
• Regel 4. Lees het gedetailleerde antwoord!

Bron: https://www.lucidar.me/en /web-dev/sessions-or-cookies/

Gedetailleerd antwoord

Cookies

• Cookies worden opgeslagen aan de clientzijde (in de browser van de bezoeker).
• Cookies zijn niet veilig: het is vrij eenvoudig om de inhoud van cookies te lezen en te schrijven.
• Als je cookies gebruikt, moet je bezoekers op de hoogte stellen volgens de Europese wetgeving (GDPR).
• De vervaldatum kan worden ingesteld, maar de gebruiker of browser kan deze wijzigen.
• Gebruikers (of browser) kunnen (worden ingesteld om) het gebruik van cookies te weigeren.

Sessies

• Sessies worden op de server opgeslagen.
• Sessies gebruiken cookies (zie hieronder).
• Sessies zijn veiliger dan cookies, maar niet onkwetsbaar.
• De vervaldatum is ingesteld in de serverconfiguratie (bijvoorbeeld php.ini).
• Standaard vervaltijd is 24 minuten of wanneer de browser is gesloten.
• De vervaldatum wordt gereset wanneer de gebruiker een nieuwe pagina vernieuwt of laadt.
• Gebruikers (of browser) kunnen (worden ingesteld om) het gebruik van cookies te weigeren, dus sessies.
• Juridisch moet je bezoekers ook op de hoogte stellen van de cookie, maar het ontbreken van een precedent is nog niet duidelijk.

De juiste keuze

Sessies gebruiken een cookie!Sessiegegevens worden aan de serverzijde opgeslagen, maar een UID wordt aan de clientzijde in een cookie opgeslagen. Hiermee kan de server een bepaalde gebruiker koppelen aan de juiste sessiegegevens. UID is beschermd en moeilijk te hacken, maar niet onkwetsbaar. Voor gevoelige acties (e-mail wijzigen of wachtwoord opnieuw instellen), vertrouw niet op sessies en ook niet op cookies: vraag om het gebruikerswachtwoord om de actie te bevestigen.

Gevoelige gegevensmogen nooit in cookies worden opgeslagen (e-mails, versleutelde wachtwoorden, persoonlijke gegevens …). Houd er rekening mee dat de gegevens op een vreemde computer worden opgeslagen en dat als de computer niet privé is (klaslokaal of openbare computers), iemand anders de inhoud van de cookies kan lezen.

Onthoud mij-gegevens moeten worden opgeslagen in cookies, anders gaan gegevens verloren wanneer de gebruiker de browser sluit. Sla echter geen wachtwoord of persoonlijke gebruikersgegevens op in de ‘onthoud mij’-cookie. Sla gebruikersgegevens op in de database en koppel deze gegevens aan een versleuteld ID/sleutelpaar dat in een cookie is opgeslagen.

Na het overwegen van de eerdere aanbevelingen, is de volgende vraag uiteindelijk wat u helpt bij het kiezen tussen cookies en sessies:

Moeten permanente gegevens achterblijven wanneer de gebruiker de browser sluit?

• Als het antwoord jais, gebruik dan cookies.
• Als het antwoord neeis, gebruik dan sessies.

Antwoord 5, autoriteit 8%

wanneer u de #ID opslaat als de cookie om ingelogde gebruikers te herkennen, toont u in feite gegevens aan gebruikers die niet aan hen gerelateerd zijn. Bovendien, als een derde partij willekeurige ID’s probeert in te stellen als cookiegegevens in hun browser, kunnen ze de server ervan overtuigen dat ze een gebruiker zijn, terwijl ze dat in werkelijkheid niet zijn. Dat is een gebrek aan beveiliging.

U hebt cookies gebruikt, en zoals u zei dat u het meeste van het project al hebt voltooid. Naast cookie heeft het voorrecht om lange tijd te blijven, terwijl sessies sneller eindigen. Sessies zijn dus niet geschikt in dit geval. In werkelijkheid gebruiken veel beroemde en populaire websites en services cookie en kunt u Loggound-in blijven voor een lange tijd. Maar hoe kunt u hun methode gebruiken om een ​​veiligere inlogproces te maken?

Hier is het idee: u kunt helpen de manier waarop u cookies gebruikt: als u willekeurige sleutels gebruikt in plaats van ID’s om inloggen gebruikers te herkennen, eerst lekt u uw primaire gegevens niet op willekeurige gebruikers, en ten tweede, als u dat doet Overweeg de willekeurige sleutel die groot genoeg is, het zal moeilijker zijn voor iedereen om een ​​sleutel te raden of een willekeurige manier te creëren. U kunt bijvoorbeeld een 40 lengtesleutel opslaan zoals deze in de browser van de gebruiker:
“KUYTYRFU7987GJHFJ543JHBJHCF5645UYTUYJH54657JGUTHFN”
En het zal minder waarschijnlijk zijn dat iedereen de exacte sleutel maakt en doet alsof je iemand anders bent.

Antwoord 6, Autoriteit 6%

eigenlijk sessie en cookies zijn niet altijd gescheiden dingen. Vaak gebruikt, maar niet altijd, sessie gebruikt cookies.

Er zijn hier goede antwoorden op uw vraag in deze andere vragen hier. Aangezien uw vraag specifiek is over het opslaan van de IDU (of ID) van de gebruiker, denk ik niet dat het nogal een duplicaat is van die andere vragen, maar hun antwoorden moeten u helpen.

Cookies vs sessie

Cache vs session vs cookies?

Wat is het verschil tussen een sessie en een Cookie?

Antwoord 7, Autoriteit 4%

Ik gebruik persoonlijk zowel cookies als sessie.

Cookies worden alleen gebruikt wanneer de gebruiker op het selectievakje “onthoud mij”klikt. en ook cookies zijn gecodeerden gegevens worden alleen decoderenop de server. Als iemand cookies probeert te bewerken, kan onze decrypter het detecteren en het verzoek weigeren.

Ik heb zoveel sites gezien waar inloggegevens in cookies worden opgeslagen, dat iedereen eenvoudig de gebruikers-ID en gebruikersnaam in cookies kan wijzigen om toegang te krijgen tot ieders account.

Bedankt,

Antwoord 8, autoriteit 3%

TL;DR