Verwirrt zwei Themen sessions, utf

Hallo!

Ich bin da etwas in einer Sackgasse. Ich habe nun tagelang mich mit
Recherche bezgl. sessions und utf beschäftigt.

Ich habe irgendwie bereits Zweifel ob ich mit php nicht aufs falsche
Pferd gestiegen bin.


1) Sessions

- Ich suche nach einer Möglichkeit in einem benuzterdefiniertem
session-handler die session id zu ändern. Also nicht mittels
session_id($id); (ist ja in den handler-Funktionen nicht verfügbar)
sondern bereits im Vorfeld (auch um mehrmahliges cookie
senden zu verhindern).
Dabei finde ich es sehr eigenwillig dass ein Benutzer z.B.
example.com?PHPSESSID=12345 angeben kann und dies
von php auch akzeptiert wird. Ich aber keine Möglichkeit habe im
handler die id umzuschreiben. Ich kann solch eine Anforderung
ignorieren aber des wars auch schon.
D.h. hier haben die Entwickler von php dem 'client' mehr
Gestaltungsmöglichtkeit als dem 'server' eingeräumt, wenn
ich jetzt mal nur den handler betrachte.


2) utf/unicode
Darüber habe ich jezt bereits soviel gelesen dass ich überhaupt
nicht mehr durchblicke. Jeder schreibt da irgendwas anderes, die
php-docu dazu ist dürftig.

Also ich muss nun irgendwie Ordnung ins Chaos bringen:

Gegeben ist:
- scripte in uft8 Codierung
- server codierung de_AT.UTF-8
- postgres db utf8
- erwartete Eingabe von-bis also von Westen-Osten ;-).

- Was muss ich nun bei Stringfunktionen berücksichtigen?
Ist ein, unter den oben genannten Voraussetzungen, Anwenden
von z.B. strtolower() auf A) hardcoded strings B) strings aus der db
C) strings aus userinput sicher oder nur mit den mb_ -Funktionen.
Es geht einfach nicht hervor. Arbeitet bsplsw. preg_match als utf
wenn obige Voraussetzungen zutreffen oder muss ich immer
/u angeben.

Ich blicke einfach nicht durch einmal liest man die Funktionen sind
immer 1-byte orientiert dann wieder mal sie nutzen die LOCALE
Einstellungen. Was ist nun wahr, die docu schweigt dazu.
Offensichtlich haben die php-Entwickler dem uft-Bereich eine
nur massiv untergeordnete Rolle eingeräumt.

- Wie bestimme ich unter uft z.B. alle Zeichen des "alphabets"
Ascii klar da habe ich A-Z, wie drücke ich aber dies in utf aus?
Es ist ja immer schlecht userinput darauf zu prüfen was man nicht
will weil es immer was gibt was man vergessen könnte oder nicht
weiss. Also muss ich immer aufs possitive (also was ich haben will)
Filtern - fällt mir aber z. B. bei einem Namensfeld doch eher schwer
wenn ich an Osteuropa/China/Japan denke ...
Gibts da eine sinnvolle Lösung?

- Generell wandle ich jeden userinput in utf-8 um. Nun, könnte ich
auf die Überprüfung ob oder ob nicht utf-8 angekommen ist verzichten
und einfach alles ohne Prüfung umwandeln? Oder wird ein bereits
in utf vorliegender string dann nochmals umgewandelt und dadurch
zerschossen?

Fragen über Fragen ... ;-)


Vielen Dank!

Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!

Re: Verwirrt zwei Themen sessions, utf

Anton Huber schrieb:
> - Ich suche nach einer Möglichkeit in einem benuzterdefiniertem
> session-handler die session id zu ändern. Also nicht mittels
> session_id($id); (ist ja in den handler-Funktionen nicht verfügbar)
und wozu?
session_regenerate_id()?

> sondern bereits im Vorfeld (auch um mehrmahliges cookie
> senden zu verhindern).
mehrmaliges was? Cookies werden mit dem Response an den Browser
übertragen. Das läuft nicht extra und geht nicht anders, auch nicht mit
einem benutzerdefinierten Sessionhandler.

> Dabei finde ich es sehr eigenwillig dass ein Benutzer z.B.
> example.com?PHPSESSID=12345 angeben kann und dies
das kann man u.a. in der php.ini mit
session.use_only_cookies = 1
deaktivieren

> von php auch akzeptiert wird. Ich aber keine Möglichkeit habe im
> handler die id umzuschreiben. Ich kann solch eine Anforderung
> ignorieren aber des wars auch schon.
das ist ja aber ein Defizit in deinem benutzerdefinierten S-Handler

> D.h. hier haben die Entwickler von php dem 'client' mehr
> Gestaltungsmöglichtkeit als dem 'server' eingeräumt, wenn
> ich jetzt mal nur den handler betrachte.
Das versteh ich nicht. Bitte erläutere das näher.

IMHO ist ein benutzerdefinierter Sessionhandler nur für die Ablage der
Sessiondaten möglich. Die Verknüpfung der Session mit dem Request ist
PHP-Sache. Da hier kein Spielraum für neue Logik ist, besteht auch kein
Sinn das zu ändern. Lediglich die Session-IDs können anders erzeugt
werden, aber selbst dafür stehen komplexe php-eigene Funktionen zur
Verfügung. Korrigiere mich, wenn ich mich irre.

> 2) utf/unicode
> Darüber habe ich jezt bereits soviel gelesen dass ich überhaupt
> nicht mehr durchblicke. Jeder schreibt da irgendwas anderes, die
> php-docu dazu ist dürftig.
>
> Also ich muss nun irgendwie Ordnung ins Chaos bringen:
>
> Gegeben ist:
> - scripte in uft8 Codierung
Scripte? der PHP-Code? oder die Texte, die du mit 'echo' ausgibst?

> - server codierung de_AT.UTF-8
> - postgres db utf8
> - erwartete Eingabe von-bis also von Westen-Osten ;-).
>
> - Was muss ich nun bei Stringfunktionen berücksichtigen?

> Ist ein, unter den oben genannten Voraussetzungen, Anwenden
> von z.B. strtolower() auf A) hardcoded strings B) strings aus der db
> C) strings aus userinput sicher oder nur mit den mb_ -Funktionen.
was sind hardcoded strings? sowas wie
strtolower('FOOBAR');
Userinput steht auch blos in Variablen. da utf8 zeichen aus mehreren
byte bestehen, solltest du zur Ausgabe, Konvertierung, ... auch
mb-Funktionen verwenden. Gibt ja genug[1]

> Es geht einfach nicht hervor. Arbeitet bsplsw. preg_match als utf
> wenn obige Voraussetzungen zutreffen oder muss ich immer
> /u angeben.
ich weiß, dass bei Umlauten eine richtig gesetzte Lokalisierung
ausreicht, um bei [A-Z] auch Ä, Ö und Ü zu finden.
>
> Ich blicke einfach nicht durch einmal liest man die Funktionen sind
> immer 1-byte orientiert dann wieder mal sie nutzen die LOCALE
> Einstellungen. Was ist nun wahr, die docu schweigt dazu.
Das stimmt nicht. [1] ist hier sehr ausführlich. Allerdings reicht das
nicht aus, um UTF8, Collations und Charactersets zu verstehen. Dazu
bedarf es mehr Input. Vielleicht auch von hier [2].

> Offensichtlich haben die php-Entwickler dem uft-Bereich eine
> nur massiv untergeordnete Rolle eingeräumt.
>
> - Wie bestimme ich unter uft z.B. alle Zeichen des "alphabets"
> Ascii klar da habe ich A-Z, wie drücke ich aber dies in utf aus?
A-Z

> Es ist ja immer schlecht userinput darauf zu prüfen was man nicht
> will weil es immer was gibt was man vergessen könnte oder nicht
> weiss. Also muss ich immer aufs possitive (also was ich haben will)
> Filtern - fällt mir aber z. B. bei einem Namensfeld doch eher schwer
> wenn ich an Osteuropa/China/Japan denke ...
> Gibts da eine sinnvolle Lösung?
ich würde auf setlocale() tippen und zur Verwendung der mb-Funktionen raten.
>
> - Generell wandle ich jeden userinput in utf-8 um. Nun, könnte ich
> auf die Überprüfung ob oder ob nicht utf-8 angekommen ist verzichten
> und einfach alles ohne Prüfung umwandeln? Oder wird ein bereits
> in utf vorliegender string dann nochmals umgewandelt und dadurch
> zerschossen?
Du definierst, wie die Benutzereingabe an deine Applikation geschickt
wird. Also musst du auch entscheiden, wie du mit der Eingabe umgehst.
>
> Fragen über Fragen ... ;-)
Ja, zu viel für einen Post. Ich empfehle dir konkrete Probleme zu
fokussieren. Die Lösung derer fällt weit effektiver aus, als die Antwort
auf ein allgemeines Fragezeichen. Ich schätze mal keiner hier ist fest
angestellt, in der Newsgroup zu supporten. Bei deinem Post werden sich
die meisten nicht die Zeit zum sinnvollen Kommentieren nehmen, sondern
sich ein 'RTFM' denken ;)

> Gruss
> Anton

ciao

Ulf

[1]http://www.php.net/manual/de/ref.mbstring.php
[2]http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz- Grundlagen.html

