Verlopen sessie tijd
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?
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
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.
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.
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
@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.
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.
Heeft niet echt iets met elkaar te maken.
Gewijzigd op 13/04/2016 12:52:30 door Ramon van Dongen
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.
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!
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
Blijft de session gewoon bestaan.
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 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()?
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.