Mod Rewrite

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Ich möchte gerne alle Requests, die auf ein bestimmtes Verzeichnis lauten, auf ein php-Script umleiten. Das soll dann auch geparst werden. Den jeweiligen "Dateinamen" im Request kenne ich nicht. Die Ressourcen gibt es auch gar nicht physisch. Im Script soll dann dieser "Dateiname" ausgewertet werden können.

Wie muss ich das machen?

Spirituelle Grüße
Euer Robert

[Mattes]

Ich möchte gerne alle Requests, die auf ein bestimmtes Verzeichnis lauten, auf ein php-Script umleiten. Das soll dann auch geparst werden. Den jeweiligen "Dateinamen" im Request kenne ich nicht. Die Ressourcen gibt es auch gar nicht physisch. Im Script soll dann dieser "Dateiname" ausgewertet werden können.

Ich versehe mal ganz frech auf mich: https://forum.selfhtml.org/?t=218911&m=1509340.

[Camping_RIDER]

Aloha ;)

Ich versehe mal ganz frech auf mich: https://forum.selfhtml.org/?t=218911&m=1509340.

Imho nicht gut - zumindest nicht für dieses Problem. Ich verstehe den TO so, dass er den Dateinamen überhaupt nicht kontrollieren/vorhersagen kann (also ist ein Abfang von allem unterhalb /skript oder /skript.php - zweiteres besser weil ohne files-Direktive möglich - nicht ausreichend).

Dir bleibt dann nur die Anwendung von http://de.selfhtml.org/servercgi/server/rewrite.htm@title=mod_rewrite.

Grüße,

RIDER

[Mattes]

Ich versehe mal ganz frech auf mich: https://forum.selfhtml.org/?t=218911&m=1509340.

Imho nicht gut - zumindest nicht für dieses Problem. Ich verstehe den TO so, dass er den Dateinamen überhaupt nicht kontrollieren/vorhersagen kann (also ist ein Abfang von allem unterhalb /skript oder /skript.php - zweiteres besser weil ohne files-Direktive möglich - nicht ausreichend)

Wieso soll es zum Abfang von Allem nicht ausreichend sein, alles unter dem gegebenen Pfad /skript/ abzufangen, nur, weil unbekannt ist, was da alles kommen mag? "Alles" schließt meinem Verständnis nach auch Unbekanntes ein.

[Camping_RIDER]

Aloha ;)

Wieso soll es zum Abfang von Allem nicht ausreichend sein, alles unter dem gegebenen Pfad /skript/ abzufangen, nur, weil unbekannt ist, was da alles kommen mag? "Alles" schließt meinem Verständnis nach auch Unbekanntes ein.

Ganz einfach: Weil damit eben nicht *alles* avgefangen wird, sondern nur alles unterhalb /skript/ ;) mod_rewrite ist allumfassender.

Grüße,

RIDER

[Robert R.]

Lieber Mitdenker Rider,
liebe Wissende,
liebe Neugierige,

ja!

Ich versehe mal ganz frech auf mich: https://forum.selfhtml.org/?t=218911&m=1509340.

Imho nicht gut - zumindest nicht für dieses Problem. Ich verstehe den TO so, dass er den Dateinamen überhaupt nicht kontrollieren/vorhersagen kann (also ist ein Abfang von allem unterhalb /skript oder /skript.php - zweiteres besser weil ohne files-Direktive möglich - nicht ausreichend).

Dir bleibt dann nur die Anwendung von http://de.selfhtml.org/servercgi/server/rewrite.htm@title=mod_rewrite.

Das sehe ich auch so. Da muss ich also nun mit Mod-Rewrite herumspielen, bis ich es verstanden habe.

Es gibt im Projekt noch mehr Rewrites, die ich nicht antasten darf.
Ich könnte auch darauf vertrauen, dass alle Anfragen, die von keiner real existierenden Datei beantwortet werden können, ohnehin zentral in einer index.php landen. So zumindest ist das in der Doku beschrieben. Dann müsste ich die aber verändern.

Ich will aber gerne den Spezialfall separat halten, weil ich nicht weiß, ob das später tatsächlich so bleibt und den Request für dieses Verzeichnis vorher schon abfangen, auch weil ich das vorhandene Gerüst nicht antasten will. Trifft also ein Request auf das Muster zu, sollen die anderen Rewrites gar nicht mehr abgefragt werden.

Was erreicht werden soll:

Der User erzeugt ein Abfrageergebnis aus einer Datenbank. Es entstehen Datensätze daraus, die in der Sessiondatei gespeichert werden. Darunter sind auch Datensätze, die Verweise auf Files im Dateibaum enthalten. Im View kann ich nun dafür sorgen, dass diese als Link oder neues Requestobjekt (z. B. ein <img>-Tag) ausgegeben werden.

Wenn dieser nun vom Browser aufgelöst wird, soll der Reqest auf das Verzeichnis '/private/images/PATH_TO_THE_RESOURCE.XXX' immer in ein und derselben Datei landen, die dann mittels Request-Path-Zerlegung den öffentlichen Namen der Resource feststellt und dann in der Session guckt, ob dafür eine Translation auf das lokale Verzeichnis (außerhalb der DocRoot!) vorliegt. Dann darf das Skript diese Ressource ausliefern. So erhält ein User immer nur diejenigen Files, auf die er Rechte hat. Die Rechtesteuerung findet im Datenbankmodell statt und ich darf die auch nicht anfassen.

Ich hoffe, ich konnte mein Anliegen nochmal verständlicher rüberbringen.

Ich probiere jetzt noch ein bisschen mit Mod Rewrite herum, befürchte aber, dass ich das noch nicht alleine hinbekomme.

Spirituelle Grüße
Euer Robert

[Mattes]

Ich versehe mal ganz frech auf mich: https://forum.selfhtml.org/?t=218911&m=1509340.

Imho nicht gut - zumindest nicht für dieses Problem. Ich verstehe den TO so, dass er den Dateinamen überhaupt nicht kontrollieren/vorhersagen kann (also ist ein Abfang von allem unterhalb /skript oder /skript.php - zweiteres besser weil ohne files-Direktive möglich - nicht ausreichend).

Das sehe ich auch so.

Wenn dieser nun vom Browser aufgelöst wird, soll der Reqest auf das Verzeichnis '/private/images/PATH_TO_THE_RESOURCE.XXX' immer in ein und derselben Datei landen, die dann mittels Request-Path-Zerlegung den öffentlichen Namen der Resource feststellt

Verstehe jetzt immer noch nicht, warum du nicht einfach das Skript als /private/images ablegst, wie beschrieben PHP zuweist, und fürdahin in $_SERVER["PATH_INFO"] dein "PATH_TO_THE_RESOURCE.XXX" fix und fertig geliefert bekommst – gänzlich ohne mod_rewrite-Klimmzüge, gänzlich ohne irgendwas zerlegen zu müssen, gänzlich ohne Schweißperlen auf der Stirn.

Aber gut, …

Ich probiere jetzt noch ein bisschen mit Mod Rewrite herum, befürchte aber, dass ich das noch nicht alleine hinbekomme.

… wer keine Arbeit hat, der macht sich halt welche.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Ich versehe mal ganz frech auf mich: https://forum.selfhtml.org/?t=218911&m=1509340.

Imho nicht gut - zumindest nicht für dieses Problem. Ich verstehe den TO so, dass er den Dateinamen überhaupt nicht kontrollieren/vorhersagen kann (also ist ein Abfang von allem unterhalb /skript oder /skript.php - zweiteres besser weil ohne files-Direktive möglich - nicht ausreichend).

Das sehe ich auch so.

Wenn dieser nun vom Browser aufgelöst wird, soll der Reqest auf das Verzeichnis '/private/images/PATH_TO_THE_RESOURCE.XXX' immer in ein und derselben Datei landen, die dann mittels Request-Path-Zerlegung den öffentlichen Namen der Resource feststellt

Verstehe jetzt immer noch nicht, warum du nicht einfach das Skript als /private/images ablegst, wie beschrieben PHP zuweist, und fürdahin in $_SERVER["PATH_INFO"] dein "PATH_TO_THE_RESOURCE.XXX" fix und fertig geliefert bekommst – gänzlich ohne mod_rewrite-Klimmzüge, gänzlich ohne irgendwas zerlegen zu müssen, gänzlich ohne Schweißperlen auf der Stirn.

Weil das nicht funktioniert?

Es gibt kein "das Skript" als physikalische Ressource in dem Pfad. Die Requests sind alle unterschiedlich, nur der Pfad davor ist immer derselbe. Da können Bilder angefordert werden oder PDF-Dateien oder Textdateien oder oder...

Wenn ich einen Request auf diesen speziellen Pfad nicht gleich am Anfang abfange und umleite auf immer dasselbe Skript, dann landet er aufgrund der weiteren Rewrite-Condidions und -Regeln in der zentralen index.php. Soweit habe ich das System inzwioschen schon verstanden.

Ich darf also nur Requests auf genau diesen Pfad abfangen.

Oder habe ich Dich da jetzt einfach noch nicht richtig verstanden? Ich hab's schließlich noch nicht vollständig durchschaut. Was wird zuerst ausgewertet? Die <FILES>-Direktive im Verzeichnis oder die Rewrite-Conditions und -Rules? Mir fehlen da einfach noch die Erfahrungen.

Spirituelle Grüße
Euer Robert

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Ich habe jetzt erstmal das eine Teilprojekt mit lesen, spielen, gucken bearbeitet.

  
# .htaccess  
  
RewriteEngine on  
RewriteBase /  
  
RewriteRule ^authfiles/(.*)$ /authcheck.php?$1  [L]  
  
