PHP-Umfrage

rüdiger

Nur mal um zu zeigen, das Sicherheitslücken durch PHP real sind:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-184769.html
http://www.c-plusplus.net/forum/viewtopic-var-t-is-183935.html

DEvent

import net.sf.cglib.proxy.Enhancer; 
import net.sf.cglib.proxy.MethodInterceptor; 
import net.sf.cglib.proxy.MethodProxy;

Welche Bibliothek ist das, cglib? Die kannte ich noch nicht.

Und kann man jetzt einfach

delegator = new ClassOneDelegator();
delegator.irgend_eine_methode_die_niergens_in_ClassOneDelegator_auftaucht(foo, blaa);
delegator.irgend_ein_attribut_der_niergens_in_ClassOneDelegator_auftaucht = blaa;

schreiben?

DEvent

rüdiger schrieb:

Nur mal um zu zeigen, das Sicherheitslücken durch PHP real sind:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-184769.html
http://www.c-plusplus.net/forum/viewtopic-var-t-is-183935.html

Was hat das mit Php-Fehlern zu tun? Das erste ist eine mySQL-Injektion und beim zweiten wurde der Server gehackt. Dies könnte mit jeder anderen Sprache auch passieren, wer mySQL-Befehle ohne überprüfung/maskierung ausführt ist halt selber schuld.

PHP hat aber schon sehr viel Balast von älteren Versionen. Ist ja mit C++ genauso. Vielleicht wäre es besser einen Bruch zu machen zwischen Php4 und Php5, und so die Web-Entwickler zu ihrem Glück zwingen.

ronny

dann kann man auch gleich eines der genialen frameworks in ruby oder python nehmen

die sind flotter als php und für die gewöhnlichen 08/15 seiten muss man keine zeile sql schreiben, injections werden automatisch verhindert, und man hat eine sauere trennung von modellen, opertationen und darstellung

warum also php noch ändern - einfach nur was einsetzen, das nicht mist ist

Mr. N

DEvent schrieb:

Ist ja mit C++ genauso.

Ich höre wesentlich seltener von sicherheitskritischen Bugs in GCC, glibc und libstdc++ als in PHP. Also nein, ist nicht genauso.

finix

http://www.jameslaver.com/php_vs_python.png

Badestrand

r0nny schrieb:

dann kann man auch gleich eines der genialen frameworks in ruby oder python nehmen

die sind flotter als php und für die gewöhnlichen 08/15 seiten muss man keine zeile sql schreiben, injections werden automatisch verhindert, und man hat eine sauere trennung von modellen, opertationen und darstellung

warum also php noch ändern - einfach nur was einsetzen, das nicht mist ist

Soweit ich weiß, ist Ruby (On Rails) aber wesentlich langsamer als PHP und auch wesentlich RAM-& CPU-intensiver.
Ohne FastCGI (oder so ähnlich?) soll da nix gehen, ausprobiert hab ichs aber noch nicht

Der Durchschnitt

DEvent schrieb:

import net.sf.cglib.proxy.Enhancer; 
import net.sf.cglib.proxy.MethodInterceptor; 
import net.sf.cglib.proxy.MethodProxy;

Welche Bibliothek ist das, cglib? Die kannte ich noch nicht.

Und kann man jetzt einfach

delegator = new ClassOneDelegator();
delegator.irgend_eine_methode_die_niergens_in_ClassOneDelegator_auftaucht(foo, blaa);
delegator.irgend_ein_attribut_der_niergens_in_ClassOneDelegator_auftaucht = blaa;

schreiben?

Das kann man halt in der Hinsicht schlecht mit der PHP Version vergleichen, da in Wirklichkeit eine neue Klasse erstellt wird mit der gegebenen Superklasse. Insofern sind die Methoden sowieso schon definiert, eben von der Superklasse. Überschreiben kann man sie eben mit dem MethodInterceptor mit dem man den Methoden-Aufruf weiterdelegieren kann. Wenn man nicht will, dass eine Subklasse erstellt wird, muss eben eine Schnittstelle einführen, die dann implementiert wird.

Mr. N

Der Durchschnitt schrieb:

da in Wirklichkeit eine neue Klasse erstellt wird mit der gegebenen Superklasse

Wie lange dauert das? Gregor hat mal erzählt, dass ein Aufruf der Compiler-API 900 Millisekunden gedauert hat, was ganz klar unakzeptabel langsam ist.

phlox81

Badestrand schrieb:

r0nny schrieb:

dann kann man auch gleich eines der genialen frameworks in ruby oder python nehmen

die sind flotter als php und für die gewöhnlichen 08/15 seiten muss man keine zeile sql schreiben, injections werden automatisch verhindert, und man hat eine sauere trennung von modellen, opertationen und darstellung

