CONTENIDO Forum

Meine Frage ist damit allerdings nicht beantwortet. Wo ist der Sicherheitsgewinn, wenn '!#$%&\'*+\\/=?^`{|}~' nicht als Zeichen erlaubt sind? Oder ist es einfach nur das Gefühl, dass das Erlauben von mehr Zeichen automatisch einen Sicherheitsverlust bedeutet?
Das da dürfte deine Frage nach den ...

Wobei mir bei nochmaligem genaueren Betrachten aufgefallen ist, dass dann ganz korekterweise noch einige Zeichen für den reguären Ausdruck escaped werden müssten. So sollte es dann ungefähr passen:

'!#\\$%&\'\\*\\+\\/=\\?\\^`\\{\\|\\}~'

Weil es so schön deutlich ist, bin ich ja Fan Deiner Aufteilung.
Danke :oops:!

Es geht nur um die Erhöhung der Sicherheit, damit E-Mail-Adressen, die für eine Versendung verwendet werden, auch E-Mail-Adressen sind (bzw. eine Eingabe auch nur eine E-Mail-Adresse enthält).
Statt $$sLocalRegEx ...

Ich bitte um Meinungen, ob man wirklich etliche Sondervarianten zulassen muss, oder ob es nicht ausreicht, einen "simplen" Aufbau zu verlangen? Gerne auch optional (also ein isValidMail(default oder simple oder extended)).
Ich finde den strukturierten Aufbau wie von mir vorgeschlagen (ohne mich ...

im übrigen ist im local-part nach meiner einschätzung jegliches zeichen erlaubt, ausser einem @. sogar lücken, wenn das ganze in doppelten anführungszeichen steht. in der praxis macht das zwar niemand, aber denkbar ist es schon. Siehe dazu auch diesen Beitrag etwas weiter oben.

Aber in der neuen ...

Mein Fehler, wer lesen kann, ist klar im Vorteil. $_REQUEST wird ja an der Stelle gar nicht geändert, sondern neu erzeugt, mein Vorschlag ist also Blödsinn :oops:.

Allerdings könnte ich eventuell in meinen Skripten einfach $_REQUEST verwenden, da es bei mir schon vorliegt (PHP-Version > 4.1.0) und ...

Schade - da muss ich wohl weiteren Overhead einbauen, um den Ursprungszustand meiner Variablen wiederherzustellen. Aber PHP6 wird ja bestimmt irgendwann kommen ;).

Zur Umsetzung: Was würdest du eher machen (auch im Bezug auf die Performance): In globals_off.inc.php Kopien der Originale von $_POST ...

Ansonsten als einzigen Verbesserungsvorschlag: $sDomainChar = 'a-zäöü'; Zur zusätzlichen Berücksichtigung der Besonderheiten der TLDs vielleicht besser noch $sLocalChar = '-a-z0-9!#$%&\'*+\\/=?^_`{|}~';
$sLocalRegEx = '['.$sLocalChar.'](\\.*['.$sLocalChar.'])*';
$sDomainChar = 'a-zäöü ...

ich hätte angenommen, eine email dürfe im local-part eigentlich alle zeichen enthalten ausser einem @. Der RFC, der mich zu einem anderen Urteil hat kommen lassen: RFC 2822 (siehe aber auch mein Beitrag dazu etwas weiter oben auf dieser Seite). Brazo hat aber auch so etwas angenommen. Kennst du ...

OT:

Brazo Alkher hat geschrieben:

calvini hat geschrieben:Und da Brazo sich leider nicht mehr gemeldet hat:

Sorry Jungs

Kein Grund zur Entschuldigung - sogar ich weiß, dass es ein Leben neben dem Internet gibt . Trotzdem natürlich danke für die Rückmeldung und auch eventuelle zukünftige sachdienliche Hinweise zum Thema E-Mail-Adresse.

Finde ich gut ;). Deckt sich deine Einschätzung des RFC mit meiner, dass z.B. auch %@foobar.de eine gültige Adresse ist? Und da Brazo sich leider nicht mehr gemeldet hat: Hat mal jemand geprüft, ob Umlaute auch im local-part erlaubt sind? Dazu noch ein Verweis auf eine Diskussion bei SELFHTML (kommt ...

Eventuell bringt es schon etwas, wenn du statt <div id="logo"><img src="images/trio.jpg" width="1024" height="161" border="0"></div>
<div id="additionalnavi"><a href="front_content.php?idcat=73" class="additionalnavi"> |.. Livit-Musikschule</a> <a href="front_content.php?idcat=74" class ...

Du solltest aber trotzdem beide Aufrufe ändern (also auch den in conEditFirstTime()). Wobei ich die Lösung über den Datensatzschlüssel präferieren würde, da diese das Problem behebt und nicht verlagert (mit der aktuellen Lösung sind jetzt keine META-Tags mit Unterstrich im Namen möglich). Wäre ja ...

Hat dein Provider eventuell auf PHP5 umgestellt oder experimentiert damit (siehe auch hier)?

Hier geht es weiter (kann ja ggf. einer der Mods zusammenkleben).