Verlopen sessie tijd

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ramon van Dongen

Ramon van Dongen

13/04/2016 09:37:06
Quote Anchor link
Hallo,

2 websites van klanten draaien bij Argeweb. Nu zijn opeens de php sessies na 2 minuten verlopen. Deze instelling mag ik niet meer aanpassen.

Is dit niet heel vreemd?
 
PHP hulp

PHP hulp

04/12/2022 10:37:58
 
Thomas van den Heuvel

Thomas van den Heuvel

13/04/2016 09:42:53
Quote Anchor link
2 minuten? Da's wel erg kort. En waar blijkt dit uit? Zorgt dit voor problemen? Wat voor OS wordt daar gebruikt? Windows of Linux?

Ben benieuwd naar de redenatie van deze host.

EDIT: trouwens bijna alle sessie-instellingen zijn in principe overal instelbaar (PHP_INI_ALL) dus ze moeten wel een erg goede reden hebben waarom je hier niet aan zou mogen komen...
Gewijzigd op 13/04/2016 09:44:43 door Thomas van den Heuvel
 
Ramon van Dongen

Ramon van Dongen

13/04/2016 10:04:47
Quote Anchor link
Hoi Thomas,

Ja dit zorgt wel voor problemen.

Bijvoorbeeld iemand logt in, gaat naar een HTML formulier om een nieuwsbericht te typen. 2 minuten is dan niet heel lang, drukt op opslaan en men is al uitgelogd. Het bericht wordt dan opgeslagen zonder dat er bekend is welke gebruiker het heeft gemaakt.

Ik vind het ook heel vreemd. Heb het bij andere hosts nog nooit meegemaakt zo.

Dit is de reactie van ze toen ik vroeg of ik de instelling aan kan passen:

Beste Ramon,

Onze server ondersteunt deze optie niet, wij beheren deze instellingen zelf voor onze klanten. U kunt in dit geval geen invloed op deze timeout uitoefenen. In het verleden bleven scripts namelijk onnodig lang draaien, wat voor overlast en instabiliteit zorgde. Daarom hebben we ervoor gekozen om deze optie te wijzigen en zelf voor onze klanten te gaan beheren.

Als ik nog iets voor u kan doen, laat het me dan gerust weten



Toevoeging op 13/04/2016 10:05:33:

Heb al aangegeven dat een php sessie in mijn ogen niet echt een 'script' is wat volgens hen lang zou kunnen blijven draaien.
 
Ward van der Put
Moderator

Ward van der Put

13/04/2016 10:43:46
Quote Anchor link
Technisch heeft de provider wel een punt. Een van mijn sites heeft een supergrote cache per sessie: ongeveer 1 MiB. Bij grotere bezoekersaantallen zaten we daardoor soms zonder schijfruimte, waardoor er vervolgens helemaal geen sessie meer konden worden opgeslagen. We hebben dat toen opgelost door een paar gigabyte opslag bij te huren, door de garbage collector anders te configureren én door de sessieduur te verkorten tot 6 minuten. (Bij het doorspitten van de sitestatistieken zagen we dat 99,99% van de bezoekers altijd binnen 6 minuten een volgend request verzendt, dus zo kwamen we op die sessieduur.)

Maar, maar, maar ... dat is wel typisch iets dat je als developer liefst zelf in de hand wilt hebben. Als je site gaat lijden ander het gedrag van andere sites op dezelfde server en de provider daarom op eigen houtje dit soort kunsten gaat uithalen, wordt het tijd om op zoek te gaan naar een andere provider.

Wil je toch niet verhuizen, dan zou je het sessiebeheer kunnen aanpakken: gebruik niet het standaard sessiebeheer van PHP, maar bouw zelf een vergelijkbare oplossing.
 
Thomas van den Heuvel

Thomas van den Heuvel

13/04/2016 10:52:56
Quote Anchor link
Hm, is het mogelijk om mensen onder water "door te loggen" mocht een sessietimeout optreden tijdens het invullen van een formulier of is dit om praktische redenen niet mogelijk (omdat je bijvoorbeeld dan je hele systeem/gebruikte pakket ondersteboven zou moeten keren)?

Je zegt "opeens", dus dit is een recente wijziging? Zonder inspraak/aankondiging? Ook niet erg netjes.

