GCS Reverse Proxy
1.0.0
Ein Google Cloud Storage Reverse Proxy. Für das Hosting privater statische Websites mit privaten Google Cloud -Speicherobjekten.
Sie möchten statische Websites mit Ihren GCS -Eimer servieren, möchten jedoch den Zugriff auf sie einschränken.
Dieser Reverse Proxy Micro -Dienst verhalten sich als einfacher HTTP -Server für ein Array von GCS -Eimer. Anschließend können Sie eine beliebige entsprechende Methode verwenden, um den Zugriff darauf zu beschränken. ZB, die es hinter Nginx, Caddy oder einem VPN stellt.
Der Zugriff auf private GCS -Objekte über den Browser erfordert spezielle Token, die in die URL codiert sind. Dies wird die meisten (wenn nicht alle) statischen Websites brechen, da sie diese Token nicht generieren oder die URI von Vermögenswerten, zu denen es anfordert, oder verlinkt, nicht vorhersagen können. Ein Speicherobjekt öffentlich zu machen bedeutet jedoch, dass es keine Möglichkeit gibt, den Zugriff darauf einzuschränken.
Dieser umgekehrte Proxy serviert ein privates Objekt über HTTP am erwarteten (relativ), URI und beschränkt den Zugriff auf diese Objekte überhaupt nicht. Wenn Sie diesen Server jedoch hinter einen anderen Reverse -Proxy wie Nginx oder auf ein VPN setzen, können Sie den Zugriff auf eine Weise steuern, die Ihren Anforderungen angemessen ist.
NB (Wenn Sie die GCLOUD -SDK -Installation von
gcloud infoin Ihrer Shell installiert haben, um zu überprüfen, dass Sie angemeldet sind und die richtige Projekt -ID -Set haben).
Die TARGET_BUCKETS Env Var erwartet eine von der Kommas getrennte Liste von Eimer, z. B.:
TARGET_BUCKETS='bucket-one,bucket-two'
Der Server wirft, es sei denn, ein oder mehrere Target_Buckets sind definiert.
Das Einstellen des HISTORY Env Vars auf True startet den Server im Verlaufsmodus, um eine bessere Spa -Unterstützung zu erhalten. Es reagiert mit der Datei root index.html buckets auf einen Pfad, der keine Dateierweiterung hat.
npm install
TARGET_BUCKETS="bucket-name" npm start
Sobald der Server in Betrieb ist, sollte der Zugriff auf ein privates Objekt in einem Eimer eine Get -Anfrage stellen:
<proxy-host>:<proxy-port>/<bucket-name>/<file-path>
Wenn der Dateipfad im Eimer vorhanden ist und der Server eine Vorstellung zum Lesen hat, sendet der Reverse -Proxy seinen Inhalt als Antwort. Wenn die Datei aus irgendeinem Grund nicht vom Eimer abgerufen werden kann, gibt der Server einen 404 zurück.
Wenn sich der angeforderte Eimer nicht in der Liste von target_buckets befindet, wird ein 403 zurückgegeben, unabhängig von einem echten Eimer oder nicht.
Derzeit wird die Get -Request -Methode derzeit unterstützt.
Ein einzelner Bucket-Modus bedeutet, dass nicht alle Anfragen mit einem Bucket-Name-Pfad vorfixiert werden müssen. Anfordern von <proxy-host>:<proxy-port>/<file-path> fordert den Dateipfad vom einzelnen Ziel-Bucket an.
Dieses Projekt verwendet Micro, was bedeutet, dass wir die hervorragenden Micro-Dev-Tools in der Entwicklung verwenden können.
TARGET_BUCKETS="bucket-name" npm run dev
ADC verwendet das Standarddienstkonto, das Motor-, Kubernetes -Engine-, App -Engine- und Cloud -Funktionen berechnet, für Anwendungen, die auf diesen Diensten ausgeführt werden.
Von der Einrichtung der Authentifizierung für Server bis Server -Produktionsanwendungen
Aufgrund der oben genannten Bestimmungen empfehle ich, dass Sie Rechenmotor, Kubernetes Engine oder App Engine verwenden, wo die Authentifizierung für Sie behandelt wird.
Ich habe eine Dockerfile für den Einstieg geliefert, ohne Knoten zu installieren. Dies funktioniert nicht lokal, da es keine Authentifizierung mit Google Cloud SDK einstellt.
Bei der Bereitstellung in einer Computer -Engine -VM -Instanz -Authentifizierung wird jedoch für Sie behandelt. Um zu sehen, wie Sie ein Docker -Image für eine VM -Instanz bereitstellen, lesen Sie diesen Handbuch. Vergessen Sie nicht, die Umgebungsvariable TARGET_BUCKETS festzulegen, die durch Befolgen dieses Handbuchs erfolgen kann.