Re: Verwirrt zwei Themen sessions, utf

Ulf Seltmann threw this exception:

Hallo Ulf,

>Anton Huber schrieb:
>session_regenerate_id()?

O.k. falsch ausgedrückt, ich möchte die id ändern sofern sie mir nicht
passt. Und zwar bereits im handler.


>mehrmaliges was? Cookies werden mit dem Response an den Browser
>übertragen. Das läuft nicht extra und geht nicht anders, auch nicht mit
>einem benutzerdefinierten Sessionhandler.

Na wenn ich irgenwas bastle wo ich, ups, falsch gedacht, mit
regenerate würde genau ein neues cookie gesetzt, nicht mehr
nicht weniger. O.k. danke. Gelöst.


>> Dabei finde ich es sehr eigenwillig dass ein Benutzer z.B.
>> example.com?PHPSESSID=12345 angeben kann und dies
>das kann man u.a. in der php.ini mit
>session.use_only_cookies = 1 deaktivieren

Hä? Wat'n datt. Du kennst aber schon den Spruch 'Don't trust the
client!' ?!?. Auch ein cookie kann auf PHPSESSID=12345 geändert
werden. Und auch hier schätze ich php so ein - es wird die sess 12345
anlegen.


>> von php auch akzeptiert wird. Ich aber keine Möglichkeit habe im
>> handler die id umzuschreiben. Ich kann solch eine Anforderung
>> ignorieren aber des wars auch schon.
>das ist ja aber ein Defizit in deinem benutzerdefinierten S-Handler

Hä? Wieso? Ich kann auf "Zeichengültigkeit" einer id im handler prüfen
(z.B. 12345) und darauf keine session erzeugen. Ich kann die id jedoch
nicht verändern - also - so verändern damit php es mitbekommt. Ausser
mit regenerate - was aber im handler nicht funktioniert. Aber stört
nicht mehr (s.o.).


>> D.h. hier haben die Entwickler von php dem 'client' mehr
>> Gestaltungsmöglichtkeit als dem 'server' eingeräumt, wenn
>> ich jetzt mal nur den handler betrachte.
>Das versteh ich nicht. Bitte erläutere das näher.

Der Benuzter hat direkte Einwirkmöglichkeit auf den sessionstring
(auch bei Verwendung von cookies wenn hier auch nur advanced
users ;-)). Ich aber keine im handler. Präzise genug?


>IMHO ist ein benutzerdefinierter Sessionhandler nur für die Ablage der
>Sessiondaten möglich. Die Verknüpfung der Session mit dem Request ist
>PHP-Sache. Da hier kein Spielraum für neue Logik ist, besteht auch kein
>Sinn das zu ändern. Lediglich die Session-IDs können anders erzeugt
>werden, aber selbst dafür stehen komplexe php-eigene Funktionen zur
>Verfügung. Korrigiere mich, wenn ich mich irre.

Am liebsten würde ich im sess_open oder zumindest im sess_write
die id verändern können, also das php dann diese id nimmt statt
der "vorgeschlagenen".


>> 2) utf/unicode
>> Also ich muss nun irgendwie Ordnung ins Chaos bringen:
>> - scripte in uft8 Codierung
>Scripte? der PHP-Code? oder die Texte, die du mit 'echo' ausgibst?

Alle Texte also auch der code liegen als UTF vor. Oder besser
gesagt das komplette Projekt ist UTF.


>> - server codierung de_AT.UTF-8
>> - postgres db utf8
>> - erwartete Eingabe von-bis also von Westen-Osten ;-).
>>
>> - Was muss ich nun bei Stringfunktionen berücksichtigen?
>
>> Ist ein, unter den oben genannten Voraussetzungen, Anwenden
>> von z.B. strtolower() auf A) hardcoded strings B) strings aus der db
>> C) strings aus userinput sicher oder nur mit den mb_ -Funktionen.
>was sind hardcoded strings? sowas wie
>strtolower('FOOBAR');

Ja.


>Userinput steht auch blos in Variablen. da utf8 zeichen aus mehreren
>byte bestehen, solltest du zur Ausgabe, Konvertierung, ... auch
>mb-Funktionen verwenden. Gibt ja genug[1]

Leider aber längst nicht alles (sscanf, sprintf, str_replace (nana
ereg ist kein adäquater Ersatz), u.v.m.).


>> Es geht einfach nicht hervor. Arbeitet bsplsw. preg_match als utf
>> wenn obige Voraussetzungen zutreffen oder muss ich immer
>> /u angeben.
>ich weiß, dass bei Umlauten eine richtig gesetzte Lokalisierung
>ausreicht, um bei [A-Z] auch Ä, Ö und Ü zu finden.