Dan die reactie, wat een gel...euter. Die redenatie ook:
Quote:
In het verleden bleven scripts namelijk onnodig lang draaien, wat voor overlast en instabiliteit zorgde. Daarom hebben we ervoor gekozen om deze optie te wijzigen en zelf voor onze klanten te gaan beheren.

Dus omdat er ooit problemen waren wordt iedereen nu in een onpraktisch keurslijf gedwongen? lol. En inderdaad, sessie-functionaliteit heeft in principe niets van doen met lang draaiende, inefficiënte scripts. Klinkt alsof ze het probleem op de verkeerde manier aan het oplossen zijn?

Zit je op shared hosting? Zou dan gelijk controleren of je niet in een gezamenlijke directory je sessie-bestanden parkeert :).

Het klinkt niet alsof ze hun zaken erg goed voor elkaar hebben en/of hun klanten willen opvoeden/aanspreken op baggerscripts. Toch met klem verzoeken om timeouts weer terug aan te passen omdat je anders niet met redelijk fatsoen je eigen programmatuur kunt draaien (daarnaast is het een eenzijdig doorgevoerde, en nogal rigoreuze, actie) en als ze dat niet willen doen dan maar verhuizen :/.
Gewijzigd op 13/04/2016 10:56:29 door Thomas van den Heuvel
 
Ramon van Dongen

Ramon van Dongen

13/04/2016 12:16:01
Quote Anchor link
@Ivo; in dat geval geef ik ze inderdaad groot gelijk om je in elk geval de keuze te geven; of zij beperken iets of je huurt ruimte bij. Bij deze sites gaat het om enkele bytes. Bij 1 site zelfs alleen een gebruikers_ID. Niet heel spannend dus.

@Thomas; het is inderdaad shared hosting. Het geeft de laatste tijd pas problemen, ik verwacht dus (maar kan ik niet bewijzen) dat het pas de laatste tijd zonder aankondiging aangepast is.

Iets met onder water doorgeven zou uiteraard kunnen. Maar het gaat me nu ook wel om het principe. Deze klanten heb ik destijds vooral naar deze hostingpartij gestuurd omdat het een degelijk bedrijf is/was. Door dit opeens zo aan te passen, krijgt de klant niet waarvoor ze betaalt.

Erg vreemd dus. Gelukkig heb ik die mening dus niet alleen gezien jullie reacties.
 
Ivo P

Ivo P

13/04/2016 12:44:52
Quote Anchor link
maar wordt hier niet de levensduur van een session bestand verward met de max-run-time van een script?

Een script dat 2 minuten draait: dat is inderdaad rijkelijk lang. 30 seconden, of hooguit een minuut zou voor de meeste situaties voldoende moeten zijn.
Mogelijk als je een flinke pdf samenstelt of een groot excelsheet niet.

Maar ik vraag me af wat de session lifetime daaraan bijdraagt.
 
Ramon van Dongen

Ramon van Dongen

13/04/2016 12:52:08
Quote Anchor link
Ja inderdaad Ivo. Ik vraag om de php sessie tijd / lifetime, maar ze blijft terug komen op dat scripts lang bleven draaien vandaar dat deze instelling niet aangepast kan worden en op 2 minuten staat.

Heeft niet echt iets met elkaar te maken.
Gewijzigd op 13/04/2016 12:52:30 door Ramon van Dongen
 
Frank Nietbelangrijk

Frank Nietbelangrijk

13/04/2016 21:16:54
Quote Anchor link
Opmerkelijk zou ik het wel willen noemen. Als er meerdere websites op die shared host draaien met een login dan krijgen ze meer klanten op hun nek. Dat kan niet missen. Ik zou nog een poging wagen en het verschil tussen runtime script en sessie proberen uit te leggen. Direct zeggen dat je gedwongen wordt op op te zeggen en te verhuizen naar een andere host die het verschil wel kent. En dan maar hopen op een positief antwoord.
 
Ben van Velzen

Ben van Velzen

13/04/2016 21:40:52
Quote Anchor link
Of natuurlijk verwijzen naar dit topic, uiteraard. Want zoals gezegd: de session lifetime heeft nog minder dan niets te maken met de max execution time.
 
Ramon van Dongen

Ramon van Dongen

13/04/2016 21:45:26
Quote Anchor link
Ik heb het meerdere malen uitgelegd en ook verwezen naar dit topic... Helaas snapt Argeweb het niet of wil het niet snappen

Toevoeging op 13/04/2016 21:46:44:

In elk geval erg vreemd

Toevoeging op 14/04/2016 09:01:13:

Ze hebben gelukkig een 'oplossing' gevonden:

Quote:
Ik heb het voor de zekerheid nog even nagevraagd en het blijkt dat de timeout geen twee, maar drie minuten is. Sessies mogen dus gedurende 180 seconden lopen alvorens deze door onze server worden afgebroken. Op een gedeeld webhostingplatform zijn er helaas limieten waar u als gebruiker tegenaan kunt lopen.

Alternatief zou u een VPS kunnen overwegen waar u de server volledig zelf kunt configureren en dergelijke instellingen zelf kunt beheren. Hier ondervindt u niet de limieten welke op een gedeeld platform zijn ingesteld.


Mijn oplossing is om de verhuiscodes maar aan te vragen... Bedankt voor jullie ideeen allemaal!
 
Ramon van Dongen

Ramon van Dongen

15/04/2016 19:15:01
Quote Anchor link
Ik heb toch maar even een uitgebreid logscriptje ertussen gezet, de sessie bleef soms namelijk langer bestaan dan 2 minuten.

Nu blijkt dat soms het ip adres van de server wisselt en dan de sessie wijzigt / verdwijnt. Ze gaan ermee aan de slag nu om het op te lossen.
Gewijzigd op 15/04/2016 19:15:37 door Ramon van Dongen
 
- SanThe -

- SanThe -

17/04/2016 21:32:07
Quote Anchor link
Ik heb met Javascript (Ajax) iets gebouwd dat om de zoveel tijd even een session-var random veranderd.
Blijft de session gewoon bestaan.
 

18/04/2016 22:09:01
Quote Anchor link
Zo'n oplossing heb ik ook een keer gebouwd SanThe. Mijn probleem was dat eindgebruikers een langere sessie-tijd wilden dan dat in te stellen viel.
Maar het bouwen van een eigen sessie-handler zoals Ward voorstelt valt niet mee, het kost een hoop tijd voordat alle valkuilen zijn gedicht, zelfs als je het codevoorbeeld uit een boek haalt.
Afhankelijk van hoe gehecht je bent aan de hoster, kan je besluiten om over te stappen of een alternatieve handler te bouwen.
Overigens is het wel zo dat je gegevens niet veilig kunt stellen bij een shared host met de standaard-sessie handler van PHP. Het is algemeen bekend dat gevoelige data in een verzamelplek als /tmp terecht komt waar derden kunnen lezen en schrijven. Blijf je bij een shared host, gebruik dan een alternatieve sessie handler.
 
Thomas van den Heuvel

Thomas van den Heuvel

19/04/2016 00:26:41
Quote Anchor link
Wat je ook zou kunnen doen is
Thomas van den Heuvel op 06/04/2016 14:21:00:
Dus, in plaats van het zoeken naar oplossingen om dingen onbeperkt in stand te houden, zou je ook kunnen kijken naar oplossingen waarbij het verlopen van zaken niet langer voor problemen zorgt.


An tje op 18/04/2016 22:09:01:
Overigens is het wel zo dat je gegevens niet veilig kunt stellen bij een shared host met de standaard-sessie handler van PHP. Het is algemeen bekend dat gevoelige data in een verzamelplek als /tmp terecht komt waar derden kunnen lezen en schrijven. Blijf je bij een shared host, gebruik dan een alternatieve sessie handler.

session_save_path()?
 

19/04/2016 12:18:08
Quote Anchor link
Met session_save_path() wordt het probleem verplaatst naar een andere locatie. Als de shared host het toelaat zou je het save path kunnen instellen naar een afgeschermd deel. Dan ben je snel klaar.
Al vind ik wel dat je je bij persoonlijke gegevens altijd moet af blijven vragen welke derde partij er nog meer bij kan, want die is er bijna altijd. Bijvorbeeld de hostingpartij kan bij bestanden. Dus is het afgeschermde deel versleuteld voor de hostingpartij? En waar blijven backups, misschien ergens 'in de cloud'?
Meestal is dit het deel waarover niemand zich zorgen wil maken.
Mijn persoonlijke voorkeur is om sessie-informatie op te slaan in een database via een eigen handler, omdat je dan meer kunt vastleggen, zelf extra rechten in kunt stellen en alle data bij elkaar hebt.
 



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.