content Type "Email Formular"
Posted: Mon 13. Sep 2004, 17:30
------[DEUTSCH]-----
Ich hab hier so meine kleinen Problemchen mit dem Email Formular.
Im Prinzip ist dieser Content Type ja nicht schwer zu verstehen, dennoch hab ich so meine Problemchen damit.
Es geht sich um die verschiedenen reservierten Felder, z.B: redirect, redirect_error, usw.
Mir ist gerade erst aufgefallen, dass diese Felder tatsächlich sichtbar im Quellcode stehen und direkt ausgelesen werden können.
Schade eigenltich, denn wenn sie da stehen, befinden sie sich automatisch auch in den verschiedenen Datenbanken diverser Spammer.
Daher hätte ich folgenden Vorschlag :
Statt die Felder auf die bisherige Art und Weise einzubinden, sollte man überlegen, ob man nicht das Backend ein wenig umändert.
Dort sollten die Felder :
Empfänger, Betreff, sowie alle reservierten versteckten Felder fest eingetragen werden können und in der DB in einer separaten Tabelle gespeichert werden (für den Fall dass es mehrere Email Empfänger gibt und auch mehrere Male der content type verwendet wird.)
Beim Absenden des Email Formulars werden dann die Felder, die jeder sehen kann und darf im Quellcode via post-methode übergeben, jedoch der Wert der oben genannten Felder aus der DB ausgelesen.
Das hat den Vorteil, dass sie nicht aus dem Quellcode ablesbar sind,
womit einige Leute ihren Wunsch nach verschlüsselten Email Adressen ebenfalls glücklich wären.
Ausserdem erspart es einem das doch recht umständliche einfügen auf diese Art und Weise :
Besteht die Möglichkeit sowas in die nächste Version einzubauen ?
------[ENGLISH]-----
I have some little Problems with the included content type "Email Form".
The usage is not really complicated, but I still have my problems with it.
More specific :
My issue are the different reserverd hidden fields available for this content type, i.e. redirect, redirect_error,
I found those hidden fields easy readable in the source code, what creates a little bit of headache, because if I can read those fields even SPAM Bots can find those adresses and I don't need to explain the mess
So this leads me to my feature request :
Instead of including those fields in the actual way, what about including those fields entirely in the backend.
The fields should be editable the same way as "Receiver" and "Subject" are editable at the moment.
After editing them in the backend they are stored in a sepearate table in the Database, for the case that there are different instanced of the content type with different receivers.
When the visitor then sends the email via the front end, all other created fields are send via post-method and all other fields from the backend are taken from the database.
The enormous advantage of this method :
Email Adresses could not be read anymore from source code, which would make many users having trouble with SPAM quite happy. And even other feature request concerning "encoded" email" would be solved that way.
This will also make the (IMHO) complicated way of adding those fields via
unnecessary.
Is there the possibility to include this modification in the next release ?
Ich hab hier so meine kleinen Problemchen mit dem Email Formular.
Im Prinzip ist dieser Content Type ja nicht schwer zu verstehen, dennoch hab ich so meine Problemchen damit.
Es geht sich um die verschiedenen reservierten Felder, z.B: redirect, redirect_error, usw.
Mir ist gerade erst aufgefallen, dass diese Felder tatsächlich sichtbar im Quellcode stehen und direkt ausgelesen werden können.
Schade eigenltich, denn wenn sie da stehen, befinden sie sich automatisch auch in den verschiedenen Datenbanken diverser Spammer.
Daher hätte ich folgenden Vorschlag :
Statt die Felder auf die bisherige Art und Weise einzubinden, sollte man überlegen, ob man nicht das Backend ein wenig umändert.
Dort sollten die Felder :
Empfänger, Betreff, sowie alle reservierten versteckten Felder fest eingetragen werden können und in der DB in einer separaten Tabelle gespeichert werden (für den Fall dass es mehrere Email Empfänger gibt und auch mehrere Male der content type verwendet wird.)
Beim Absenden des Email Formulars werden dann die Felder, die jeder sehen kann und darf im Quellcode via post-methode übergeben, jedoch der Wert der oben genannten Felder aus der DB ausgelesen.
Das hat den Vorteil, dass sie nicht aus dem Quellcode ablesbar sind,
womit einige Leute ihren Wunsch nach verschlüsselten Email Adressen ebenfalls glücklich wären.
Ausserdem erspart es einem das doch recht umständliche einfügen auf diese Art und Weise :
Code: Select all
IH|language|0||10,100|DE|0
IH|redirect|0||10,100|http://www.apple.com|0
IH|redirect_error|0||10,100|http://www.microsoft.com|0
IH|send_copy|0||10,100|1|0
IH|email|0||10,100|adresse@meine-domain.de|0------[ENGLISH]-----
I have some little Problems with the included content type "Email Form".
The usage is not really complicated, but I still have my problems with it.
More specific :
My issue are the different reserverd hidden fields available for this content type, i.e. redirect, redirect_error,
I found those hidden fields easy readable in the source code, what creates a little bit of headache, because if I can read those fields even SPAM Bots can find those adresses and I don't need to explain the mess
So this leads me to my feature request :
Instead of including those fields in the actual way, what about including those fields entirely in the backend.
The fields should be editable the same way as "Receiver" and "Subject" are editable at the moment.
After editing them in the backend they are stored in a sepearate table in the Database, for the case that there are different instanced of the content type with different receivers.
When the visitor then sends the email via the front end, all other created fields are send via post-method and all other fields from the backend are taken from the database.
The enormous advantage of this method :
Email Adresses could not be read anymore from source code, which would make many users having trouble with SPAM quite happy. And even other feature request concerning "encoded" email" would be solved that way.
This will also make the (IMHO) complicated way of adding those fields via
Code: Select all
IH|language|0||10,100|DE|0
IH|redirect|0||10,100|http://www.apple.com|0
IH|redirect_error|0||10,100|http://www.microsoft.com|0
IH|send_copy|0||10,100|1|0
IH|email|0||10,100|adresse@meine-domain.de|0Is there the possibility to include this modification in the next release ?
