Warum...

[cody]

---

Sondern auch Ersties??

[Der_Ich]

---

@cody

Sondern auch Ersties??

Erstis sind eine Teilmenge von Computernutzern.

[siccegge]

---

@TheFlow:1321969409

(Komma statt Punkt, etc.)

Dumm nur, dass eine Email adresse durchaus kommas enthalten darf

[Das_F]

---

Ich dachte Komma wären eins der wenigen Zeichen die nicht erlaubt sind…

[John_Late]

---

http://www.remote.org/jochen/mail/info/chars.html

Erlaubt schon, dann muss aber gequotet werden. In der Regel will man mit seiner Mailadresse Emails empfangen und nicht fremde Software testen, von daher eine schlechte Idee.

Aber wenn man selbst Adress-Validierung baut, ist das natürlich eine der vielen perversen Stellen um die man sich kümmern müsste.

[miniwahr]

---

@John Late

http://www.remote.org/jochen/mail/info/chars.html

Erlaubt schon, dann muss aber gequotet werden. In der Regel will man mit seiner Mailadresse Emails empfangen und nicht fremde Software testen, von daher eine schlechte Idee.

Aber wenn man selbst Adress-Validierung baut, ist das natürlich eine der vielen perversen Stellen um die man sich kümmern müsste.

Hmm… vielleicht kann man durch Ausnutzung solcher Regeln eine spamfreie Emailadresse einrichten? Schließlich haben Spammer doch vermutlich das selbe Problem?

[John_Late]

---

Wenn es dumm läuft, haben die Spammer damit weniger Probleme als die Leute die dir wirklich Mails schicken können sollen

[TheFlow]

---

Dass Kommas pirinzipiell erlaubt sind war mir nicht bewusst. Wieder was gelernt :). Wobei auch noch gequotet in Hochkommas möchte ich nicht wissen, wie viele Email-Clients oder gar Server man damit aus dem Tritt bringen kann ;).

@John Late

Wenn es dumm läuft, haben die Spammer damit weniger Probleme als die Leute die dir wirklich Mails schicken können sollen

Vermutlich, aber da man mit der Adresse dann nicht viele „normale“ Emails bekommen wird fällt zumindest das Sortieren leicht :D.

[siccegge]

---

@TheFlow

Dass Kommas pirinzipiell erlaubt sind war mir nicht bewusst. Wieder was gelernt :). Wobei auch noch gequotet in Hochkommas möchte ich nicht wissen, wie viele Email-Clients oder gar Server man damit aus dem Tritt bringen kann ;).

also exim kanns zustelln und gnus kommt mit zurecht

[t.animal]

---

Also ich kenne Leute, die haben ne Mail <Name"@@domain.tld> um Spam zu verhindern.

[heeen]

---

Das geht auch einfacher: einfach Mailserver Port ändern.

[neverpanic]

---

@heeen

Das geht auch einfacher: einfach Mailserver Port ändern.

Das geht auch einfacher: /etc/init.d/ stop.

Funktioniert gut, netter Nebeneffekt: Man hat gleich viel weniger Arbeit und weniger Leute wollen was von einem.

[Yves]

---

@Der Ich:1321953122

Verwendest du ein PHP-Framework?

Nein. Nur meine eigene Code-Sammlung aus den letzten Jahren. Und mit jeder Nutzung in einem neuen Projekt schreibe ich die Funktionen und Klassen ein bisschen wiederverwendbarer. In letzter Zeit konnte ich oft einfach Code aus anderen Projekten einsammeln und hatte schon alles Grundlegende zusammen. Aber ich weiß schon, dass ich Dinge gerne selber mache. Oft aus der Erfahrung, dass es dann am besten funktioniert… :huh: Dann ist es gut, wenn mir kein closed-source/binary Framework oder sowas im Weg steht, das ich nicht anpassen kann.

also Schutz gegen XSS, CSRF und Injections sind praktisch built-in.

Wie soll das denn bitte gehen? So wie bei ASP.NET, wo mir die Seite bei bestimmten verdächtigen Benutzereingaben runtergeplumpst ist, weil Microsoft meinte, das sei gefährlich? War es aber gar nicht. Musste diese Prüfung auf der betreffenden Seite dann ganz ausschalten. Die genannten Angriffswege müssen im Anwendungskonzept behandelt werden. In der Programmiersprache (oder einem Framework) ist nicht mehr genügend Information vorhanden, um das korrekt zu machen. Dann kommen solche Fehler dabei raus, dass es unzuverlässig wird.

[code]
class User < ActiveRecord::Base
validates :tos, :acceptance => true, :on => :create

(…)[/code]

IMO liest sich das wie von selbst.

