Apache: reverse proxy streikt bei Cookies - Versionsgeschichte

Niki am 2. Mai 2009 um 21:11 Uhr

2009-05-02T21:11:55Z

Niki am 1. Februar 2008 um 15:32 Uhr

2008-02-01T15:32:43Z

Niki: Die Seite wurde neu angelegt: x

2006-04-30T05:30:44Z

Die Seite wurde neu angelegt: x

Neue Seite

@@ Zeile 35: / Zeile 35: @@
 Eine grandiose Idee, die aber noch warten kann, hab ich noch: Nachdem ich sowieso will, dass man sich mit dem CMS der Intranetsite einloggt und dann kein shareaza Passwort mehr braucht, wäre es schön, das Cookie einfach vorher zu setzen. Das CMS kontrolliert vorher lediglich, ob man für den Zugriff befugt ist, wenn ja, wird ein Perl-Parser-Script gestartet, das die Session-ID holt. Danach setzt das CMS das Cookie mit der richtigen SID und dem Path und startet Shareaza in einem iframe.
 Für zusätzliche Sicherheit könnte man eventuell noch Basic-Auth verwenden, die ebenfalls vom CMS freigeschaltet wird.
 [[Kategorie:Weblog]]

← Nächstältere Version		Version vom 1. Februar 2008, 15:32 Uhr
Zeile 1:		Zeile 1:
−	x	+	<section begin="head"/>
		+	Heute wollte ich das Webinterface von shareaza über mod_proxy nach aussen bringen. Das Konzept von mod_proxy und seinen optionalen Modulen hört sich sehr gut an. Doch kaum eine Webapplikation funktioniert mehr ohne Cookies. Und trotzdem ist es NICHT (ohne patch) möglich, Cookies zu manipulieren :-( Führt für mich das Konzept schon ein bisschen ad absurdum...
		+	<section end="head"/>
		+
		+	Der Aufbau selbst ist extrem einfach
		+
		+	In einen passenden VirtualHost kommt einfach
		+
		+	ProxyPass /shareaza/ http://192.168.0.4:4711/remote/
		+
		+	Das kürzt auch gleich das ekelige "remote" weg. Ein
		+
		+	ProxyHTMLURLMap http://192.168.0.4:4711/remote /shareaza
		+
		+	sorgt dafür, dass auch alle absoluten Links in den Daten (HTML) ersetzt werden.
		+
		+	Damit auch die URLs bei den Antworten ersetzt werden, gibt es ProxyPassReverse, das setzt man am besten gleich in die Location (damit umgeht man Probleme mit mehreren Webapplikationen)
		+
		+	<Location /shareaza/>
		+	ProxyPassReverse /remote/
		+	SetOutputFilter proxy-html
		+	ProxyHTMLURLMap / /shareaza/
		+	ProxyHTMLURLMap /shareaza /shareaza
		+
		+	RequestHeader unset Cookie
		+	RequestHeader add Cookie “ShareazaRemote=4664; path=/”
		+	</Location>
		+
		+	Das funktioniert soweit wunderbar, doch meldet man sich an, ist man auf einmal wieder auf der Loginseite. Wieso? Weil das schei** Shareaza den Pfad des session-Cookies auf "/remote" setzt. Den hab ich dann aber leider nicht mehr.
		+
		+	Hab nun versucht, mit RequestHeader zu spielen, doch das erlaubt nur statische Manipulation der Header. Wären regex nicht doll...
		+
		+	Das ganze könnte man natürlich über einen virtuellen Host lösen, oder shareaza direkt auf "/remote" setzen, doch das will ich nicht.
		+
		+	Eine grandiose Idee, die aber noch warten kann, hab ich noch: Nachdem ich sowieso will, dass man sich mit dem CMS der Intranetsite einloggt und dann kein shareaza Passwort mehr braucht, wäre es schön, das Cookie einfach vorher zu setzen. Das CMS kontrolliert vorher lediglich, ob man für den Zugriff befugt ist, wenn ja, wird ein Perl-Parser-Script gestartet, das die Session-ID holt. Danach setzt das CMS das Cookie mit der richtigen SID und dem Path und startet Shareaza in einem iframe.
		+	Für zusätzliche Sicherheit könnte man eventuell noch Basic-Auth verwenden, die ebenfalls vom CMS freigeschaltet wird.
		+
		+	[[Kategorie:Weblog]]