URL kürzen

[Electronix]

Hallo,

gibt es eine Funktion in PHP, mit der ich eine Url kürzen kann, sodass zum Beispiel
http://www.example.com/ordner/../index.php
zu
http://www.example.com/index.php wird?

Also die Funktion soll ordner/.. löschen, da dies sich ja gegenseitig "aufhebt".

Gibt es sowas vielleicht, oder komm ich an einer komplizierteren Lösung nicht vorbei?

MfG,

Electronix

[Sven Rautenberg]

Moin!

gibt es eine Funktion in PHP, mit der ich eine Url kürzen kann, sodass zum Beispiel
http://www.example.com/ordner/../index.php
zu
http://www.example.com/index.php wird?

Also die Funktion soll ordner/.. löschen, da dies sich ja gegenseitig "aufhebt".

Gibt es sowas vielleicht, oder komm ich an einer komplizierteren Lösung nicht vorbei?

realpath() anwenden auf den Pfad-Teil, den dir parse_url() zurückgibt. Dann wieder zusammensetzen zu einer URL.

- Sven Rautenberg

[Electronix]

Hallo,

vielen Dank,
es klappt!

MfG,

Electronix

[Electronix]

Hallo,

vielen Dank,
es klappt!

MfG,

Electronix

[Tom]

Hello Sven,

realpath() anwenden auf den Pfad-Teil, den dir parse_url() zurückgibt. Dann wieder zusammensetzen zu einer URL.

ist es denn zulässig, die Funktion so ohne Weiteres auf URLs anzuwenden? Realpath bezieht sich doch eigentlich auf das Dateisystem und nicht auf Ressourcen, auch wenn die zufällig genauso aussehen, wie ein Pfad im Dateisystem.

Könnte ja sein, dass eine Path-Info übermittelt wird und kein Pfad.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

realpath() anwenden auf den Pfad-Teil, den dir parse_url() zurückgibt. Dann wieder zusammensetzen zu einer URL.

ist es denn zulässig, die Funktion so ohne Weiteres auf URLs anzuwenden? Realpath bezieht sich doch eigentlich auf das Dateisystem und nicht auf Ressourcen, auch wenn die zufällig genauso aussehen, wie ein Pfad im Dateisystem.

realpath() ist eine reine Stringfunktion, die keinerlei Kontakt zum Dateisystem aufnimmt.

- Sven Rautenberg

[Tom]

Hello,

realpath() anwenden auf den Pfad-Teil, den dir parse_url() zurückgibt. Dann wieder zusammensetzen zu einer URL.

ist es denn zulässig, die Funktion so ohne Weiteres auf URLs anzuwenden? Realpath bezieht sich doch eigentlich auf das Dateisystem und nicht auf Ressourcen, auch wenn die zufällig genauso aussehen, wie ein Pfad im Dateisystem.

realpath() ist eine reine Stringfunktion, die keinerlei Kontakt zum Dateisystem aufnimmt.

Und wie schafft sie es dann, symbolische Links aufzulösen? Das verstehe ich dann nicht.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

realpath() ist eine reine Stringfunktion, die keinerlei Kontakt zum Dateisystem aufnimmt.

Darum steht sie im PHP-Manual auch unter filesystem functions :-))
Bitte korrigiere Deine Aussage.

Aber ich habe noch ein wenig weiter geforscht.
Die Funktion realpath() aus dem Apachefreinds-WAMPP-PHP 5.2.9 funktioniert nicht.

Das liegt aber auch daran, dass ein LNK (sic!) unter Windows doppelt verkettet ist.
Ein Aufruf des Links mittels realpath() erzeugt leider eine Ausgabe, aber keine Rückgabe.
Der zurückgegene Infoblock wird von PHP 5.2.9 nicht richtig ausgewertet oder aufgefangen (?).
Da haben die PHP-ler was falsch gemacht.

Es ist mir allerdings jetzt zu müßig, den Bug zu melden, zumal die Version 5.2.9 nicht mehr angeboten wird im Bugtracker und Apachefriends noch keine XAMPP-Version mit PHP 5.2.10 anbieten.

Mach aber mal selber ein Versuche und vielleicht hast Du ja auch die Geduld, diesen arroganten PHP-lern den Bug zu melden.

Unter Linux funktioniert alles wie erwartet.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

´Hallo,

Die Funktion realpath() aus dem Apachefreinds-WAMPP-PHP 5.2.9 funktioniert nicht.

bitte beschreibe das genauer.

Das liegt aber auch daran, dass ein LNK (sic!) unter Windows doppelt verkettet ist.

Was meinst du jetzt? Einen Hardlink, wie von NTFS unterstützt? Oder nur eine "gewöhnliche" Verknüpfung im Windows-Explorer?

Zu ersteren will ich mangels Erfahrung nichts sagen; letztere sind überhaupt nicht mit irgendwas "verkettet". Eine Windows-Verknüpfung ist lediglich eine Datei mit der Extension ".lnk", in der der Pfad eines anderen Objekts im Filesystem steht. Für eine Anwendung ist das eine stinknormale Datei; die Sonderfunktion "Link" oder "Verknüpfung" löst nur der Windows-Explorer als Standard-Shell auf.

Wenn realpath() daher bei Windows-Verknüpfungen nicht auf das Ziel der Verknüpfung auflöst, ist das kein Fehler, sondern aus technischer Sicht völlig korrektes Verhalten.

Ein Aufruf des Links mittels realpath() erzeugt leider eine Ausgabe, aber keine Rückgabe.

Eine Ausgabe? - Du meinst eine Fehlermeldung? Dann verrate uns bloß nicht, welche. ;-)
Keine Rückgabe? - realpath() ist eine Funktion, die liefert *immer* eine Rückgabe (außer wenn das Script innerhalb der Funktion abgebrochen wird).

Der zurückgegene Infoblock wird von PHP 5.2.9 nicht richtig ausgewertet oder aufgefangen (?).

Infoblock? Die Funktion realpath() liefert lediglich einen String, keinen "Infoblock".

Unter Linux funktioniert alles wie erwartet.

Da werden Links auch direkt im Dateisystem aufgelöst, nicht erst in der Shell.

So long,
 Martin

[Tom]

Hello,

Zu ersteren will ich mangels Erfahrung nichts sagen; letztere sind überhaupt nicht mit irgendwas "verkettet". Eine Windows-Verknüpfung ist lediglich eine Datei mit der Extension ".lnk", in der der Pfad eines anderen Objekts im Filesystem steht. Für eine Anwendung ist das eine stinknormale Datei; die Sonderfunktion "Link" oder "Verknüpfung" löst nur der Windows-Explorer als Standard-Shell auf.

Sorry, wenn es jetzt etwas dürftig bleibt. Ich habe im Moment keine Zeit.

Das Testscript liefert:

<?php   ### realpath.php ###

$path = 'testbild.jpg.lnk';  ## (ohne .lnk gibt es false)

#$linkok = link($path, 'Q:/galerie/bilder/testbild.jpg');

if($realpath = realpath($path))
{
    $realrealpath = file_get_contents($realpath);
#    header('Content-Type: image/jpg');
#    readfile($realrealpath);

echo "<p>Der Pfad lautet <b>$realpath</b></p>\r\n";
    echo "<p>Der reale Pfad lautet <b>$realrealpath</b></p>\r\n";
}
else
{
    echo "<p>konnte <b>$path</b> nicht auflösen</p>\r\n";
#    echo "<p>".($linkok?'true':'false')."</p>\r\n";
}
?>

Der Pfad lautet C:\Programme\xampp\htdocs\test\dateizugriffe\directories\realpath\testbild.jpg.lnk

Ein Aufwand für die Widerleung einer solch simplen Falsch-Behauptung!
      Realpath ist keine reine Stringfunktion!

'testbild.jpg.lnk' ist wohl auch das, was readdir() liefern würde. Windows zeigt aber nur testbild.jpg an im Filesystem-Explorer.

Den Rest musst Du bitte mal selber rausfummeln :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo Tom,

Sorry, wenn es jetzt etwas dürftig bleibt. Ich habe im Moment keine Zeit.

gut, aber das Wesentliche ist (zumindest aus meiner Sicht) jetzt klar.

$path = 'testbild.jpg.lnk';  ## (ohne .lnk gibt es false)

Natürlich erhältst du ohne die Extenstion ".lnk" kein sinnvolles Ergebnis, denn testbild.jpg existiert ja in diesem Verzeichnis nicht. Die Datei testbild.jpg.lnk, die auf testbild.jpg verweist, ist wie schon erklärt eine ganz gewöhnliche Datei ohne jede Sonderbedeutung. Die Funktion eines Links implementiert ausschließlich der Windows-Explorer.

