Statisches WordPress · Authentifizierung
Statische WordPress-Authentifizierung einfach gemacht: Bereitstellung mit der AWS-SAR-Vorlage
Ein statisches WordPress-Frontend entfernt die PHP-Laufzeit aus öffentlichen Anfragen, damit aber auch die native WordPress-Anmeldung aus der ausgelieferten Website. Geschützte Portale, Downloads und Mitgliederbereiche benötigen daher ein Identitäts- und Edge-Zugriffsmodell, das für die statische Bereitstellung ausgelegt ist.
Wichtiger Hinweis
Dieser Bereitstellungsweg wurde abgelöst
Die in diesem Artikel beschriebene Vorlage im AWS Serverless Application Repository (SAR) ist nicht mehr verfügbar. WP Suite verwendet jetzt Deployment Access mit CloudFormation-Vorlagen, die die von allen WP-Suite-Plugins benötigte Backend-Infrastruktur abdecken.
Demnächst: Ein neuer Leitfaden führt durch den aktualisierten Deployment-Access-Ablauf und die erweiterte Lösung.
Das Muster
Mit Cognito authentifizieren, die Auslieferung über CloudFront autorisieren.
Gatey meldet den Benutzer an
Der Browser authentifiziert sich über das in WordPress-generierte Seiten eingebettete Gatey-Erlebnis bei einem Amazon Cognito User Pool.
Ein Signer stellt Cookies aus
Eine geschützte API prüft den authentifizierten Benutzer und gibt signierte CloudFront-Cookies mit begrenztem Pfad und begrenzter Gültigkeitsdauer zurück.
CloudFront schützt Inhalte
CloudFront-Verhaltensweisen und eine vertrauenswürdige Schlüsselgruppe erzwingen den Zugriff, bevor geschützte statische Objekte aus S3 ausgeliefert werden.
01 · Warum
Warum benötigt statisches Publishing eine andere Anmeldearchitektur?
Nach dem Export von WordPress in statische Dateien gibt es im öffentlichen Pfad weder eine PHP-Sitzung noch eine WordPress-Datenbankabfrage. Die Website kann weiterhin interaktives JavaScript anzeigen, doch das native WordPress-Authentifizierungssystem ist am Edge nicht mehr vorhanden.
Der Ersatz sollte den Pfad der Inhaltsauslieferung selbst schützen und nicht lediglich Links im Browser verbergen. Signierte CloudFront-Cookies eignen sich, wenn ein authentifizierter Benutzer unter derselben Distribution auf mehrere geschützte Dateien oder Pfade zugreifen muss.
- Verlassen Sie sich bei der Zugriffskontrolle nicht auf clientseitige Sichtbarkeitsregeln.
- Schützen Sie den Ursprung, damit Besucher CloudFront nicht umgehen und S3-Objekte nicht direkt lesen können.
- Beschränken Sie Cookie-Richtlinien auf die erforderliche Domain, den Pfad und die Gültigkeitsdauer.
So entsteht eine statische Website, die cachefähig bleibt und weltweit ausgeliefert wird, während ausgewählte Inhalte durch eine durchsetzbare Edge-Richtlinie geschützt sind. Die vollständige Problemstellung erläutert, wie Sie eine Anmeldung zu statischem WordPress hinzufügen, ohne PHP-Sitzungen zurückzubringen, und wie dynamische Funktionen nach dem statischen Publishing erhalten bleiben.
Statisches und dynamisches WordPress
| Merkmal | Dynamisches WP (PHP/MySQL) | Statisches WP (S3 + CloudFront) |
|---|---|---|
| Geschwindigkeit | Serverseitig gerendert, abhängig von PHP/DB | Am CDN-Edge zwischengespeichert, extrem schnell |
| Sicherheit | Core und Plugins vergrößern die Angriffsfläche | Minimale Angriffsfläche (statische Dateien) |
| Skalierbarkeit | Durch Serverressourcen begrenzt | Mit CloudFront praktisch unbegrenzt |
| Authentifizierung | Integrierte WordPress-Anmeldung | SAR + Gatey (signierte Cookies) |
| Wartung | Patches und Datenbanksicherungen | Dateisynchronisierung und Cache-Invalidierung |
02 · Komponenten
Was stellt der Static-Site-Guardian-Stack bereit?
Das Bereitstellungsmuster kombiniert einen S3-Ursprung, ein Verhalten der CloudFront-Distribution, einen öffentlichen CloudFront-Schlüssel samt Schlüsselgruppe sowie API-Gateway- und Lambda-Endpunkte, die nach der Authentifizierung signierte Cookies ausstellen und löschen.
Unterstützende Ressourcen können Signiermaterial sicher speichern, eine benutzerdefinierte Domain und ein Zertifikat anbinden, WAF-Schutz anwenden und Ausgaben bereitstellen, die Gatey oder die WordPress-Konfiguration verwenden können.
- Privater S3-Ursprung und Auslieferung über CloudFront.
- Endpunkte zum Ausstellen von Cookies und zum Abmelden mit pfadspezifischer Autorisierung.
- Schlüssel, Protokolle, Domains und AWS-Servicekosten im Besitz des Kunden.
Die genauen Ressourcen hängen von den gewählten Bereitstellungsparametern ab, die Zugriffskontrolle bleibt jedoch außerhalb der exportierten HTML-Dateien. Weitere Einzelheiten zur Auslieferungsgrenze finden Sie in der Architektur für signierte CloudFront-Cookies.
03 · Integration
Wie verbindet Gatey die Anmeldung mit den geschützten statischen Pfaden?
Gatey steuert den Cognito-Kontoablauf im Browser. Nach einer erfolgreichen Anmeldung ruft das Frontend den konfigurierten Cookie-Aussteller-Endpunkt mit dem erforderlichen authentifizierten Kontext auf. Die Antwort setzt signierte Cookies für die CloudFront-Domain; anschließend kann der Besucher den geschützten Pfad normal anfordern.
Beim Abmelden müssen sowohl die Anwendungssitzung als auch die CloudFront-Cookies gelöscht werden. Weiterleitungsziele sollten eindeutig festgelegt sein, damit abgelaufene oder nicht autorisierte Anfragen den Besucher zu einem sinnvollen Anmeldepfad statt zu einem allgemeinen Auslieferungsfehler führen.
- Stimmen Sie Cognito-Callback, Website-Domain und Cookie-Domain aufeinander ab.
- Testen Sie Anmeldung, direkten Zugriff auf geschützte URLs, Ablauf und Abmeldung.
- Vermeiden Sie Cookie-Gültigkeitsbereiche, die nicht zugehörige Websites oder Pfade abdecken.
Der Benutzer erlebt einen normalen Kontoablauf, während CloudFront die Entscheidung über die Auslieferung durchsetzt.
04 · Betrieb
Was sollte nach der Bereitstellung getestet werden?
Eine erfolgreiche CloudFormation-Bereitstellung ist nur der Anfang. Veröffentlichen Sie die statischen Dateien im erwarteten S3-Präfix, invalidieren Sie die relevanten CloudFront-Pfade und prüfen Sie, dass öffentliche Pfade erreichbar bleiben, während geschützte Pfade anonyme Anfragen ablehnen.
Testen Sie anschließend mehrere Benutzer, Cookie-Ablauf, Datenschutzmodi des Browsers, benutzerdefinierte Domains, das CORS-Verhalten der Signer-API, Schlüsselrotation, Protokolle, Alarme und Rollback-Verfahren. Stellen Sie sicher, dass Änderungen an der WordPress-Seite nicht versehentlich die für das exportierte Frontend erforderlichen Integrationseinstellungen entfernen.
- Testen Sie anonyme, authentifizierte, abgelaufene und abgemeldete Zustände.
- Überwachen Sie Signer-Fehler und unerwartete Autorisierungsantworten.
- Dokumentieren Sie, wie Schlüssel und Konfiguration ohne Ausfallzeit rotiert werden.
Die statische Auslieferung reduziert die öffentliche WordPress-Angriffsfläche, beseitigt jedoch nicht die Verantwortung für Identität, Schlüssel, APIs und Betrieb.
Regel für die Zugriffskontrolle
Eine statische Seite kann interaktiv sein, doch der Browser darf nicht die Sicherheitsgrenze bilden.
Nutzen Sie Browserlogik zur Verbesserung der Benutzererfahrung. Verwenden Sie Cognito, geschützte APIs, CloudFront-Richtlinien und einen privaten Ursprung, um zu entscheiden, ob geschützte Inhalte tatsächlich ausgeliefert werden.
Nächster Schritt
Planen Sie die geschützten Pfade vor der Bereitstellung des Stacks.
Prüfen Sie Static Publisher und Deployment Access, um abzubilden, wie die Website exportiert wird, wo sie ausgeliefert wird und welche Pfade Schutz durch signierte Cookies benötigen.