4. Javascript auf dem Server

Javascript auf dem Server

  • M

    Was mich grad interessieren würde...

    Es ist ja nicht wirklich üblich, JavaScript auf dem Server einzusetzen, obwohl es auf dem Client ständig verwendet wird. Was spricht da eigentlich dagegen? (Außer dass es halt nicht üblich ist und kein Apache-Modul hat und so...)

    Bzw. was würdet ihr zu Javascript auf dem Server meinen - einfach mal angenommen?

    (Nein, ich habe jetzt keine konkrete Anwendung. ;))

    0
  • B

    ka was dagegen spricht, aber was spricht dafür?

    0
  • M

    byto schrieb:

    ka was dagegen spricht, aber was spricht dafür?

    1. Javascript ist eigentlich ne ziemlich nette Sprache.
    2. Man verwendet Javascript schon im Browser, also hat man mehr oder weniger nur eine Skriptsprache, die man nutzen muss.

    PS: Wieso "$$$"?

    0
  • ?

    - JavaScript unterstützt eine "andere" Objektorientierung, als z.B. C++ oder PHP. Ein Objekt ist in JavaScript lediglich ein Hash. Nix private oder protected ...
    - JavaScript besitzt keine Standardbibliothek die annähernd benutzbar ist. Keine Datenbankanbindung. Keine Template-Engine. Nichts.
    - Der Code wird vom Browser interpretiert. Wer aber interpretiert den serverseitigen Code? Super, jetzt haben wir nicht mehr nur 3 Browser, die sich nicht einig werden, sondern auch noch verschiedene Webserver mit ihren proprietären Implementationen ...
    - Ein integraler Bestandteil von JavaScript ist inzwischen DOM geworden. Das wäre aber bei serverseitiger Anwendung völlig sinnlos. Wer bestimmt, was beim Server enthalten ist und was nicht? Haben wir dann nicht streng genommen wieder 2 Sprachen? Wenn beide Varianten identisch bleiben, wie reagiert ein Server auf asymmetrische Ajax-Request? Wie reagiert der Client, wenn wir eine Verbindung zum SQL-Server herstellen wollen, oder die Pipe xyz öffnen? Man müsste alles haarklein definieren, und da ein serverseitiges JavaScript eine anständige Standardbibliothek bräuchte, stellte sich wieder die Frage: Wie erklärt man das den Browserherstellern? Da die alle ihr eigenes Süppchen kochen, hätte man wiederum 2 verschiedene Sprachen ... usw. usf.

    Ich könnte noch weiter machen 😉

    0
  • M

    árn[y]ék schrieb:

    - JavaScript unterstützt eine "andere" Objektorientierung, als z.B. C++ oder PHP. Ein Objekt ist in JavaScript lediglich ein Hash. Nix private oder protected ...

    🙂

    Das stört mich aber nicht soo sehr.

    árn[y]ék schrieb:

    - JavaScript besitzt keine Standardbibliothek die annähernd benutzbar ist. Keine Datenbankanbindung. Keine Template-Engine. Nichts.

    Hmm doch, da gibt es ein paar Sachen. Trotzdem ein guter Punkt.

    árn[y]ék schrieb:

    - Der Code wird vom Browser interpretiert. Wer aber interpretiert den serverseitigen Code? Super, jetzt haben wir nicht mehr nur 3 Browser, die sich nicht einig werden, sondern auch noch verschiedene Webserver ...

    Wer interpretiert PHP-Code? 😉

    árn[y]ék schrieb:

    Ich könnte noch weiter machen

    Ja bitte! 😋

    0
  • S

    Mr. N schrieb:

    Es ist ja nicht wirklich üblich, JavaScript auf dem Server einzusetzen

    Meinst du vielleicht JScript (vergl. http://de.wikipedia.org/wiki/JScript)? JScript ist in großen Teilen kompatibel zu JavaScript und wird als Alternative zu VBScript auf so manchem (Web-) Server eigesetzt.

    0
  • M

    schmidt-webdesign.net schrieb:

    Mr. N schrieb:

    Es ist ja nicht wirklich üblich, JavaScript auf dem Server einzusetzen

    Meinst du vielleicht JScript (vergl. http://de.wikipedia.org/wiki/JScript)? JScript ist in großen Teilen kompatibel zu JavaScript und wird als Alternative zu VBScript auf so manchem (Web-) Server eigesetzt.

    Nein, ich meine eigentlich Javascript. - Aber sind ja glaub verwandte Sprachen. - Gegen die Verwendung von JScript würde wohl sprechen, dass es AFAIK nicht auf Linux-Servern funktioniert.

    0
  • ?

    wozu noch so ne dreckssprache auf nem server? damit noch mehr hilfsfrickler ne zu ihnen passende sprache haben um sicherheitslöcher zu produzieren?

    0
  • S

    auf der schachtel schrieb:

    wozu noch so ne dreckssprache auf nem server? damit noch mehr hilfsfrickler ne zu ihnen passende sprache haben um sicherheitslöcher zu produzieren?

    Hast du vielleicht ein Beispiel, das zeigt, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen?

    0
  • S
    Mod

    Mr. N schrieb:

    Bzw. was würdet ihr zu Javascript auf dem Server meinen - einfach mal angenommen?

    Super Idee. Es fehlt lediglich an Libraries - aber die würden ja kommen wenn JS auf dem Server eingesetzt werden würde.

    Das Problem dabei ist denke ich nur, dass kein Know-How vorhanden ist. Kaum ein Webentwickler kann wirklich JavaScript - es wird meistens nur zusammen gehackt.

    Aber im Prinzip wäre JS eine Super Serverseitige Sprache - vorallem weil es dann die Möglichkeit bietet dynamisch zu entscheiden ob ich den Code jetzt auf dem Server ausführen will oder auf dem Client.

    Wenn es zB einen import von PHP oder Perl Libraries gäbe und der Serverseitige JS Interpreter technisch OK wäre und eine halbwegs ordentliche Verbreitung hätte - würde ich JS wohl PHP vorziehen. Wie gesagt - hauptproblem wäre, dass es keine Libs gibt um sinnvolle Sachen zu machen - wenn man aber PHP oder Perl Libraries importieren könnte - wäre das Problem gelöst.

    0
  • R

    das sollte mit parrot innerhalb nicht vorhersehbarer zeit machbar sein

    0
  • H

    http://www.onlamp.com/pub/a/onlamp/2007/08/30/introducing-trimpath-junction.html

    0
  • M

    Shade Of Mine schrieb:

    Wenn es zB einen import von PHP oder Perl Libraries gäbe und der Serverseitige JS Interpreter technisch OK wäre und eine halbwegs ordentliche Verbreitung hätte - würde ich JS wohl PHP vorziehen. Wie gesagt - hauptproblem wäre, dass es keine Libs gibt um sinnvolle Sachen zu machen - wenn man aber PHP oder Perl Libraries importieren könnte - wäre das Problem gelöst.

    Einen Import aus PHP oder Perl stell ich mir relativ aufwendig vor, aber Import aus Java geht wohl, wenn man einen Java-Interpreter benutzt.

    headhunter schrieb:

    http://www.onlamp.com/pub/a/onlamp/2007/08/30/introducing-trimpath-junction.html

    Bin wohl nicht der einzige, der sich die Frage gestellt hat. 😉

    0
  • ?

    schmidt-webdesign.net schrieb:

    auf der schachtel schrieb:

    wozu noch so ne dreckssprache auf nem server? damit noch mehr hilfsfrickler ne zu ihnen passende sprache haben um sicherheitslöcher zu produzieren?

    Hast du vielleicht ein Beispiel, das zeigt, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen?

    Wenns mal Libraries gibt mit denen man auf Server DBs usw zugreifen kann, dann bekommen die Frickler das sicher hin.

    0
  • ?

    es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.

    0
  • S

    auf der schachtel schrieb:

    es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.

    Ein Beispiel, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen, hast du also nicht (hätte mich auch gewundert). Hast du dir den Begriff "Javascript-Injection" selbst ausgedacht oder nur mit SQL-Injection verwechselt?

    0
  • M

    schmidt-webdesign.net schrieb:

    auf der schachtel schrieb:

    es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.

    Ein Beispiel, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen, hast du also nicht (hätte mich auch gewundert). Hast du dir den Begriff "Javascript-Injection" selbst ausgedacht oder nur mit SQL-Injection verwechselt?

    eval(formdata.mytextfield)

    😉

    Aber ich behaupte, das ist nicht Javascript-spezifisch.

    0
  • ?

    schmidt-webdesign.net schrieb:

    auf der schachtel schrieb:

    es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.

    Ein Beispiel, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen, hast du also nicht (hätte mich auch gewundert).

    😕 Ist es doch. Ich gehe mal davon aus, dass man mit serverseitigem Javascript auch die Möglichkeit hat auf eine DB zuzugreifen, sonst bringt es auf dem Server ja nix.

    Hast du dir den Begriff "Javascript-Injection" selbst ausgedacht oder nur mit SQL-Injection verwechselt?

    Google: Javascript-Injection Im Moment kann man "nur" Clientseitig HTML Seiten "hacken", aber sobald es auf dem Server läuft geht viel mehr.

    0
  • S
    Mod

    auf der schachtel schrieb:

    Google: Javascript-Injection Im Moment kann man "nur" Clientseitig HTML Seiten "hacken", aber sobald es auf dem Server läuft geht viel mehr.

    Quasi jede Scriptsprache hat ein eval()

    0
  • L

    Nur weil die Sprache bei Client und Server die gleiche ist heißt das doch noch lange nicht, dass deswegen plötzlich andere/mehr Sicherheitslücken auf dem Server entstehen als bei einer anderen serverseitigen Sprache.

    So eval()-Hacks gibts bei thedailywtf.com regelmäßig wo per ajax/js irgendwas an ein php-Skript geschickt wird welches das ganze mit eval() ausführt.

    0
Anmelden zum Antworten