☰

Reverse-Proxy mit mehreren Sitzungen im selben Browser

tag-icon • tag-icon apache-2.4 reverse-proxy httpd.conf
Reverse-Proxy mit mehreren Sitzungen im selben Browser

Mein Reverse-Proxy scheint größtenteils zu funktionieren. Wenn ich jedoch im selben Browser Sitzungen zu verschiedenen Backend-Servern öffne, erhalte ich diese Meldung vom Browser (getestet mit Chrome und IE):

Already a session is running in this browser, so opening the same session

Sobald ich die 2. Sitzung öffne, stören sich die beiden Sitzungen so, dass eine davon abgemeldet wird.

Die beiden Anforderungs-URLs lauten:

https://proxy-server/backend1/index.html
https://proxy-server/backend2/index.html

Der Reverse-Proxy ordnet diese Anfragen zu:

https://backend1:1234/index.html  and
https://backend2:1234/index.html

Ich vermute, das hängt mit den Cookies zusammen? Ich habe sie also verglichen und jedes hat einen einzigartigen Cookie-Inhalt, z. B.:

Session to backend1:
  QSESSIONID: c1f9468714084ee2fePE6l5x3FqyPl

Session to backend2:
  QSESSIONID: 06b2468a5a0509eb1aWoJRH8TpslxC

Was muss ich im Reverse-Proxy konfigurieren, damit sich diese Sitzungen nicht gegenseitig stören?

Danke,
Matt.

Antwort1

Ich beantworte meine eigene Frage ... Um direkt zur Antwort zu kommen, musste ich ProxyPassReverseCookiePathFolgendes hinzufügen <VirtualHost>:

<Location "/backend1">
  ...
  ProxyPass https://backend1:1234/
  ProxyPassReverse https://backend1:1234/
  ...
  ProxyPassReverseCookiePath / /backend1
  ...
</Location>

Um herauszufinden, was ich hinzufügen musste, musste ich den Set-CookieHeader auf dem Backend-Server und auf dem Proxy-Server verfolgen.

Auf dem Backend verwende ich lighttpd. So verfolgen Sie die Backend-Anfrage/Antwort:

server.modules += ("mod_accesslog")
accesslog.use-syslog = "enable"
accesslog.syslog-level = 6
accesslog.format = "%h %l %u %t \"%r\" \"C:%{Cookie}i\" \"S-C:%{Set-Cookie}o\" %>s %b"

Der Reverse-Proxy läuft unter Apache, also habe ich dies zu meinem <VirtualHost>... hinzugefügt.

LogFormat "%h %l %u %t \"%r\" \"C:%{Cookie}i\" \"S-C:%{Set-Cookie}o\" %>s %b"
TransferLog "/store/log/httpd_access_log"

Da ich nun über die Protokollierungsdetails verfügte, konnte ich sehen, was passierte ...

Nach dem ersten Anmeldebildschirm wird eine Sitzung eingerichtet und der Backend-Server erstellt den Cookie-Inhalt und fügt ihn dem Set-CookieHeader hinzu. Der Hinweis, den ich brauchte, war, dass es Set-Cookiemit angibt Path=/. Um zu verhindern, dass sich Sitzungen von verschiedenen Backend-Servern gegenseitig stören, musste ich das PathAttribut vom Namen des Backend-Servers abhängig machen. Das ProxyPassReverseCookiePathmacht das für mich.

Der Proxy sieht den Set-CookieHeader und ordnet das PathAttribut zu.

Die Protokolle zeigten auf lighttpd (für ein besseres Sehvergnügen bearbeitet):

"POST /api/session HTTP/1.1" "C:i18next=en-us" "S-C:SID=3bmx; path=/; secure"

Und nachdem diese Antwort den Proxy passiert hat, wird sie durch die ProxyPassReverseCookiePathDirektive wie folgt geändert:

POST /backend1/api/session HTTP/1.1 C:i18next=en-us S-C:SID=3bmx; path=/backend1;secure

Jetzt ist der Cookie-Pfad vom Namen des Backend-Servers abhängig.

Matthäus.

verwandte Informationen