Ja, aber es bringt mir ja nichts wenn ich einen Japaner vorm server
habe. Ich brauche ja irgenwie einen universellen Ansatz.


>> Ich blicke einfach nicht durch einmal liest man die Funktionen sind
>> immer 1-byte orientiert dann wieder mal sie nutzen die LOCALE
>> Einstellungen. Was ist nun wahr, die docu schweigt dazu.
>Das stimmt nicht. [1] ist hier sehr ausführlich. Allerdings reicht das
>nicht aus, um UTF8, Collations und Charactersets zu verstehen. Dazu
>bedarf es mehr Input. Vielleicht auch von hier [2].

Na, ich schreibe jetzt gerade das ich mir alles reingezogen habe
und du kommst ma wieder mit der php-Docu ;-). Die php-Docu
in allen Ehren über manch doch sehr wichtige Dinge schweigt
sie sich aus. Bei den mb_ Funktionen merkt man eigentlich
das dies keinen Entwickler so richtig beschäftigt.

O.K. Ich nehme mal folgendes her:

Programmierung C unter Win32. Ich nehme die tchar.h mappings
her. Ich 'stelle' den compiler auf ANSI. Programm kann mit an
Russen nichts anfangen. Ich 'stelle' den compiler auf unicode ->
Der Russe kann chatten.
Funktionieren tut es weil tchar.h entweder auf die ANSI oder
unicode Funktionen/Typen mapped.

So nun, nochmals (den ich glaube ich verstehe das Sprachgewirr
etwas): Wen der ganze server unter UTF-8 läuft (LC_ALL) wie
verhält sich dann strtolower()? Ansi? Iso-xxxx-x? Utf-8? Undefiniert?

Dies geht aus der php-docu nur indirekt hervor und wird im
web an 100ten stellen negiert.


>> Offensichtlich haben die php-Entwickler dem uft-Bereich eine
>> nur massiv untergeordnete Rolle eingeräumt.
>>
>> - Wie bestimme ich unter uft z.B. alle Zeichen des "alphabets"
>> Ascii klar da habe ich A-Z, wie drücke ich aber dies in utf aus?
>A-Z

Damit meine ich alle Zeichen die keine 'controls', keine
Escapesequenzen, keine Punktuations-, Interpunktions- oder
Satzzeichen sind. Im Utf sind ja ein haufen Zeichen drinnen
die 'normale' Buchstaben sind aber nicht in A-Z fallen. Dieses A-Z
ist überhaupt ein sehr amerikanistisches Weltbild ;-).


>> Es ist ja immer schlecht userinput darauf zu prüfen was man nicht
>> will weil es immer was gibt was man vergessen könnte oder nicht
>> weiss. Also muss ich immer aufs possitive (also was ich haben will)
>> Filtern - fällt mir aber z. B. bei einem Namensfeld doch eher schwer
>> wenn ich an Osteuropa/China/Japan denke ...
>> Gibts da eine sinnvolle Lösung?
>ich würde auf setlocale() tippen und zur Verwendung der mb-Funktionen raten.

Vielleicht reden wir auch aneinader vorbei. Der server steht an einem
Ort und läuft unter utf. Wie kann ich universell verschiedene Eingaben
von der ganzen Welt validieren bzw. ver/bearbeiten?


>> - Generell wandle ich jeden userinput in utf-8 um. Nun, könnte ich
>> auf die Überprüfung ob oder ob nicht utf-8 angekommen ist verzichten
>> und einfach alles ohne Prüfung umwandeln? Oder wird ein bereits
>> in utf vorliegender string dann nochmals umgewandelt und dadurch
>> zerschossen?
>Du definierst, wie die Benutzereingabe an deine Applikation geschickt
>wird. Also musst du auch entscheiden, wie du mit der Eingabe umgehst.

Hä? Ich kann zwar definieren was ich gerne haben würde, aber
was ich bekomme steht auf einem anderen Blatt ;-).

Ich verteile die Seiten in utf und ich stelle soweit es in meinem
Einflussbereich liegt alle Weichen auf uft. Aber der client muss
sich ja nicht daran halten.

Soll ich deiner Aussage entnehmen "Wenn der client nicht parriert
ist es sein Problem"?. Nur werde ich dann halt auch oft mal
shredder-Texte in der db haben ...


>> Fragen über Fragen ... ;-)
>Ja, zu viel für einen Post. Ich empfehle dir konkrete Probleme zu
>fokussieren. Die Lösung derer fällt weit effektiver aus, als die Antwort
>auf ein allgemeines Fragezeichen. Ich schätze mal keiner hier ist fest
>angestellt, in der Newsgroup zu supporten. Bei deinem Post werden sich
>die meisten nicht die Zeit zum sinnvollen Kommentieren nehmen, sondern
>sich ein 'RTFM' denken ;)