RewriteCond %{REQUEST_FILENAME} !-f  
RewriteCond %{REQUEST_FILENAME} !-l  
  
RewriteRule (.*) index.php/$1 [QSA]  
  

Das scheint zu funktionieren.

Ist das [L] der Hinweis darauf, dass keine weitere Regel mehr ausgwertet wird?

Was bedeutet das [QSA]?

In dem anderen Projektteil sind soviele Regeln, dass ich mich da überhaupt noch nicht rantraue. Das lief nicht mehr, nachdem ich meine Zeile mit dem authcheck eingefügt hatte.

Spirituelle Grüße
Euer Robert

[Mattes]

RewriteRule ^authfiles/(.*)$ /authcheck.php?$1  [L]

RewriteRule (.*) index.php/$1 [QSA]

Ist das [L] der Hinweis darauf, dass keine weitere Regel mehr ausgwertet wird?

Grundsätzlich ja. In der Praxis kann es vorkommen, dass der ganze Regelsatz nochmals durchlaufen wird, weil das, was mod_rewrite am Ende ausspuckt, vom Server möglicherweise noch weiterverarbeitet wird.

Was bedeutet das [QSA]?

QSA steht für query string append. Gibst du als RewriteRule-Ziel eine URL mit Parametern an, werden die ursprünglichen Parameter normalerweise entsorgt. Mit QSA werden sie weitergegeben.

[Robert R.]

Lieber Mitdenker Mattes,
liebe Wissende,
liebe Neugierige,

ja!

Ist das [L] der Hinweis darauf, dass keine weitere Regel mehr ausgwertet wird?

Grundsätzlich ja. In der Praxis kann es vorkommen, dass der ganze Regelsatz nochmals durchlaufen wird, weil das, was mod_rewrite am Ende ausspuckt, vom Server möglicherweise noch weiterverarbeitet wird.

Was bedeutet das [QSA]?

QSA steht für query string append. Gibst du als RewriteRule-Ziel eine URL mit Parametern an, werden die ursprünglichen Parameter normalerweise entsorgt. Mit QSA werden sie weitergegeben.

Das arbeitet aber nicht mit dem [L] zusammen, oder? Jedenfalls bekomme ich dann immer einen Serverfehler. Der Name des Skriptes muss nach außen nicht bekannt sein, finde ich auch gut so. Kann man da nun noch den Direktaufruf unterbinden?

Im Skript habe ich jetzt testhalber

  
<?php   /* authcheck.php */  
  
		header('Content-Type: text/plain; CharSet=utf-8;');  
		  
		echo "Ich habs bekommen\r\n";  
  
		if (isset($_SERVER['PATH_INFO']))  
		{  
			echo $_SERVER['PATH_INFO'] . "\r\n";	  
		}	  
		  
		echo $_SERVER['REQUEST_URI']."\r\n";  
		  
		if (isset($_SERVER['REDIRECT_QUERY_STRING'])) {	echo $_SERVER['REDIRECT_QUERY_STRING']."\r\n"; }  
		else { echo "Keine Anfrage vorhanden\r\n"; }  
  
		print_r($_GET);	  
		  
?>		  

stehen. Daraus müsste ich eigentlich alle benötigten Daten ermitteln können, wenn es denn stabil ist. Wie der geschützte Pfadteil lautet, weiß das Skript. Der nächste Part /.../ ist der Schlüssel. Dann hat man immer noch die Chance, per weiteren Path-Parts und weiteren Parametern weitere Infos durchzuleiten, wenn das mal notwendig ist.

Da sollte ich eigentlich genügend Entwicklungsspielraum haben.

Spirituelle Grüße
Euer Robert

[Mattes]

Es gibt kein "das Skript" als physikalische Ressource in dem Pfad.

Das Skript musst du zwangsläufig irgendwo speichern, also kannst du es auch auf dem gewünschten Pfad speichern.

nur der Pfad davor ist immer derselbe.

Nämlich diesem.

Wenn ich einen Request auf diesen speziellen Pfad nicht gleich am Anfang abfange und umleite auf immer dasselbe Skript, dann landet er aufgrund der weiteren Rewrite-Condidions und -Regeln in der zentralen index.php.

Da täte ich hinterfragen, warum dieser Pfad überhaupt in einer zentralen index.php landet, die scheint ein wenig gierig zu sein. Andererseits scheinst du mit dem Gierschlund geschlagen zu sein, insofern wirst du wohl tatsächlich nicht darum herumkommen, per RewriteRule den Fressnapf zu durchsuchen, bevor das Vieh alles sich reinstopft.

Probiere es mit

RewriteRule ^/images/private/(.*) /skript.php?datei=$1 [L]

als erste Anweisung in der Regelliste.

[hotti]

hi,

