10
Nginx-pfad für bestimmte IP whitelisten (iframe)
Hallo zusammen,
ich habe einen Dienst, welcher mittels nginx-Reverse-Proxy über einen Pfad erreichbar gemacht wird (https://beispiel.de/pfad)
Nun möchte ich jedoch keinen direkten Zugriff erlauben. Das wäre ja kein Problem mittels.
Allerdings möchte ich die Applikation mittels iframe oder ähnlichem innerhalb einer anderen Website anzeigen lassen, dabei jedoch auch ausschließlich von dieser Webseite.
Da kam mir bzw in den Sinn, dies würde jedoch den generellen Zugriff nicht blockieren.
Eine Passwortabfrage möchte ich nicht einbauen, da das iframe bereits in einer passwortgesicherten Anwendung eingebaut werden soll und ich gerne vermeiden würde, dass der Nutzer zweimal ein Passwort eingeben muss.
Gibt es überhaupt eine Möglichkeit, das umzusetzen?
ich habe einen Dienst, welcher mittels nginx-Reverse-Proxy über einen Pfad erreichbar gemacht wird (https://beispiel.de/pfad)
Nun möchte ich jedoch keinen direkten Zugriff erlauben. Das wäre ja kein Problem mittels
deny all;Allerdings möchte ich die Applikation mittels iframe oder ähnlichem innerhalb einer anderen Website anzeigen lassen, dabei jedoch auch ausschließlich von dieser Webseite.
Da kam mir
X-Frame-OptionsContent-Security-Policy: frame-ancestorsEine Passwortabfrage möchte ich nicht einbauen, da das iframe bereits in einer passwortgesicherten Anwendung eingebaut werden soll und ich gerne vermeiden würde, dass der Nutzer zweimal ein Passwort eingeben muss.
Gibt es überhaupt eine Möglichkeit, das umzusetzen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1291205500
Url: https://administrator.de/contentid/1291205500
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
10 Kommentare
Neuester Kommentar
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Zitat von @149569:
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Danke für den Vorschlag.
Aber kann das nginx an sich? Auf die Anwendung, die da läuft, habe ich leider keinen Einfluss.
Zitat von @HannibalSmith:
Danke für den Vorschlag.
Aber kann das nginx an sich? Auf die Anwendung, die da läuft, habe ich leider keinen Einfluss.
Zitat von @149569:
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Danke für den Vorschlag.
Aber kann das nginx an sich? Auf die Anwendung, die da läuft, habe ich leider keinen Einfluss.
Du kanns die Basic Auth Header auch weiterleiten, die Seite dahinter muss natürlich auch eine Basic Auth anfordern und die User entsprechend dort auch hinterlegt sein.
proxy_pass_request_headers on;
proxy_pass_header Authorization;Zitat von @149569:
Du kanns die Basic Auth Header auch weiterleiten, die Seite dahinter muss natürlich auch eine Basic Auth anfordern und die User entsprechend dort auch hinterlegt sein.
Zitat von @HannibalSmith:
Danke für den Vorschlag.
Aber kann das nginx an sich? Auf die Anwendung, die da läuft, habe ich leider keinen Einfluss.
Zitat von @149569:
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Du könntest eine Passthru-Authentifizierung zur Seite machen die im iFrame geladen wird. Also bspw. der Seite im iFrame eine Session-ID über URL Parameter mitgeben. Die Seite des iFrame prüft dann die Session-ID auf Gültigkeit und lässt nur gültige User mit aktiver Session rein.
Musst dann halt die aktuellen Session-IDs mit der vorgeschalteten Seite teilen/aktuell halten.
Danke für den Vorschlag.
Aber kann das nginx an sich? Auf die Anwendung, die da läuft, habe ich leider keinen Einfluss.
Du kanns die Basic Auth Header auch weiterleiten, die Seite dahinter muss natürlich auch eine Basic Auth anfordern und die User entsprechend dort auch hinterlegt sein.
> proxy_pass_request_headers on;
> proxy_pass_header Authorization;
> Da die Seite, die den iframe einbindet, in einer Nextcloud-Installation liegt, kann ich hier schlecht die Logins modifizieren.
Wie leite ich die Header denn weiter? Bei dem iframe habe ich nur Einfluss auf die URL.
Zitat von @HannibalSmith:
Wie leite ich die Header denn weiter? Bei dem iframe habe ich nur Einfluss auf die URL.
Macht der Proxy automatisch beim Zugriff. Btw. iFrame ist sowas von "old" und auch deprecated, und auch schon lange nicht mehr die empfohlene Methode, da gibt es inzwischen bessere Methoden ...Wie leite ich die Header denn weiter? Bei dem iframe habe ich nur Einfluss auf die URL.
Zitat von @149569:
Zitat von @HannibalSmith:
Wie leite ich die Header denn weiter? Bei dem iframe habe ich nur Einfluss auf die URL.
Macht der Proxy automatisch beim Zugriff. Btw. iFrame ist sowas von "old" und auch deprecated, und auch schon lange nicht mehr die empfohlene Methode, da gibt es inzwischen bessere Methoden ...Wie leite ich die Header denn weiter? Bei dem iframe habe ich nur Einfluss auf die URL.
Also müsste es reichen die beiden Zeilen in die nginx-conf zu packen und dann rennt das Ding?
Bzgl. iframe: Ich weiß ich weiß, aber nextcloud bietet ein Modul wie man eine externe Seite intern einbinden kann und das läuft nun mal leider mittels iframe... ärgerlich, aber hilft nichts.
Zitat von @HannibalSmith:
Also müsste es reichen die beiden Zeilen in die nginx-conf zu packen und dann rennt das Ding?
Wie gesagt das Backend dahinter muss was mit den Basic-Auth Zugangsdaten der vorgeschalteten Seite (die die den iFrame enthält)anfangen können sonst wird das nichts.Also müsste es reichen die beiden Zeilen in die nginx-conf zu packen und dann rennt das Ding?
Zitat von @149569:
Zitat von @HannibalSmith:
Also müsste es reichen die beiden Zeilen in die nginx-conf zu packen und dann rennt das Ding?
Wie gesagt das Backend dahinter muss was mit den Basic-Auth Zugangsdaten der vorgeschalteten Seite (die die den iFrame enthält)anfangen können sonst wird das nichts.Also müsste es reichen die beiden Zeilen in die nginx-conf zu packen und dann rennt das Ding?
Dann bringt mir die Möglichkeit leider nichts, wie vorher geschrieben habe ich auf die Anwendung bzw deren Backend keinen Einfluss. Kennst du vielleicht eine andere Möglichkeit?
Zitat von @HannibalSmith:
Dann bringt mir die Möglichkeit leider nichts, wie vorher geschrieben habe ich auf die Anwendung bzw deren Backend keinen Einfluss. Kennst du vielleicht eine andere Möglichkeit?
Sehe ich beim guten Willen nicht. Das Absichern geht dann so nicht wie du es vorhast wenn du gar keinen Einfluss auf das dahinterliegende Backend hast.Dann bringt mir die Möglichkeit leider nichts, wie vorher geschrieben habe ich auf die Anwendung bzw deren Backend keinen Einfluss. Kennst du vielleicht eine andere Möglichkeit?
Zitat von @149569:
Zitat von @HannibalSmith:
Dann bringt mir die Möglichkeit leider nichts, wie vorher geschrieben habe ich auf die Anwendung bzw deren Backend keinen Einfluss. Kennst du vielleicht eine andere Möglichkeit?
Sehe ich beim guten Willen nicht. Das Absichern geht dann so nicht wie du es vorhast wenn du gar keinen Einfluss auf das dahinterliegende Backend hast.Dann bringt mir die Möglichkeit leider nichts, wie vorher geschrieben habe ich auf die Anwendung bzw deren Backend keinen Einfluss. Kennst du vielleicht eine andere Möglichkeit?
Alles klar - Danke trotzdem!