warum also php noch ändern - einfach nur was einsetzen, das nicht mist ist

Soweit ich weiß, ist Ruby (On Rails) aber wesentlich langsamer als PHP und auch wesentlich RAM-& CPU-intensiver.
Ohne FastCGI (oder so ähnlich?) soll da nix gehen, ausprobiert hab ichs aber noch nicht

kannst du es auch beweisen?
Ausserdem kann man immer einen fetteren Server kaufen

Der Durchschnitt

Mr. N schrieb:

Der Durchschnitt schrieb:

da in Wirklichkeit eine neue Klasse erstellt wird mit der gegebenen Superklasse

Wie lange dauert das? Gregor hat mal erzählt, dass ein Aufruf der Compiler-API 900 Millisekunden gedauert hat, was ganz klar unakzeptabel langsam ist.

Ich weiß noch, dass das vor 2 Jahren auf jeden Fall ein Problem war, zumindestens wenn man ständig Proxies neu erstellen wollte. Wie das heute aussieht, weiß ich ehrlich gesagt nicht so genau, aber ansich ist das, selbst wenn es heute noch so ist, kein so großes Problem, wie du es darstellst. Letztendlich brauchst du ja nur ein Proxy-Objekt pro Klasse und dieses kannst du dann benutzen um die Aufrüfe an weitere "Proxies" zu delegieren. Dadurch hast du maximal etwas längere Startzeiten je nachdem wieviele Klassen man für die Proxies erstellen muss. Soweit ich weiß, hat es beispielsweise Google beim Google Guice Framework ähnlich implementiert, da die ja auch CGLIB verwenden.

Badestrand

phlox81 schrieb:

kannst du es auch beweisen?
Ausserdem kann man immer einen fetteren Server kaufen

Ich hab mich einfach auf (mehrere) Erfahrungsberichte verlassen, die User gepostet haben
Ich meine auch gelesen zu haben, dass die RoR-Leute selber empfehlen, FastCGI zu nehmen, und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.

Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich :p

rüdiger

Badestrand schrieb:

und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.

naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...

Mr. N

Der Durchschnitt schrieb:

Dadurch hast du maximal etwas längere Startzeiten je nachdem wieviele Klassen man für die Proxies erstellen muss.

Naja wenn man 500 Klassen erstellen will ist das sicher nicht so praktikabel. Oder?

Badestrand schrieb:

Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich

Bewährt und praxistauglich hieße für mich auch: Wenige Sicherheitslücken.

pale dog

jedenfalls haben die meisten 'ich hasse php' angekreuzt.
was die PHP-hasser wohl für die webprogrammmierung nehmen würden?
JSP? ASP.NET oder was anderes?

Der Durchschnitt

Mr. N schrieb:

Der Durchschnitt schrieb:

Dadurch hast du maximal etwas längere Startzeiten je nachdem wieviele Klassen man für die Proxies erstellen muss.

Naja wenn man 500 Klassen erstellen will ist das sicher nicht so praktikabel. Oder?

Wenn wir von dem Fall ausgehen, dass ein Projekt 500 Proxyklassen direkt beim Start benötigt, dann denke ich, dass es angemessen ist zu behaupten: Das ist mit ziemlicher Sicherheit keine 1-Tier Anwendung, die nur auf dem Desktop läuft. Realistischer ist wohl eher, dass ein Web- oder gar Applicationserver verwendet wird und hierbei ist es ja für den Benutzer nicht so wichtig wie lange die Startzeiten sind, da er diese nie abwarten muss. Zusätzlich erlauben ja viele Applicationserver auch noch Hot-Deployment womit sich Performanceeinbußen beim Starten noch weiter relativieren.

was die PHP-hasser wohl für die webprogrammmierung nehmen würden?
JSP? ASP.NET oder was anderes?

Obwohl ich eigentlich eingefleischter Java-Programmierer bin, würde ich für kleinere Projekte, die ich ansonsten womöglicherweise auch in PHP implementieren würde, zu ASP.NET greifen, sofern es die Infrastruktur eben erlaubt. Man müsste schon beinahe absichtlich entsprechende Lücken einbauen, damit z.B. SQL Injection oder ähnliches möglich wäre. Entwicklungszeiten sind auch phänomenal kurz und was Microsoft da mit ASP.NET AJAX produziert hat spricht ja wirklich für sich. ASP.NET ist eben nicht ASP, da darf man Vorurteile auf keinen Fall mitschleppen.

mick

pale dog schrieb:

jedenfalls haben die meisten 'ich hasse php' angekreuzt.
was die PHP-hasser wohl für die webprogrammmierung nehmen würden?
JSP? ASP.NET oder was anderes?