Der User erzeugt ein Abfrageergebnis aus einer Datenbank. Es entstehen Datensätze daraus, die in der Sessiondatei gespeichert werden. Darunter sind auch Datensätze, die Verweise auf Files im Dateibaum enthalten. Im View kann ich nun dafür sorgen, dass diese als Link oder neues Requestobjekt (z. B. ein <img>-Tag) ausgegeben werden.

Wenn dieser nun vom Browser aufgelöst wird, soll der Reqest auf das Verzeichnis '/private/images/PATH_TO_THE_RESOURCE.XXX' immer in ein und derselben Datei landen, die dann mittels Request-Path-Zerlegung den öffentlichen Namen der Resource feststellt und dann in der Session guckt, ob dafür eine Translation auf das lokale Verzeichnis (außerhalb der DocRoot!) vorliegt. Dann darf das Skript diese Ressource ausliefern. So erhält ein User immer nur diejenigen Files, auf die er Rechte hat. Die Rechtesteuerung findet im Datenbankmodell statt und ich darf die auch nicht anfassen.

Ich hoffe, ich konnte mein Anliegen nochmal verständlicher rüberbringen.

Es ist sehr umständlich und auch an einer Stelle unlogisch: Wenn das Berechtigungssystem in der DB abgebildet ist, warum müssen dann nach einer Abfrage die Berechtigungen erneut geprüft werden wenn es um Ausliefern von Content geht?

Du kannst das viel einfacher lösen mit einer Routing-Table und einer Klassenbindung an die entsprechenden Ressource:
  URL => Class

Die Berechtigung jedoch, wird weder in der URL kodiert noch in der Class, vielmehr wird je nach Benutzergruppe ganz einfach eine andere Routing-Table in den Hauptspeicher geladen. So hast du das Berechtigungssystem komplett vom Code getrennt und welche Class zu welchem URL gehört ist nur noch eine Frage der Konfiguration (außerhalb vom Code).

Ich probiere jetzt noch ein bisschen mit Mod Rewrite herum, befürchte aber, dass ich das noch nicht alleine hinbekomme.

Ja freilich, Rewrite brauchst Du fürs Routing.

MfG

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Der User erzeugt ein Abfrageergebnis aus einer Datenbank. Es entstehen Datensätze daraus, die in der Sessiondatei gespeichert werden. Darunter sind auch Datensätze, die Verweise auf Files im Dateibaum enthalten. Im View kann ich nun dafür sorgen, dass diese als Link oder neues Requestobjekt (z. B. ein <img>-Tag) ausgegeben werden.

Wenn dieser nun vom Browser aufgelöst wird, soll der Reqest auf das Verzeichnis '/private/images/PATH_TO_THE_RESOURCE.XXX' immer in ein und derselben Datei landen, die dann mittels Request-Path-Zerlegung den öffentlichen Namen der Resource feststellt und dann in der Session guckt, ob dafür eine Translation auf das lokale Verzeichnis (außerhalb der DocRoot!) vorliegt. Dann darf das Skript diese Ressource ausliefern. So erhält ein User immer nur diejenigen Files, auf die er Rechte hat. Die Rechtesteuerung findet im Datenbankmodell statt und ich darf die auch nicht anfassen.

Ich hoffe, ich konnte mein Anliegen nochmal verständlicher rüberbringen.

Es ist sehr umständlich und auch an einer Stelle unlogisch: Wenn das Berechtigungssystem in der DB abgebildet ist, warum müssen dann nach einer Abfrage die Berechtigungen erneut geprüft werden wenn es um Ausliefern von Content geht?

Weil bei HTTP alle Requests immer für sich alleine stehen?

Du kannst das viel einfacher lösen mit einer Routing-Table und einer Klassenbindung an die entsprechenden Ressource:
  URL => Class

Verstehe ich nicht. Woher soll der rquest auf eine <img>-Ressource die Klasse seines Hauptdokumentes kennen, wenn er die nicht aus der Session bekommt?

Es funktioniert jetzt aber so, wie ich mir das vorgestellt habe.

Spirituelle Grüße
Euer Robert

[hotti]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

Es ist sehr umständlich und auch an einer Stelle unlogisch: Wenn das Berechtigungssystem in der DB abgebildet ist, warum müssen dann nach einer Abfrage die Berechtigungen erneut geprüft werden wenn es um Ausliefern von Content geht?

Weil bei HTTP alle Requests immer für sich alleine stehen?

Content Negotiation ist das Stichwort.

Du kannst das viel einfacher lösen mit einer Routing-Table und einer Klassenbindung an die entsprechenden Ressource:
  URL => Class

Verstehe ich nicht. Woher soll der rquest auf eine <img>-Ressource die Klasse seines Hauptdokumentes kennen, wenn er die nicht aus der Session bekommt?

Siehe Routing-Table.

Es funktioniert jetzt aber so, wie ich mir das vorgestellt habe.

Freut mich.

MfG

[Robert R.]

Lieber Mitdenker Hotti,
liebe Mitdenker im gesamten Forum,
liebe Wissende,
liebe Neugierige,

ja!

Es ist sehr umständlich und auch an einer Stelle unlogisch: Wenn das Berechtigungssystem in der DB abgebildet ist, warum müssen dann nach einer Abfrage die Berechtigungen erneut geprüft werden wenn es um Ausliefern von Content geht?

Ich würde die möglichen Konzepte gerne noch weiter diskutieren.
Das ist ein grundsätzliches Problem von CMS im HTTP-Umfeld. Viele Systeme und Portale haben da immense Lücken.

Ich wollte die nun bei unserem _bestehenden_ System durch eine möglichst simple und für nachfolgende Betreuer leicht verständliche Anprogrammierung schließen. Bisher werden nämlich immer die URLs der Bilder, die dann auch noch in einem Verzeichnis innerhalb der Document Root liegen, in der Antwort auf den Primärrequest der Ressource (MRD = Main Response Document, so heißt das bei uns zumindest) ausgegeben. Das ist kritisch, da z.B. Bilder von Mitgliedern der Community nur genau einer bestimmten Gruppe der Community zugänglich sein dürfen. Man könnte theoretisch das Verzeichnis durchklappern, ob man Treffer findet.

1.) Ersteinmal könnte man das Bilderverzeichnis (gilt aber auch sinngemäß für alle anderen MIME-Types) aus der DocRoot rausnehmen.

2.) Dann könnte man die zu sichernden Documents mit einem kryptischen Namen, ähnlich dem Sessionnamen von PHP versehen. Das verringert schon einmal die Trefferquote um Faktor (Namensvorrat/Anzahl der Dateien). Das Verhältnis dürfte selbst bei 1.000.000 Dokumente noch hoch genug liegen, dass es als _relativ_ sicher gelten kann.

3.) Da der Zugriff nun nur noch per Skript möglich ist, könnte man dessen Ausführung auch noch von einger gültigen Session abhängig machen.

4.) Da es nun möglich ist, Fehlversuche genau dem Sessionbesitzer zuzuordnen, könnte man nach z.B. 10 Fehlversuchen den Benutzer sperren.

5.) Schlussendlich könnte man die Ressourcelocators auch noch verschlüsseln, was dann aber zu extrem langen Ressourcekennungen (RUL-Encode lässt grüßen) führen könnte. Und die Sicherheit würde vermutlich aufgrund des ohnehin schon riesigen Namensvorrates nicht erhöht werden. Die Ergebnisse werden vermutlich ohnehin aus derselben Zielmenge stamnmen.

Was spart man dadurch?

• Keine zusätzlichen Datenbankzugriffe für Sekundärerequests nötig.
• Keine Instantiierung des Gesamtsystems bei jedem Sekundärrequest nötig.
• Kein Eingriff in die grundlegende Sicherheitsarchitektur des Systems nötig

Die Sessiondatei wird ohnehin geladen, die Datei mit den Hauptfunktionen auch. Man kann die Sekundärrequests auch mit einem Minimalskript abarebiten, das ausschließlich die Config-Dateien benötigt und die Session aufrufen muss, um festzustellen, ob die Gültig ist.

Weil bei HTTP alle Requests immer für sich alleine stehen?

Content Negotiation ist das Stichwort.

Was soll ich da verhalndeln?
Content Negotiation würde die Sicherheit eher verringern, als erhöhen.

Du kannst das viel einfacher lösen mit einer Routing-Table und einer Klassenbindung an die entsprechenden Ressource:
  URL => Class

Das würde ja bei Mod_Rewrite schon so wein. Da benötige ich nur das zugehörige Skript, dass keinerlei Sonderregelungen mehr benötigt (siehe obige Beschreibungen)

Spirituelle Grüße
Euer Robert

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

Ich wollte die nun bei unserem _bestehenden_ System durch eine möglichst simple und für nachfolgende Betreuer leicht verständliche Anprogrammierung schließen. Bisher werden nämlich immer die URLs der Bilder, die dann auch noch in einem Verzeichnis innerhalb der Document Root liegen, in der Antwort auf den Primärrequest der Ressource (MRD = Main Response Document, so heißt das bei uns zumindest) ausgegeben. Das ist kritisch, da z.B. Bilder von Mitgliedern der Community nur genau einer bestimmten Gruppe der Community zugänglich sein dürfen. Man könnte theoretisch das Verzeichnis durchklappern, ob man Treffer findet.

1.) Ersteinmal könnte man das Bilderverzeichnis (gilt aber auch sinngemäß für alle anderen MIME-Types) aus der DocRoot rausnehmen.

2.) Dann könnte man die zu sichernden Documents mit einem kryptischen Namen, ähnlich dem Sessionnamen von PHP versehen. Das verringert schon einmal die Trefferquote um Faktor (Namensvorrat/Anzahl der Dateien). Das Verhältnis dürfte selbst bei 1.000.000 Dokumente noch hoch genug liegen, dass es als _relativ_ sicher gelten kann.