Ich hätte nicht geschrieben - wenn ich aus reinem Lesen noch irgendwie
weitergekommen wäre. Das Problem ist, ich kann derzeit noch keine
'Fremdsprachen' simulieren, will aber später beim pre-release nicht
vor einem Trümmerhaufen stehen.
Derzeit habe ich soweit es möglich ist alle Stringmanipulationen auf
mb_ umgeschrieben bzw. eigene Versionen erstellt. Ich hoffe nur,
nichts Fatales übersehen zu haben.


Vielen Dank für Deine Ausdauer!



Gruss
Anton
--
Aber wieso? Gestern ging's doch noch!

Re: Verwirrt zwei Themen sessions, utf

Anton Huber meinte:

> Hä? Wat'n datt. Du kennst aber schon den Spruch 'Don't trust the
> client!' ?!?. Auch ein cookie kann auf PHPSESSID=12345 geändert
> werden. Und auch hier schätze ich php so ein - es wird die sess 12345
> anlegen.

Ja und? Selbst wenn eine serverseitige Sessiondatei angelegt wird - was
soll da schon drinstehen? Gefahr wäre ja nur beim Erraten der aus einem
Hash gebildeten Id gegeben - IIRC war da ohnedies kürzlich ein Thread zu
dem Thema - und das dauert doch recht lange... Dass Sessions nur in
Cookies akzeptiert werden, soll v.a. DAUs davon abhalten, ihre
Session-ID in Webforen und sonstwo mitzuposten.

> Der Benuzter hat direkte Einwirkmöglichkeit auf den sessionstring
> (auch bei Verwendung von cookies wenn hier auch nur advanced
> users ;-)). Ich aber keine im handler. Präzise genug?

Er kann einen GET-Parameter mit dem Namen PHPSESSID übergeben - wie soll
das "vermieden" werden? Und wenn eine Session mit der entsprechenden ID
vorhanden ist, dann wird sie genommen...

Gregor



--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Verwirrt zwei Themen sessions, utf

Gregor Kofler threw this exception:

Hallo Gregor!

>> Hä? Wat'n datt. Du kennst aber schon den Spruch 'Don't trust the
>> client!' ?!?. Auch ein cookie kann auf PHPSESSID=12345 geändert
>> werden. Und auch hier schätze ich php so ein - es wird die sess 12345
>> anlegen.
>
>Ja und? Selbst wenn eine serverseitige Sessiondatei angelegt wird - was
>soll da schon drinstehen? Gefahr wäre ja nur beim Erraten der aus einem
>Hash gebildeten Id gegeben - IIRC war da ohnedies kürzlich ein Thread zu
>dem Thema - und das dauert doch recht lange... Dass Sessions nur in
>Cookies akzeptiert werden, soll v.a. DAUs davon abhalten, ihre
>Session-ID in Webforen und sonstwo mitzuposten.
>
>> Der Benuzter hat direkte Einwirkmöglichkeit auf den sessionstring
>> (auch bei Verwendung von cookies wenn hier auch nur advanced
>> users ;-)). Ich aber keine im handler. Präzise genug?
>
>Er kann einen GET-Parameter mit dem Namen PHPSESSID übergeben - wie soll
>das "vermieden" werden? Und wenn eine Session mit der entsprechenden ID
>vorhanden ist, dann wird sie genommen...

Genau. Und dieses Verhalten möchte ich nicht. Ich präzisiere nochmals:
Was der client sendet ist mir egal nur ich möchte im Griff haben ob
ich die Daten akzeptieren will oder nicht.
Im sess.-handler habe ich aber nur die Möglichkeit die session nicht
an zu legen (sofern diese nicht entspricht also z.B. 12345). Ich kann
php jedoch nicht mitteilen wie die id nun wirklich lauten soll.

Ob sich da nun was ausnutzen lässt oder nicht ist nicht die primäre
Frage (über kurz oder lang sicher). Mir geht es darum klar definierte
Werte zu haben.

Das session-handling unter php ist ja eher so als würde der client
erst mal was in eine Datenbank schreiben können. Ich überprüfe dann
ob dies mir in den Kram passt - lösche es gegebenenfalls. Ist nicht
wirklich ein guter Ansatz (wenn auch programmatisch einfacher ;-)) ).

Eines sollte klar sein, solche Sachen sind immer der Anfang eines
Problems. Man sollte doch in der Lage sein, zumindest sever-seitig,
alles Kontrollieren und klar definieren zu können.
Ja, ja ich weiss es gibt ja funktionen dafür. Was ich nur nicht
verstehe ist warum diese nicht gleich im handler zu tragen kommen
können. Was anderes wollte ich eigentlich nicht sagen/fragen.


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!