$realrealpath = file_get_contents($realpath);

Und hier liest du den Inhalt von testbild.jpg.lnk aus - der liegt aber weder in einer lesbaren, textbasierten Form vor, noch hat er irgendwas mit JPEG zu tun.

#    header('Content-Type: image/jpg');
#    readfile($realrealpath);

Böses Foul: Du willst hier dem Client (Browser) den Inhalt von testbild.jpg.lnk als JPEG-Bilddaten verkaufen.

echo "<p>Der Pfad lautet <b>$realpath</b></p>\r\n";
    echo "<p>Der reale Pfad lautet <b>$realrealpath</b></p>\r\n";

Was du hier als $realrealpath angibst, ist nur der (binär strukturierte) Inhalt der testbild.jpg.lnk, wie jetzt klar sein sollte.

Dein Ergebnis ist daher genau das, was man erwarten müsste.

Ein Aufwand für die Widerleung einer solch simplen Falsch-Behauptung!
      Realpath ist keine reine Stringfunktion!

Nein, sicher nicht. Kann sie auch nicht, wenn sie -wie im PHP-Manual steht- auch Querverweise im Filesystem auflösen soll.

'testbild.jpg.lnk' ist wohl auch das, was readdir() liefern würde.

Richtig. Es ist das, was an dieser Stelle wirklich als Datei gespeichert ist.

Windows zeigt aber nur testbild.jpg an im Filesystem-Explorer.

Natürlich, der ist drauf dressiert, die Extensions ".lnk", ".url" und ".pif" *niemals* anzuzeigen, unabhängig von den Explorer-Einstellungen. Aber lösch mal den standardmäßig vorhandenen Registry-Schlüssel
 [HKCR\lnkfile\NeverShowExt]
und du wirst feststellen, dass der Windows-Explorer dann plötzlich auch diese bisher verborgene Extension anzeigt - zum Beispiel auch bei sämtlichen Verknüpfungen im Startmenü.

Den Rest musst Du bitte mal selber rausfummeln :-)

Wie gesagt: Diese Art von Verknüpfungen sind kein Feature des Filesystems, sondern eine übergestülpte Interpretation bestimmter Dateien durch die Shell.

Schönen Sonntag noch,
 Martin

[Tom]

Hello,

#    header('Content-Type: image/jpg');
#    readfile($realrealpath);

Böses Foul: Du willst hier dem Client (Browser) den Inhalt von testbild.jpg.lnk als JPEG-Bilddaten verkaufen.

Nee, nicht Foul, sondern stochern im Heuhaufen. Ist ja schließlich schon wieder auskommentiert.
Meine diversen Versuche habe ich noch nicht sauber genug dokumentiert, um sie hier den kurzsichtigen Mitlesern zu präsentieren... *uff, Ärger bestellt*

Jedenfalls sind zwei Dinge bewiesen:

1. realpath() ist eine echte Filesystem-Funktion und daher für URLs nicht ohne
   Beachtung von Randbedingungen einsetzbar

2. Die PHP-Implementation für Windows ist falsch, denn dafür müsste der Information-Block,
   den Windows liefert, ausgewertet werden und die Ausgabe unterdrückt werden.

#------
Ich muss mich jetzt wieder um unsere Server-Einbrecher kümmern. Das "totale Logging" für Linux-Hosts (diverser Distributionen) habe ich leider immer noch nicht hinbekommen.

Die Paypal-Phischer sind jedenfalls sehr aktiv!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

2. Die PHP-Implementation für Windows ist falsch, denn dafür müsste der Information-Block,
      den Windows liefert, ausgewertet werden und die Ausgabe unterdrückt werden.

nein, ich bin anderer Meinung. Windows-Verknüpfungen sind, wie ich schon versucht habe klarzumachen, *keine* Funktion des Filesystems! Sie sind ganz normlae Dateien, die bloß vom Windows-Explorer besonders behandelt werden. Alle anderen Applikationen (PHP eingeschlossen) sehen da nur Dateien mit der Externsion ".lnk", mit denen sie nichts anfangen können.

Ich würde es vielmehr für verwerflich halten, wenn PHP jetzt auch noch in Eigenregie versuchte, LNK-Dateien zu entziffern und zu interpretieren. Das tut ja sonst auch keine Anwendung!

Schönen Sonntag noch,
 Martin

[Tom]

Hello,

