Automatische PHPSESSID in Formular valide machen

[CharlyH]

Hallo liebe Forumsteilnehmer,

ist die php.ini entsprechend konfiguriert, wird bei deaktivierten Cookies bei Links und Formularen automatisch die PHPSESSID eingefügt. Im Quelltext sieht das dann so aus:

<form action="foo.php" method="post"><input type="hidden" name="PHPSESSID" value="4860886e35ea7dc569e3c008396ba1ba" />
[...]

Der Quellcode ist somit nicht mehr XHTML 1.0 strict valide. (document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag [...])

Nun gibt es den bekannten Workaround, bei dem in der php.ini der Eintrag 'url_rewriter.tags' modifiziert wird. Ändert man dort die Einstellung 'a=href,area=href,frame=src,input=src,form=fakeentry,fieldset=' auf 'a=href,area=href,frame=src,input=src,fieldset=' und fügt einem Formular ein <fieldset> hinzu, dann bringt die Validierung das gewünschte Ergebnis. Der Quellcode sieht nun so aus:

<form action="form1.php" method="post">  
<fieldset><input type="hidden" name="PHPSESSID" value="ac2b5fc24d0e0f29032765ed38b68c77" />

[...]

Nun ist es jedoch so, dass ich ein Formular im Einsatz habe, bei dem ich absolut kein Fieldset möchte. Das Formular besteht nur aus einem hidden input und einem Absendebutton. Die Ausgabe mit dem Fieldset-Rechteck ist nicht nur unhübsch, sondern auch verwirrend. Also würde es naheliegen, die selbe Lösung statt mit <fieldset> mit einem <p> zu verwirklichen.

Ändere ich versuchsweise in der php.ini den Eintrag also auf 'a=href,area=href,frame=src,input=src,p=' (ob mit oder ohne einem <p></p> nach dem einleitenden form-Tag), dann wird die PHPSESSID _überhaupt nicht mehr_ eingefügt.

Meine Frage:

Gibt es auch eine Möglichkeit, die PHPSESSID _valide_ einfügen zu lassen, _ohne_ ein <fieldset> zu benutzen? Also zB. so wie von mir angedacht mit einem Absatz?

Ich bedanke mich für jeden Hinweis!

Mit lieben Grüßen

CharlyH

[dedlfix]

Hi!

Die Ausgabe mit dem Fieldset-Rechteck ist nicht nur unhübsch, sondern auch verwirrend. Also würde es naheliegen,

... es mit CSS passend zu formatieren.

Gibt es auch eine Möglichkeit, die PHPSESSID _valide_ einfügen zu lassen, _ohne_ ein <fieldset> zu benutzen? Also zB. so wie von mir angedacht mit einem Absatz?

Hast du schon ein DIV probiert?

Lo!

[CharlyH]

Hallo lieber dedlfix,

... es mit CSS passend zu formatieren.

