[neues plugin] wellrad - Onlineshop

[manu]

gehört IMO auch hier rein: der WellradShop und GXSecurity - beides sehr verheissungsvolle plugins - vertragen einander nicht.
Bei gesetzter GXSecurity geht der Seitenaufruf in die Endlosschlaufe.
Ich vermute auch hier, dass da das session handling durcheinander gerät. Hat hier jemand schon Erkenntnisse oder muss dies in die Grundlagenforschung?
merci und Gruss
manu

EDIT: Wieso setzt GXSecurity seine session_id explizit und individuell? Wenn ich am Ende des Wellrad plugins ein session_write_close() setze (~58), dann gehts einigermassen, kann aber wohl nicht die Lösung sein, oder!?

[Martin]

Hallo manu,

eine andere als deine Lösung habe ich bisher noch nicht gefunden. Vielleicht also wirklich ein Fall für die Grundlagenforschung.

Wenn ich am Ende des Wellrad plugins ein session_write_close() setze (~58), dann gehts einigermassen, ...

Was meinst du denn mit "einigermaßen"? Gibt es danach noch Schwierigkeiten? (Ich entdecke keine.)

LG

Martin

[johnjdoe]

EDIT: Wieso setzt GXSecurity seine session_id explizit und individuell?

Selbst ich als "Programmierer" von GXSecurity kann diese Frage leider nicht beantworten. Ich bin kein wirklicher Programmierer, sondern habe ausgehend von einem alten Script damals angefangen ein Sicherheitsplugin zu schreiben. Bestimmt kein besonders guter Weg, aber damals der einzig mögliche für mich. Und das Resultat ist zumindest nicht so schlecht geworden. Richtige Programmierer sehen das vielleicht anders.

GXSecurity hat in der Tat hier und da Kollisionen mit anderen Plugins. Warum kann ich nicht sagen, da ich bisher keine Antwort darauf gefunden habe. Ob es an GXSecurity oder den anderen Plugins oder am Pluginloader liegt, weiß ich nicht.

Aber vielleicht ist das hier jetzt der Anstoß, dass der eine oder andere versiertere Programmierer als ich, sich GXSecurity mal unter die Lupe nimmt und Verbesserungen des Konzepts vornimmt? Das würde mich freuen und würde auch sicher für CMSimple wertvoll sein!

[manu]

Was meinst du denn mit "einigermaßen"? Gibt es danach noch Schwierigkeiten? (Ich entdecke keine.)

Hallo Martin, es gab wohl keine schwere Fehlermeldung mehr, ich habe aber das plugin nicht komplett durchgetestet, ob es auch wirklich fehlerfrei läuft.
Zudem ein Problem in Wellrad zu fixen, welches in GXSecurity entsteht, finde ich etwas fragwürdig. Beim wellrad ist höchstens die systemweite Namensgebung problematisch ($task, $page_name, $published..) was irgendwann zu Problemen führen wird.
Mal grundsätzlich: es können mehrere sessions mit unterschiedlichen _id's definiert werden, offen aufs Mal kann aber nur eine sein. GXSecurity möchte seine eigene session mit eigener id - aus welchem Grund auch immer (individuelle ini_set's?) - starten. Da aber bei Abarbeitung der plugins bereits eine session gestartet wurde, wird der session_start() in GXSecurity ignoriert, da nützt auch das Setzen der session_id nichts. Daher verabschiedet sich GXSecurity in die Unendlichkeit, wenn von irgendeinem plugin her eine session aktiv ist.

@johnjdoe: wie wärs den, wenn Du am Anfang

Code: Select all

session_write_close(); //close random open sessions EM+

ini_set("session.use_only_cookies","1");
ini_set("session.use_trans_sid","0"); 

setzen würdest. Damit würde eine allfällige aktive session geschlossen. Deine zu setzenden session Direktiven schaden meiner Meinung niemandem, vor allem nicht jenen, die GXSecurity verwenden. Und dann das Setzen einer eigenen session_id ~508 unterlassen. Die Namenskonvention der $_SESSION Variablen von GXSecurity wird ja konsequent eingehalten.
Gruss manu

[Martin]

Beim wellrad ist höchstens die systemweite Namensgebung problematisch ($task, $page_name, $published..) was irgendwann zu Problemen führen wird.

Das stimmt. Ich gelobe Besserung - und sitze auch schon dran ...

Martin

[johnjdoe]

@johnjdoe: wie wärs den, wenn Du am Anfang

Code: Select all

session_write_close(); //close random open sessions EM+

ini_set("session.use_only_cookies","1");
ini_set("session.use_trans_sid","0");

setzen würdest. Damit würde eine allfällige aktive session geschlossen. Deine zu setzenden session Direktiven schaden meiner Meinung niemandem, vor allem nicht jenen, die GXSecurity verwenden. Und dann das Setzen einer eigenen session_id ~508 unterlassen. Die Namenskonvention der $_SESSION Variablen von GXSecurity wird ja konsequent eingehalten.

OK, habe ich im Code der 1.3 Beta 1 reingetan. Mal sehen, ob's hilft.

[johnjdoe]

gehört IMO auch hier rein: der WellradShop und GXSecurity - beides sehr verheissungsvolle plugins - vertragen einander nicht.
Bei gesetzter GXSecurity geht der Seitenaufruf in die Endlosschlaufe.
Ich vermute auch hier, dass da das session handling durcheinander gerät. Hat hier jemand schon Erkenntnisse oder muss dies in die Grundlagenforschung?
merci und Gruss
manu

EDIT: Wieso setzt GXSecurity seine session_id explizit und individuell? Wenn ich am Ende des Wellrad plugins ein session_write_close() setze (~58), dann gehts einigermassen, kann aber wohl nicht die Lösung sein, oder!?

Siehe http://www.cmsimpleforum.com/viewtopic.php?f=16&t=901

[wosee]

Kann es sein, dass das Ding mit CMSimple_XH nicht läuft?

[Martin]

Nö. Ist nicht so. CMSimple oder CMSimple_xh, das ist dem Ding schnurz.

Wenn es also irgendwo hakt, an dieser Umstellung liegt es nicht. Wo hakt es denn?

Martin

[wosee]

Keine Ahnung, hat nur ein Kollege gesagt. Ich werd' dem Mal nachgehen.