PHP rocks! wünscht allen Mitgliedern einen guten Rutsch ins neue Jahr 2017 !!!
Hinweis: Das Forum zieht um! Um keine Datenverluste zu haben, schalten wir zwecks Übernahme der Daten das Forum am Sonntag, den 24.04.2016 um ca. 21:00 Uhr offline und passen anschliessend die DNS-Einträge an.
www.php-rocks.de wird euch dann nach den Aktualisierungen der DNS-Server wieder wie gewohnt uneingeschränkt zur Verfügung stehen.
Danke für euer Verständnis!

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Session Files werden nicht beschrieben
#1
Ich bin mit meiner Migration nach php 7.1 nun fast durch und hänge nun an Sessions fest:
Egal ob ich "{WEBSPACEROOT}{/}tmp" oder "/tmp"(+open base dir) als session.save_path angebe,
es werden zwar die Session-Dateien erstellt, aber nicht mit Daten befüllt (0kb).

Code:
<?php
session_start();

if(!isset($_SESSSION['testcount']))$_SESSSION['testcount']=0;
$_SESSSION['testcount']=$_SESSSION['testcount']+1;

if (!is_writable(session_save_path())) {
   echo 'Session path "'.session_save_path().'" is not writable for PHP!<br />';
}
echo sys_get_temp_dir().'<br />';
echo session_save_path().'/'.session_id().'<br />';
echo $_SESSSION['testcount'];
Dies Ausgabe/der Counter bleibt immer auf 1 und das session file bleibt 0kb groß.

Irgendein anderer client/Anwendung(*) schafft es allerdings auf der Domain/im session.save_path session files zu erstellen welche mit Daten befüllt werden und das prefix "sess_sess" haben (statt nur "sess_).
...

EDIT 1:
*=Das ist die Production-Anwendung welche die Session auf der Test-Domain in das Verzeichnis schreibt.
Die Anwendung auf der Production-Domain verwendet allerdins das 'user' session module und session_set_save_handler(db-basiert),
hier scheint es Probleme zu geben:
- Die DB konnektiert zwar richtig in der Anwendung, es gibt allerdings noch teilweise Kollationsprobleme durch alte
 non-utf8 Daten, ich glaube aber nicht das dies hier das Problem ist?
 Ich suche weiter....!?

EDIT 2:
Mist: Jetzt geht meine alte Version auch nicht mehr, weiß aber grad spontan nicht was ich dort verändert habe.

...Sorry, ich muß wohl erstmal einen Kaffee trinken, poste aber schonmal vielleicht kennt jemand das Verhalten und hat einen Tipp für mich?

mfg
Till
Antworten
#2
Zitat:Mist: Jetzt geht meine alte Version auch nicht mehr, weiß aber grad spontan nicht was ich dort verändert habe.
Ein Cross-Domain-Request mit einer geteilten/SSO -Session welche nicht richtig synchronisiert war hat sich gegenseitig ausgeloggt.
Alte Version geht wieder, neue noch nicht.

...

mfg
Antworten
#3
Hallo,
habe die Session Einstellungen überarbeitet, ich denke das es nun eigentlich klappt aber:
Es ist ein reines Kollationsproblem:
Die verschiedenen Scripte und Datenbankeinträge schleppen verschiedene Kollationen mit sich rum aus "legacy" Beständen.

Ich hatte dazu hier im Forum mal an anderer Stelle einen Artikel dazu geschrieben welcher aber vom Admin gelöscht wurde (@Arne?):
Es ging darum, das Datenbanken mit "mixed-collations" (Datzen/Einstellungen/Scripte/Verbindunen) ausgegeben werden sollten mit php Scripten mit "mixed-collations".
Meine Lösung war:
- Ich habe im output-buffer-handler die Ausgabe analysiert und dort die Kollationsprobleme repariert, in der ersten Version mit einem teilweise erheblichen CPU-Aufwand, später gut funktionierend.
Meine Lösung ist nun:
- Ich habe die Migration zunächst downgegraded nach php 5.6.x, erst "ganz" neue Scripte (ohne "mixed-collations") werde ich aufschalten in 7.1.x.

mfg
Till

p.S. /werbung:
- Ich habe einige Erfahrung, mit neuer und alter php Software und speziell in Verbindung mit Versions-Migrationen.
Zum Beispiel gibt es einen flexiblen mysql -> PDO Wrapper, für die Verwendung von "legacy" Scripte in php 7.x.
Antworten
#4
Zitat:Ich hatte dazu hier im Forum mal an anderer Stelle einen Artikel dazu geschrieben welcher aber vom Admin gelöscht wurde (@Arne?)
Nope... [Bild: http://www.smilies.4-user.de/include/Denken/smilie_denk_49.gif]

Wenn ich etwas von registrierten Usern löschen sollte, bekäme der Betroffene eine Nachricht mit dem Grund.
Hast Du das unter Deinem Account gepostet? Wann war das ungefähr?

Gruß Arne
Antworten
#5
Hi Arne,
wenn ich mich recht errinere hatte ich den genannten Beitrag als Antwort gepostet auf Deinen Beitrag:
http://www.php-rocks.de/thema/98-die-utf8-verschw-rung.html

Ich hatte die Löschung nicht hinterfragt, da ich zum einen den Admin respektiere zum anderen meinen Beitrag selbst als nicht besonders geistreich empfand.
Natürlich kann es sein das ich mich auch irre und den Beitrag selber gelöscht habe?

Wie dem auch sei, der Beitrag handelte davon im php outputhandler die Kollation/das Encoding von "mixed collations/encoding" zu reparieren.
Wenn sich jemand dafür interresiert versuche ich gerne den Beitrag zu reproduzieren.

Ansonten wünsche ich einen schönen Vatertag Smile

mfg
Till
Antworten
#6
Hi Till,

Danke für die Rückmeldung/Aufklärung.
Der Beitrag steht in der Rubrik Tutorials, darin sind keine Antworten möglich, weil die Themen nach Veröffentlichung geschlossen werden, um Diskussionen und OT an der Stelle zu vermeiden.
Daher wurde Dein Beitrag dann vermutlich gar nicht erst gespeichert. Wink

Merkwürdig ist zwar, warum Du in einem geschlossenen Thema überhaupt eine Möglichkeit zu antworten hattest, aber zumindest wissen wir jetzt, dass Dein Beitrag nicht mutwillig gelöscht wurde.

Danke und Gruß
Arne

ps: Schick mir sonst gerne Deine Ausführung zu dem Thema per PN oder Mail, evtl. kann ich das Tutorial ja um Deine Infos erweitern.
Antworten


Möglicherweise verwandte Themen...
Thema Verfasser Antworten Ansichten Letzter Beitrag
  phpinfo wird nicht ausgelesen! HelgeHH 10 1.864 12.10.2016, 10:21
Letzter Beitrag: Arne Drews

Gehe zu: