Problem mit mod_rewrite und PHP-Sessions

Thice · 23.02.2008, 09:31

Ich bin gerade dabei ein kleines CMS für die Nutzung von lesbaren Domains fit zu machen. Also eine simulierte Ordnerstruktur mittels mod_rewrite. Das funktioniert soweit gut bis auf ein Problem:

Ich verwende für ein Formular ein Captcha um Spam einzugrenzen. Der korrekte Code wird bei der Bildgenerierung in eine Session gespeichert und bei der Überprüfung der Formulardaten wieder ausgelesen. Das hat bisher wunderbar funktioniert, jetzt nicht mehr.

Das Formular hat so einen URI:
http://local/contact/ (rewrite auf http://local/index.php)
Das Captcha hat diesen:
http://local/img/captcha.php

Ich habe im Formular einen Schlüssel "foo" in die Session geschrieben um zu testen, ob die Session überhaupt funktioniert.

Wenn ich jetzt $_SESSION dumpe kommen in den beiden Dateien verschiede Sachen herraus:

contact:

Code:

array(1) {
  ["foo"]=>
  &string(5) "hello"
}

captcha:

Code:

array(2) {
  ["foo"]=>
  &string(5) "hello"
  ["cpt_code"]=>
  &array(2) {
    ["code"]=>
    string(6) "694828"
    ["time"]=>
    int(1203754338)
  }
}

Die Sessionvariable aus dem Formular ist also im Captcha lesbar, anders herum aber nicht.

Ich hatte schon gedacht, dass durch mod_rewrite die SessionID nicht korrekt übergeben wird. Daher hab ich mir session_id() ausgeben lassen. In beiden Dateien die gleiche.

Wenn ich, wie ohne mod_rewrite direkt über http://local/index.php?id=contact auf das Formular zugreife und auch das Formular da hin schicke, tut alles wunderbar.

Hat jemand eine Ahnung woran das liegen kann? Ich bin gerade ziemlich ratlos...

Noch kurz zum System:
- XAMPP
- Windows XP
- Apache/2.2.6 (Win32) DAV/2 mod_ssl/2.2.6 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.4
- PHP Version 5.2.4

Schon mal vielen Dank und viele Grüße,
Andy

dr.e. · 23.02.2008, 12:51

Zitat:

Die Sessionvariable aus dem Formular ist also im Captcha lesbar, anders herum aber nicht.

Warum? In der captcha.php sind doch einfach nur weitere Offsets in der Session registriert...

Thice · 23.02.2008, 14:06

Zitat:

Zitat von dr.e.

Warum? In der captcha.php sind doch einfach nur weitere Offsets in der Session registriert...

Danke für deine Antwort.

Aber genau auf diese neu gesetzten Offsets kann ich in der Formularauswertung nicht zugreifen. Das ist nur aus der captcha.php heraus möglich.

Der Fluss sieht ja so aus:
1. Formular startet die Session (setzt zu Testzwecken das 'foo' Offset). Das Formular beinhaltet einen <img>-Tag, der captcha.php einbindet und diesem die SessionID übergibt.
2. captcha.php startet die Session, generiert einen Code, speichert diesen in die Session und stellt ihn dar.
3. Das Formular wird abgeschickt. Dabei wird der von Benutzer eingegebene Code per POST übergeben. Dabei wird auch die SessionID übergeben.
4. Das Formular erhält die Daten, startet die Session, liest den Code aus und vergleicht.

Die SessionID ist bei allen drei serverseitigen Teilen (Formular, Captcha, Überprüfung) die gleiche, also muss ja auch die Session die gleiche sein. Daten, die irgendwann in die Session gespeichert werden, müssten zu einem späteren Zeitpunkt noch darin sein.

In 1) befindet sich 'foo' in der Session
In 2) befinden sich 'foo' und der Code in der Session
In 4) befindet sich nur noch 'foo' in der Session.

Nochmal: Die SessionID ist IMMER die gleiche. Wenn ich das ganze ohne mod_rewrite mache tut es. Also wird auch nicht irgendwo etwas aus der Session heraus gelöscht.

Ich frage mich also ob es sein kann, dass bestimmte Daten in der Session nur von bestimmten Pfaden der Seite ausgelesen werden können. /contact/ und /img/captcha.php liegen ja in gewisser Weise in verschiedenen Unterverzeichnissen. Der CookiePath ist '/', zusätzlich übergebe ich die SessionID auch noch per GET. Aber die Session wird ja auch gefunden. Nur manche Daten sind daraus verschwunden...

MfG,
Andy

Thice · 23.02.2008, 17:13

Ich habe mir jetzt mal die Session-Variable in eine Datei dumpen lassen. Jeweils bevor das Formular angezeigt bzw. die Daten geprüft werden und nachdem der Code im Captcha generiert und in die Session gespeichert wurde. Ich habe das Formular aufgerufen (dabei wird das Captcha angezeigt) und abgeschickt. Aufgrund der ungültigen Daten wird das Formular erneut angezeigt und das Captcha auch. Der Dump dieser sehr einfachen Aktion sieht sehr komisch aus:

Code:

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: captcha (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(2) { ["foo"]=> &string(5) "hello"
["cpt_code"]=> &array(2) {
    ["code"]=> string(6) "668254"
    ["time"]=> int(1203781641)
} }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(2) { ["foo"]=> &string(5) "hello"
["cpt_code"]=> &array(2) {
    ["code"]=> string(6) "668254"
    ["time"]=> int(1203781641)
} }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }
->compare!

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: captcha (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(2) { ["foo"]=> &string(5) "hello"
["cpt_code"]=> &array(2) {
    ["code"]=> string(6) "668254"
    ["time"]=> int(1203781641)
} }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(2) { ["foo"]=> &string(5) "hello"
["cpt_code"]=> &array(2) {
    ["code"]=> string(6) "668254"
    ["time"]=> int(1203781641)
} }
->compare!

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de)
array(1) { ["foo"]=> &string(5) "hello" }

file: xx gibt an in welcher Datei der dump gemacht wurde.
->compare! markiert die Stellen an denen der eingegebene mit dem generierten Code verglichen wird.

Wie man sieht wird vieles doppelt bis fünffach ausgeführt. Dabei geht auch der 'cpt_code' Offset verloren, da nach der Überprüfung der Code zurückgesetzt wird. Die "Instanz" der Seite, die schließlich die Überprüfung ausführt hat also keine Chance an die Daten zu kommen.

Meine Frage nun: Was ist denn das?! Was passiert hier? Die Dumps im Dokument werden jeweils nur einmal angezeigt. Es handelt sich also nicht um eine Schleife oder um einen Fehler im PHP-Code, der eine doppelte Ausführung bewirken würde... Die Seiten werden offenbar mehrfach aufgerufen, mein Browser macht das aber nicht. Kann das ein Problem in Apache sein? Man soll Apache2.x ja nicht produktiv mit PHP einsetzen. Hat jemand da Erfahrung und kann mir helfen?

dr.e. · 23.02.2008, 18:27

Hallo Thice,

das ist meiner Meinung nach ein race condition bzw. timing problem. Kannst du mir noch kurz erklären, wie deine captcha.php und wie deine index.php aufgerufen werden? Solltest du die captcha.php in einem img-Tag verwenden ist das ganz klar ein timing problem, da die index.php _vor_ der captcha.php fertig bearbeitet ist. Hier solltest du über eine Änderung deines Softwaredesigns nachdenken und die nötigen Informationen komplett in der Business-Logik deiner Software generieren und anschließend in die Session schreiben. Die captcha.php sollte dabei _nur_ lesend auf die Session zugreifen, dann funktioniert das.

Thice · 23.02.2008, 21:43

Danke dr.e. für deine Antwort,