Perl mit mod_perl
einfach genial - genial einfach
und sicherer
und ich liebe einfach solche aufrufe wie com am[y]... wieter oben beschrieben...

Badestrand

rüdiger schrieb:

Badestrand schrieb:

und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.

naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...

Ganz ehrlich Rüdiger, ich kenne mich mit der Thematik kaum aus; vor ein oder zwei Wochen wollte ich mir nur mal Ruby On Rails anschauen, hab ein wenig damit herumgespielt und mir halt Erfahrungsberichte durchgelesen.
Das waren die Informationen, die ich erhalten hab und ich "glaube" daran, jedenfalls im Groben.
Was ich davon noch im Kopf hab, ist, dass "normales" CGI irgendwelchen Krams bei Bedarf lädt und ausführt. FastCGI hingegen behält den Krams die ganze Zeit über im Arbeitsspeicher und verwendet aus irgendwelchen Gründen auch mehr CPU als Normal-CGI. Ich weiß, dass diese "Informationen" sehr sehr vage sind, ich hab aber nunmal keine Lust, mich wegen der Diskussion tiefer in die Thematik einzuarbeiten.
Jedenfalls soll laut einiger Quellen RoR mit normalem CGI sehr langsam laufen, der Server sollte deshalb FastCGI verwenden, was aber mehr Ressourcen beansprucht. Für gegenläufige Aussagen will ich Beweise

Mr. N schrieb:

Badestrand schrieb:

Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich

Bewährt und praxistauglich hieße für mich auch: Wenige Sicherheitslücken.

Das ist Ansichtssache, Windows finde ich auch "bewährt und praxistauglich", strotzt(e) aber auch nicht vor Sicherheit.

DEvent

Mr. N schrieb:

DEvent schrieb:

Ist ja mit C++ genauso.

Ich höre wesentlich seltener von sicherheitskritischen Bugs in GCC, glibc und libstdc++ als in PHP. Also nein, ist nicht genauso.

Naja, wieviel GCC, glibc und libstdc++ wird den in Servern für die generierung von HTML-Seiten verwendet?

Das hört sich allerdings interessant an:

... und für die gewöhnlichen 08/15 seiten muss man keine zeile sql schreiben, injections werden automatisch verhindert, und man hat eine sauere trennung von modellen, opertationen und darstellung

Achja btw, der Grund wieso ich mich noch nicht mit RonR beschäftigt habe ist eigentlich der: Ruby ist eine mächtige OO-Sprache, aber irgendwie ist Ruby bei Web-Anwendung wie mit Kanonnen auf Spatzen zu schießen. Relativiert sich das vielleicht mit der Größe des Web-Projektes, aber trotzdem. Für einfache Einsatzzwecke sollte man auch ein einfaches Werkzeug benutzen, und da hat eben php Vorteile.

Na, in nächster Zeit werde ich paar Bücher zu RonR lesen, dann sprechen wir uns wieder.

Mr. N

Badestrand schrieb:

rüdiger schrieb:

Badestrand schrieb:

und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.

naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...

Ganz ehrlich Rüdiger, ich kenne mich mit der Thematik kaum aus; vor ein oder zwei Wochen wollte ich mir nur mal Ruby On Rails anschauen, hab ein wenig damit herumgespielt und mir halt Erfahrungsberichte durchgelesen.
Das waren die Informationen, die ich erhalten hab und ich "glaube" daran, jedenfalls im Groben.
Was ich davon noch im Kopf hab, ist, dass "normales" CGI irgendwelchen Krams bei Bedarf lädt und ausführt. FastCGI hingegen behält den Krams die ganze Zeit über im Arbeitsspeicher und verwendet aus irgendwelchen Gründen auch mehr CPU als Normal-CGI. Ich weiß, dass diese "Informationen" sehr sehr vage sind, ich hab aber nunmal keine Lust, mich wegen der Diskussion tiefer in die Thematik einzuarbeiten.
Jedenfalls soll laut einiger Quellen RoR mit normalem CGI sehr langsam laufen, der Server sollte deshalb FastCGI verwenden, was aber mehr Ressourcen beansprucht. Für gegenläufige Aussagen will ich Beweise

Erst nicht auskennen und dann Forderungen stellen, ja das haben wir gerne. :p

Beweise du lieber erstmal, dass mod_php keine Ressourcen braucht...

Badestrand schrieb:

Mr. N schrieb:

Badestrand schrieb:

Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich

Bewährt und praxistauglich hieße für mich auch: Wenige Sicherheitslücken.

Das ist Ansichtssache, Windows finde ich auch "bewährt und praxistauglich", strotzt(e) aber auch nicht vor Sicherheit.

PHP ist noch eine Größenordnung schlimmer als Windows.