Ich würde es vielmehr für verwerflich halten, wenn PHP jetzt auch noch in Eigenregie versuchte, LNK-Dateien zu entziffern und zu interpretieren. Das tut ja sonst auch keine Anwendung!

Das wäre eine Sache der Einstellung

os_win.resolve.links = on

wäre mein Vorschlag.

Wenn ich viel Zeit habe, werde ich das den arroganten Schnöseln von PHP mal so aufbereiten, dass sie es verstehen, also alle verständlichen deutschen Ausdrücke im Anforderungsprofil durch pseudo-Fachbegriffe erstezen und ordentlich dummschwafeln.

Vermutlich bekomme ich ja jetzt hier erstmal wieder auf die Mütze. Aber das macht nichts, das kenne ich schon. Irgendwann später wird mein Vorschlag sowieso umgesetzt, nur dann kommt er von jemand anderem :-)

#----
Muss jetzt erstmal physisch zu einem Kunden. Der kann keine rechnungen mehr schreiben und das ist tödlich. Sonntag ist Check-Out-Day :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

Ich würde es vielmehr für verwerflich halten, wenn PHP jetzt auch noch in Eigenregie versuchte, LNK-Dateien zu entziffern und zu interpretieren. Das tut ja sonst auch keine Anwendung!

Das wäre eine Sache der Einstellung
    os_win.resolve.links = on
wäre mein Vorschlag.

wäre denkbar, sicher. Aber warum? Welchen Grund sollte PHP haben, einen Pfad anders aufzulösen als jede andere Anwendung?

Wenn ich mal annehme:

E:\demo\verzeichnis\info.txt

und eine Verknüpfung

E:\shortcut\info.txt.lnk

Du schlägst nun vor, wenn ich dich richtig verstehe, dass realpath() die Angabe E:\shortcut\info.txt (also eine Datei, die gar nicht existiert) auf E:\demo\verzeichnis\info.txt auflösen soll. Mit welcher Begründung?

Wenn ich viel Zeit habe, werde ich das den arroganten Schnöseln von PHP ...

Oh, hast du mit denen schlechte Erfahrungen gemacht? Die wenigen Fälle, in denen bisher Kontakt zu der mannschaft hatte, empfand ich als sehr sachlich und höflich.

Vermutlich bekomme ich ja jetzt hier erstmal wieder auf die Mütze.

Ach was. :-)

Schönen Sonntag noch,
 Martin

[Tom]

Hello,

Du schlägst nun vor, wenn ich dich richtig verstehe, dass realpath() die Angabe E:\shortcut\info.txt (also eine Datei, die gar nicht existiert) auf E:\demo\verzeichnis\info.txt auflösen soll. Mit welcher Begründung?

Nein, schlage ich nicht vor.

Ich schlage vor, dass PHP auf bestimmten Windows-Versionen einen Dateinamen 'info.txt.lnk' auflöst, so wie die Windows-Shell es tut, nämlich schaut, ob ein gültiger Information-Block dahinter steckt. Wenn ja, soll dem Inhalt dieses Blocks gefolgt werden.

Das wäre dann eine OS-typische Handlungsweise. Wieso sollte PHP, dass die Shell ja schließlich nachbilden muss, dies also nicht berücksichtigen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Du schlägst nun vor, wenn ich dich richtig verstehe, dass realpath() die Angabe E:\shortcut\info.txt (also eine Datei, die gar nicht existiert) auf E:\demo\verzeichnis\info.txt auflösen soll. Mit welcher Begründung?

Nein, schlage ich nicht vor.

Ich schlage vor, dass PHP auf bestimmten Windows-Versionen einen Dateinamen 'info.txt.lnk' auflöst, so wie die Windows-Shell es tut, nämlich schaut, ob ein gültiger Information-Block dahinter steckt. Wenn ja, soll dem Inhalt dieses Blocks gefolgt werden.

Das wäre dann eine OS-typische Handlungsweise. Wieso sollte PHP, dass die Shell ja schließlich nachbilden muss, dies also nicht berücksichtigen?

Vielleicht mag sich ja einer mit einer Hilfsfunktion dafür beschäftigen. Hier ist zumindest das Format: http://www.i2s-lab.com/Papers/The_Windows_Shortcut_File_Format.pdf

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

Du schlägst nun vor, wenn ich dich richtig verstehe, dass realpath() die Angabe E:\shortcut\info.txt (also eine Datei, die gar nicht existiert) auf E:\demo\verzeichnis\info.txt auflösen soll. Mit welcher Begründung?