3.) Da der Zugriff nun nur noch per Skript möglich ist, könnte man dessen Ausführung auch noch von einger gültigen Session abhängig machen.

4.) Da es nun möglich ist, Fehlversuche genau dem Sessionbesitzer zuzuordnen, könnte man nach z.B. 10 Fehlversuchen den Benutzer sperren.

5.) Schlussendlich könnte man die Ressourcelocators auch noch verschlüsseln, was dann aber zu extrem langen Ressourcekennungen (RUL-Encode lässt grüßen) führen könnte. Und die Sicherheit würde vermutlich aufgrund des ohnehin schon riesigen Namensvorrates nicht erhöht werden. Die Ergebnisse werden vermutlich ohnehin aus derselben Zielmenge stamnmen.

Was spart man dadurch?

• Keine zusätzlichen Datenbankzugriffe für Sekundärerequests nötig.
• Keine Instantiierung des Gesamtsystems bei jedem Sekundärrequest nötig.
• Kein Eingriff in die grundlegende Sicherheitsarchitektur des Systems nötig

Die Sessiondatei wird ohnehin geladen, die Datei mit den Hauptfunktionen auch. Man kann die Sekundärrequests auch mit einem Minimalskript abarebiten, das ausschließlich die Config-Dateien benötigt und die Session aufrufen muss, um festzustellen, ob die Gültig ist.

Leider hatte das Ganze so einfach doch eine Lücke. Die ältere Idee war besser!

Wenn man nicht will, dass für Subrequests auf authorisierte Elemente die ganze Abfrage wieder zur Verfügung stehen muss (Der Query-String müsste dann an jeder URL dranhängen und auch ausgewertet werden), dann hat man gar keine andere Wahl, als die authorisierten Elemente in der Session zu referenzieren.

Dann ist aber wieder die Frage, wie man mehrere Requests gleichzeitig bedient, oder ob man einfach die "authorised elements" solange in der Session hält, wie die gültig ist. Wenn der Besucher ein Bild auf Seite 12 authorisiert bekommen hat, warum sollte es ihm dann auf Seite 14 nicht mehr zur Verfügung stehen. Schließlich ist es dasselbe Bild und vermutlich auch dieselbe URL dafür?

Man könnte aber ggf. den "Elements-Translation-Table" bei jedem Request bereinigen und die zu alten Einträge wieder raussschmeißen.

Das bedeutet dann, dass jeder Primary-Request einheitlich Elemente authorisieren kann und auch die zu alten rausschmeißt. Das Abfragescript für Secondary-Requests würde dann nur einen einheitlichen Zugriff auf das jeweilige Element kennen, der immer per Mod-Rewrite auf ein Script umgeleitet wird, dass danach zu schauen hat, ob eine Session besteht, diese noch aktiv ist (die Sessiondatei darf durchaus noch Tage weiterbestehen), ggf. das Aufräumen vornimmt und schaut, ob das geforderte Element in der Authorisierungsliste steht und dieses dann ausliefert.

Ich habe den Themenbereich geändert, weil es eine Eigenart des HTTP-Protokolls und von HTML & Co. ist, dass man derartige Aufgabenstellungen lösen muss. Es würde bestimmt auch zu "PROGRAMMIERTECHNIK" passen, aber nicht ursprünglich.

Wäre wirklich mal toll, hier von Fachleuten durchdachte Diskussionsbeiträge zu meinen Gedanken zu bekommen. Und 'Ja!': Ich werde mich damit beschäftigen, wenn sie ausreichend verständlilch dargeboten werden und nicht einfach nur Brocken hingeworfen werden, deren Kontext ich nicht kenne und die nur zum Ausdruck bringen sollen, dass alles Quatsch sei, das ich mir ausdenke.

Das wäre dann keine Diskussion, das wäre Mobbing!

Ich habe dieses Forum mal vor über 10 Jahren kennengelernt - da war es für mich das beste von allen!

Spirituelle Grüße
Euer Robert

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Kennt einer diese Fehlermeldung?

  
Warning:  file_get_contents(http://example.org/fotos.php?id=56679):  
	failed to open stream:  
		Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden.  
 in C:\USER\RR\WebTests\Xampp\fsockopen\fotos.php on line 21  
  

Das Skript hat voerher und hinterher ganz normal weitergearbeitet.

Spirituelle Grüße
Euer Robert

[Camping_RIDER]

Aloha ;)

Kennt einer diese Fehlermeldung?

Nö.

Das Skript hat voerher und hinterher ganz normal weitergearbeitet.

Naja, das liegt daran, dass es nur eine WARNING ist und kein ERROR. Vielleicht findet sich ja jemand, der mehr Bescheid weiß als ich und dir sagen kann, wie du's behebst.

