Browser eine andere URL "vortäuschen" ?

[drombo]

Hallo Forum!

Wir nutzen ein serverseitiges Programm, um unsere Seiten für das Intranet zu generieren. Jetzt sieht der Aufruf in etwa so aus:

http://unserintranet/einpfad/das_programm?start&param1=Xaj26&param2=cdfe517

Das sieht nicht sehr schön aus, und die URL ist auch nicht sonderlich "sprechend". Besser wäre es jetzt wenn in der Addressleiste des Browsers dann nicht das "http://unserintranet/einpfad/das_programm?start&param1=Xaj26&param2=cdfe517
" steht, sondern z.b. "http://unserintranet/einpfad/die_seite.htm".

Habe mir schon die Felder des HTTP-Response-Headers angeschaut, aber irgendwie konnte ich da keine passenden Felder für unser Vorhaben finden.

Habt Ihr eine Idee, wie zwar das Serverprogramm aufgerufen werden kann, aber die URL trotzdem eine "sprechende" wird?

Vielen Dank schon mal im Voraus :-)

[steckl]

Hi,

Habt Ihr eine Idee, wie zwar das Serverprogramm aufgerufen werden kann, aber die URL trotzdem eine "sprechende" wird?

Du suchst wohl nach mod_rewrite. Darüber gibt es auch was bei Selfhtml.

mfG,
steckl

[Alexander (HH)]

Moin Moin!

steckl hat vollkommen recht. Wobei ich es ziemlich sinnfrei finde, URLs aufzuhübschen, nur damit sie hübsch aussehen. mod_rewrite kostet Extra-Arbeit auf dem Server, die bestehenden "häßlichen" URLs nicht.

Eins noch: Fändest Du es sinnvoll, wenn eine Seite über irgendeinen beliebigen Mechanismus die Adresszeile des Browsers ändern könnte?

Nehmen wir mal an, man könnte es über ein Meta-Tag machen:

Jemand klickt auf <a href="http://evil.example.com/phishing/sparkasse-knuffingen.php">http://www.sparkasse-knuffingen.de/</a>. Die Resource liefert eine HTML-Seite aus, die exakt wie http://www.sparkasse-knuffingen.de/ aussieht, aber in der zusätzlich folgendes Meta-Tag steckt:

<meta name="fake-url" value="http://www.sparkasse-knuffingen.de/">

Et voila:

Der Browser zeigt eine üble Phising-Seite an, dekoriert mit der echten Adresse der Sparkasse Knuffingen. Perfekt.

Kla, man könnte HTTPS benutzen. Auch dann würde der Trick funktionieren, weil evil.example.com ein perfektes, gültiges Zertifikat präsentiert, das der typische Benutzer ohnehin nicht prüft. Das Zertifikat könnte z.B. auf "Sprakasse Knuffingen" ausgestellt sein, so dass selbst moderne Browser, die einen Teil des Zertifikats in der Adressleiste anzeigen, nicht wirklich helfen.

Alexander

[Joachim]

Hi,

Wobei ich es ziemlich sinnfrei finde, URLs aufzuhübschen, nur damit sie hübsch aussehen.

Deswegen wird es i.d.R. auch nicht gemacht. SEO ist Dir ein Begriff?

Gruesse, Joachim

[Alexander (HH)]

Moin Moin!

»» Wobei ich es ziemlich sinnfrei finde, URLs aufzuhübschen, nur damit sie hübsch aussehen.
Deswegen wird es i.d.R. auch nicht gemacht. SEO ist Dir ein Begriff?

Ja, 1227. Insbesondere in einem Intranet extrem sinnvoll.

Alexander

[drombo]

es geht ja nicht primär darum, dass die urls "hübsch" aussehen, sondern dass sie - wie bereits geschrieben - sprechend sind.

kannst du dir "http://unserintranet/einpfad/das_programm?start&param1=Xaj26&param2=cdfe517" merken, wenn du deinem kollegen einen tipp geben willst?
sowas wie "http://unserintranet/abteilung/ansprechpartner.html" geht da schon eher.

es soll ja nicht direkt im client manipuliert werden (also etwa per js die adressleiste verändern). typo3 macht sowas meines wissens doch auch, da heisst das glaube ich "real url".

[Tom]

Hello,

sowas wie "http://unserintranet/abteilung/ansprechpartner.html" geht da schon eher.

Und das kann man mMn beim Apachen auch ohne Mod_Rewrite erreichen
PHP unterstüzt z.B. die Path Info (durchsuch mal das Archiv und Google danach).
Wenn man nun einen Pfad:

http://unserintranet.lan/abteilung.php/ansprechpartner/weiblich/

aufbaut und in abteilung.php den Pfad auswertet, dann hat man die beiden Positions-Parameter

ansprechparter
   weiblich

zur Verfügung, um damit etwas anzustellen.

Wenn man nun z.B. noch den x-bit-hack aktiviert, muss der Link auch nur noch