Hä? Ich versteh gar nix. Es wird wohl eine Klasse definiert, die kleiner ist als eine andere, aber wo ist jetzt der Code?

@TheFlow:1321957070

(wobei, gibt es überhaupt eine TLD, die kürzere 2nd-Level-Domains als zwei Zeichen erlaubt?)

http://x.org/ Bei ccTLDs ist mir ein solches Beispiel nicht bekannt, aber es gibt ja nur 36*240 Möglichkeiten zum Durchprobieren…

[sabel]

---

@Yves

@TheFlow:1321957070

(wobei, gibt es überhaupt eine TLD, die kürzere 2nd-Level-Domains als zwei Zeichen erlaubt?)

http://x.org/ Bei ccTLDs ist mir ein solches Beispiel nicht bekannt, aber es gibt ja nur 36*240 Möglichkeiten zum Durchprobieren…

Für .de wurden die alle vor nem Jahr oder so vergeben.
http://a.de

[Der_Ich]

---

@Yves

also Schutz gegen XSS, CSRF und Injections sind praktisch built-in.

Wie soll das denn bitte gehen? So wie bei ASP.NET, wo mir die Seite bei bestimmten verdächtigen Benutzereingaben runtergeplumpst ist, weil Microsoft meinte, das sei gefährlich? War es aber gar nicht. Musste diese Prüfung auf der betreffenden Seite dann ganz ausschalten. Die genannten Angriffswege müssen im Anwendungskonzept behandelt werden. In der Programmiersprache (oder einem Framework) ist nicht mehr genügend Information vorhanden, um das korrekt zu machen. Dann kommen solche Fehler dabei raus, dass es unzuverlässig wird.

nunja standardmäßig wird jeglicher text escaped ausgegeben im view. Für CSRF werden diese einmal-tokens erzeugt und sql-statements schreibt man nicht mehr selbst.

[code]
class User < ActiveRecord::Base
validates :tos, :acceptance => true, :on => :create

(…)[/code]

IMO liest sich das wie von selbst.

Hä? Ich versteh gar nix. Es wird wohl eine Klasse definiert, die kleiner ist als eine andere, aber wo ist jetzt der Code?

< ist die Ruby-Syntax für Vererbung von Klassen und ActiveRecord::Base ist die Basisklasse für neue Models.

validates :tos, :acceptance => true, :on => :create

Das ist zum Beispiel ein Validator der die variable :tos (terms-of-service) prüft ob sie akzeptiert wurde, aber nur wenn ein neues User-Model erschaffen wird (:on => :create) wird dieser validator gecheckt.

Will nun mit Sicherheit keinen der schon 10 Jahre+ PHP macht zum konvertieren bewegen Für mich fand ich es aber eine passable Alternative und wollte es mal als (wenn es auch sehr euphorisch klang) als eine PHP-Alternative etwas anpreisen.

[Yves]

---

@Der Ich

nunja standardmäßig wird jeglicher text escaped ausgegeben im view.

Ah, so wie dieses dämliche magic-quoting, das bei PHP jetzt zum Glück ganz abgeschafft wird. Da kommen dann so Formularbestätigungen wie „Ich kann\\'s nicht haben, wenn alles \\„escapet\\“ wird“ bei raus. Sehr nützlich.

Für CSRF werden diese einmal-tokens erzeugt

Okay, aber auch die haben ihre Nachteile.

und sql-statements schreibt man nicht mehr selbst.

Woher weiß denn Rails (wir waren doch bei Rails, oder?), was ich die Datenbank fragen will? Und ganz so weit braucht man gar nicht gehen: Parameter Binding ist völlig ausreichend gegen SQL Injections. Es darf halt nur kein Stückchen Netzwerk-Input irgendwie Bestandteil eines SQL-Strings werden.

[sabel]

---

@Yves

@Der Ich

nunja standardmäßig wird jeglicher text escaped ausgegeben im view.

Ah, so wie dieses dämliche magic-quoting, das bei PHP jetzt zum Glück ganz abgeschafft wird. Da kommen dann so Formularbestätigungen wie „Ich kann\\'s nicht haben, wenn alles \\„escapet\\“ wird“ bei raus. Sehr nützlich.

Er meint wohl eher, dass die Zeichen in HTML entities umgewandelt werden.

@Yves

@Der Ich

und sql-statements schreibt man nicht mehr selbst.

Woher weiß denn Rails (wir waren doch bei Rails, oder?), was ich die Datenbank fragen will? Und ganz so weit braucht man gar nicht gehen: Parameter Binding ist völlig ausreichend gegen SQL Injections. Es darf halt nur kein Stückchen Netzwerk-Input irgendwie Bestandteil eines SQL-Strings werden.