Nein, schlage ich nicht vor.
Ich schlage vor, dass PHP auf bestimmten Windows-Versionen ...

wenn's um dieses Merkmal geht: Alle Windows-Versionen seit 95.

... einen Dateinamen 'info.txt.lnk' auflöst, so wie die Windows-Shell es tut, nämlich schaut, ob ein gültiger Information-Block dahinter steckt. Wenn ja, soll dem Inhalt dieses Blocks gefolgt werden.

Zum einen ist das nicht ganz richtig: Diese Auflösung geschieht nur, wenn über die Shell (Explorer) eine LNK-Datei geöffnet werden soll - nicht aber bei reinen Verzeichnis-Suchoperationen. Auch bei einer Dateisuche wird ein Link auf ein anderes Verzeichnis nicht aufgelöst.
Zum andern müsstest du, wenn du das verlangst, konsequenterweise ebenso verlangen, dass Funktionen wie readdir() oder glob() die Extensions von den Dateinamen abschneiden, weil das auch das per Default voreingestellte Standardverhalten ist (ungeachtet der Tatsache, dass ich das Unterdrücken der Extensions für Unsinn halte).

Das wäre dann eine OS-typische Handlungsweise. Wieso sollte PHP, dass die Shell ja schließlich nachbilden muss, dies also nicht berücksichtigen?

Ich siedle PHP eher auf dem Niveau einer Anwendung an. Mit welchem gedanklichen Hintergrund stellst du es mit einer grafischen Shell, einem GUI gleich? Da komme ich gedanklich nicht ganz mit.

So long,
 Martin

[Tom]

Hello,

Ich siedle PHP eher auf dem Niveau einer Anwendung an. Mit welchem gedanklichen Hintergrund stellst du es mit einer grafischen Shell, einem GUI gleich? Da komme ich gedanklich nicht ganz mit.

Du denkst falsch. Du glaubst nämlich immer noch, ich wolle PHP einen theoretischen Fehler unterstellen. Das will ich gar nicht. Ich sage nur, so wie PHP es im Moment auf Windows löst, ist es unbrauchbar. Das liegt aber an Windows. Windows hat hier dem GUI eine Funktion zugeordnet, die eigentlich in die Windows-API gehört.

Wenn man aber über das GUI mit einem beliebigen dafür geeigneten Programm so einen Link doppelklickt, bekommt dieser nicht den Link, sondern das verlinkte File zur Bearbeitung.

Nun habe ich versucht, aus Textpad heraus so eine Link-Datei zu öffnen. Das ist ebenfalls nicht möglich, wenn man den Angebotenen Linknamen verwendet. Auch Textpad öffnet dann das verlinkte File...
Das machen die anderen Programme (Photoed, Word, etc.) übrigens auch alle.

Benutzen die nun den richtigen[tm] Interrupt (wäre ja vorstellbar) und PHP benuttz den falschen, oder ist da auch Windows wieder mit der GUI dazwischen?

Ich bin mir da unsicher, ob der Apache und PHP in der Windows-C-API wirklich den "richtigen" Interrupt (oder eben das richtige ASM/C/C++-Makro) benutzen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo Tom,

Du denkst falsch. Du glaubst nämlich immer noch, ich wolle PHP einen theoretischen Fehler unterstellen. Das will ich gar nicht. Ich sage nur, so wie PHP es im Moment auf Windows löst, ist es unbrauchbar. Das liegt aber an Windows. Windows hat hier dem GUI eine Funktion zugeordnet, die eigentlich in die Windows-API gehört.

okay, so wird ein Schuh draus. Da stimme ich dir hundertprozentig zu.

Nun habe ich versucht, aus Textpad heraus so eine Link-Datei zu öffnen. Das ist ebenfalls nicht möglich, wenn man den Angebotenen Linknamen verwendet. Auch Textpad öffnet dann das verlinkte File...
Das machen die anderen Programme (Photoed, Word, etc.) übrigens auch alle.

Das ist eine Illusion. Die benutzen alle den Dateiauswahl-Dialog, den der Explorer zur Verfügung stellt. Letztendlich ist es also auch hier wieder der Windows-Explorer, der die Funktionalität realisiert, nicht die Anwendung.

Benutzen die nun den richtigen[tm] Interrupt (wäre ja vorstellbar) und PHP benuttz den falschen, oder ist da auch Windows wieder mit der GUI dazwischen?

