DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Thanksquote:Op dinsdag 24 juni 2008 22:37 schreef Xcalibur het volgende:
met ini_set(session.gc_maxlifetime)
Zie ook hier: http://nl.php.net/manual/en/session.configuration.php
Ja, dat probleem heb je bv met shared hosting. In Unix slaat PHP standaard z'n sessiefiles op in de /tmp directory. Maar die map is voor alle gebruikers van de server beschikbaar en anderen kunnen dan dus ook met je sessiefiles kloten.quote:Op dinsdag 24 juni 2008 22:37 schreef Xcalibur het volgende:
Overigens kunnen verschillende sites op dezelfde server elkaar qua session lifetime dwars zitten kennelijk, als ze allemaal dezelfde map gebruiken om hun session files in op te slaan... Degene met de kortste lifetime pleurt ook de sessies van de rest weg: http://www.centresource.c(...)ifetime-an-adventure
Ook kom je zo in de problemen als er meerdere webservers worden gebruikt (bv met load balancing). Dan zit je de ene request op de ene server (waar je sessie in de /tmp staat) en de volgende request misschien wel op een andere server (en kan je sessie niet meer gevonden worden, want die server heeft een andere /tmp dir).
Het is daarom altijd handig om je eigen map met sessies bij te houden, liefst een level boven je document root. Moeilijk is het niet, kwestie van even een mapje maken met schrijfrechten voor de webserver en dmv van ini_set of php.ini ervoor zorgen dat "session.save_path" de sessie-map aanwijst.
Ik begin het nut van een eigen sessiemap ook te zien inderdaad
Alleen het meerdere webservers / loadbalancing probleem los je daar niet mee op natuurlijk, dan zul je toch echt je session in een database moeten opslaan lijkt me?
Alleen het meerdere webservers / loadbalancing probleem los je daar niet mee op natuurlijk, dan zul je toch echt je session in een database moeten opslaan lijkt me?
Nee hoor, ondanks dat er meerdere webservers zijn (met meerdere /tmp directories), heb je natuurlijk wel altijd beschikking over je eigen directory met je eigen files. En dus ook je eigen sessies.quote:Op woensdag 25 juni 2008 09:00 schreef Xcalibur het volgende:
Alleen het meerdere webservers / loadbalancing probleem los je daar niet mee op natuurlijk, dan zul je toch echt je session in een database moeten opslaan lijkt me?
quote:Op dinsdag 24 juni 2008 15:59 schreef ursel het volgende:
Kheb er weer eentje
Met de exec functie probeer ik het programma ABC Amber Excel Converter aan te sturen. Heb echter al vele manieren ondertussen geprobeerd, maar tot nog toe zonder resultaat.
Als ik de ingevoerde executable in cmd knal werkt het proces wel gewoon goed.
De volgende command moet aangestuurd worden:
"C:\Program Files\ABC Amber Excel Converter\abcexcel.exe" "C:\demo.xls" "C:\demo.pdf" 3 1
Zoals je kan zien draait het dus op windows / IIS..
Overigens draaien we nog een ander programma vanaf de exec functie. Deze werkt wel gewoon goed. Permissies op beide exe files zijn identiek en zover ik heb kunnen achterhalen is op dit niveau geen verschil.
quote:Op dinsdag 24 juni 2008 16:22 schreef ursel het volgende:
[..]
Nope, dat is het niet.
Ook heb ik zelf al de slashes veranderd in / en ook geprobeerd met de bijbehorende escapes.
Iemand anders een suggestie hierop??
Hoe roep je het momenteel aan?quote:Op woensdag 25 juni 2008 11:29 schreef ursel het volgende:
[..]
[..]
Iemand anders een suggestie hierop??
In theory there is no difference between theory and practice. In practice there is.
Even snel alle varianten hier op een simpelle manier weergegeven.quote:
| 1 2 3 4 5 6 7 8 9 | $command = '\"C:\\Progra~1\\ABC_Amber_Excel_Converter\\abcexcel.exe\" \"D:\\wwwroot\\dev\\tmp\\file.xls\" \"D:\\wwwroot\\dev\\tmp\\file.csv\" 0 1'; $command = 'C:\Progra~1\ABC_Amber_Excel_Converter\abcexcel.exe D:\wwwroot\dev\tmp\file.xls D:\wwwroot\dev\tmp\file.csv 0 1'; $command = '"C:/Progra~1/ABC_Amber_Excel_Converter/abcexcel.exe" "D:/wwwroot/dev/tmp/file.xls" "D:/wwwroot/dev/tmp/file.csv" 0 1'; $command = '\"C:\/Progra~1\/ABC_Amber_Excel_Converter\/abcexcel.exe\" \"D:\/wwwroot\/dev\/tmp\/file.xls\" \"D:\/wwwroot\/dev\/tmp\/file.csv\" 0 1'; $command = 'C:/Progra~1/ABC_Amber_Excel_Converter/abcexcel.exe D:/wwwroot/dev/tmp/file.xls D:/wwwroot/dev/tmp/file.csv 0 1'; $result = exec('"'.$command.'"'); $result = exec($command); |
Waarij de combinaties (regel nummers) :
1-9
2-9
5-9
2-8
5-8
een CGI error gaven. Alle andere varianten werden wel doorlopen door PHP, maar er werd niets uitgevoerd. (Te controleren aan de hand dat er geen file.csv was.
)
Joy... Een raar probleem:
Ik maak gebruik van Net_LDAP2 (een PEAR package) en op mijn eigen machine werkt dit:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | function _get_manager($dn) { $result = "UNKNOWN"; if ($dn ) { $res = $this->ldap->dnExists($dn); if ($res instanceof Net_LDAP2_Error) { printf("%s failed due to %s\n", __FUNCTION__, "bloody hell!"); } elseif ($res === true) { $entry = $this->ldap->getEntry($dn, array('displayName')); if ($entry instanceof Net_LDAP2_Entry) { return $entry->getValue('displayName'); } } } return "UNKNOWN"; } ?> |
Ik maak gebruik van Net_LDAP2 (een PEAR package) en op mijn eigen machine werkt dit:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | User 'xxx' found, details are: Array ( [username] => xxx [name] => xxx [phone] => +31 20 xxxxxx [gsm] => +31 6 xxxxxx [title] => xxxxx [info] => Armed and dangerous [url] => http://xxxxx/ [email] => xxxxx@xxxxx [manager] => xxxxxx ) # Zelfde call, op een andere server (PHP versie is hier 5.1.5) _get_manager failed due to bloody hell! User 'xxx' found, details are: Array ( [username] => xxx [name] => xxx [phone] => +31 20 xxxxxx [gsm] => +31 6 xxxxxx [title] => xxxxx [info] => Armed and dangerous [url] => http://xxxxx/ [email] => xxxxx@xxxxx [manager] => UNKNOWN ) |
In theory there is no difference between theory and practice. In practice there is.
Ik bedoel wanneer 1 website over meerdere webservers geloadbalanced wordt...quote:Op woensdag 25 juni 2008 10:53 schreef Tijn het volgende:
Nee hoor, ondanks dat er meerdere webservers zijn (met meerdere /tmp directories), heb je natuurlijk wel altijd beschikking over je eigen directory met je eigen files. En dus ook je eigen sessies.
Als je dan op de site inlogt op server 1 staat je sessie daar in /tmp, als je daarna naar server 2 overgezet wordt heeft die geen sessie van jou en wordt je dus uitgelogd
Of zie ik nu iets over het hoofd?
Ik heb overigens inmiddels mijn eigen session folder, dat lijkt probleemloos te werken
Deze functie returnt altijd "UNKNOWN" ?quote:Op woensdag 25 juni 2008 17:08 schreef slacker_nl het volgende:
Joy... Een raar probleem:
[ code verwijderd ]
Nee, de eerste array is daar wel gevuldquote:Op woensdag 25 juni 2008 21:19 schreef Xcalibur het volgende:
[..]
Deze functie returnt altijd "UNKNOWN" ?
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Nee, dat klopt preciesquote:Op woensdag 25 juni 2008 21:16 schreef Xcalibur het volgende:
[..]
Ik bedoel wanneer 1 website over meerdere webservers geloadbalanced wordt...
Als je dan op de site inlogt op server 1 staat je sessie daar in /tmp, als je daarna naar server 2 overgezet wordt heeft die geen sessie van jou en wordt je dus uitgelogd
Of zie ik nu iets over het hoofd?
Dat is ook gelijk het voordeel van een eigen sessie-map, want dan ben je dus niet meer afhankelijk van de server waar je op zit. Je hebt namelijk ongeacht je webserver altijd de beschikking over je eigen directories.Ik doe het ook voor alle sites die ik maak. Het kost weinig moeite en scheelt veel problemenquote:Ik heb overigens inmiddels mijn eigen session folder, dat lijkt probleemloos te werken
Nee, op regel 11 staat ook nog een return. Met de goede voorwaarden wordt die uitgevoerd en dan de return op regel 15 niet.quote:Op woensdag 25 juni 2008 21:19 schreef Xcalibur het volgende:
[..]
Deze functie returnt altijd "UNKNOWN" ?
Het kost inderdaad erg weinig moeite, ik had het een stuk lastiger verwachtquote:Op woensdag 25 juni 2008 21:24 schreef Tijn het volgende:
Ik doe het ook voor alle sites die ik maak. Het kost weinig moeite en scheelt veel problemen
Is wel een blijvertje inderdaad....
Wat gebruik jij als session lifetime over het algemeen? De default 24 minuten is duidelijk te kort
Je hebt gelijk, had ik overheen gekeken.quote:Op woensdag 25 juni 2008 21:33 schreef Light het volgende:
Nee, op regel 11 staat ook nog een return. Met de goede voorwaarden wordt die uitgevoerd en dan de return op regel 15 niet.
Ik gebruik zelf altijd maar 1 return statement, dus ik verwachtte die andere ook niet
Ik sla het SID op in een cookie en gebruik dat om de sessie te starten/resumen. Een sessie gaat dan niet verloren wanneer de browser wordt afgesloten. Maar wat er gebeurt wanneer een pagina 24 minuten lang staat te idlen weet ik eigenlijk niet precies.quote:Op woensdag 25 juni 2008 21:40 schreef Xcalibur het volgende:
[..]
Wat gebruik jij als session lifetime over het algemeen? De default 24 minuten is duidelijk te kort
Een autologin dus in principe?
Die heb ik al, dat is op zich wel een oplossing maar niet altijd wenselijk lijkt me....
Ik heb nou de afgelopen 3 weken al van 5 verschillende klanten dat soort vage session timeout error gehoord, toch typisch... wat DOEN die mensen al die tijd tijdens het invullen van een formuliertje enzo
Die heb ik al, dat is op zich wel een oplossing maar niet altijd wenselijk lijkt me....
Ik heb nou de afgelopen 3 weken al van 5 verschillende klanten dat soort vage session timeout error gehoord, toch typisch... wat DOEN die mensen al die tijd tijdens het invullen van een formuliertje enzo
Dat is gewoon afhankelijk van de expiry time die je in de cookie instelt. Als je daar 31 december 2038 invult zoals google dan kunnen mensen gaan schijten tot ze een ons wegen, de sessie expire't niet.quote:Op woensdag 25 juni 2008 21:54 schreef Tijn het volgende:
[..]
Ik sla het SID op in een cookie en gebruik dat om de sessie te starten/resumen. Een sessie gaat dan niet verloren wanneer de browser wordt afgesloten. Maar wat er gebeurt wanneer een pagina 24 minuten lang staat te idlen weet ik eigenlijk niet precies.
Als je 24 minuten geen pagina opvraagt dan bestaat de sessie niet meer. Dan heb je niets meer aan je cookie.quote:Op woensdag 25 juni 2008 21:54 schreef Tijn het volgende:
[..]
Ik sla het SID op in een cookie en gebruik dat om de sessie te starten/resumen. Een sessie gaat dan niet verloren wanneer de browser wordt afgesloten. Maar wat er gebeurt wanneer een pagina 24 minuten lang staat te idlen weet ik eigenlijk niet precies.
Hmmja, nu ga ik zelf twijfelen.quote:Op woensdag 25 juni 2008 22:04 schreef Farenji het volgende:
[..]
Dat is gewoon afhankelijk van de expiry time die je in de cookie instelt. Als je daar 31 december 2038 invult zoals google dan kunnen mensen gaan schijten tot ze een ons wegen, de sessie expire't niet.
Neequote:Op woensdag 25 juni 2008 21:19 schreef Xcalibur het volgende:
[..]
Deze functie returnt altijd "UNKNOWN" ?
Maar dat heb je al gezien..
In theory there is no difference between theory and practice. In practice there is.
Echt wel, gewoon je cookie wegflikkeren.quote:Op woensdag 25 juni 2008 22:04 schreef Farenji het volgende:
[..]
Dat is gewoon afhankelijk van de expiry time die je in de cookie instelt. Als je daar 31 december 2038 invult zoals google dan kunnen mensen gaan schijten tot ze een ons wegen, de sessie expire't niet.
In theory there is no difference between theory and practice. In practice there is.
Is het mogelijk om in PHP mee te geven dat de browser de pagina niet moet cachen?
Want er wijzigt constant data op de website, echter als ik de URL in tik zonder de browser te sluiten zie ik de wijzigingen niet, pas na een harde refresh (F5) zie ik de gewijzigde data, dus hij onthoud het in zijn cache.
Want er wijzigt constant data op de website, echter als ik de URL in tik zonder de browser te sluiten zie ik de wijzigingen niet, pas na een harde refresh (F5) zie ik de gewijzigde data, dus hij onthoud het in zijn cache.
ne okuyon, bokmu var?
quote:Op donderdag 26 juni 2008 10:20 schreef saban het volgende:
Is het mogelijk om in PHP mee te geven dat de browser de pagina niet moet cachen?
Want er wijzigt constant data op de website, echter als ik de URL in tik zonder de browser te sluiten zie ik de wijzigingen niet, pas na een harde refresh (F5) zie ik de gewijzigde data, dus hij onthoud het in zijn cache.
| 1 2 3 4 | header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1 header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past ?> |
zie ook http://www.php.net/header :-)
quote:Op donderdag 26 juni 2008 10:20 schreef saban het volgende:
Is het mogelijk om in PHP mee te geven dat de browser de pagina niet moet cachen?
| 1 2 3 4 | header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1 header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past ?> |
Wat Tiemie zegt dus
Om helemaal bitneukerig te zijn kan je zelfs stellen dat dit HTTP headers zijn, geen PHP headersquote:Op donderdag 26 juni 2008 10:36 schreef Tijn het volgende:
[..]
[ code verwijderd ]
Wat Tiemie zegt dus
[ Bericht 0% gewijzigd door #ANONIEM op 26-06-2008 10:53:48 ]
Het zijn HTTP-headers. Met HTML heeft dit weinig te maken.quote:Op donderdag 26 juni 2008 10:46 schreef Scorpie het volgende:
[..]
Om helemaal bitneukerig te zijn kan je zelfs stellen dat dit HTML headers zijn, geen PHP headers
Je hebt helemaal gelijkquote:Op donderdag 26 juni 2008 10:50 schreef Tijn het volgende:
[..]
Het zijn HTTP-headers. Met HTML heeft dit weinig te maken.
Maakte die typo omdat ik met een cursus HTML bezig ben voor mijn zwager 
Ik haalde die 2 door elkaar. Bedoelde HTTP headers te schrijven, schreef ipv daarvan HTMLquote:Op donderdag 26 juni 2008 11:39 schreef GI het volgende:
HTML naar HTTP is geen typo. Das gewoon een fout
EN NU WEER BACK ONTOPIC JA!