Rails macht sowas wie Doctrine für PHP

Doctrine (PHP)

[Der_Ich]

---

@Yves

und sql-statements schreibt man nicht mehr selbst.

Woher weiß denn Rails (wir waren doch bei Rails, oder?), was ich die Datenbank fragen will? Und ganz so weit braucht man gar nicht gehen: Parameter Binding ist völlig ausreichend gegen SQL Injections. Es darf halt nur kein Stückchen Netzwerk-Input irgendwie Bestandteil eines SQL-Strings werden.

Der Standardkram und noch ein bisschen mehr wird dadurch abgedeckt, wenn man ganz spezielle Abfragen braucht kann man die natürlich immer noch manuell stellen…

Btw. so ist das rechtmühselig jedes kleine Fitzel zu erklären, wenn es dich tatsächlich interessiert kannst du dir ja dies hier zu Gemüte führen:

Getting Started

Ruby on Rails Tutorial

[shock_gone_wild]

---

Hm… also was jetzt wirklcih die bessere Sprache fuer Webanwendungen ist, liegt doch im Ermessen des Programmierers…
Man kann mit PHP absolut schlechten Code schreiben, aber man kann seine Webanwendungen auch gut durchdacht und
sicher gestalten.

@DerIch

also Schutz gegen XSS, CSRF und Injections sind praktisch built-in.

Ich verwende zum Beispiel das CodeIgniter Framework fuer PHP, da ist dieser Schutz quasi auch built-in, wenn ich
die Acitve-Record Syntax verwende…
Fuer XSS Schutz kann ich den globalen XSS Filter verwenden und CSRF kann ich mit dem Form-Helper bzw. ner selbst erstellten Form-Klasse
erreichen…
Und zur endgueltigen Absicherung verwendet man noch sowas wie PHPIDS…

Wenn man als Programmierer weis, welche Gefahren lauern dann ist das schon die halbe Miete, weil man dann egal, welche Sprache man benutzt,
auf boeswillige Eingaben reagieren kann. Leider tun das die wenigsten (vor allem Anfaenger).
Und genau darin liegt meiner Meinung nach die Schwaeche von PHP, was zu viel Murks erlaubt.

Aber wenn man sich auskennt, dann kann man auch mit PHP durchaus objektorientiert Programmieren und muss nicht mal auf Type-Hinting etc verzichten. Die Zeiten von Magic_Quotes und Safe_Mode in PHP sind vorbei.

Wo ich recht geben muss ist die inkonsistenz bei Parametern, aber zu den Funktionen bietet php.net eine ausgezeichnete Doku…

Wie ihr seht, bin ich ein Verfechter pro PHP, ohne Rails je angeschaut zu haben.
Es liegt halt daran, was man mit der verwendeten Sprache anstellt…

Ich war mal interesse halber in ner Vorlesung, da meinte ein Prof, PHP ist kacke, weil man da zum Beispiel nicht die Sessions mehrerer Webshops auf demselben Server trennen kann… Von session.save_path hatte er anscheinend noch nichts gehoert…

Also ich bin der Meinung man sollte das benutzen, mit dem man sich sicher im Umgang fuehlt… nich was irgendwelche Artikel/Forumeintraege propagieren

[xwolf]

---

@shock_gone_wild

Die Zeiten von Magic_Quotes und Safe_Mode in PHP sind vorbei.

Leider nicht, denn 1. schreibst du es selbst:

@shock_gone_wild

Man kann mit PHP absolut schlechten Code schreiben

Ich würde davon ausgehen, daß derzeit die Mehrheit alle Leute die mit Web zu tun haben, keine Ahnung von PHP, $AndereProgrammiersprache, JavaScript, CSS, HTML oder $CMS haben. Aber gleichzeitig der Meinung sind, daß sie den Job trotzdem tun können. Web kann doch schliesslich jeder. Sieht man doch auch im Werbefernsehen. Einfach die Homepage zusammenklickern…

Und 2.: Mindestens 60% aller Webauftritte werden von Leuten ge-un-pflegt, die vor Jahren mal diese übernommen haben und wo irgendwer der längst nicht mehr da und bekannt ist, ein Skript (meist in PHP) installierte, was „irgendwas“ macht, wovon der aktuelle „Betreuer“ aber nicht den Hauch einer Ahnung hat, sich aber trotzdem nicht traut, es wegzuwerfen. „Es könnte ja wichtig sein“!

Bei Perl und anderen Sprachen ists natürlich genauso. Matt Wrights „berüchtigtes“ FormMail.cgi 1.0 wackelt auch noch durchs Netz…