Gegevens opslaan in sessie of niet

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Full Stack Developer Industriële Automatiseri

Raster levert slimme industriële automatiseringsoplossingen aan nationale en internationale opdrachtgevers voor wie procesveiligheid van groot belang is. We zijn sterk in spraakmakende one-off projecten in de productie- en procesautomatisering waarbij extreme engineering een terugkerend thema is. Daarbij kun je denken aan: Het veilig en duurzaam ontwerpen, plaatsen én weer opruimen van olie- en gas- productieplatformen De transformatie van de olie- en gasmarkt naar windenergie op zee Het oplossen van lokale parkeerproblematiek in dichtbevolkte steden Het cyber secure maken van kritische industriële productieomgevingen Het op afstand veilig produceren door onbemande platformen op de Noordzee Het succesvol lanceren van satellieten in de

Bekijk vacature »

Jan R

Jan R

15/11/2020 09:41:26
Quote Anchor link
Hi,

Om ts zijn topic niet te "stelen" start ik even een nieuw.
https://www.phphulp.nl/php/forum/topic/htaccess-en-leestekens-in-gebruikersnaam/103781/last/

Ik hou rollen in de sessie voor de logins welke net NIET in de database staan.
Voor deze welke wel in de database staan worden deze elke keer vernieuwd. Deze ids zijn kleiner dan 0.

session_regenerate_id heb ik wel toegevoegd. Ik had dat vroeger ook maar was blijkbaar bij de grote opkuis verdwenen:(

HTTP Authenticatie kende ik niet, wel eens gehoord in de verte, maar ik geef toch de voorkeur aan een mooi inlogformulierke.

Jan
 
PHP hulp

PHP hulp

06/12/2021 21:56:34
 
Rob Doemaarwat

Rob Doemaarwat

15/11/2020 11:32:24
Quote Anchor link
1) Zo min mogelijk gegevens in de sessie.
- Anders loop je inderdaad de kans dat de gegevens verouderd zijn (rechten ingetrokken, maar user was nog ingelogd en kan dus vrolijk doorgaan).
- Bij veel gebruikers en een "grote sessie" loopt je /tmp vol (of waar de sessie bestanden ook staan; vaak een RAM disk met beperkte omvang), en/of trekt het sowieso een grote wissel op je disk IO (elke keer die hele bups data lezen/schrijven).

2) Gegevens die voor elke call opgehaald moeten worden (gebruikersgegevens, rechten, enz) toch maar (tijdelijk) "cachen" in de sessie.
- Het scheelt een hoop requests naar de DB toe. Als de rechten via een aantal joins over rollen/profielen heen bij elkaar geharkt moeten worden zijn het meestal ook niet de meest soepele queries.
- Een initiële pagina request ("de HTML") heeft vaak direct daarna een aantal AJAX calls tot gevolg. De kans dat binnen die paar seconden de rechten zijn herzien is natuurlijk minimaal. Meestal cache ik dit soort info dan ook in de sessie met een timestamp er bij. Na een x aantal seconden wordt de informatie dan toch opnieuw opgehaald (maar hoeft dus voor die directe AJAX requests niet steeds opnieuw bepaald te worden).
 
Thomas van den Heuvel

Thomas van den Heuvel

15/11/2020 13:21:45
Quote Anchor link
Maar 2) werkt 1) in de hand. Wat is er op tegen om elke request een soort van user object te bouwen met de minimale informatie in de sessie (een user id volstaat)? Tenzij je dus een soort van omslagpunt bereikt waarbij het tijdelijk cachen duidelijke voordelen heeft ten opzichte van alles elke keer opnieuw ophalen.

Vervolgens gebruikt je applicatie (hoe dan ook) uitsluitend dit user object, en heeft de sessie in het geheel niet nodig, dit zorgt ook voor een wat nettere scheiding.
 
Rob Doemaarwat

Rob Doemaarwat

15/11/2020 13:47:04
Quote Anchor link
Dat was ook het idee: 1) is leidend, 2) moet soms toch af en toe ("omslagpunt"). Maar indien niet nodig, dan inderdaad gewoon bij 2) vandaan blijven.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.