Wenn dir niemand beim Beheben helfen kann tuts im allergrößten Notfall (!) auch das @-Zeichen (Bitte: Das ist keine Empfehlung, die Warnung zu ignorieren. Nur ein letzter Ausweg...).

Grüße,

RIDER

[Robert R.]

Liebe Mitdenker Camping_RIDER,
liebe Wissende,
liebe Neugierige,

ja!

Aloha ;)

Kennt einer diese Fehlermeldung?

Nö.

Das Skript hat voerher und hinterher ganz normal weitergearbeitet.

Naja, das liegt daran, dass es nur eine WARNING ist und kein ERROR. Vielleicht findet sich ja jemand, der mehr Bescheid weiß als ich und dir sagen kann, wie du's behebst.

Wenn dir niemand beim Beheben helfen kann tuts im allergrößten Notfall (!) auch das @-Zeichen (Bitte: Das ist keine Empfehlung, die Warnung zu ignorieren. Nur ein letzter Ausweg...).

Das wäre dumm. Aber ich kann diplay_errors auf 0 setzen. Dann hätte ich nachher wenigstens noch die Meldungen im Log zur Auswertung. Der Fehler tritt auch nur selten auf und unregelmäßig, im Mittel vielleicht zu 0,1% der Abfragen oder weniger.

Mir geht es darum, WER für diese Fehlermeldung verantwortlich ist. Kann doch sein, dass es die Jungs und Mädels von Apachefriends waren. Ist schon ungewöhnlich, in PHP eine Fehlermeldung auf Deutsch zu bekommen.

Man könnte vielleicht die Sourcen mal danach durchsuchen. Hab ich aber total lange nicht mehr gemacht.

Spirituelle Grüße
Euer Robert

[M.]

Mahlzeit,

Das Skript hat voerher und hinterher ganz normal weitergearbeitet.

Es ist ja auch kein Fehler sondern eine Warnung. Und ich gehe davon aus, dass dein verwendeter Port schon in Benutzung ist.

[Robert R.]

Liebe(r) Mitdenker(in) M.,
liebe Wissende,
liebe Neugierige,

ja!

Das Skript hat vorher und hinterher ganz normal weitergearbeitet.

in einer Schleife, sechs Threads davon parallel.

Es ist ja auch kein Fehler sondern eine Warnung. Und ich gehe davon aus, dass dein verwendeter Port schon in Benutzung ist.

Ich kann das bei file_get_contents() doch gar nicht steuern, welchen Port ich für die _Response_ nutzen will. Da da mehrere solcher Abfragethreads parallel laufen, kann es selbstverständlich sein, dass die PHP-Entwickler ein Semaphor nicht beachten. Aber eigentlich wäre das für mich eine Aufgabe des OS, einen Port für die Response auf den Request per Socket zur Verfügung zu stellen.

Mich wundert besonders, dass diese Meldung auf Deutsch kommt und gar nicht so arrogant wie die sonstigen PHP-Fehlermeldungen klingt. Die muss sich also jemand anderes ausgedacht haben ;-)

Spirituelle Grüße
Euer Robert

[dedlfix]

Tach!

Mich wundert besonders, dass diese Meldung auf Deutsch kommt und gar nicht so arrogant wie die sonstigen PHP-Fehlermeldungen klingt. Die muss sich also jemand anderes ausgedacht haben ;-)

Erste Maßnahme bei unbekannten Fehlermeldungen: Kopieren und bei Google einkippen. Und siehe da, zu dem Text findet man eine Menge Ergebnisse, aber die aus dem .NET-Umfeld.

Wenn dir das nun noch nichts sagt, dann werden wohl größere Kanonen herangefahren werden müssen. Schau doch mal mit dem Leitungshai (Wireshark) nach, was da so alles passiert (gefiltert nach HTTP-Requests).

dedlfix.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Mich wundert besonders, dass diese Meldung auf Deutsch kommt und gar nicht so arrogant wie die sonstigen PHP-Fehlermeldungen klingt. Die muss sich also jemand anderes ausgedacht haben ;-)

Erste Maßnahme bei unbekannten Fehlermeldungen: Kopieren und bei Google einkippen. Und siehe da, zu dem Text findet man eine Menge Ergebnisse, aber die aus dem .NET-Umfeld.

Wenn dir das nun noch nichts sagt, dann werden wohl größere Kanonen herangefahren werden müssen. Schau doch mal mit dem Leitungshai (Wireshark) nach, was da so alles passiert (gefiltert nach HTTP-Requests).

Ich habe tatsächlich noch jemanden gefunden, der den gelichen Fehler beschreibt:

Google fand ziemlich weit hinten für mich:
http://compgroups.net/comp.unix.programmer/why-there-is-still-bind-error-address-al/305701

ganz unten auf der Seite geht es dann zur ausführlicheren Fehlerbeschreibung:
http://compgroups.net/comp.lang.ruby/-address-already-in-use-error-with-net-http/769179

