Installations- und Konfigurationshinweise für die IIS-Erweiterung iisnode zum Ausführen von Node.js

Installations- und Konfigurationshinweise für die IIS-Erweiterung iisnode zum Ausführen von Node.js_node.js

WBOY

Freigeben： 2016-05-16 16:11:44

Original

1553 Leute haben es durchsucht

Zu Beginn dieses Jahres hatte ich geplant, Node.js zu verwenden, um das Blog-Programm basierend auf dem Express-Framework neu zu schreiben und mich von ASP.NET zu verabschieden. Der VPS, den ich derzeit verwende, ist jedoch ein Windows Server-System und ein IIS-Server. Wenn sowohl Express als auch IIS Port 80 überwachen dürfen, liegt offensichtlich ein Konflikt vor. Glücklicherweise gibt es eine Erweiterung namens iisnode, die Node.js-Programme auf IIS hosten kann. Darüber hinaus bedeutet ein solches Hosting auch, dass Sie verschiedene Funktionen in IIS nutzen können (Prozessverwaltung, GZip-Komprimierung, Protokolle, Cache, Berechtigungskontrolle, Domänennamenbindung usw.).

Um iisnode verwenden zu können, müssen Sie Folgendes installieren:

1.Node.js
2.URL-Rewrite-Modul von IIS
3.iisnode

Befolgen Sie nach der Installation die üblichen Schritte und erstellen Sie eine Site im IIS-Manager, die auf das Verzeichnis des Express-Programms verweist. Der Schlüssel besteht darin, eine web.config-Datei hinzuzufügen:

Code kopieren Der Code lautet wie folgt:

In

Dieser Inhalt kann auch über die visuelle Oberfläche von IIS Manager konfiguriert werden. Es bedeutet wahrscheinlich, dass alle Anfragen an bin/www umgeschrieben werden und die iisnode-Erweiterung verwendet wird, um bin/www auszuführen. Nach dem Öffnen der Seite erschien jedoch diese Fehlermeldung:

Code kopieren

Der Code lautet wie folgt:

Das Anforderungsfiltermodul ist so konfiguriert, dass Pfade in URLs abgelehnt werden, die einen Abschnitt „hiddenSegment“ enthalten Zuerst dachte ich, es sei unklar, aber dann wurde mir plötzlich klar, dass das bin-Verzeichnis in ASP.NET ein spezielles Verzeichnis ist, auf das nicht zugegriffen werden darf. Schreiben Sie die Anfrage in bin/www um, was zufällig diese Regel trifft. Ändern Sie also einfach den Verzeichnisnamen, ändern Sie beispielsweise bin in launch (es stellt sich heraus, dass dies keine gute Vorgehensweise ist, ich werde später darüber sprechen), und auch web.config sollte entsprechend angepasst werden:

Code kopieren

Der Code lautet wie folgt:

Starten Sie die Site im IIS-Manager neu und greifen Sie erneut darauf zu. Es ist nicht einfach. Aber es war noch zu früh, um glücklich zu sein.

Während des Funktionstests des Programms stellte ich fest, dass die erhaltene IP leer war. Im Express-Framework wird IP über req.ip abgerufen, das wiederum den Wert von REMOTE_ADDR im Anforderungsheader erhält. Durch einen einfachen Testcode wurde festgestellt, dass der Wert von REMOTE_ADDR ebenfalls leer ist. Offensichtlich gingen diese Header-Informationen im Prozess von IIS zu Node.js verloren. Nach etwas Google habe ich herausgefunden, dass iisnode
dieses Problem

hat. Die offizielle Lösung ist die Verwendung von X-Forword-For, aber ich habe einen anderen Weg gefunden.

Es gibt eine Konfiguration in Web.config (hinzugefügt vor ), die REMOTE_ADDR behalten kann:

Code kopieren

Der Code lautet wie folgt:

Gemäß den Anweisungen wird die reservierte REMOTE_ADDR in x-iisnode-REMOTE_ADDR umbenannt, Sie müssen also den Wert von req.ip einmal überschreiben und eine Middleware-Funktion in Express app.js hinzufügen:

Code kopieren

Der Code lautet wie folgt: app.use(function(req, res, next) { req.ip = req.headers['x-iisnode-REMOTE_ADDR']; next(); });

Nach einer solchen Anpassung ist die erhaltene IP jedoch immer noch leer, sodass sich die Leute fragen, ob die Zuweisung von req.ip fehlgeschlagen ist. Wenn wir uns den Quellcode von Express ansehen, können wir feststellen, dass req.ip durch define getter definiert wird. Um es zu überschreiben, müssen Sie es also erneut definieren: 

Code kopieren

Der Code lautet wie folgt: app.use(function(req, res, next) { Object.defineProperty(req, 'ip', { get: function() { return this.headers['x-iisnode-REMOTE_ADDR']🎜> }); next();

});

Dieses Problem ist endlich gelöst, aber das ist keine gute Methode. Es wird problematisch, wenn Express in Zukunft req.ip auf schreibgeschützt setzt. 

Bei weiteren Tests wurde ein weiteres Problem entdeckt. Normalerweise überträgt die Datei-Upload-Funktion im Blog-Hintergrund Dateien in das Verzeichnis public/upload, tatsächlich wird der Ordner public/upload jedoch im Startverzeichnis (dem ursprünglichen bin-Verzeichnis) generiert. Tatsächlich liegt der Grund darin, dass sich die WWW-Datei als Programmeintrag im Startverzeichnis befindet, sodass das Startverzeichnis zum Ausführungsverzeichnis der Anwendung wird. Meine Lösung besteht darin, den Namen des Startverzeichnisses wieder in „bin“ zu ändern und eine launch.js im Stammverzeichnis zu erstellen, um bin/www aufzurufen:

Code kopieren

Der Code lautet wie folgt:

#!/usr/bin/env node require('./bin/www');

然后把程序入口改为launch.js:

复制代码代码如下: