Eine statische Website benötigt günstiges Browserhosting? Static Website aktivieren und CORS konfigurieren

Veröffentlicht am:

CloudTrips benötigt günstiges Hosting für HTML, CSS und Browser-JavaScript ohne Webserver. Azure Storage kann Dateien aus einem speziellen $web-Container ausliefern; berechnet werden nur gespeicherte Daten, Vorgänge und Netzwerkübertragung.

Dieser Trip demonstriert außerdem CORS (Cross-Origin Resource Sharing). Ein Browser verhindert normalerweise, dass JavaScript von einem Origin die Antwort eines anderen Origins liest. CORS-Antwortheader des Servers können diesen Zugriff ausdrücklich erlauben.

Azure Storage CORS gilt nicht für den Static-Website-Endpunkt selbst. Hier wird die Seite vom Website-Endpunkt ausgeliefert und ihr JavaScript fordert data.json vom separaten Blob-Service-Endpunkt an. Die CORS-Regel gehört zu diesem Blob Service:

Static-Website-Origin (.web.*)
  └─ Browser-Fetch
       └─ Blob-Service-Origin (.blob.core.windows.net)
            └─ CORS-Regel erlaubt den Website-Origin

Storage Account erstellen

Suche nach Storage accounts, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: Create new → rg-cloudtrips-staticweb-test-weu
Storage account name: stctstaticdmytrotestweu
Region: West Europe
Primary service: Azure Blob Storage or Azure Data Lake Storage Gen2
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Belasse Hierarchical namespace: Disabled. Aktiviere unter Security Allow enabling anonymous access on individual containers, da der Browser das kleine Demonstrations-JSON-Blob ohne Credentials lesen muss. Erstelle den Account.

Static-Website-Hosting aktivieren

Öffne den Account und wähle Data management > Static website. Wähle:

Static website: Enabled
Index document name: index.html
Error document path: 404.html

Speichere die Konfiguration. Azure erstellt den speziellen $web-Container und zeigt einen Primary endpoint. Kopiere den vollständigen HTTPS-Endpunkt; er ist die öffentliche URL und der für die CORS-Regel benötigte Origin.

Static-Website-Dateien sind über diesen Website-Endpunkt anonym lesbar, selbst wenn der $web-Container in der Bloboberfläche privat erscheint. Statisches Hosting bietet keinen serverseitigen Code, keine Authentifizierung und keine Konfiguration eigener Antwortheader.

Static-Website-Seite mit index.html, 404.html und generiertem Primary Endpoint

Website hochladen

Die vorbereiteten Dateien befinden sich unter:

examples/static-website-cors/

Öffne Data storage > Containers > $web und lade hoch:

index.html
404.html

Bei Datei- und Pfadnamen wird Groß-/Kleinschreibung unterschieden. Wird ein anderer Storage-Account-Name verwendet, ersetze stctstaticdmytrotestweu vor dem Upload in index.html.

Browserdaten-Container erstellen

Erstelle unter Containers:

Name: browser-data
Anonymous access level: Blob (anonymous read access for blobs only)

Lade examples/static-website-cors/data.json in diesen Container hoch. Nur die Blobs sind öffentlich; anonyme Benutzer können den Container nicht auflisten. Der öffentliche Zugriff hält ausschließlich dieses CORS-Lab klein—für Produktionsdaten ist ein geeignetes Autorisierungsdesign erforderlich.

CORS für den Blob Service konfigurieren

Öffne Settings > Resource sharing (CORS). Füge im Abschnitt Blob service eine Regel hinzu:

Allowed origins: <STATIC_WEBSITE_PRIMARY_ENDPOINT_WITHOUT_TRAILING_SLASH>
Allowed methods: GET, HEAD, OPTIONS
Allowed headers: *
Exposed headers: Content-Type
Max age: 3600

Lautet der Primary Endpoint beispielsweise https://stctstaticdmytrotestweu.z6.web.core.windows.net/, trage folgenden Origin ein:

https://stctstaticdmytrotestweu.z6.web.core.windows.net

Verwende den exakten Endpunkt aus dem Portal, da dessen Zonenkennung abweichen kann. Verwende für Allowed origins nicht *: Ein benannter Origin verhindert, dass jede fremde Website über diese Regel Berechtigung erhält. Speichere.

Blob-Service-CORS-Regel für GET, HEAD und OPTIONS vom exakten Static-Website-Origin

Website und CORS-Anfrage testen

Öffne den Primary endpoint der statischen Website in einem neuen Browsertab. Die Seite sollte Folgendes anzeigen:

{
  "message": "CORS allowed this Blob Storage response",
  "source": "browser-data/data.json"
}

Damit sind zwei getrennte Vorgänge bewiesen: Azure lieferte index.html aus $web aus und der Browser durfte die Cross-Origin-Blobantwort dem JavaScript der Seite bereitstellen.

Statische Website mit dem vom Cross-Origin-Blobrequest zurückgegebenen JSON

Optional kannst du den CORS-Antwortheader im lokalen Terminal prüfen. Ersetze den Origin durch den exakten Wert aus dem Portal:

curl --silent --dump-header - --output /dev/null \
  --header 'Origin: <STATIC_WEBSITE_ORIGIN>' \
  'https://stctstaticdmytrotestweu.blob.core.windows.net/browser-data/data.json'

Die Antwort sollte Access-Control-Allow-Origin mit demselben Website-Origin enthalten. CORS wird von Browsern erzwungen; es ist weder Authentifizierung noch Verschlüsselung oder Firewall. Werkzeuge wie curl blockieren eine Antwort nicht, nur weil ein CORS-Header fehlt.

Bereinigen

Deaktiviere Static website, falls der Account erhalten bleibt; der Website-Endpunkt bleibt öffentlich lesbar, solange die Funktion aktiviert ist. Lösche für dieses eigenständige Lab die Ressourcengruppe:

az group delete \
  --name rg-cloudtrips-staticweb-test-weu \
  --yes

Bestätige, dass sie nicht mehr existiert:

az group exists --name rg-cloudtrips-staticweb-test-weu

Erwartetes Ergebnis: false.