es scheint tatsächlich ein Timingproblem zu sein. Allerdings nur, da die einzelnen Skripte wesentlich öfter aufgerufen werden, als sie sollten. Ich könnte jetzt natürlich einen Hack basteln, der genau damit dann trotzdem funktioniert, aber das bringt ja nicht viel. Vielmehr würde mich interessieren, was da schief läuft...

Prinzipiell ist das recht simpel strukturiert bei mir. Es gibt eine Klasse captcha_controller, die sich um die Verwaltung der Captcha-Tokens kümmert. Sie hat die Methoden create(), isAvailable(), get() und delete().

Bevor ein Formular dargestellt wird, wird $myCpt->delete() aufgerufen um bei jedem Formularaufruf einen neuen Token zu erzeugen. Genauso nach jeder Datenauswertung um nach jedem Versuch das Formular abzuschicken ein neuer Token generiert wird. Das Formular selbst enthält ein Bild, das captcha.php als Ziel hat. captcha.php überprüft ob bereits ein Token vorliegt, falls nicht wird einer erstellt. Danach wird der Token ausgelesen und als Bild gerendert.

Ich denke, dass es in der Tat sinnvoll ist, die Generierung des Tokens aus dem Bilderstellung-Skript, das ja zum Presentation-Layer gehört, herauszunehmen. Ich glaube aber nicht, dass das Problem dadurch behoben wird, da ja immer noch unkontrolliert Aufrufe an die Skripte stattfinden, die die Daten zurücksetzen bevor sie ausgewertet werden.

Leider habe ich immer noch keine Ahnung woher das kommt...

MfG,
Andy

dr.e. · 23.02.2008, 22:01

Hallo Thice,

die Captcha-Logik sollte in der Business-Schicht untergebracht sein. Die Präsentationsschicht sollte nur genau so viel Logik enthalten, wie zur Datenstellung der GUI notwendig ist. Aus diesem Grund würde ich die Erstellung des Captchas auch aus der Präsentationsschicht verbannten. Anregungen zur Umsetzung sind unter http://www.adventure-php-framework.o...mentarFunktion in Kapitel 5.

Was du auf jeden Fall prüfen solltest, warum die Skripten mehrmals aufgerufen werden. Bau hierzu am besten ein Logging in das Script ein und logge alle Parameter (z.B. $_SERVER). Evtl. hilft das.

Thice · 23.02.2008, 23:14

So! Ich geh jetzt ein bisschen meinen Kopf gegen die Wand hauen ^^

Ich habe mittlerweile den Grund für das seltsame Verhalten gefunden. Ich hatte für das FovoritenIcon der Seite keinen absoluten sondern einen relativen Pfad angegeben. Dadurch hat Firefox versucht das Bild /contact/favicon.ico zu laden. Das existiert natürlich nicht und /contact/ wird per mod_rewrite an das Kontaktformular umgeleitet. Dadurch gab es jedes Mal schon vor Aufruf der Formularauswertung einen Aufruf des Formulars wodurch die Werte der Session zurückgesetzt wurden...

Ich habe jetzt einen absoluten Pfad eingesetzt und alles tut wunderbar.

Danke dr.e. für deine Tipps. Ich werde das ganze auf jeden Fall noch mehr in Richtung MVC trimmen.

MfG,
Andy

@solved

dr.e. · 23.02.2008, 23:30

Schön, dass du den Grund gefunden hast.

Zitat:

Ich werde das ganze auf jeden Fall noch mehr in Richtung MVC trimmen.

MVC hat nichts mit der 3-Schicht-Architektur zu tun, die ich beschrieben habe. Weiterhin ist MVC _nur_ ein Pattern, das die Präsentationsschicht "verfeinert". Siehe hierzu "cooperation vs. coexistance of patterns". Ich empfehle dir mal das Buch "Patterns of enterprise application architecture" von Martin Fowler oder ein Gang of 4 Buch zu Pattern zu lesen.

Thice · 24.02.2008, 00:14

Zitat:

Zitat von dr.e.

MVC hat nichts mit der 3-Schicht-Architektur zu tun, die ich beschrieben habe. [...] Weiterhin ist MVC _nur_ ein Pattern, das die Präsentationsschicht "verfeinert". Siehe hierzu "cooperation vs. coexistance of patterns".

Das werde ich mir mal genauer anschauen. Für mich war eine Trennung in Presentation, Business und Data Layer bisher automatisch MVC.

Zitat:

Zitat von dr.e.

Ich empfehle dir mal das Buch "Patterns of enterprise application architecture" von Martin Fowler oder ein Gang of 4 Buch zu Pattern zu lesen.

"Design Patterns" der Gang of 4 liegt hier neben mir ^^

MfG,
Andy

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Sicherheitsfrage mit Sessions - Problem mit Intellitamper	Leibi	PHP-Fortgeschrittene	26	03.07.2008 12:38
Sessions Problem	StephenKing	PHP Tipps 2008	3	16.10.2007 08:30
sessions problem	022.9	PHP Tipps 2006	5	19.06.2006 18:13
problem bei sessions in komb. m. cookies. header umgehen?	Promaetheus	PHP Tipps 2006	10	02.05.2006 15:52
Ewiges Problem mit den Sessions / Warenkorb	max-dhom	PHP Tipps 2006	12	13.04.2006 18:04
Cookies, Sessions, Login-Fehler		PHP Tipps 2006	1	23.03.2006 12:59
Sessions Problem Mehrseitiges Formular		PHP Tipps 2006	6	02.02.2006 18:59
[Erledigt] Riesiges Problem mit Sessions		PHP Tipps 2005	3	30.04.2005 01:47
Problem bei einer If-Abfrage mit Sessions	maximus	PHP Tipps 2005	12	30.04.2005 01:36
Problem mit Sessions seit Upgrade auf PHP 4.3.10		PHP Tipps 2005	7	09.03.2005 01:29
Problem mit Sessions unter PHP 4.3.10		PHP Tipps 2005	2	22.02.2005 23:14
Problem mit Sessions		PHP Tipps 2005	2	10.02.2005 11:57
Proble mit Sessions		PHP Tipps 2005	7	07.02.2005 17:42
Problem mit "Keksen" bei Sessions?		PHP-Fortgeschrittene	4	17.09.2004 00:05
PHP Serverpfad Problem mit Sessions		PHP Tipps 2004	2	05.08.2004 18:56

23.02.2008, 09:31
Thice Erfahrener Benutzer Registriert seit: 27.10.2003 Beiträge: 530	Problem mit mod_rewrite und PHP-Sessions Ich bin gerade dabei ein kleines CMS für die Nutzung von lesbaren Domains fit zu machen. Also eine simulierte Ordnerstruktur mittels mod_rewrite. Das funktioniert soweit gut bis auf ein Problem: Ich verwende für ein Formular ein Captcha um Spam einzugrenzen. Der korrekte Code wird bei der Bildgenerierung in eine Session gespeichert und bei der Überprüfung der Formulardaten wieder ausgelesen. Das hat bisher wunderbar funktioniert, jetzt nicht mehr. Das Formular hat so einen URI: http://local/contact/ (rewrite auf http://local/index.php) Das Captcha hat diesen: http://local/img/captcha.php Ich habe im Formular einen Schlüssel "foo" in die Session geschrieben um zu testen, ob die Session überhaupt funktioniert. Wenn ich jetzt $_SESSION dumpe kommen in den beiden Dateien verschiede Sachen herraus: contact: Code: array(1) { ["foo"]=> &string(5) "hello" } captcha: Code: array(2) { ["foo"]=> &string(5) "hello" ["cpt_code"]=> &array(2) { ["code"]=> string(6) "694828" ["time"]=> int(1203754338) } } Die Sessionvariable aus dem Formular ist also im Captcha lesbar, anders herum aber nicht. Ich hatte schon gedacht, dass durch mod_rewrite die SessionID nicht korrekt übergeben wird. Daher hab ich mir session_id() ausgeben lassen. In beiden Dateien die gleiche. Wenn ich, wie ohne mod_rewrite direkt über http://local/index.php?id=contact auf das Formular zugreife und auch das Formular da hin schicke, tut alles wunderbar. Hat jemand eine Ahnung woran das liegen kann? Ich bin gerade ziemlich ratlos... Noch kurz zum System: - XAMPP - Windows XP - Apache/2.2.6 (Win32) DAV/2 mod_ssl/2.2.6 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.4 - PHP Version 5.2.4 Schon mal vielen Dank und viele Grüße, Andy __________________ kintzebros.de \| KintzeBros Home Entertainment 2061. Nach dem Frieden \| kurzfilm Paula \| spielfilm


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