http://unserintranet.lan/abteilung/ansprechpartner/weiblich/

heißen und wenn das Script 'abteilung' gefunden wird, wird es vom PHP-Parser ausgeführt.

typo3 macht sowas meines wissens doch auch, da heisst das glaube ich "real url".
Liebe Grüße aus Syburg

Tom vom Berg

[Alexander (HH)]

Moin Moin!

»» sowas wie "http://unserintranet/abteilung/ansprechpartner.html" geht da schon eher.

Und das kann man mMn beim Apachen auch ohne Mod_Rewrite erreichen
PHP unterstüzt z.B. die Path Info (durchsuch mal das Archiv und Google danach).

Nicht nur PHP.

Wenn man nun einen Pfad:

http://unserintranet.lan/abteilung.php/ansprechpartner/weiblich/

aufbaut und in abteilung.php den Pfad auswertet, dann hat man die beiden Positions-Parameter

ansprechparter
   weiblich

zur Verfügung, um damit etwas anzustellen.

Auch das ist nicht PHP-spezifisch.

Wenn man nun z.B. noch den x-bit-hack aktiviert, muss der Link auch nur noch

http://unserintranet.lan/abteilung/ansprechpartner/weiblich/

heißen und wenn das Script 'abteilung' gefunden wird, wird es vom PHP-Parser ausgeführt.

Sooo tief hakt sich der PHP-Interpreter in den Apachen ein? Normalerweise dient der X-Bit-Hack doch nur dazu, "normale" HTML-Dateien durch mod_include zu jagen.

Es reicht aus, wenn der Webserver die Resource unserintranet.lan/abteilung als ausführbares Programm erkennt. Exakt das habe ich vor einiger Zeit für eine FastCGI-Anwendung gemacht, der entsprechende Teil der URI hieß schlicht "run":

FastCGIExternalServer /srv/www/www.example.com/htdocs/run -socket /srv/www/www.example.com/tmp/fcgi-socket

Hierbei existiert weder eine Datei noch ein Verzeichnis /srv/www/www.example.com/htdocs/run. Die URLs lauten dann typischerweise http://www.example.com/run/login oder http://www.example.com/run/admin/user/list. Der FastCGI-Prozess hat dann jeweils die PATH_INFO ausgewertet, also "login" oder "admin/user/list".

Alexander

[Tom]

Hello,

Wenn man nun z.B. noch den x-bit-hack aktiviert, muss der Link auch nur noch

http://unserintranet.lan/abteilung/ansprechpartner/weiblich/

heißen und wenn das Script 'abteilung' gefunden wird, wird es vom PHP-Parser ausgeführt.

Sooo tief hakt sich der PHP-Interpreter in den Apachen ein? Normalerweise dient der X-Bit-Hack doch nur dazu, "normale" HTML-Dateien durch mod_include zu jagen.

Ja. ich hatte es erst die letzten Tage nochmal gelesen. Trotzdem musste ich eben eine Weile Suchen, um es im Handbuch wieder zu finden:

http://www.php.net/manual/en/apache.configuration.php#ini.xbithack

Liebe Grüße aus Syburg

Tom vom Berg

[Alexander (HH)]

Moin Moin!

»» > Wenn man nun z.B. noch den x-bit-hack aktiviert [...]
»» Sooo tief hakt sich der PHP-Interpreter in den Apachen ein? [...] X-Bit-Hack [...]

Ja. ich hatte es erst die letzten Tage nochmal gelesen. Trotzdem musste ich eben eine Weile Suchen, um es im Handbuch wieder zu finden:

http://www.php.net/manual/en/apache.configuration.php#ini.xbithack

Das ist aber ein anderer X-Bit-Hack als der für mod_include. Die gleiche Idee, aber eine andere Stelle im laufenden Code.

Alexander

[Tom]

Hello,

Ja. ich hatte es erst die letzten Tage nochmal gelesen. Trotzdem musste ich eben eine Weile Suchen, um es im Handbuch wieder zu finden:

http://www.php.net/manual/en/apache.configuration.php#ini.xbithack

Das ist aber ein anderer X-Bit-Hack als der für mod_include. Die gleiche Idee, aber eine andere Stelle im laufenden Code.

Das nehme ich an. Aber es ist dasselbe x-Bit und das könnte dann Probleme machen mit SSI, wenn SSI auch das x-bit benutzt.

Insofern ist die force-type-Methode vermutlich besser.

Liebe Grüße aus Syburg

Tom vom Berg

[ChrisB]

Hi,

Sooo tief hakt sich der PHP-Interpreter in den Apachen ein? Normalerweise dient der X-Bit-Hack doch nur dazu, "normale" HTML-Dateien durch mod_include zu jagen.

Mittels der Direktiven Files(Match) und ForceType bspw. kann man auf dem Apachen das für PHP auch recht einfach erreichen.

MfG ChrisB