Mir ist schon klar, dass ich mit CSS das fieldset-Rechteck verschwinden lassen kann. Möchte aber trotzdem eine Lösung, die auch _ohne_ CSS optisch befriedigend ist. (Eine ausgegebene Seite mit einem 'LOS GEHT'S'-Button nach einem Textabsatz braucht einfach kein leeres Rechteck zwischen Text und dem Button.)

Hast du schon ein DIV probiert?

Ja, natürlich habe ich auch daran gedacht. Das hat bisher leider auch nicht den gewünschten Erfolg gebracht. In der php.ini habe ich das 'url_rewriter.tags' auf 'a=href,area=href,frame=src,input=src,div=' gesetzt. Das Ergebnis davon ist, dass auch hier wieder _überhaupt_ keine PHPSESSID mehr automatisch hinzugefügt wird. Unabhängig davon, ob ich dem Formular ein zusätzliches <div> mit auf den Weg gebe oder nicht.

Auch mit GOOGLE komme ich zu keiner Lösung weil _alle_ Workarounds mit dem <fieldset> arbeiten.

Hast Du irgend eine Idee? Vielleicht muß man ja nur das 'url_rewriter.tags' richtig - also anders - konfigurieren.

Mit lieben Grüßen

CharlyH

[Tom]

Hello,

Ist eine wirklich interessante Problemstellung.
Eigentlich müsste PHP dafür einen zusätzlichen Schalter für XHTML-Konformität bekommen.

Nur 'ne ganz blöde Idee:
Wie wäre es, wenn Du eine Exit- (register_shutdown_function()), oder eine Autoappend-Prozedur festlegst, die in jedes <Form> automatisch ein <p> einbaut, wenn ein NAME=session_name() darin zu finden ist?

Dazu müsstest Du wahrscgheinlich aber mit Output-Buffering arbeiten.

Ich weiß leider noch nicht, in welcher Reihenfolge hier welcher Job intern abgehandelt wird. Das Rewriting der URLs findet ja scheinbar on-the-fly statt, oder?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[CharlyH]

Hallo lieber Tom,

ich mache das jetzt _völlig_ anders. In der php.ini setze ich 'session.use_trans_sid' auf '0' und 'session.use_only_cookies' auf '1'. Dann setze ich auf der Startseite der Aplikation einen kleinen Testcookie und überprüfe in Folge auf der nächsten Seite, ob der Cookie vorhanden ist.

Bei positivem Ergebnis kommt es zur Skriptverarbeitung - ist kein Cookie abrufbar (ergo sind Cookies deaktiviert), wird dem User mitgeteilt, dass die Aplikation aus Sicherheitsgründen nur mit Cookies funktioniert.

Mir ist das sowieso lieber, wenn _ich_ bestimme, was in meinen Formularen steht.

Mit lieben Grüßen

CharlyH

[Tom]

Hello,

Bei positivem Ergebnis kommt es zur Skriptverarbeitung - ist kein Cookie abrufbar (ergo sind Cookies deaktiviert), wird dem User mitgeteilt, dass die Aplikation aus Sicherheitsgründen nur mit Cookies funktioniert.

Dann achte aber darauf, dass Du die Seite mit dem Startcookie entsprechend kennzeichnest, nicht dass es nachher eine Endlosschleife ergibt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Mir ist schon klar, dass ich mit CSS das fieldset-Rechteck verschwinden lassen kann. Möchte aber trotzdem eine Lösung, die auch _ohne_ CSS optisch befriedigend ist.

Warum? Wer CSS ausschaltet, hat noch ganz andere optische Veränderungen als den Rahmen.

Hast du schon ein DIV probiert?
Ja, natürlich habe ich auch daran gedacht. Das hat bisher leider auch nicht den gewünschten Erfolg gebracht.

Es scheint, dass url_rewriter.tags nur ein paar definierte Einträge haben will und nicht irgendwas nimmt.

Hast Du irgend eine Idee?

Wenn du CSS nicht magst und dich die Optik stört, dann bleibt nur, an der Stelle bewusst auf die Validität zu verzichten und das fieldset wegzulassen. Ich denke nicht, dass das gravierende negative Auswirkungen hat. Die Browser werden problemlos damit klarkommen. Alternativ nimm Transitional, dann ist es auch wieder valide - ebenfalls ohne Auswirkungen auf die Browser.

Lo!

[Tom]

Hello,

Es scheint, dass url_rewriter.tags nur ein paar definierte Einträge haben will und nicht irgendwas nimmt.

Es wäre ja auch nicht sinnvoll, außerhalb von Formularen Hidden-Fields einzubauen für die Session-ID, denn die würden ja gar nicht mitgeschickt werden beim Request, würden aber den gesamten Quellcode vermüllen, wenn sie z.B. in jedes <p> eingebaut würden.

Ein Fieldset kommt hingegen _üblicherweise_ nur in einem Form-Element vor und enthält dann _üblicherweise_ auch Input-Elemente. Das hat dann vermutlich die geringsten Schmerzen gekostet beim Nachfrickeln...

Welches Element würde denn eurer Meinung nach innerhalb eines Form-Elementes die geringsten Schmerzen verursachen, wenn es kein Fieldset sein soll?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Welches Element würde denn eurer Meinung nach innerhalb eines Form-Elementes die geringsten Schmerzen verursachen, wenn es kein Fieldset sein soll?

div. Das ist üblicherweise unsichtbar.
Was ich nicht sehe: Welchen Sinn/Vorteil es hat, bei Strict in das form noch ein Element schachteln zu müssen.

Lo!

[Tom]

Hello,

Welches Element würde denn eurer Meinung nach innerhalb eines Form-Elementes die geringsten Schmerzen verursachen, wenn es kein Fieldset sein soll?

div. Das ist üblicherweise unsichtbar.
Was ich nicht sehe: Welchen Sinn/Vorteil es hat, bei Strict in das form noch ein Element schachteln zu müssen.

Das habe ich auch nicht eingesehen, aber muss man immer alles verstehen, was das W3C so verzapft?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Das habe ich auch nicht eingesehen, aber muss man immer alles verstehen, was das W3C so verzapft?

Man sollte, denn dann kann man es intentionsgemäß verwenden und denkt sich nicht nur um der lieben Validität willen einen Workaround aus.

Lo!

[Der Martin]

Hallo,

Was ich nicht sehe: Welchen Sinn/Vorteil es hat, bei Strict in das form noch ein Element schachteln zu müssen.

darüber habe ich auch schon gerätselt. Eine schlüssige Erklärung habe ich nicht, aber es korreliert damit, dass auch body als übergeordnetes Container-Element in (X)HTML Strict keinen inline-Inhalt haben darf. Sowohl in body als auch in form muss inline-Inhalt in ein zusätzliches Blockelement verpackt werden.
Das Argument ist wohl, dass Text um der semantischen Struktur willen ohnehin in Überschriften, Absätze etc. organisiert sein sollte. Derselbe Gedanke liegt vermutlich auch beim form-Element zugrunde.

So long,
 Martin (der viele W3C-Ideen auch nicht nachvollziehen kann)