Das erklärt mir zumindest, warum ich diese Fehlermeldung bisher nicht kannte.
Überlicherweise fahre ich das Tool viermal im Jahr auf einem Linux-Host in der Firma.
Nun bin ich ein paar Tage zuhause und der eine Kunde drängelt. Also hab ichs auf dem XAMPP auf Meinem alten Windows gestartet. Der kann erstmal nur sechs Requests gleichzeitig, ist grottenlangsam (ca. 4-5 Requests pro Sekunde und Thread) und Windows XP scheint dann vermutlich für diesen Fehler verantwortlich zu sein.

Wäre mal interessant zu wissen, ob ein neueres Windows den Fehler nicht mehr hat *feix*

Spirituelle Grüße
Euer Robert

[Auge]

Hallo

Warning:  file_get_contents(http://example.org/fotos.php?id=56679):

>   
> Das Skript hat voerher und hinterher ganz normal weitergearbeitet.  
  
Ist das im Original auch ohne Anführungszeichen geschrieben?  
  
Tschö, Auge  

-- 
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.  
Terry Pratchett, "Wachen! Wachen!"  
  
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}  
  
[Veranstaltungsdatenbank Vdb 0.3](http://termindbase.auge8472.de/)

[Robert R.]

Liebe(r) Mitdenker(in) Auge,
liebe Wissende,
liebe Neugierige,

ja!

Warning:  file_get_contents(http://example.org/fotos.php?id=56679):

> >   
> > Das Skript hat voerher und hinterher ganz normal weitergearbeitet.  
>   
> Ist das im Original auch ohne Anführungszeichen geschrieben?  
  
Das ist in der Fehlermeldung genau so geschrieben, eben nur mit der lokalen Domain, aber im Skript selbstverständlich mit Anführungszeichen. Sonst käme doch auch sowas wie "T\_CONSTAMT ENCAPSED STRING" oder so ähnlich...  
  
Mich wundert ohnehin, dass die Fehlermeldung auf Deutsch kommt. Ich verwende hier zum Testen einen Apache mit PHP-Modul im LAMPP-Paket. Die Meldung kann eigentlich nur von denen kommen, obwohl es auch diese kryptische andere Fehlermeldung gibt, deren Sprache ich mit nicht merken kann, wenn man an passender Stelle ein Semikolon vergisst.  
  
Google weiß darüber leider auch nichts.  
  
Spirituelle Grüße  
Euer Robert

-- 
Möge der Forumsgeist wiederbelebt werden!

[Auge]

Hallo

Warning:  file_get_contents(http://example.org/fotos.php?id=56679):

> > >   
> > > Das Skript hat voerher und hinterher ganz normal weitergearbeitet.  
> >   
> > Ist das im Original auch ohne Anführungszeichen geschrieben?  
>   
> Das ist in der Fehlermeldung genau so geschrieben, eben nur mit der lokalen Domain, aber im Skript selbstverständlich mit Anführungszeichen.  
  
Ok.  
  
Mal ganz doof gefragt: Darf `file_get_contents`{:.language-php} laut deiner PHP-Konfiguration überhaupt Netzwerkadressen ansprechen? Willst du den Inhalt von fotos.php überhaupt über das Netzwerk und nicht stattdessen über das lokale Dateisystem laden?  
  
Tschö, Auge  

-- 
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.  
Terry Pratchett, "Wachen! Wachen!"  
  
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}  
  
[Veranstaltungsdatenbank Vdb 0.3](http://termindbase.auge8472.de/)

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Warning:  file_get_contents(http://example.org/fotos.php?id=56679):

> > > >   
> > > > Das Skript hat voerher und hinterher ganz normal weitergearbeitet.  
> > >   
> > > Ist das im Original auch ohne Anführungszeichen geschrieben?  
> >   
> > Das ist in der Fehlermeldung genau so geschrieben, eben nur mit der lokalen Domain, aber im Skript selbstverständlich mit Anführungszeichen.  
  

> Mal ganz doof gefragt: Darf `file_get_contents`{:.language-php} laut deiner PHP-Konfiguration überhaupt Netzwerkadressen ansprechen? Willst du den Inhalt von fotos.php überhaupt über das Netzwerk und nicht stattdessen über das lokale Dateisystem laden?  
  
Der Wrapper für URL ist eingeschaltet. Und das ist auch so gewünscht:  
~~~apache
  
    php_flag allow_url_fopen = 1  
  

http://php.net/manual/de/filesystem.configuration.php#ini.allow-url-fopen
http://php.net/manual/de/ini.list.php
http://php.net/manual/de/wrappers.php

Der Einfachheit halber habe ich die Socketbenutzung nicht vernünftig programmiert, sondern dieses file_get_contents() benutzt. Da kann man dann selber leider nicht feststellen, in welcher Stufe des Zugriffs der Fehler auftritt.

Mir ging es um die Herkunft dieser witzigen Fehlermeldung.

Spirituelle Grüße
Euer Robert