Apache: reverse proxy streikt bei Cookies: Unterschied zwischen den Versionen
Niki (Diskussion | Beiträge) (Die Seite wurde neu angelegt: x) |
Niki (Diskussion | Beiträge) |
||
| (Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | + | <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. | ||
| + | |||
| + | = Kommentare = | ||
| + | |||
| + | <comments />{{:{{TALKSPACE}}:{{PAGENAME}}}} | ||
| + | |||
| + | [[Kategorie:Weblog]] | ||
Aktuelle Version vom 2. Mai 2009, 22:11 Uhr
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...
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.
Kommentare
<comments />
Andreas B said ...
Niki said ...
Vielen Dank für den Hinweis! Früher oder später komme ich sicher wieder vor so ein Szenario ;-)
--Niki 14:39, 6. Dez. 2010 (CET)
Hallo,
ein bisschen spät, aber für alle die diese Seite per Suchmaschine finden: Zumindest seit Version 2.2 gibt es dafür die Direktive "ProxyPassReverseCookiePath".
Gruß, Andreas
--Andreas B 14:31, 6. Dez. 2010 (CET)