nicht angemeldet
WELCHE Dateien werden aus dem session.save_path gelöscht?
Robert R.
WELCHE Dateien werden aus dem session.save_path gelöscht?
Robert R.
AugeLiebe Mitdenker,
liebe Wissende,
liebe Neugierige,
ja!
Da ist sie, meine Frage zu PHP-Sessions:
Wo wird eingestellt, _welche_ Dateien aus dem Session-Verzeichnis gelöscht werden sollen?
Bekannt sind mir bisher die INI-Einstellungen zum
- session-save_path
- session.gc_maxlifetime & Co
Aber wo das Präfix "sess_" festgelgt ist, hab ich noch nicht gefunden.
Außerdem hätte ich gerne eine Funktion, um solch einen Sessionamen selber auszuwürfeln. Meine alte ist wohl überholt. Inzwischen sind da ganz viel neue Zeichen in den Vorrat aufgenommen worden. Welche sind zulässig?
Die Länge scheint aber geblieben zu sein.
Der Sinn der Übung?
Ich möchte Uploaddateien temporär in einem Verzeichnis unterbringen, aus der sie, soe wie die Sessiondateien selber, nach einiger Zeit der Nichtbeachtung wieder entfernt werden, ohne dass man sich darum kümmen muss. Da könnte das Session-Verzeichnis doch ganz praktisch sein. Oder steht dem etwas entgegen?
Spirituelle Grüße
Euer Robert
--
Möge der Forumsgeist wiederbelebt werden!
Möge der Forumsgeist wiederbelebt werden!
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,Ich möchte Uploaddateien temporär in einem Verzeichnis unterbringen, aus der sie, soe wie die Sessiondateien selber, nach einiger Zeit der Nichtbeachtung wieder entfernt werden, ohne dass man sich darum kümmen muss. Da könnte das Session-Verzeichnis doch ganz praktisch sein. Oder steht dem etwas entgegen?
Ja, die Möglichkeit, ein Upload OHNE temporäre Dateien zu machen.
MfG
-
Lieber Hotti,
Ich möchte Uploaddateien temporär in einem Verzeichnis unterbringen, aus der sie, soe wie die Sessiondateien selber, nach einiger Zeit der Nichtbeachtung wieder entfernt werden, ohne dass man sich darum kümmen muss. Da könnte das Session-Verzeichnis doch ganz praktisch sein. Oder steht dem etwas entgegen?
Ja, die Möglichkeit, ein Upload OHNE temporäre Dateien zu machen.
Bringst Du da etwas durcheinander?
Temporäre Dateien kann man für den erwünschten Zweck nicht nutzen, denn die verschwinden zwischen den Roundturns. Die hochgeladenen Dateien sollen aber einige Roundturns überleben.Man könnte die hochgeladene Datei bestimmt in der Sessiondatei zwischenspeichern. Aber bei größeren Bildern wird das schon eklig. Also kam ich auf die Idee, für jedes Dokument/Bild eine eigene Sessiondatei anzulegen. Die muss, solange sie nicht bearbeitet wird, nicht im Arbeitsspeicher liegen. Platte reicht.
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!-
Hallo
Lieber Hotti,
Ich möchte Uploaddateien temporär in einem Verzeichnis unterbringen, aus der sie, soe wie die Sessiondateien selber, nach einiger Zeit der Nichtbeachtung wieder entfernt werden, ohne dass man sich darum kümmen muss. Da könnte das Session-Verzeichnis doch ganz praktisch sein. Oder steht dem etwas entgegen?
Ja, die Möglichkeit, ein Upload OHNE temporäre Dateien zu machen.
Bringst Du da etwas durcheinander?
Temporäre Dateien kann man für den erwünschten Zweck nicht nutzen, denn die verschwinden zwischen den Roundturns.Du sollst sie laut hotti nicht nutzen.
Man könnte die hochgeladene Datei bestimmt in der Sessiondatei
zwischenspeichern.
Eine Session-Datei ist eine Textdatei.
Aber bei größeren Bildern wird das schon eklig. Also kam ich auf die Idee, für jedes Dokument/Bild eine eigene Sessiondatei anzulegen.
Das heißt, dass der zugehörige benutzer jedesmal die Session wechselt, alte Sessions ihm also nicht mehr zugeordnet werden können. Was passiert mit den verwaisten Bildern?
Die muss, solange sie nicht bearbeitet wird, nicht im Arbeitsspeicher liegen. Platte reicht.
Das passiert normalerweise sowieso. Welchen Zeitraum gedenkst du damit überhaupt zu überbrücken? Warum sollte irgendwer sich die Mühe machen, Bilder heraufzuladen, die dann wieder gelöscht werden?
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
Veranstaltungsdatenbank Vdb 0.3-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Hallo Auge,
sehr guter Hinweis. Danke.
Man könnte die hochgeladene Datei bestimmt in der Sessiondatei
zwischenspeichern.Eine Session-Datei ist eine Textdatei.
Die Daten müssten also z. B. base64 codiert werden, sonst kracht es.
Das heißt, dass der zugehörige benutzer jedesmal die Session wechselt, alte Sessions ihm also nicht mehr zugeordnet werden können. Was passiert mit den verwaisten Bildern?
Nein, die Stamm-Session kann für die Dauer des Zugriffs auf eine weitere Sessiondatei unterbrochen werden und anschließend wiederaufgenommen werde.
Ich werde mal ein paar "normale" Dateien im Sessionverzeichnis plazieren und schauen, ob die auch aufgeräumt werden. Das scheint mir noch die sauberste Lösung zu sein. Die Trennung, die Chris zu Recht reklamiert, kann man vielleicht durch ein anderes Präfix erreichen.
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!
-
-
Lieber Hotti,
Ich möchte Uploaddateien temporär in einem Verzeichnis unterbringen, aus der sie, soe wie die Sessiondateien selber, nach einiger Zeit der Nichtbeachtung wieder entfernt werden, ohne dass man sich darum kümmen muss. Da könnte das Session-Verzeichnis doch ganz praktisch sein. Oder steht dem etwas entgegen?
Ja, die Möglichkeit, ein Upload OHNE temporäre Dateien zu machen.
Bringst Du da etwas durcheinander?
Dir fehlt das Hintergrundwissen: Beim Upload mit dem Enctype="multipart/form-data" wird grundsätzlich eine temporäre Datei angelegt wenn in einer der Multipart-Komponenten der Parameter file="Dein_Upload_Input_Feld" gesetzt ist. Bei mehreren Upload-Feldern mit dem type="file" sind es dementsprechend mehrere temporäre Dateien.
Die Sicherheitslücke besteht darin, dass in dem Zeitraum, wo es diese temporären Dateien gibt, ein Eindringling (Hacker) auf dem Server auch Zugriff darauf hat. Ein bösartiger Hacker kann diese Daten also für eigene Zwecke missbrauchen, ohne dass der Anwender etwas davon mitbekommt. Dieses Problem betrifft sowohl Perl als auch PHP, wobei es in PHP wahrscheinlich wie in Perl eine Möglichkeit gibt, zumindest den Zugriff auf diese temp. Dateien einzuschränken.
Unabhängig davon besteht immer die Gefahr, dass solche temporären Dateien als Leichen verbleiben.
Temporäre Dateien kann man für den erwünschten Zweck nicht nutzen, denn die verschwinden zwischen den Roundturns. Die hochgeladenen Dateien sollen aber einige Roundturns überleben.
Wie ich bereits schrieb: Auf temporäre Dateien verzichten, die hochgeladenen Bytesequenzen direkt aus STDIN lesen und gleich da speichern wo sie hinsollen.
MfG
-
Dir fehlt das Hintergrundwissen:
Dir auch.
Beim Upload mit dem Enctype="multipart/form-data" wird grundsätzlich eine temporäre Datei angelegt [...] Dieses Problem betrifft sowohl Perl als auch PHP, wobei es in PHP wahrscheinlich wie in Perl eine Möglichkeit gibt, zumindest den Zugriff auf diese temp. Dateien einzuschränken.
Quatsch. Bei PHP vielleicht. In Perl nur dann, wenn Du CGI.pm einsetzt. Dort lässt es aber auch abschalten:
-
Dir fehlt das Hintergrundwissen:
Dir auch.
Beim Upload mit dem Enctype="multipart/form-data" wird grundsätzlich eine temporäre Datei angelegt [...] Dieses Problem betrifft sowohl Perl als auch PHP, wobei es in PHP wahrscheinlich wie in Perl eine Möglichkeit gibt, zumindest den Zugriff auf diese temp. Dateien einzuschränken.
Quatsch. Bei PHP vielleicht. In Perl nur dann, wenn Du CGI.pm einsetzt. Dort lässt es aber auch abschalten:
Na bitte, gibt ja doch auch andere Möglichkeiten, das Anlegen temp. Files abzuschalten.
-
Na bitte, gibt ja doch auch andere Möglichkeiten, das Anlegen temp. Files abzuschalten.
Wie "na bitte"? Erst behauptet Du fälschlicherweise, dass grundsätzlich temporäre Dateien erzeugt werden und es evtl. aber Möglichkeiten gibt, den _Zugriff_ auf diese einzuschränken. Dann wirst du zumindest für Perl (AFAIR mittlerweile sogar bei PHP) eines Besseren belehrt und sagst "na bitte"!?! LOL
-
Na bitte, gibt ja doch auch andere Möglichkeiten, das Anlegen temp. Files abzuschalten.
Wie "na bitte"? Erst behauptet Du fälschlicherweise, dass grundsätzlich temporäre Dateien erzeugt werden und es evtl. aber Möglichkeiten gibt, den _Zugriff_ auf diese einzuschränken. Dann wirst du zumindest für Perl (AFAIR mittlerweile sogar bei PHP) eines Besseren belehrt und sagst "na bitte"!?! LOL
Mensch Kerle, kennst Du alle Möglichkeiten, wo Dir eine PL bietet, Deine Programme so zu bauen, dass sie genau das machen, was Du willst?
PHP wie Perl-Porter und CPAN-Autoren sind auch nur Menschen da ist Bewegung drin und da steht die Entwicklung niemals still. Es ist ausgeschlossen, alles zu kennen, was mit bestimmten Modulen im Einzelnen möglich ist und wenn, dann ist das eine Momentaufnahme.
MfG
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
-
-
-
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Lieber Hotti,
Ja, die Möglichkeit, ein Upload OHNE temporäre Dateien zu machen.
Bringst Du da etwas durcheinander?
Dir fehlt das Hintergrundwissen: Beim Upload mit dem Enctype="multipart/form-data" wird grundsätzlich eine temporäre Datei angelegt wenn in einer der Multipart-Komponenten der Parameter file="Dein_Upload_Input_Feld" gesetzt ist.
Bei PHP kümmert sich das Runtime um die Beseitigung der Datei am Scriptende und nicht das OS/Filesystem. Das ist bei Linux schönzu beobachten. Es wird zwar das (eingestellte) tmp-Verzeichnis benutzt, nicht aber der Mechanismus für Temporärdateien. Es werden ganz normale Dateien benutzt. Soviel erst einmal zur Nachhilfe!
Ich möchte nun Dateien haben, die während der ganzen Session des Users bereit gehalten werden, beginnend vom Upload innerhalb der Sessiontime.
@Chris:
im Prinzip gut, Daten nach ihrer Bestimmung getrennt zu halten. Aber einen zusätzlichen Mechanismus zu bauen, der nichts anderes tut, als der bereits vorhandene, ist schlechtes Design. "Soetwas tut man nicht" ;-)Ich werde daher mit den Parametern der Session mal rumspielen, um die Voraussetzungen für eine empirische Untersuchung zu schaffen. Mich interessiert, welche Dateien vom Garbage Controller aus dem Verzeichnis gelöscht werden. Vielleicht ist doch nur der Last-Access-Stempel von Belang, nicht aber der Name?
Das wäre günstig.
------ end of Chris' section -------Die Sicherheitslücke besteht darin, dass in dem Zeitraum, wo es diese temporären Dateien gibt, ein Eindringling (Hacker) auf dem Server auch Zugriff darauf hat.
Für diesen Fall ohne Belang.
Unabhängig davon besteht immer die Gefahr, dass solche temporären Dateien als Leichen verbleiben.
Jetzt kann ich Dir nicht folgen. Du weißt schon, wovon mein Thread eigentlich handelt?
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!-
Mahlzeit,
Ich möchte nun Dateien haben, die während der ganzen Session des Users bereit gehalten werden, beginnend vom Upload innerhalb der Sessiontime.
Dann mach das so. Sessions werden per Cron aufgeräumt, zumindest unter Linux.
Also entweder baust du dir nen passenden Sessionhandler, der die Bilder nach Ablauf der Session löscht oder du fährst das ganze "per Hand"
Bei einem eigenen Session-Handler kannst du im GC festlegen, dass er dann die Bilder löschen soll.--
eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Liebe(r) M.,
Ich möchte nun Dateien haben, die während der ganzen Session des Users bereit gehalten werden, beginnend vom Upload innerhalb der Sessiontime.
Dann mach das so. Sessions werden per Cron aufgeräumt, zumindest unter Linux.
Also entweder baust du dir nen passenden Sessionhandler, der die Bilder nach Ablauf der Session löscht oder du fährst das ganze "per Hand"
Bei einem eigenen Session-Handler kannst du im GC festlegen, dass er dann die Bilder löschen soll.Ich werde mir nur eine neue Funktion zum Auswürfeln eines Sessiondateinamen erstellen und dann den vorhandenen Mechanismus mitbenutzen. Bleiben nur die Fragen
1. Welche Zeichen für den Zeichenvorrat?
2. Welche Namen räumt der GC weg?
3. Schaut der auch rein in die Datei, oder geht der nur nach dem Lasr-Access-Stempel?Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!-
Mahlzeit,
- Welche Zeichen für den Zeichenvorrat?
Alle, die der Zeichensatz des Zielservers hergibt.
- Welche Namen räumt der GC weg?
Der räumt die Session weg. Namen sind Schal und Rauch
- Schaut der auch rein in die Datei, oder geht der nur nach dem Lasr-Access-Stempel?
Keine Ahnung, meine Sessions liegen in der Datenbank und da wird nach Zeitstempel gelöscht.
--
eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...
-
-
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,Unabhängig davon besteht immer die Gefahr, dass solche temporären Dateien als Leichen verbleiben.
Jetzt kann ich Dir nicht folgen.
Wenn ein Prozess stirbt, werden temp. Dateien möglicherweise nicht abgeräumt (meine Güte, ich drück mich ja schon ganz vorsichtig aus *G).
Du weißt schon, wovon mein Thread eigentlich handelt?
Ja, Du möchtest die hochgeladenen Dateien über eine Session behalten. PHP nutzt für Session-Dateien einen Serializer, der binärsicher arbeitet. D.h., Du könntest die hochgeladenen Dateien auch in der Session-Datei speichern, ohne dass Du da mit Base64 was machen musst, da kannst Du einfach in das Session-Array greifen, diesbezügliche Schlüssel legst Du selbst fest.
Nun kommts natürlich darauf an, wie groß die Dateien sind, wenns ein bischen mehr sein darf im dreistelligen Megabytebereich, bremst die Größe der Sessiondatei die ganze Session aus. Da wird Dir nur ein Eigenbau übrigbleiben, ggf. auch eine Speicherung im MySQL mit der Session-ID (die hast Du ja) zusammen mit einer fortlaufenden Nummer (autoincrement) als primary Key. Das Aufräumen einer solchen Tabelle ist dann nebensächlich, bei einer Million Einträgen würde ich darüber nachdenken :)
MfG
-
Tach!
im Prinzip gut, Daten nach ihrer Bestimmung getrennt zu halten. Aber einen zusätzlichen Mechanismus zu bauen, der nichts anderes tut, als der bereits vorhandene, ist schlechtes Design. "Soetwas tut man nicht" ;-)
Machst du ja nicht, er räumt ja andere Dateien auf. Ansonsten kannst du ja auch den Session-Handler komplett selbst implementieren, der dann auch andere Dateien berücksichtigen kann.
dedlfix.
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Tach!
und Tach zurück :-)
im Prinzip gut, Daten nach ihrer Bestimmung getrennt zu halten. Aber einen zusätzlichen Mechanismus zu bauen, der nichts anderes tut, als der bereits vorhandene, ist schlechtes Design. "Soetwas tut man nicht" ;-)
Machst du ja nicht, er räumt ja andere Dateien auf. Ansonsten kannst du ja auch den Session-Handler komplett selbst implementieren, der dann auch andere Dateien berücksichtigen kann.
Das war doch eine meiner Fragen, ob der GC ALLE Dateien im session.save_path aufräumt.
Ich habe es bisher noch nicht nachvollziehen können. Da muss ich erst eine Testumgebung einrichten, in der ich alle Parameter von session.???? frei verkurbeln kann. Mit zwei Clients bekomme ich sonst nicht genug Sessionaufrufe hin, um den GC zum Arbeiten zu bewegen.
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!-
Tach!
Das war doch eine meiner Fragen, ob der GC ALLE Dateien im session.save_path aufräumt.
Ich glaube nicht. Wenn das im globalen Temp-Verzeichnis wäre, würden sich die anderen Anwendungen bedanken. Selbst wenn Session- und andere temporäre Datei nur einer Anwendung in einem separaten Verzeichnis stünden, da allerdings gemeinsam, wäre das kein bejubelnswertes Vorgehen.
Ich habe es bisher noch nicht nachvollziehen können. Da muss ich erst eine Testumgebung einrichten, in der ich alle Parameter von session.???? frei verkurbeln kann. Mit zwei Clients bekomme ich sonst nicht genug Sessionaufrufe hin, um den GC zum Arbeiten zu bewegen.
Es gibt zwei Parameter (mit gc im Namen), die die Startwahrscheinlichkeit steuern. Die entsprechend setzen und dann läuft er immer los.
dedlfix.
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Das war doch eine meiner Fragen, ob der GC ALLE Dateien im session.save_path aufräumt.
Ich glaube nicht. Wenn das im globalen Temp-Verzeichnis wäre, würden sich die anderen Anwendungen bedanken. Selbst wenn Session- und andere temporäre Datei nur einer Anwendung in einem separaten Verzeichnis stünden, da allerdings gemeinsam, wäre das kein bejubelnswertes Vorgehen.
Da ist wahrscheinlich (noch nicht überprüft) gar kein Problem, da echjte temporäte Dateien im tmp-Verzeichnis zunlichst mit dem t-Flag markiert werden. Da würde der GC die gar nicht in die Finger bekommen, auch wenn er aus einem PHP-Modul kommt. Da schreddert er dann (vermutlich) nur die Dateien aller PHP-Nutzer, die das Modul nutzen und keine INI-Einstellung für session.save_path vorgenommen haben.
Ich habe es bisher noch nicht nachvollziehen können. Da muss ich erst eine Testumgebung einrichten, in der ich alle Parameter von session.???? frei verkurbeln kann. Mit zwei Clients bekomme ich sonst nicht genug Sessionaufrufe hin, um den GC zum Arbeiten zu bewegen.
Es gibt zwei Parameter (mit gc im Namen), die die Startwahrscheinlichkeit steuern. Die entsprechend setzen und dann läuft er immer los.
Jo! Die werde ich mal besonders ins Auge nehmen.
Mein PC läuft nun auf wundersame wieder. Mal sehen, ob er morgen auch noch wieder Kaltstart kann.
Da kann ich jetzt mal 'was einrichten.Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!
-
-
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,im Prinzip gut, Daten nach ihrer Bestimmung getrennt zu halten. Aber einen zusätzlichen Mechanismus zu bauen, der nichts anderes tut, als der bereits vorhandene, ist schlechtes Design. "Soetwas tut man nicht" ;-)
Machst du ja nicht, er räumt ja andere Dateien auf. Ansonsten kannst du ja auch den Session-Handler komplett selbst implementieren, der dann auch andere Dateien berücksichtigen kann.
Immer noch die Frage, wie Session-IDs heute festgelegt werden.
Alt: sess_19c179ad7fa02a491947c33d9d2552e8
Neu: sess_u9488q6an4jhqc6df23hh9oqa3
Neu: sess_eo6esqn6t4tm8pejj4b7431q83
Neu: sess_f1foe0pjcb0or5f98clr6lip46Wie es aussieht, sowohl kürzer als auch entropischer
Hauptsache, dass keine Session-ID mit "invalid: ########"; # für numerische Werte
anfängt. Dann kann ich nämlich mein Loginsystem erstmal wegschmeißendedlfix.
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!
-
-
-
-
-
-
Hi,
Aber wo das Präfix "sess_" festgelgt ist, hab ich noch nicht gefunden.
Intern vermutlich; mir wäre nicht bekannt, dass das konfigurierbar wäre wenn man den Default-Sessionhandler von PHP benutzt.
Außerdem hätte ich gerne eine Funktion, um solch einen Sessionamen selber auszuwürfeln.
Lass’ PHP das machen, das macht es gut.
Ich möchte Uploaddateien temporär in einem Verzeichnis unterbringen, aus der sie, soe wie die Sessiondateien selber, nach einiger Zeit der Nichtbeachtung wieder entfernt werden, ohne dass man sich darum kümmen muss. Da könnte das Session-Verzeichnis doch ganz praktisch sein. Oder steht dem etwas entgegen?
Die Vermischung von Inhalten vollkommen unterschiedlicher Bedeutung ist selten eine gute Idee.
Nutze ein eigenes Verzeichnis für diese Uploads, und räume dort selber auf – entweder per Cronjob, oder vergleichbar zum Session-Mechanismus durch einen zufallsgesteuerten Aufruf.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/ -
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Nur mal für alle Interessierten mitgeteilt:
Das Speichern von Uploadfiles in der Session ist absolut unkritisch möglich. Die Umrechnung ins Stream-Format (also die Serialisierung) übernimmt PHP von ganz alleine.
Man kann also sinngemäß einfach
$_SESSION['files'][$userfilename][] = file_get_contents($_FILES[$userfilename]['tmp_name']);schreiben und das nachher, hier als Beispiel mit einem jpeg-Bild, mit
<?php /* get_image.php */ session_start(); $userfilename = 'bilder'; if ( isset($_SESSION['files'][$userfilename]) && isset($_GET['img']) && isset($_SESSION['files'][$userfilename][intval($_GET['img'])]) ) { header('Content-Type: image/jpeg'); echo $_SESSION['files'][$userfilename][intval($_GET['img'])]; } ?> ## der Link dafür lautet dann z.B. <img src="get_image.php?img=7" alt="upload-Vorschau">wieder abfragen und ausgeben.
Ob man aber die maximale Größe für die Sessiondatei (begrenzt durch den für das Script verfügbaren Speicher) überschreiten wird, ist unklar. PHP scheint die Größe der Sessiondatei in Extents zu steuern und nicht direkt abhängig vom benötigten Speicherplatz zu machen. Die vorherige Abschätzung, um wieviel die Sessiondatei mit einem neuen Upload wachsen wird, ist also schwierig.
Da kann es dann wohl passieren, dass man Daten zwar noch wegschreiben, sie aber nicht wiederholen kann :-(
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Nur mal für alle Interessierten mitgeteilt:
[...]
Ich habe die Angelegenheit noch weiter vereinfacht.
Siehe Posting unter https://forum.selfhtml.org/?t=218940&m=1509735Ich weiß aber immer noch nicht, welche Zeichen nun seit PHP XX? füe den Zeichenvorrat von Sessionnamen benutzt werden. Wäre einfach supi, wenn jemand einen Verweis auf die passende Stelle in einer PHP-Doku hätte.
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,
liebe Faulpelze,ja!
Es weihnachtet mal wieder.
Darum will ich für die Neugierigen und Faulpelze hier trotzdem meine Rechercheergebnisse wiedergeben. Die Mitdenker und Wissenden haben zu meinem Bedauern nicht mitgewirkt an der Beantwortung der Frage, welchen Zeichenvorrat PHP für gültige Sessiondateinamen im Moment gerade benutzt.
Ich habe daher den öffentlichen Webserver mal ein paar Tage Sessiondateien erzeugen lassen, mit davon nach Datum sortiert einige (630) gegriffen und die Namen auszählen lassen:
[0] => 598
[1] => 584
[2] => 548
[3] => 591
[4] => 592
[5] => 587
[6] => 551
[7] => 560
[8] => 496
[9] => 497
[_] => 630
[a] => 512
[b] => 506
[c] => 496
[d] => 486
[e] => 508
[f] => 500
[g] => 484
[h] => 465
[i] => 484
[j] => 481
[k] => 516
[l] => 512
[m] => 470
[n] => 507
[o] => 504
[p] => 486
[q] => 510
[r] => 469
[s] => 470
[t] => 455
[u] => 493
[v] => 462Es werden augenscheinlich nur die Zeichenrepräsentanzen für [0-9], [a-v] benutzt, was 32 unterschiedliche Möglichkeiten ergibt. Das '_' habe ich nur mitzählen lassen, um die Anzahl der Dateinamen zu haben. Es kommt in jedem nur genau einmal vor. Das vorangestellte "sess" habe ich hingegen nicht mitgezählt.
Warum man das nun auf 32 Zeichen begrenzt hat, ist mir noch unklar. Klar, Binärzahl, aber es wird doch ohnehin in einem 7- bzw. 8-Bit-System abgebildet.
Schon mal Frohes Fest, wenn ich nicht mehr reinschaue :-)
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!
-
-
-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
Wo wird eingestellt, _welche_ Dateien aus dem Session-Verzeichnis gelöscht werden sollen?
Bekannt sind mir bisher die INI-Einstellungen zum
- session.save_path
- session.gc_maxlifetime & Co
Aber wo das Präfix "sess_" festgelegt ist, hab ich noch nicht gefunden.
Scheint wohl hart codiert zu sein oder irgendwo vorgegeben zu werden, wo man als PHP-Anwendungsprogrammierer nicht heran kommt.
Jedenfalls werden alle Dateien, die mit "sess_" anfangen in den Focus des GC gerückt und nach den Vorgaben der INI-Einstellungen unter "sess.*" gelöscht, wenn der GC passende Dateirechte darauf hat. Will man also, dass eine einzelne Session nicht gelöscht wird, würde das Voranstellen eines Zeichens (z.B. '#')schon genügen. Dass dieser Dateiname dann zufällig schon vorhanden wäre, wäre wirklich ein großer Zufall. Beim Rückbenennen sollte man allerdings etwas besser hingucken. Aber auch da sollte ein Konflikt nahzu ausgeschlossen sein.
Außerdem hätte ich gerne eine Funktion, um solch einen Sessionnamen selber auszuwürfeln. Meine alte ist wohl überholt. Inzwischen sind da ganz viel neue Zeichen in den Vorrat aufgenommen worden. Welche sind zulässig?
Eine Funktion habe ich mir erstellt. Die funktioniert auch prima und berücksichtigt auch die Regeln gegen Race-Conditions. Sie gibt den ausgewürfelten Namen und einen Filepointer auf die geöffnete und gesperrte Datei zurück. Es macht dem GC auch nix, wenn man [,._()w-z-] noch hinzu nimmt zum Zeichenvorrat. Die übrigen Zeichen habe ich mir wegen der Konflikte mit html, Filsystemen (Windows/Linux), Shells, usw. lieber gleich verkniffen.
Die Länge scheint aber geblieben zu sein.
Die Länge der Namen hat sich etwas verringert, wie es aussieht inclusive "sess_" auf 31 Zeichen.
Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden!