Weiterleitung / Cloaking

[selfuser]

Hallo,

Zurzeit erstelle ich eine PDF-Datei, die mehrere Links enthält. Diese sollen jedoch nicht direkt zum Ziel führen, sondern

• da sich die Zieladressen ändern können - zuerst auf meine Website (ohne WordPress) und von dort aus weitergeleitet werden, damit man die Zieladressen bei Bedarf ändern kann und die PDF-Datei trotzdem noch weiter funktioniert. (In Zukunft wird es noch mehr derartige PDFs geben.)

Wie kann man das realisieren? Pro Link eine Weiterleitungsdatei oder besser eine Liste, die von einem Script verarbeitet wird...? (Meine Website habe ich bei HostGator.com.)

Vielen Dank!

[BaBa]

Hallo,

Wie kann man das realisieren?

Du musst Dir überlegen, wie Du a) die Info für die Zielressource an Deine Seite sendest und b) wie Du die Weiterleitung gestaltest.

Zu a) bspw:
www.example.domain/referrer?res=xla0shj (code über GET-parameter)
referrer.example.org/xla0shj (code als Adresse)
www.example.org/beispiel-fuer-ressource (wie 2.)

Zu b) bspw:
php-Header,
html Weiterleitung
Javascriptweiterleitung

Pro Link eine Weiterleitungsdatei

Nennen wir es mal "pro Link eine Weiterleitungsressource". Ja, das wäre eine Möglichkeit. Allerdings keine schöne, da blöd zu warten, etc.

oder besser eine Liste, die von einem Script verarbeitet wird...?

Das wäre doch schöner für Dich. Im Falle von 2b) müsstest Du dann eben nicht eine "echte" Resource xla0shj erzeugen, sondern nur alle Anfragen auf eine Resource (zum Beispiel index.php) umleiten, bspw. per .httaccess und mod-rewrite und dort die URL evaluieren und eine geeignete Weiterleitung ausgeben.

Cheers,
BaBa

[Gunnar Bittersmann]

@@BaBa

oder besser eine Liste, die von einem Script verarbeitet wird...? Das wäre doch schöner für Dich. Im Falle von 2b) müsstest Du dann eben nicht eine "echte" Resource xla0shj erzeugen, sondern nur alle Anfragen auf eine Resource (zum Beispiel index.php) umleiten, bspw. per .httaccess und mod-rewrite und dort die URL evaluieren und eine geeignete Weiterleitung ausgeben.

Du willst einen URL-Shortener. Jedenfalls etwas, was genauso funktioniert, selbst wenn die URLs bei dir nicht gar kurz sein sollten.

LLAP

[BaBa]

Du willst einen URL-Shortener.

So, wie ich den OP verstanden haben, können sich die targets ändern. Meines Wissens nach leistet ein URL-Shortener nicht, dass Du Verknüpfungen aktualisieren kannst. Außerdem bietet die Lösung auf dem eigenen Server die Möglichkeit die Klicks zu zählen, etc.

Cheers,
BaBa

[Jörg Reinholz]

Moin!

Du willst einen URL-Shortener. Meines Wissens nach leistet ein URL-Shortener nicht,

Die klassischen nicht. Aber ein selbst betriebener kann das wohl.

Dem TO (selfuser) würde ich zur Liste raten. etwas wie

ID;URL
1;http://forum.selfhtml.org/self/2015/apr/08/weiterleitung-strich-cloaking/1636614#m1636614

ist leicht und schnell zu verarbeiten. Zudem sollen ja eh noch Zugriffe gezählt werden e.t.c.

Jörg Reinholz

[selfuser]

Danke für eure Vorschläge! (Sorry für die späte Antwort, meine Festplatte wurde defekt und musste ausgetauscht werden!)

Nun habe ich entsprechend gesucht und schließlich ein interessantes Redirection-Script gefunden: https://gist.github.com/jdevalk/5622742 Was haltet ihr davon?

Ein Problem: wie kann ich die vorgeschlagene .htaccess Datei (5 Zeilen) mit meiner bestehenden...

<FilesMatch "\.(?i:pdf|mp4)$">
   Header set Content-Disposition "attachment"
</FilesMatch>

... vereinen?

Eine Frage noch, die den Betreiber der Seite betrifft, auf der der Link letztlich ankommt: Welche Informationen über die Herkunft des Ursprungs-Links sind bestimmbar? Ist es technisch möglich festzustellen, ob der Link z.B. in einer E-Mail, RTF-Datei oder auf einer Web-Seite geklickt wurde?

Danke nochmals!

[Camping_RIDER]

Aloha ;)

Danke für eure Vorschläge! (Sorry für die späte Antwort, meine Festplatte wurde defekt und musste ausgetauscht werden!)

Lustig. Genau das mache ich gerade im Moment auch.

Nun habe ich entsprechend gesucht und schließlich ein interessantes Redirection-Script gefunden: https://gist.github.com/jdevalk/5622742 Was haltet ihr davon?

Sieht ganz gut aus, eine gangbare Alternative, wenn mans nicht selberschreiben will.

Ein Problem: wie kann ich die vorgeschlagene .htaccess Datei (5 Zeilen) mit meiner bestehenden...

<FilesMatch "\.(?i:pdf|mp4)$">
   Header set Content-Disposition "attachment"
</FilesMatch>

... vereinen?

Den neuen Inhalt einfach hinten ran hängen :)

Eine Frage noch, die den Betreiber der Seite betrifft, auf der der Link letztlich ankommt: Welche Informationen über die Herkunft des Ursprungs-Links sind bestimmbar? Ist es technisch möglich festzustellen, ob der Link z.B. in einer E-Mail, RTF-Datei oder auf einer Web-Seite geklickt wurde?

Unter Umständen, ja. Je nachdem, ob und was der Browser des Users für einen Wert setzt, kann z.B. die PHP-Variable

$_SERVER['HTTP_REFERER']

die Seite, auf der der Link steht, enthalten.

Für dich als Betreiber der Seite ist das nicht zuverlässig, da der Wert ja im Browser gesetzt und damit manipulierbar oder unterdrückbar ist. Es kann also auch sein, dass da gar nix drinsteht.

Das gilt für den Fall eines Links auf einer Website. Die anderen von dir genannten Fälle sind u.U. noch ganz anders gelagert, weil die entsprechenden Leseprogramme, sobald du den Link klickst, erst den Browser öffnen, der im Normalfall dann wahrscheinlich nichts über den Ursprung des Links weiß. - Also eher im Ausnahmefall.

Wenn du Links über deine eigene Webseite leitest, wie beschrieben, ist es allerdings wahrscheinlich, dass der Betreiber der verlinkten Website in dieser Variable deine Website vorfindet, da die meisten User das senden des Referer nicht unterdrücken bzw. manipulieren, und egal wo der Link ursprünglich saß ist deine Website das, was der Browser direkt vor dem Aufruf des Linkziels zu Gesicht bekommen hat - wenn auch nur in Form einer Anweisung zur Weiterleitung.

Ich hoffe das beantwortet die Frage, ich weiß nämlich nicht genau worauf du rauswolltest.

Danke nochmals!

Gern geschehen :)

Grüße,

RIDER

[selfuser]

Danke für die hilfreiche Antwort!

https://gist.github.com/jdevalk/5622742 Was haltet ihr davon?

Sieht ganz gut aus, eine gangbare Alternative, wenn mans nicht selberschreiben will.

Um es selbst schreiben zu können fehlt es mir an Spezialwissen. Es ist nicht eine Frage des Wollens, sondern wäre einfach zu viel Aufwand für dieses Einzelprojekt.

Ich hoffe das beantwortet die Frage...

Ich verstehe es so, dass niemand genau sagen kann wo genau geklickt wurde.

... ich weiß nämlich nicht genau worauf du rauswolltest.

OK es geht um Amazon-TOS, und ob die Einhaltung dieser Bestimmungen überhaupt kontrollierbar ist, wie hier diskutiert:

http://www.warriorforum.com/main-internet-marketing-discussion-forum/956641-amazon-affiliate-links-email.html

... aber ich glaube das ist etwas off-topic hier, oder?

[Camping_RIDER]

Aloha ;)

Ich hoffe das beantwortet die Frage...

Ich verstehe es so, dass niemand genau sagen kann wo genau geklickt wurde.

Ja, fast. Genau sagen kann mans (manchmal) schon, nur eben nie sicher.

... ich weiß nämlich nicht genau worauf du rauswolltest.

OK es geht um Amazon-TOS, und ob die Einhaltung dieser Bestimmungen überhaupt kontrollierbar ist, wie hier diskutiert:

http://www.warriorforum.com/main-internet-marketing-discussion-forum/956641-amazon-affiliate-links-email.html

... aber ich glaube das ist etwas off-topic hier, oder?

Off-Topic gibts hier im Forum so gut wie nicht, Thread-Drift ist durchaus erwünscht und nicht verboten, deshalb auch die Möglichkeit, den Betreff und die Tags im Sub-Thread zu ädern.

Was deine Frage angeht: Ich gehe - ohne das zu wissen - eher davon aus, dass Amazon in diesem Fall auf die eigenen Möglichkeiten vertraut als auf die launischen technischen. Ich halte es für wahrscheinlicher, dass Amazon den speziellen Link, den du fürs Affiliate-Programm nutzt, intern deinem Amazon-Nutzerkonto zuordnen kann. Ich halte es also für wahrscheinlich, dass das Aufrufen eines Links, der per Affiliate-Programm zu Nutzer xyz gehört, immer die selbe Aktion auslöst, vollkommen unabhängig davon, auf welcher Seite sich der Link befand.

Ich zumindest würde es so machen, das verspricht viel genauere und zuverlässigere Auskunft.

Grüße,

RIDER

[selfuser]

Hallo Camping_RIDER, bist du noch da? (oder wer sonst helfen kann/möchte)

Ein paar kleine Fragen sind noch ungelöst bezüglich des erwähnten Redirection-Scripts https://gist.github.com/jdevalk/5622742 plus Beschreibung auf https://yoast.com/cloak-affiliate-links/ - das eigentlich aus 4 Dateien besteht (siehe unten im [out] Folder.

Meine Domains/Addon Domains und Seiten auf HostGator (www.hostgator.com, Business Plan, unlimited Domains) sind wie folgt strukturiert:

[public_html]
	index.html (one page website for domain1.com)
	[cgi-bin] (empty folder)
	[domain2.net]
		.htaccess
		index.html (one page website for domain2.net)
		favicon.ico
		[cgi-bin] (empty folder)
		[out]
			.htaccess
			robots.txt
			index.php
			redirects.txt
	[domain3.org]
		.htaccess
		index.html (one page website for domain3.org)
		favicon.ico
		[cgi-bin] (empty folder)
	...

Zu den 3 im Artikel vorgegebenen Dateien habe ich noch die angesprochene robots.txt im [out] Folder hinzugefügt:

user-agent: *
disallow: /out/

Alles scheint zu funktionieren, ich weiß nur nicht, ob WIRKLICH alles funktioniert...

1. Ist die robots.txt Datei so OK?
2. Ist es in Ordnung alle 4 Dateien im gleichen, einen Folder zu verwenden? (Dazu gabe es keine Hinweise in dem Artikel.)
3. Wirken sich .htaccess und robots.txt dann nur in diesem Folder aus?
4. Wirkt sich die höher liegende .htaccess (anderer Inhalt; im [domain2.net] Folder) auch auf den [out] Folder (darunter liegend) aus?
5. Sollte man robots.txt besser in [public_html] haben und von dort aus disallowed Folders für alle Domains definieren?
6. Eigentlich will ich immer nur, dass die index.html Dateien von den Robots registriert werden. Wie geht das am einfachsten?
7. Oder handelt es sich bei den Addon Domains um völlig unabhängige Bereiche und man muss einen robots.txt in jedem domainx.... Folder haben?
8. Letzte Frage (am Rande): Ich verstehe so einigermaßen, was in index.php passiert, aber was macht eigentlich diese RewriteRule in .htaccess?

Vielen Dank!

[Camping_RIDER]

Aloha ;)

Hallo Camping_RIDER, bist du noch da? (oder wer sonst helfen kann/möchte)

Ja, ich lebe noch :) Ich bin allerdings aktuell zu beschäftigt um regelmäßiger vorbeizuschauen, daher meine Passivität ;)

Alles scheint zu funktionieren, ich weiß nur nicht, ob WIRKLICH alles funktioniert...

1. Ist die robots.txt Datei so OK?

Soweit ich das beurteilen kann, ja. Bin da aber kein Experte. Ich interpretiere das, was im Wiki steht, so, dass das passt.

2. Ist es in Ordnung alle 4 Dateien im gleichen, einen Folder zu verwenden? (Dazu gabe es keine Hinweise in dem Artikel.)

Prinzipiell sehe ich da kein Problem. Aber...

3. Wirken sich .htaccess und robots.txt dann nur in diesem Folder aus?

...genau. Und da liegt sicher ein Problem. Das Wiki sagt mir:

Die robots.txt muss unter diesem Namen (alle Buchstaben klein geschrieben) im Wurzelverzeichnis der Web-Dateien der Domain abgelegt werden. Wenn Sie also einen Domain-Namen example.org haben, dann muss die robots.txt in dem Verzeichnis abgelegt werden, in dem auch die oberste Einstiegsdatei von www.example.org liegt. Der URI wäre also http://www.example.org/robots.txt. Nur so kann sie von Suchmaschinen-Robots, die das Projekt aufsuchen, gefunden werden. Quelle: Wiki

d.h. du darfst gerade die robots.txt eben NICHT in ein Unterverzeichnis legen. Was die htaccess angeht ist das in Ordnung (sofern sich die Regeln darin eben nur auf den Ordner "out" beziehen, denn...)

4. Wirkt sich die höher liegende .htaccess (anderer Inhalt; im [domain2.net] Folder) auch auf den [out] Folder (darunter liegend) aus?

...ja, ganz genau. .htaccess gilt immer für das aktuelle und alle darunter liegenden Verzeichnisse.

5. Sollte man robots.txt besser in [public_html] haben und von dort aus disallowed Folders für alle Domains definieren?

Nein. robots.txt ist eine "proprietäre" (wenn man das so nennen kann) Technik, die nicht standardisiert ist und insbesondere nicht von deinem Webserver verwaltet wird. Die Suchmaschinen fordern, wenn sie auf eine Domain zugreifen, die robots.txt an - sofern es diese gibt. Das bedingt, wie oben geschrieben, dass die robots.txt exakt im Wurzelverzeichnis der Domain liegt, die betroffen ist. Im drüberliegenden Verzeichnis hätte die Suchmaschine im Zweifelsfall ja auch keinen Zugriff auf die robots.txt

6. Eigentlich will ich immer nur, dass die index.html Dateien von den Robots registriert werden. Wie geht das am einfachsten?

Imho ist das auch im Interesse der Robots. Auf .htaccess kann der robot sowieso nicht zugreifen. Andere Dateien, z.B. eine index.php, kannst du natürlich per robots.txt ausschließen...

Disallow: /newsticker.shtml

...auch wenn ich mich immer frag, wem dieses extreme Rumgefummle am Suchmaschinen-Crawl-Verhalten wirklich was bringen soll ;) Sicherheitsrelevante Fragen dürfen sich sowieso nicht auf robots.txt verlassen (denn dessen Einhaltung ist rein freiwillig) und die Suchmaschinen wissen meist schon selber, was gut für sie ist...


> 7. Oder handelt es sich bei den Addon Domains um völlig unabhängige Bereiche und man muss einen robots.txt in jedem domainx.... Folder haben?

Ja. Siehe oben.


> 8. Letzte Frage (am Rande): Ich verstehe so einigermaßen, was in index.php passiert, aber was macht eigentlich diese RewriteRule in .htaccess?

RewriteRules in .htaccess biegen Anfragen auf ein Skript um. Z.B. könntest du wollen, dass dein Webserver alle Anfragen, die kommen, an ein Skript weiterleitet. Z.B. um die Ausgabe manipulieren zu können. So funktionieren AFAIK viele der sprechenden URL's, die man real oft sieht.

Beispiel: Anfrage an http://meineDomain.net/xyz/abc

1.: Ohne RewriteRule - der Webserver schaut ins Verzeichnis /xyz/abc, sucht dort nach einer index.html, einer index.php, (o.ä.) und liefert das dann aus

2.: Mit RewriteRule vom Verzeichnis /xyz auf das Skript /php/output.php - der Webserver bemerkt die RewriteRule und schaut überhaupt nicht ins Verzeichnis /xyz/abc, sondern führt das Skript /php/output.php aus. Das kennt den ursprünglichen URI und kann seine Ausgabe daran entsprechend anpassen. Das Verzeichnis /xyz/abc muss - obwohl der User sich scheinbar darin befindet - nicht mal existieren. Auch bei einem Aufruf von /xyz/def landet die Anfrage wieder bei besagtem Skript.

Die RewriteRules können beliebig komplex oder allgemein sein, das kommt auf die konkrete Anwendung an. Sie können nur Anfragen mit bestimmten Dateiendungen abfangen, oder Anfragen auf bestimmte Verzeichnisse, oder eben - alles ;)


> Vielen Dank!

Gern geschehen.

Grüße,

RIDER



-- 
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
  
Erreichbar meist Mittwochs ab 21 Uhr im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem [eigenen TeamSpeak-Server](http://www.tsviewer.com/index.php?page=ts_viewer&ID=1060332) (fritz.campingrider.de). 
  
  
# [Facebook](http://www.tsviewer.com/index.php?page=ts_viewer&ID=1060332) # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) #
  
  
 ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[

[selfuser]

Danke für die Hilfe!

1. Ich habe nun robots.txt ins Root verschoben. Da wahrscheinlich noch einige "disallow" Folder dazu kommen werden (und ich nicht die ganze Liste in robots.txt veröffentlichen möchte), habe ich es nun allgemeiner formuliert (es soll ja nur index.html zugänglich sein):

user-agent: *
disallow: /
allow: /index.html

Im Wiki habe ich zwar gelesen, dass "allow" nicht definiert ist (?), aber bei Google gibt's das (inzwischen?) schon. Ist es dann so OK?

2. Die Verwendung von RewriteRule... via .htaccess in Verbindung mit dem Redirect-Script wurde aus Sicherheitsgründen empfohlen. Ich denke ich verstehe, was du allgemein übers Abbiegen schreibst, kann in meinem Beispiel aber nicht nachvollziehen, was in meinem Fall abläuft. Es sind diese wenigen Zeilen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^index\.php$ - [L]
RewriteRule (.*) ./index.php?id=$1 [L]
</IfModule>

Es ist doch alles im gleichen Folder. Man kommt über einen Link wie http://www.meineDomain.net/go/parameterxyz zum Redirect-Script index.php. Was ändert sich durch RewriteRule... daran? Oder was verbessert sich dadurch bzgl. der Sicherheit?

Ich sehe, dass es funktioniert, aber ich wüsste gern, was da genau abläuft.

Danke nochmals.

[Camping_RIDER]

Aloha ;)

Im Wiki habe ich zwar gelesen, dass "allow" nicht definiert ist (?), aber bei Google gibt's das (inzwischen?) schon. Ist es dann so OK?

Allow macht halt keinen so rechten Sinn, denn es ist ja gerade der Sinn einer robots.txt etwas zu verbieten, erlaubt ist per se ja alles, was nicht verboten ist (zumindest in der Denke einer Suchmaschine :D).

Trotzdem, wie gesagt. robots.txt ist nicht standardisiert, und wenn Google was Bestimmtes interpretiert und du Wert auf Googles Behandlung deiner Seite legst, spricht nichts dagegen das auch zu benutzen.

Ich denke ich verstehe, was du allgemein übers Abbiegen schreibst, kann in meinem Beispiel aber nicht nachvollziehen, was in meinem Fall abläuft.

Kein Ding, ich klamüser dir das auseinander. Weiterführende Lektüre mit Syntax und allen verfügbaren Befehlen: http://httpd.apache.org/docs/current/mod/mod_rewrite.html

<IfModule mod_rewrite.c>

Wenn das rewrite-Modul im Apache-Server verfügbar ist...

RewriteEngine On

Starte den Umleitungs-Sklaven :)

RewriteRule ^index\.php$ - [L]

RewriteRule erwartet einen regulären Ausdruck, mit dem die aufgerufene Addresse verglichen wird, dann eine Addresse, zu der im Match-Fall umgeleitet wird, und dann optional Flags.

Im Einzelnen:

^index\.php$

Dieser Ausdruck passt auf alle Aufrufe, deren (zum Domain-Root relativer) URI mit index.php beginnt (^) und endet ($). Der Backslash dient lediglich der Maskierung des ".", der in regulären Ausdrücken ansonsten eine Spezialbedeutung hätte.

-

Hier würde normalerweise die URL stehen, auf die intern umgeleitet wird. Hier steht ein "- (dash)", das bedeutet quasi "tu nichts". Im Klartext werden also Aufrufe, die direkt an /index.php gehen, eben NICHT umgeleitet, sondern durch diese Regel extra von der Umleitung ausgenommen.

[L]

Das L-Flag bedeutet: "Wenn die Regel zutrifft, überprüfe keine weitere Regel mehr - beende den Rewrite-Prozess sofort". Das ist nötig, um eben genau zu erreichen, dass die erste Regel eine Ausnahme von der zweiten ist (denn wenn die erste passt sorgt dieses Flag dafür, dass die zweite nicht angewandt wird).

RewriteRule (.*) ./index.php?id=$1 [L]

Okay. Wenn diese Regel zur Anwendung kommt, dann ist die Addresse nicht /index.php gewesen (Erklärung siehe oben).

Der Reguläre Ausdruck ist

(.*)

Das heißt jedes beliebige Zeichen (.) unendlich oft hintereinander (*), matcht also schlicht und ergreifend ALLES. Die Klammern sorgen dafür, dass der Server sich den gematchten Ausdruck intern "merkt", damit man ihn nachher wiederverwenden kann.

Jede Klammer bedeutet eine Variable die man später verwenden kann, und zwar mit $1, ..., $9

Umgeleitet wird auf...

./index.php?id=$1

...das Skript index.php (das wir aus diesem Grund mit der ersten Regel ausnehmen mussten, weil ansonsten Endlosschleife und so). Desweiteren geben wir dem Skript einen GET-Parameter namens "id" mit und füllen ihn mit der ursprünglich aufgerufenen Addresse (die ja dank der Klammern im regulären Ausdruck in $1 gespeichert ist).

Zu guter Letzt folgt wieder das L-Flag, das hier dafür sorgt, dass auf keinen Fall eine weitere Regel "dazwischenfunkt". Könnte man an der Stelle imho aber auch weglassen.

</IfModule>

Naja. Ende vom IF eben ;)

Es ist doch alles im gleichen Folder. Man kommt über einen Link wie http://www.meineDomain.net/go/parameterxyz zum Redirect-Script index.php. Was ändert sich durch RewriteRule... daran? Oder was verbessert sich dadurch bzgl. der Sicherheit?

Naja, RewriteRule hat den Vorteil, dass es keine wirkliche Umleitung, sondern nur eine Art interne Umleitung ist. Der User bleibt mit dem Browser (anders als bei einer wirklichen Umleitung) auf der Addresse, die er aufgerufen hat. Die Ausgabe wird aber intern durch index.php generiert (und nicht durch ein statisches File http://www.meineDomain.net/go/parameterxyz wie der User vermuten würde) - dass ein "index.php" tätig wird, bekommt der User also gar nicht mit.

Das ist einerseits ein Sicherheitsfeature (wenn alle Aufrufe durch ein PHP-Skript laufen müssen, bei dem Sicherheitsabfragen vorgenommen werden können), andererseits ein Komfortfeature (der User muss nicht http://www.meineDomain.net/files/id1123462354.html im Browser öffnen, sondern hat eine schöne URL http://www.meineDomain.net/Katzen/Bilder, obwohl da inhaltlich auch nur das durch index.php gemapte http://www.meineDomain.net/files/id1123462354.html drinsteckt).

Außerdem nützt es der Sicherheit gemäß dem Konzept Security by Obscurity, da ein potenzieller Angreifer von deinen URLs nicht auf die Dateistruktur auf deinem Server schließen kann.

Ich sehe, dass es funktioniert, aber ich wüsste gern, was da genau abläuft.

Na, alle Klarheiten beseitigt? :)

Grüße,

RIDER

[selfuser]

Kein Ding, ich klamüser dir das auseinander.

Also Camping-RIDER, das war ja wirklich erstaunlich und umfassend! :-)

UND ich konnte sogar folgen. Ein nützliches Script, finde ich.

Weiterführende Lektüre mit Syntax und allen verfügbaren Befehlen...

Weiterführende Lektüre würde zu weit führen. Ich fühle mich nun rundum informiert. 100%.

Danke für die große Mühe!