Re: Verwirrt zwei Themen sessions, utf

Also ich verstehe eigentlich nicht warum Du was willst, versuche
aber mal ein wenig zu antworten.

Am Wed, 09 Apr 2008 10:28:15 +0200 schrieb Anton Huber:
> 1) Sessions
> - Ich suche nach einer Möglichkeit in einem benuzterdefiniertem
> session-handler die session id zu ändern. Also nicht mittels
> session_id($id); (ist ja in den handler-Funktionen nicht verfügbar)
> sondern bereits im Vorfeld (auch um mehrmahliges cookie senden zu
> verhindern).

Sonderwünsche erfordern Sonderlösungen. Du wirst um was selbst
geschriebenes nicht herumkommen. Du hast alle Möglichkeiten diesbezüglich
unter PHP. Kannst sogar selbst in C ein Modul programmieren ;-).

Sessions sind ja in Wahrheit nur Strohdumm. Verbinde mit einer langen
Zeichenfolge Inhalte und sorge, daß der Client die Nummer empfängt und Du
sie wieder zurückbekommst. Viel Spielraum lässt eine solche
Aufgabenstellung nicht.

> Dabei finde ich es sehr eigenwillig dass ein Benutzer z.B.
> example.com?PHPSESSID=12345 angeben kann und dies von php auch
> akzeptiert wird.

Warum sollte PHP das nicht akzeptieren. Was allerdings mit 12345
passiert, bestimmst Du. Und hier glaube ich, drückst Du dich schlecht
aus, oder Du weißt nicht, wie Sessions ablaufen. Letzteres schließe ich
aus dem bisher gelesenen aus.

> Ich aber keine Möglichkeit habe im handler die id
> umzuschreiben.

Auf was soll die ID denn umgeschrieben werden?

> Ich kann solch eine Anforderung ignorieren aber des wars
> auch schon.
> D.h. hier haben die Entwickler von php dem 'client' mehr
> Gestaltungsmöglichtkeit als dem 'server' eingeräumt, wenn ich jetzt mal
> nur den handler betrachte.

Ich sehe keinen Grund dies zu ändern.

Zur Sicherheit der grobe Ablauf des Sessionhandlings:
Wenn der Benutzer das ERSTE mal kommt, wird eine ID am Server generiert
und eine dementsprechende Datei angelegt. Diese ID Generierung hast Du in
der Hand. Danach hast Du bei jedem Zugriff diese SessionId. Die kannst Du
jederzeit abfragen und darauf reagieren. Du hast sogar die Möglichkeit
hier wieder eine neue SessionId zu generieren und dem Client zu senden.

Es ist in meinen Augen alles transparent. Ich denke, Du solltest Dich
gezielter ausdrücken. Mit Deinen Fragen verwirrst Du mich bisher eher ;-).

Gruß
Andreas
--
Kraftl EDV - Dienstleistungen
Linuxschulungen, Weblösungen, Linuxlösungen
http://www.kraftl.at

Re: Verwirrt zwei Themen sessions, utf

Anton Huber meinte:

> Genau. Und dieses Verhalten möchte ich nicht. Ich präzisiere nochmals:
> Was der client sendet ist mir egal nur ich möchte im Griff haben ob
> ich die Daten akzeptieren will oder nicht.

MUss ich nicht verstehen...

> Im sess.-handler habe ich aber nur die Möglichkeit die session nicht
> an zu legen (sofern diese nicht entspricht also z.B. 12345). Ich kann
> php jedoch nicht mitteilen wie die id nun wirklich lauten soll.

Du kannst dir ja eigenes Session-Handling basteln. Ein GET-Parameter
(antonhubersession=12345) - was und wie du damit dann umgehst, kannst
dann ganz allein du bestimmen.

> Ob sich da nun was ausnutzen lässt oder nicht ist nicht die primäre
> Frage (über kurz oder lang sicher).

Dass sich was ausnützen lässt? Nichts was nicht bei der
selbstgestrickten Lösung nicht auch passieren kann. Nachdem aber die
Default-Sessions von PHP auf Millionen Webseiten seit Jahren verwendet
werden, sind die potentiellen Probleme offensichtlich vertretbar.

Gregor



--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Verwirrt zwei Themen sessions, utf

Andreas Kraftl threw this exception:

Hallo Andreas!

>Also ich verstehe eigentlich nicht warum Du was willst, versuche
>aber mal ein wenig zu antworten.

>Sonderwünsche erfordern Sonderlösungen. Du wirst um was selbst
>geschriebenes nicht herumkommen. Du hast alle Möglichkeiten diesbezüglich
>unter PHP. Kannst sogar selbst in C ein Modul programmieren ;-).