Letzteres.

Ich bin mir da unsicher, ob der Apache und PHP in der Windows-C-API wirklich den "richtigen" Interrupt (oder eben das richtige ASM/C/C++-Makro) benutzen.

Apache und PHP benutzen hier tatsächlich *direkt* das Windows-API, das von sogenannten Verknüpfungen in Form von LNK-Dateien nichts "weiß". Anders sieht es mit "echten" Dateisystem-Links auf NTFS-Volumes aus, die man mit dem fsutil-Tool anlegen kann - die werden auch direkt über das Filesystem-API aufgelöst.

So long,
 Martin

[Tom]

Hello Martin,

Ich bin mir da unsicher, ob der Apache und PHP in der Windows-C-API wirklich den "richtigen" Interrupt (oder eben das richtige ASM/C/C++-Makro) benutzen.

Apache und PHP benutzen hier tatsächlich *direkt* das Windows-API, das von sogenannten Verknüpfungen in Form von LNK-Dateien nichts "weiß". Anders sieht es mit "echten" Dateisystem-Links auf NTFS-Volumes aus, die man mit dem fsutil-Tool anlegen kann - die werden auch direkt über das Filesystem-API aufgelöst.

Also müsste PHP jetzt für eine analoge Funktionsweise Linux/Windows für die Funktionen

• is_link()
• realpath()
• ?

einen Workaround bauen, der eben bei Dateien, die auf *.lnk enden, das File ausliest und schaut, ob es ein gültiges Link-Informations-File ist. Dann kann entsprechend analog reagiert werden zur Funktionsweise auf Linux.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Hello,

realpath() anwenden auf den Pfad-Teil, den dir parse_url() zurückgibt. Dann wieder zusammensetzen zu einer URL.

ist es denn zulässig, die Funktion so ohne Weiteres auf URLs anzuwenden? Realpath bezieht sich doch eigentlich auf das Dateisystem und nicht auf Ressourcen, auch wenn die zufällig genauso aussehen, wie ein Pfad im Dateisystem.

realpath() ist eine reine Stringfunktion, die keinerlei Kontakt zum Dateisystem aufnimmt.

Und wie schafft sie es dann, symbolische Links aufzulösen? Das verstehe ich dann nicht.

Ok, da habe ich dann wohl was verwechselt. Oder falsch erinnert. Oder es hat sich da was geändert seit PHP 4. ;) realpath() hat tatsächlich Kontakt zum Dateisystem.

Das gilt aber nicht für einige andere Funktionen, die zwar unter Dateisystemfunktionen stehen, aber im Prinzip dateisystemorientierte Stringfunktionen sind:

basename()
dirname()
pathinfo()
und natürlich :)
parse_ini_string()

basename, dirname und pathinfo zerlegen nur den übergebenen String, unabhängig davon, ob die so bezeichnete Datei nun existiert, oder nicht.

- Sven Rautenberg

[Tom]

Hello,

Ok, da habe ich dann wohl was verwechselt. Oder falsch erinnert. Oder es hat sich da was geändert seit PHP 4. ;) realpath() hat tatsächlich Kontakt zum Dateisystem.

Ist ja kein Beinbruch. :-)

Nur, welchen Einfluss hat das jetzt auf die Rückführung einer URL auf eine "realurl", die ja durchaus einen ähnlichen Aspekt haben kann, wie ein Pfad aus dem Filesystem?

Mir begegnet das Thema im Moment bei den Angriffsversuchen auf einen Kundenserver schließlich auch dauernd. Da werden dann URLs angeforsert, die reichlich '../../../../../" enthalten.

Allerdings kümmert sich bei einer HTTP-Anforderung der Apache schon darum.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Mir begegnet das Thema im Moment bei den Angriffsversuchen auf einen Kundenserver schließlich auch dauernd. Da werden dann URLs angeforsert, die reichlich '../../../../../" enthalten.

Allerdings kümmert sich bei einer HTTP-Anforderung der Apache schon darum.

Das ist das übliche "Directory Traversal"-Muster: Den Baum bestmöglich nach oben klettern, um dann auf Root zu stoßen und /etc/passwd usw. zu erreichen.

Der Apache kümmert sich drum - schlecht programmierte Software nicht unbedingt, wenn so ein Pfad als Parameter angenommen wird.

- Sven Rautenberg