23.02.2008, 17:13
Thice Erfahrener Benutzer Registriert seit: 27.10.2003 Beiträge: 530	Ich habe mir jetzt mal die Session-Variable in eine Datei dumpen lassen. Jeweils bevor das Formular angezeigt bzw. die Daten geprüft werden und nachdem der Code im Captcha generiert und in die Session gespeichert wurde. Ich habe das Formular aufgerufen (dabei wird das Captcha angezeigt) und abgeschickt. Aufgrund der ungültigen Daten wird das Formular erneut angezeigt und das Captcha auch. Der Dump dieser sehr einfachen Aktion sieht sehr komisch aus: Code: file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: captcha (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(2) { ["foo"]=> &string(5) "hello" ["cpt_code"]=> &array(2) { ["code"]=> string(6) "668254" ["time"]=> int(1203781641) } } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(2) { ["foo"]=> &string(5) "hello" ["cpt_code"]=> &array(2) { ["code"]=> string(6) "668254" ["time"]=> int(1203781641) } } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } ->compare! file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: captcha (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(2) { ["foo"]=> &string(5) "hello" ["cpt_code"]=> &array(2) { ["code"]=> string(6) "668254" ["time"]=> int(1203781641) } } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(2) { ["foo"]=> &string(5) "hello" ["cpt_code"]=> &array(2) { ["code"]=> string(6) "668254" ["time"]=> int(1203781641) } } ->compare! file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: contact (SID: 23ca6d8b8a96f89f8a50f242ee9550de) array(1) { ["foo"]=> &string(5) "hello" } file: xx gibt an in welcher Datei der dump gemacht wurde. ->compare! markiert die Stellen an denen der eingegebene mit dem generierten Code verglichen wird. Wie man sieht wird vieles doppelt bis fünffach ausgeführt. Dabei geht auch der 'cpt_code' Offset verloren, da nach der Überprüfung der Code zurückgesetzt wird. Die "Instanz" der Seite, die schließlich die Überprüfung ausführt hat also keine Chance an die Daten zu kommen. Meine Frage nun: Was ist denn das?! Was passiert hier? Die Dumps im Dokument werden jeweils nur einmal angezeigt. Es handelt sich also nicht um eine Schleife oder um einen Fehler im PHP-Code, der eine doppelte Ausführung bewirken würde... Die Seiten werden offenbar mehrfach aufgerufen, mein Browser macht das aber nicht. Kann das ein Problem in Apache sein? Man soll Apache2.x ja nicht produktiv mit PHP einsetzen. Hat jemand da Erfahrung und kann mir helfen? __________________ kintzebros.de \| KintzeBros Home Entertainment 2061. Nach dem Frieden \| kurzfilm Paula \| spielfilm

23.02.2008, 18:27
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hallo Thice, das ist meiner Meinung nach ein race condition bzw. timing problem. Kannst du mir noch kurz erklären, wie deine captcha.php und wie deine index.php aufgerufen werden? Solltest du die captcha.php in einem img-Tag verwenden ist das ganz klar ein timing problem, da die index.php _vor_ der captcha.php fertig bearbeitet ist. Hier solltest du über eine Änderung deines Softwaredesigns nachdenken und die nötigen Informationen komplett in der Business-Logik deiner Software generieren und anschließend in die Session schreiben. Die captcha.php sollte dabei _nur_ lesend auf die Session zugreifen, dann funktioniert das. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

23.02.2008, 21:43
Thice Erfahrener Benutzer Registriert seit: 27.10.2003 Beiträge: 530	Danke dr.e. für deine Antwort, es scheint tatsächlich ein Timingproblem zu sein. Allerdings nur, da die einzelnen Skripte wesentlich öfter aufgerufen werden, als sie sollten. Ich könnte jetzt natürlich einen Hack basteln, der genau damit dann trotzdem funktioniert, aber das bringt ja nicht viel. Vielmehr würde mich interessieren, was da schief läuft... Prinzipiell ist das recht simpel strukturiert bei mir. Es gibt eine Klasse captcha_controller, die sich um die Verwaltung der Captcha-Tokens kümmert. Sie hat die Methoden create(), isAvailable(), get() und delete(). Bevor ein Formular dargestellt wird, wird $myCpt->delete() aufgerufen um bei jedem Formularaufruf einen neuen Token zu erzeugen. Genauso nach jeder Datenauswertung um nach jedem Versuch das Formular abzuschicken ein neuer Token generiert wird. Das Formular selbst enthält ein Bild, das captcha.php als Ziel hat. captcha.php überprüft ob bereits ein Token vorliegt, falls nicht wird einer erstellt. Danach wird der Token ausgelesen und als Bild gerendert. Ich denke, dass es in der Tat sinnvoll ist, die Generierung des Tokens aus dem Bilderstellung-Skript, das ja zum Presentation-Layer gehört, herauszunehmen. Ich glaube aber nicht, dass das Problem dadurch behoben wird, da ja immer noch unkontrolliert Aufrufe an die Skripte stattfinden, die die Daten zurücksetzen bevor sie ausgewertet werden. Leider habe ich immer noch keine Ahnung woher das kommt... MfG, Andy __________________ kintzebros.de \| KintzeBros Home Entertainment 2061. Nach dem Frieden \| kurzfilm Paula \| spielfilm

23.02.2008, 22:01
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hallo Thice, die Captcha-Logik sollte in der Business-Schicht untergebracht sein. Die Präsentationsschicht sollte nur genau so viel Logik enthalten, wie zur Datenstellung der GUI notwendig ist. Aus diesem Grund würde ich die Erstellung des Captchas auch aus der Präsentationsschicht verbannten. Anregungen zur Umsetzung sind unter http://www.adventure-php-framework.o...mentarFunktion in Kapitel 5. Was du auf jeden Fall prüfen solltest, warum die Skripten mehrmals aufgerufen werden. Bau hierzu am besten ein Logging in das Script ein und logge alle Parameter (z.B. $_SERVER). Evtl. hilft das. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

23.02.2008, 23:14
Thice Erfahrener Benutzer Registriert seit: 27.10.2003 Beiträge: 530	So! Ich geh jetzt ein bisschen meinen Kopf gegen die Wand hauen ^^ Ich habe mittlerweile den Grund für das seltsame Verhalten gefunden. Ich hatte für das FovoritenIcon der Seite keinen absoluten sondern einen relativen Pfad angegeben. Dadurch hat Firefox versucht das Bild /contact/favicon.ico zu laden. Das existiert natürlich nicht und /contact/ wird per mod_rewrite an das Kontaktformular umgeleitet. Dadurch gab es jedes Mal schon vor Aufruf der Formularauswertung einen Aufruf des Formulars wodurch die Werte der Session zurückgesetzt wurden... Ich habe jetzt einen absoluten Pfad eingesetzt und alles tut wunderbar. Danke dr.e. für deine Tipps. Ich werde das ganze auf jeden Fall noch mehr in Richtung MVC trimmen. MfG, Andy @solved __________________ kintzebros.de \| KintzeBros Home Entertainment 2061. Nach dem Frieden \| kurzfilm Paula \| spielfilm