Danke ;-), könnte ich wenn ich Zeit dafür hätte ;-).


>Sessions sind ja in Wahrheit nur Strohdumm. Verbinde mit einer langen
>Zeichenfolge Inhalte und sorge, daß der Client die Nummer empfängt und Du
>sie wieder zurückbekommst. Viel Spielraum lässt eine solche
>Aufgabenstellung nicht.
>
>> Dabei finde ich es sehr eigenwillig dass ein Benutzer z.B.
>> example.com?PHPSESSID=12345 angeben kann und dies von php auch
>> akzeptiert wird.
>
>Warum sollte PHP das nicht akzeptieren. Was allerdings mit 12345
>passiert, bestimmst Du. Und hier glaube ich, drückst Du dich schlecht
>aus, oder Du weißt nicht, wie Sessions ablaufen. Letzteres schließe ich
>aus dem bisher gelesenen aus.
>
>> Ich aber keine Möglichkeit habe im handler die id
>> umzuschreiben.
>
>Auf was soll die ID denn umgeschrieben werden?

O.k. wir sind hier schon in einem Bereich wo es eher nur mehr um
"Ansichtssache" geht.

Also wenn php jede id akzeptiert soll es nur recht sein.

Mit session_id() und regenerateid() kann ich die 12345 rausfiltern.

Nun, sinniger wäre es IMHO, wenn es schon die Möglichkeit eines
benuzterdefinierten handler gibt, hier auch die id validieren zu
können und gegebenenfalls eine andere zu generieren.
Oder sagen wir's programmatisch die id müsste im handler als
Referenz/Zeiger übergeben werden.

Ich sage nochmals ich finde es eigenartig dass ich hier im
handler keine Möglichkeit dazu habe.

Ich will ja nur Daten die ich will ;-).

Wenn ich bestimme es gibt nur sessions die mit A anfangen und
mit B aufhören, dann will ich nicht sess_12345 in /tmp liegen haben.
Mit diesen Einschränkungen habe ich auch die Sicherheit diese
id ist 'von mir' generiert.

Im handler habe ich nur zwei Möglichkeiten entweder ich akzeptiere
die sessionid oder ich führe keine Aktion aus - was sehr
unbefriedigend ist.


>> Ich kann solch eine Anforderung ignorieren aber des wars
>> auch schon.
>> D.h. hier haben die Entwickler von php dem 'client' mehr
>> Gestaltungsmöglichtkeit als dem 'server' eingeräumt, wenn ich jetzt mal
>> nur den handler betrachte.
>
>Ich sehe keinen Grund dies zu ändern.

Sehr gut. Es gibt auch sehr viele konträre Meinungen zu diesem Thema,
ich bin nicht der Einzige der dies bekrittelt


>Zur Sicherheit der grobe Ablauf des Sessionhandlings:
>Wenn der Benutzer das ERSTE mal kommt, wird eine ID am Server generiert
>und eine dementsprechende Datei angelegt. Diese ID Generierung hast Du in
>der Hand.

Falsch. Wenn der client bereits eine, für mich nicht valide (damit
meine ich nicht ob diese nun existiert oder nicht, sondern ob die
Zeichen (also die Syntaktik) des session-strings für mich passt) id
mitschickt, habe ich bereits eine Datei in /tmp die ich nicht haben
will. Finde ich, ehrlich gesagt befremdlich.
Ändern kann ich die id es erst nach session_start(). Sogesehen
habe ich es im zweiten Anlauf erst wirklich in der Hand.


>Danach hast Du bei jedem Zugriff diese SessionId. Die kannst Du
>jederzeit abfragen und darauf reagieren. Du hast sogar die Möglichkeit
>hier wieder eine neue SessionId zu generieren und dem Client zu senden.
>Es ist in meinen Augen alles transparent. Ich denke, Du solltest Dich
>gezielter ausdrücken. Mit Deinen Fragen verwirrst Du mich bisher eher ;-).

Ist es jetzt verständlich? Ich will nicht das der client was 'anlegen'
kann was für mich nicht in Ordnung ist. Ich will aber auch nicht das
überhaupt keine session (Datei) angelegt wird.

Aber ich denke wir reden hier über was wo sich andere schon
mehr Kopfzerbrechen gemacht haben.


PS: Der grösste Hit ist, eine PHPSESSID=(/&)/%/ anzugeben dann
wird eine session 'sess_' angelegt ...
Und da kanns sicher mal zu einer Komplikation kommen ...


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!

Re: Verwirrt zwei Themen sessions, utf

>> Im sess.-handler habe ich aber nur die Möglichkeit die session nicht an
>> zu legen (sofern diese nicht entspricht also z.B. 12345). Ich kann php
>> jedoch nicht mitteilen wie die id nun wirklich lauten soll.

Vorweg: Ich hab keinen Blassen Schimmer von der Programmierung eigener
session-handler. Allerdings schaut mir das Problem so aus, als sei hier
ein Missverständnis/Fehler bei der Programmierung dieses Handlers
vorhanden. PHP hat einen eigenen Session-Handler. Dieser Bekommt die
Session ID und macht was damit. Wenn es eine Datei mit dieser session id
gibt, dann wird die session fortgeführt, ansonsten wird eine neue session
erstellt. Es wird NICHT eine neue session mit der session id erstellt,
die PHP übergeben wurde, sondern PHP denkt sich eine eigene neue session
id aus. Ich denke mal, dass dein session handler auf eine fehlerhafte
session id reagieren muss, indem die session nicht erstellt wird, dann
wird dein handler vielleicht nocheinmal aufgerufen mit dem Auftrag eine
neue session zu erstellen und bei diesem Auftrag übergibst du dann eine
neue session id.
Wie gesagt, das ist nur so aus dem Bauch vermutet, aber das Problem ist
sicherlich der selbst geschriebene session-handler.

Re: Verwirrt zwei Themen sessions, utf

Frank Arthur threw this exception:

Hallo Frank!

Wir sind mit dem thread etwas 'out of bound' ;-).

>>> Im sess.-handler habe ich aber nur die Möglichkeit die session nicht an
>>> zu legen (sofern diese nicht entspricht also z.B. 12345). Ich kann php
>>> jedoch nicht mitteilen wie die id nun wirklich lauten soll.
>
>Vorweg: Ich hab keinen Blassen Schimmer von der Programmierung eigener
>session-handler. Allerdings schaut mir das Problem so aus, als sei hier
>ein Missverständnis/Fehler bei der Programmierung dieses Handlers
>vorhanden. PHP hat einen eigenen Session-Handler. Dieser Bekommt die
>Session ID und macht was damit. Wenn es eine Datei mit dieser session id
>gibt, dann wird die session fortgeführt, ansonsten wird eine neue session
>erstellt. Es wird NICHT eine neue session mit der session id erstellt,
>die PHP übergeben wurde, sondern PHP denkt sich eine eigene neue session
>id aus.

Nein das ist schlichtweg falsch. Php übernimmt die session sowie der
client sie sendet. Und deswegen gibt es diese Diskussion auch erst
überhaupt. (auch bei php-handler).

Wenn ich id=12345 übergebe wird die session id=12345 angelegt.
Und das ist ein befremdliches Verhalten.

Im handler habe ich keine Eingriffsmöglichkeit ausser die session
nicht an zu legen. Was aber unbefriedigend ist.


> Ich denke mal, dass dein session handler auf eine fehlerhafte
>session id reagieren muss,

Kann er nur auf eine bestimmte Art.


> indem die session nicht erstellt wird, dann
>wird dein handler vielleicht nocheinmal aufgerufen mit dem Auftrag eine
>neue session zu erstellen und bei diesem Auftrag übergibst du dann eine
>neue session id.

Vielleicht?!? Nein wird er nicht es gibt dann eben für diesen request
keine session. Resultat: unbefriedigend.


>Wie gesagt, das ist nur so aus dem Bauch vermutet, aber das Problem ist
>sicherlich der selbst geschriebene session-handler.

Wahrscheinlich ;-). Das Verhalten ist aber nur beim php-eigenem
handler zu beobachten. Meiner ignoriert derzeit solche id=12345 ...



Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!

Re: Verwirrt zwei Themen sessions, utf

Anton Huber schrieb:
> Nein das ist schlichtweg falsch. Php übernimmt die session sowie der
> client sie sendet. Und deswegen gibt es diese Diskussion auch erst
> überhaupt. (auch bei php-handler).
>
> Wir sind mit dem thread etwas 'out of bound' ;-).

Was heißt das?

Unglaublich. Hab es eben selbst getestet. Tatsächlich erzeugt PHP mit
seinem standard session handler eine session-Datei mit dem Namen, dem das
PHP-script z.B. per url übergeben wird.

In deinem eigenen session handler könntest du doch eine Sicherheitsebene
einbauen, indem du deine session nicht mit dem übergebenem session string
speicherst, sondern einfach eine MD5 Prüfsumme davon. Dann bekommst du
z.B. 12345 von PHP und speicherst aber immer MD5 davon (vielleicht sowas
wie 456fcd67df767fd, nur geraten). Oder du entfernst Zeichen, die du
nicht haben willst und als kritisch betrachtest. Wenn du diese Routine
immer auf den session string von PHP anwendest, kannst du auch später
immer 12345 deiner Datei mit dem bereinigten Namen zuordnen.