Welche Programmiersprache für aktive Internetseiten?

drakon

byto schrieb:

Freehoster sind maximal für irgendwelche Kellerprojekte zu gebrauchen, die eh niemand aufruft.

Dem stimme ich zu. Und auch sonst kann man sich die paar Euro pro Jahr wirklich geben, auch wenn es halt nur ein einfacher Blog sein wird. (Anderseits machst du mal ne Webseite für ne Kleinfirma und hast bereits jemanden, der dir den Server bezahlt. :p)

BasicMan01

ich verwende hauptsächlich auch nur PHP. Besonders ist es leicht und man kann schnell dynamische Sachen umsetzen. Die restliche Zeit ist auch notwendig, um seine Seite in allen Browsern gut aussehen zu lassen.
Des weiteren ist jeder Programmierer selber Schuld, wenn er seine Software offen lässt wie ein Scheunentor. Gegen SQL-Injections gibts auch in PHP Möglichkeiten. Ich sag nur als Beispiel mysql_real_escape_string

tntnet

BasicMan01 schrieb:

ich verwende hauptsächlich auch nur PHP. Besonders ist es leicht und man kann schnell dynamische Sachen umsetzen. Die restliche Zeit ist auch notwendig, um seine Seite in allen Browsern gut aussehen zu lassen.
Des weiteren ist jeder Programmierer selber Schuld, wenn er seine Software offen lässt wie ein Scheunentor. Gegen SQL-Injections gibts auch in PHP Möglichkeiten. Ich sag nur als Beispiel mysql_real_escape_string

Meines erachtens ist so eine Technik wie die genannte mysql_real_escape_string nicht der richtige Weg, um SQL-Injections zu vermeiden. Die Funktion bringt gleich 2 Nachteile mit sich.

Zunächst einmal ist es mysql-Spezifisch. Ein Programm sollte so Datenbankunabhängig wie möglich gemacht werden.

Ausserdem sollte man lieber Prepared Statements verwenden. Diese sind mehr oder wenige statische SQL-Statements mit Platzhaltern für die Daten. Die Daten werden dabei dann intern getrennt vom eigentlichen SQL-String transportiert und nicht mit diesem geparst. Der Vorteil ist zum einen, dass hier SQL-Injections prinzipiell ausgeschlossen werden können und zum anderen bringt das eine bessere Performance. In der Regel ist das Parsen und Optimieren des Statements relativ teuer. Mit Prepared Statements wird dieses Parsen und Optimieren für ein Statement ein mal gemacht und das Statement kann dann beliebig oft benutzt werden.

Aber fragt mich nicht, welche APIs in PHP dafür zur Verfügung stehen. Ich verwende kein PHP.

Nico D.

tntnet schrieb:

Ich verwende kein PHP.

Dann frage ich mich, wie du zur folgenden Aussage kommen konntest:

Meines erachtens ist so eine Technik wie die genannte mysql_real_escape_string nicht der richtige Weg, um SQL-Injections zu vermeiden. Die Funktion bringt gleich 2 Nachteile mit sich.
[...]
Zunächst einmal ist es mysql-Spezifisch. Ein Programm sollte so Datenbankunabhängig wie möglich gemacht werden.

Und zudem frage ich mich, was der zweite Nachteil von mysql_real_escape_string sein soll, so heisst es doch auf php.net:

mysql_real_escape_string() ruft die Funktion mysql_real_escape_string der MySQL-Bibliothek auf, die folgende Zeichen mit einem Backslash ('\') versieht: \x00, \n, \r, \, ', " und \x1a.

Ich wuesste nicht, wie da noch SQL-Injektionen moeglich sein sollten. Vielleicht koenntest du mich aufklaeren?

PS: Dass bei Verwendung dieser Funktion auch MySQL verwendet werden muss, ist wohl jedem bekannt. Sonst wuerde kein mysql voran stehen.

tntnet

heini schrieb:

tntnet schrieb:

Ich verwende kein PHP.

Dann frage ich mich, wie du zur folgenden Aussage kommen konntest:

Meines erachtens ist so eine Technik wie die genannte mysql_real_escape_string nicht der richtige Weg, um SQL-Injections zu vermeiden. Die Funktion bringt gleich 2 Nachteile mit sich.
[...]
Zunächst einmal ist es mysql-Spezifisch. Ein Programm sollte so Datenbankunabhängig wie möglich gemacht werden.

Und zudem frage ich mich, was der zweite Nachteil von mysql_real_escape_string sein soll, so heisst es doch auf php.net:

mysql_real_escape_string() ruft die Funktion mysql_real_escape_string der MySQL-Bibliothek auf, die folgende Zeichen mit einem Backslash ('\') versieht: \x00, \n, \r, \, ', " und \x1a.

Ich wuesste nicht, wie da noch SQL-Injektionen moeglich sein sollten. Vielleicht koenntest du mich aufklaeren?

PS: Dass bei Verwendung dieser Funktion auch MySQL verwendet werden muss, ist wohl jedem bekannt. Sonst wuerde kein mysql voran stehen.

Ich verstehe Deinen Einwand nicht. Zunächst einmal muss ich kein PHP verwenden, um seine Nachteile zu kennen. Vielleicht verwende ich PHP ja nicht, weil ich seine Nachteile kenne.

Aber nun zu Deinen konkreten Einwänden.

Ich finde es einfach unschön, datenbankabhängige Funktionen zu verwenden. Und ich muss kein PHP-Kenner sein, um anzunehmen, dass mysql_real_escape_string nicht datenbankunabhänig ist. Ich habe einfach mal angenommen, dass hier eine Postgresql-spezifische-API angesprochen wird . In Perl werden Datenbanken beispielsweise mit DBI/DBD angesprochen. In Java wird JDBC verwendet. Und in anderen Sprachen finden sich auch datenbankunabhängige APIs. Ich bin halt bestrebt, auch datenbankunabhängige Lösungen zu finden. Dazu zählt mysql_real_escape_string nicht.

Der zweite Nachteil bezieht sich auf die leider oft verwendete Technik, SQL-Statements dynamisch zusammen zu bauen. Das ist prinzipiell Fehleranfällig. Als Entwickler muss man schon sehr aufpassen, dass man wirklich alles notwendige mit mysql_real_escape verarbeitet. Dieses mysql_real_escape sollte nicht die erste Lösung sein, sondern die letzte, wenn es wirklich nicht anders geht.

Nico D.

tntnet schrieb:

Der zweite Nachteil bezieht sich auf die leider oft verwendete Technik, SQL-Statements dynamisch zusammen zu bauen. Das ist prinzipiell Fehleranfällig. Als Entwickler muss man schon sehr aufpassen, dass man wirklich alles notwendige mit mysql_real_escape verarbeitet. Dieses mysql_real_escape sollte nicht die erste Lösung sein, sondern die letzte, wenn es wirklich nicht anders geht.

Keine Funktion der Welt kann vor Programmierfehlern schuetzen.

Ob PHP oder nicht, mag ja Geschmackssache sein. Aber man kann eine Funktion nicht als unsicher bezeichnen, wenn sie selbst es nicht ist, sondern die Moeglichkeit der Unsicherheit letztlich nur darin bestehen koennte, wenn der Programmierer Fehler macht. Dann ist das ein Fehler des Programmierers und nicht der Funktion.

Und wenn man MySQL verwendet, wuesste ich keinen Grund, weshalb man diese Funktion nicht nutzen sollte. Alles andere in PHP selbst zusammengefriemelte waere

langsamer,
aufwendiger,
eine Neuerfindung einer bereits bestehenden Loesung und
wieder fehleranfaelliger.

Ich kann ja nachvollziehen, welchen Standpunkt du vertrittst - und wenn man andere Datenbanksysteme einbinden moechte, macht eine Verwendung speziell dieser Funktion logischerweise keinen Sinn. Aber wenn man davon ausgeht, dass ausschliesslich MySQL verwendet wird, macht alles andere keinen Sinn.

Und diese Anmerkung allein war Grund meines Einwands.

zwutz

in PHP sind vier Abstraktionsebenen und diverse spezifische Funktionen diverser Datenbanksysteme implementiert[*]. Also daran sollte es in PHP nicht scheitern.

Aber nur, weil man keine Prepared-Statements verwendet, ist eine Datenbankanwendung nicht automatisch unsicher.

BasicMan01

Was war denn an "Ich sag nur als Beispiel mysql_real_escape_string" so falsch zu verstehen? ... Ja Substantive sind ja net so wichtig. Das nächste mal lass ich das Wort "Beispiel" weg
Aber wie dem auch sei, prepared Statements sind in PHP auch kein Problem.
Datenbankunabhängige Programmierung ... aha .. soso ... Kein Problem für PHP, ich sag nur PDO. PHP wäre schon lange verschwunden, wenn die sich auf die faule Haut legen würden und die Sprache net weiterentwickeln würden.

PRIEST

Kennt jemand performance vergleiche zwischen PHP, Python und Ruby (on rails)?

Shade Of Mine

PRIEST schrieb:

Kennt jemand performance vergleiche zwischen PHP, Python und Ruby (on rails)?

Relativ irrelevant, da es auf die Skalierbarkeit ankommt. Man hat für jede Sprache sowieso Opcode caches, so dass es nur in den wenigsten Fällen wirklich relevant wird in welcher Sprache der Code geschrieben ist.

Aber schau zB mal hier:
http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

Prinzipiell ist Performance aber keine Frage der Sprache sondern eine des Frameworks. Für optimale Performance braucht man dann sowieso ein eigenes Framework... Und die Performance kommt im Web aus Caches.