Auf session zugreifen und auslesen

[rethus]

Das http sieht mir nur nach einem kleinen Worarround aus:

Zeile 79 checkt, ob ein Protokoll vorhanden ist (irgendwas://)
Zeile 80-82: wenn nicht, setzt er selbst http:// davor
... scheinbar damit Zeile 86 nicht umgeschrieben werden muss, welches den Substr. erzeugt, um das Protokoll wegzuschneiden.

Is n bisschen doppelt gemoppelt, aber sollte so funktionieren.

Man könnte ggf mit nem einfachen Trenären Operator die Zeilen 78 - 86 vereinfachen/verkürzen:

Code: Alles auswählen

$start = strpos($url, '://');
$path = ( $start ) ?  substr($url, $start + 3) : $url ;
 

http://api.contenido.org/con4911/source ... on.html#78

Code: Alles auswählen

 78:             // remove protocol from contenido URL
 79:             $start = strpos($url, '://');
 80:             if (false === $start) {
 81:                 $url = 'http://' . $url;
 82:                 $start = strpos($url, '://');
 83:             }
 84: 
 85:             // url of contenido folder with hostname
 86:             $path = substr($url, $start + 3);
 87: 
 88:             $start = strpos($path, '/');
 89:             if (false !== $start) {
 90:                 $path = substr($path, $start);
 91:                 session_set_cookie_params(0, $path, null, $cfg['secure'], true);
 92:             } else {
 93:                 // fall back to entire domain if no path can be computed
 94:                 session_set_cookie_params(0, '/', null, $cfg['secure'], true);
 95:             }
 

[Faar]

Das http sieht mir nur nach einem kleinen Worarround aus:

Klar, wenn man nicht parse_url() nehmen will.

Zeile 79 checkt, ob ein Protokoll vorhanden ist (irgendwas://)
Zeile 80-82: wenn nicht, setzt er selbst http:// davor
... scheinbar damit Zeile 86 nicht umgeschrieben werden muss, welches den Substr. erzeugt, um das Protokoll wegzuschneiden.

Sollte bis dahin funktionieren, wenn die URL nicht bereits ein Pfad ist.
z.B. dingens/moep/hier
Hat jemand mal geschaut, was mit $url an kommt?
Sonst würde es zu http://dingens/moep/hier werden, um dann wieder zu dingens/moep/hier zu werden.

Is n bisschen doppelt gemoppelt, aber sollte so funktionieren.

Naja, sicher ist sicher, aber es prüft nicht, ob es eine URL ist oder bereits ein Pfad.
Jedenfalls wird scheints das http bei 86 immer weg geschnitten, so dass es mit https keine Probleme geben dürfte.

Aber wenn es :// in 79 bereits nicht gibt, macht es doch wenig Sinn, http:// voran zu stellen, nur um mit strpos() den Anfang von :// zu finden, oder?
Wichtiger wäre doch an dieser Stelle, herauszufinden, ob man es mit einer URL zu tun hat oder etwas anderem, wie einem Pfad.
Steht am Anfang ein / oder nicht? Oder ein "." ? Vielleicht ein Schreibfehler, wie http:/// ?
Wenn man sich ganz sicher sein kann, dass immer entweder ein http://www.domain.de/dingens/moep/hier oder ein domain.de/dingens/moep/hier in $url steht, kann man das so machen.
Sonst nicht.

Edit: manche haben auch ein domain.de//dingens/moep/hier mit zwei // drin stehen.

Was mich interessiert, ob man bei substr() eine mathematische Operation wie $start + 3 eintragen kann, oder ob dort nicht nur eine Zahl oder eine Variable stehen darf?
Also vorher lieber $start = $start+3 machen.
Ich sehe nirgends Hinweise, dass substr($url, $start + 3) üblich wäre und immer funktionieren würde.

Aber um zum Pfad in der URL zurück zu kommen:

$start = strpos($path, '/');

Angenommen wir hätten das hier als Pfad: dingens/moep/hier
Wo würde obiges dann anfangen zu zählen?
Bei /moep/hier vermutlich.

88: $start = strpos($path, '/');
89: if (false !== $start) {
90: $path = substr($path, $start);
91: session_set_cookie_params(0, $path, null, $cfg['secure'], true);
92: } else {

Das wäre dann also nicht falsch, folglich würde im Beispiel dann /moep/hier als $path eingehen statt dingens/moep/hier
Das else käme mit dem erlösenden "/" dann nicht zum Einsatz.

session_set_cookie_params(0, '/', null, $cfg['secure'], true);

http://api.contenido.org/con4911/source ... on.html#78

[rethus]

Das Ziel diesen String-Schnipselei ist m.E. das ein Pfad daraus wird.
Bei meiner vereinfachten Lösung siehst du, das wenn :// gar nicht vorkommt, das dann mit der URL auch nichts weiter passiert.

Du hast natürlich recht, das man sicher stellen muss, das es ein valider Pfad ist, und nicht http://///ding///bums/// etc.
Hier würde sich dann eine regexp. anbieten. Ist ne gute Anregung von dir, hier sollte man ggf. mal zurückvervolgen, ob dieser Path durch einen Dispatcher gejagt wird, um alle Unstimmigkeiten (und somit potenzielle Angriffe) rauszufiltern.

Auswertung von Operationen und Argumenten ist in substr möglich. Hier brauchst du dies nicht in einer separaten Variablen-Zuweisung erledigen.

Angenommen wir hätten das hier als Pfad: dingens/moep/hier
Wo würde obiges dann anfangen zu zählen?

strpos() gibt das erste vorkommen des Suchstrings zurück, wenn nicht gefunden "false". In deinem Beispiel also 7. Auf Basis dieser Zahl ist deine Vermutung korrekt, das substr($path, strpos("$path","/")) /moep/hier zurück gibt.

Das wäre dann also nicht falsch, folglich würde im Beispiel dann /moep/hier als $path eingehen statt dingens/moep/hier
Das else käme mit dem erlösenden "/" dann nicht zum Einsatz.

Ja, das ist korrekt, wenn kein führendes / in einem normalen Path wäre. Momentan ist es durch dieses voransetzen des http:// und anschließenden wegschneidens ja gelöst - weshalb ich es Workarround nannte.

Hast du denn derzeit die Vermutung, das dieser Part eine Fehler produziert, oder interessiert es dich eher in Sachen "clean Code"?

Wenn du da ein Fehlerfall hast, debugge es doch mal mit dem XDebugger, dann siehst du exakt welche Art von Pfaden/Url's dort ankommen.

[Faar]

Nur wegen Clean-Code interessiert mich das

Ich hatte früher mal viel mit Links und URL zu tun und da tauchen Sachen auf, die ahnt man vorher nicht. Die Annahme, dass da immer eine vernünftige URL ankommen würde, hatte mich damals in die Irre geführt und ParseURL() war damals auch die Rettung. Man muss sich ja nur mal hier das Beispiel #2 anschauen: http://php.net/manual/de/function.parse-url.php

Code: Alles auswählen

$url = '//www.example.com/path?googleguy=googley';

parseurl() kann inzwischen (ab 5.4.7) damit umgehen, aber kann der Workarround von Contenido das, mit "://"?
Eher nicht.
Auch Deiner nicht, weil eine URL mit // anzufangen nicht korrekt ist, aber sowas, und noch viel mehr, kommt vor.

Darum sehe ich die Ursache in der ankommenden $url, weil was da in den Fehlerfällen drin steht, ist interessant.

[rethus]

Die Annahme, dass da immer eine vernünftige URL ankommen würde, hatte mich damals in die Irre geführt

Oh ja, wer hat da noch nicht Lehrgeld gezahlt ^^
Ich nutze eigentlich auch gerne paresURL, weiß nicht, ob es Gründe gibt, warum dies hier nicht gemacht wurde. Feedback kommt bestimmt von frederic... einfach mal abwarten.

[frederic.schneider_4fb]

In der neuesten Version sieht der Code folgendermaßen aus:

Code: Alles auswählen

// remove protocol from contenido URL
$start = cString::findFirstPos($url, '://');
if (false === $start) {
   $url = 'http://' . $url;
   $start = cString::findFirstPos($url, '://');
}

// url of contenido folder with hostname
$path = cString::getPartOfString($url, $start + 3);

$start = cString::findFirstPos($path, '/');
if (false !== $start) {
   $path = cString::getPartOfString($path, $start);
   session_set_cookie_params(0, $path, null, $cfg['secure'], true);
} else {
   // fall back to entire domain if no path can be computed
   session_set_cookie_params(0, '/', null, $cfg['secure'], true);
}

(Bitte nicht wundern: Wir haben für einige String-Funktionalitäten zukünftig eigene Funktionen, die die MultiByte-String-Varianten nutzen. findFirstPos entspricht also mb_strpos, getPartOfString mb_substring usw. Natürlich funktioniert CONTENIDO auch weiterhin ganz "klassisch".)

Auf diesem Stand müsste eigentlich nahezu jedes Szenario funktionieren

[malsdgtac]

Hallo Frederic,

vielen Dank für deine Arbeit. Gibt es eine Einschränkung ab welcher Contenidoversion die Anpassung funktioniert?

[frederic.schneider_4fb]

Wie meinst Du Deine Frage?
Die cString-Funktionalitäten sind erst ab er nächsten, Stand heute noch nicht veröffentlichten Version verfügbar. MultiByte-Strings setzen wir allerdings schon länger im Setup voraus, sodass die neue cString-Wrapper-Klasse auch rückwirkend funktionieren sollte.
Unabhängig von den cString-Codestellen, die ich gestern gepostet habe, ist der o. g. Code seit Version 4.9.11 funktionsfähig. Seinerzeit haben wir u. a. die Secure-Flag ergänzt

[malsdgtac]

Danke für die Info