Ik begin me net te beginnen met het leren van de ontwikkeling van webtoepassingen, met behulp van Python. Ik kom over de termen ‘cookies’ en ‘sessies’. Ik begrijp cookies in dat ze wat info opslaan in een belangrijke waardepaar in de browser. Maar ik heb een beetje verwarring over sessies, ook in een sessie slaan we gegevens op in een cookie in de browser van de gebruiker.

Bijvoorbeeld – ik log in met username='rasmus'en password='default'. In een dergelijk geval worden de gegevens gepost op de server die mij moet controleren en inloggen indien geverifieerd. Tijdens het hele proces genereert de server echter ook een sessie-ID die zal worden opgeslagen in een cookie in mijn browser. Nu slaat de server deze sessie-ID op in zijn bestandssysteem of datastore.

Maar op basis van alleen de sessie-ID, hoe zou het mijn gebruikersnaam kunnen kennen tijdens mijn daaropvolgende traversal via de site? Wist het de gegevens op de server als een dict waar de toets een sessie-ID zou zijn en details zoals username, emailetc. zijn de waarden?

Ik word hier behoorlijk in de war. Hulp nodig.

Antwoord 1, Autoriteit 100%

Omdat HTTP staatloos is, om een ​​verzoek aan een ander verzoek te associëren, hebt u een manier nodig om gebruikersgegevens tussen HTTP-aanvragen op te slaan.

Cookies of URL-parameters (voor ex. zoals http://example.com/mypage ? ASD = LOL & AMP; BOO = NO ) zijn beide geschikte manieren om gegevens tussen 2 of meer verzoek te vervoeren.
Ze zijn echter niet goed voor het geval je niet wilt dat dat gegevens leesbaar / bewerkbaar zijn op de kant van de klant.

De oplossing is om die kant van de dataserver op te slaan, er een “id” aan te geven en de client alleen dat ID te laten weten (en bij elk http-verzoek terug te geven). Ziezo, sessies geïmplementeerd. Of u kunt de client gebruiken als een handige externe opslag, maar u zou de gegevens versleutelen en de geheime serverkant bewaren.

Natuurlijk zijn er andere aspecten waarmee u rekening moet houden, zoals u niet wilt dat mensen sessies van anderen kapen, u wilt dat sessies niet voor altijd duren maar verlopen, enzovoort.

In uw specifieke voorbeeld wordt de gebruikers-ID (kan een gebruikersnaam of een andere unieke ID in uw gebruikersdatabase zijn) opgeslagen in de sessiegegevens, server-side, na succesvolle identificatie. Voor elk HTTP-verzoek dat u van de client ontvangt, verwijst de sessie-ID (gegeven door de client) u naar de juiste sessiegegevens (opgeslagen door de server) die de geverifieerde gebruikers-ID bevatten – op die manier weet uw code welke gebruiker het is praat met.

Antwoord 2, autoriteit 35%

Uitleg via Afbeeldingen:

Eenvoudige uitleg naar analogie

Stel je voor dat je bij een bank zit en probeert wat geld van je rekening te halen. Maar het is donker; de bank is pikdonker: er is geen licht en je kunt je hand niet voor je gezicht zien. Je wordt omringd door nog eens 20 mensen. Ze zien er allemaal hetzelfde uit. En iedereen heeft dezelfde stem. En iedereen is een potentiële slechterik. Met andere woorden, HTTP is staatloos.

Deze bank is een grappig type bank – omwille van het argument, hier is hoe de dingen werken:

1. je wacht in de rij (of online) en je praat met de baliemedewerker: je doet een verzoek om geld op te nemen, en dan
2. je moet even op de bank wachten, en 20 minuten later
3. je moet je geld daadwerkelijk gaan ophalen bij de balie.

Maar hoe zal de teller jou onderscheiden van alle anderen?

De baliemedewerker kan je niet zien of herkennen, denk eraan, omdat de lichten allemaal uit zijn. Wat als uw bankier uw opname van $ 10.000 aan iemand anders geeft – de verkeerde persoon?! Het is absoluut essentieel dat de bankier u kan herkennen als degene die de opname heeft gedaan, zodat u het geld (of de hulpbron) kunt krijgen waar u om heeft gevraagd.

Oplossing:

Als je voor het eerst bij de baliemedewerker verschijnt, vertelt hij of zij je in het geheim iets:

“Als je ooit met me praat”, zegt de baliemedewerker, “moet je jezelf eerst identificeren als GNASHEU329 – op die manier weet ik dat jij het bent”.

Niemand anders kent de geheime toegangscode.

Voorbeeld van hoe ik geld opnam:

Dus ik besluit om 20 minuten te gaan chillen en later ga ik naar de balie en zeg: “Ik wil mijn geld opnemen”

De kassier vraagt me: “wie ben jij??!”

“Ik ben het, meneer George Banks!”

“Bewijs het!”

En dan vertel ik ze mijn toegangscode: GNASHEU329

“Zeker, meneer Banks!”

Zo werkt een sessie eigenlijk. Het maakt het mogelijk om uniek te worden geïdentificeerd in een zee van miljoenen mensen. U moet zich elke keer dat u met de kassier omgaat, identificeren.

Als je vragen hebt of onduidelijk bent, plaats dan een reactie en ik zal proberen het voor je op te lossen. Het volgende is strikt genomen niet helemaal juist in termen van terminologie, maar ik hoop dat het je helpt bij het begrijpen van concepten.

Antwoord 3, autoriteit 10%

“Sessie” is de term die wordt gebruikt om te verwijzen naar de tijd die een gebruiker op een website doorbrengt. Het is bedoeld om de tijd weer te geven tussen hun eerste aankomst op een pagina op de site en het moment dat ze de site niet meer gebruiken. In de praktijk is het onmogelijk om te weten wanneer de gebruiker klaar is met de site. Op de meeste servers is er een time-out die een sessie automatisch beëindigt, tenzij dezelfde gebruiker een andere pagina opvraagt.

De eerste keer dat een gebruiker verbinding maakt, wordt er een soort sessie-ID gemaakt (hoe dit wordt gedaan, hangt af van de webserversoftware en het type authenticatie/login dat u op de site gebruikt).
Net als cookies wordt dit meestal niet meer in de URL verzonden omdat het een beveiligingsprobleem is. In plaats daarvan wordt het opgeslagen samen met een heleboel andere dingen die gezamenlijk ook wel de sessie worden genoemd. Sessievariabelen zijn als cookies – het zijn naam-waardeparen die worden meegestuurd met een verzoek om een pagina en worden geretourneerd met de pagina van de server – maar hun namen zijn gedefinieerd in een webstandaard.

Sommige sessievariabelen worden doorgegeven als HTTP-headers. Ze worden heen en weer gestuurd achter de schermen van elke pagina die bladert, zodat ze niet in de browser verschijnen en iedereen iets vertellen dat mogelijk privé is. Onder hen zijn de USER_AGENT, of het type browser dat de pagina opvraagt, de REFERRER of de pagina die is gekoppeld aan de pagina die wordt opgevraagd, enz. Sommige webserversoftware voegt hun eigen headers toe of draagt aanvullende sessiegegevens over die specifiek zijn voor de serversoftware. Maar de standaardversies zijn redelijk goed gedocumenteerd.

Hopelijk helpt dat.

Antwoord 4, autoriteit 4%

HTTP is een staatloos verbindingsprotocol, dat wil zeggen dat de server geen onderscheid kan maken tussen verschillende verbindingen van verschillende gebruikers.

Vandaar Cookie, zodra een klant de eerste keer op een server verbindt, genereert de server een nieuwe sessie-ID, die later naar de klant wordt verzonden als cookie-waarde. En vanaf nu zal deze sessie-ID die clientverbinding identificeren, omdat binnen elk HTTP-verzoek de juiste sessie-ID in cookies zal zien.

Nu voor elke sessie-ID, houdt de server wat data-structuur, waardoor hij gegevens kan opslaan die specifiek is voor de gebruiker, deze gegevensstructuur die u abstracte sessie kunt noemen.

Antwoord 5, Autoriteit 2%

Denk aan http als een persoon (a) die geheugenverlies op korte termijn heeft en elke persoon vergeet zodra die persoon uit het zicht gaat.

Nu, om verschillende personen te onthouden, neemt A een foto van die persoon en houdt het. De foto van elke persoon heeft een ID-nummer. Wanneer die persoon weer in zicht komt, vertelt die persoon het ID-nummer aan A en A vindt hun foto per ID-nummer.
En voila !!, een weet wie die persoon is.

hetzelfde is met http. Het lijdt aan geheugenverlies op korte termijn. Het gebruikt sessies om alles wat u deed te maken tijdens het gebruik van een website, en dan, wanneer u weer komt, identificeert het u met de hulp van cookies (cookie is als een token).
Afbeelding is hier de sessie en ID is hier de cookie.