Redirect Remover Problem

    Hallo!

    Ich habe bei meinem Firefox den Redirect Remover installiert, der seinen Dienst auch problemlos erfüllt. Nur ist mir jedoch bei Webseiten basteln eine Kleinigkeit aufgefallen:

    Und zwar habe ich ein Linkverzeichnis im CMS. Dabei generiere ich für jede Seite ein Thumbnail (bzw. cache das aus div. Thumbnaildiensten). Nun wird die Grafik wie folgt aufgerufen:

    thumb.php?url=aHR0cDovL2Fib25kYS5kZS8=

    Wobei aHR0cDovL2Fib25kYS5kZS8= eine mit base64 verschlüsselte URL ist (das mache ich um Überschneidungen bei der Übergabe mit meinen suchmaschinenfreundlichen Links zu verhindern). Ergo sieht der Quellcode so aus:

    <img src="thumb.php?url=aHR0cDovL2Fib25kYS5kZS8=" alt="">

    Wenn jetzt jedoch der Redirect Remover eingeschaltet ist, decodiert er mir (warum auch immer) den base64 Teil, und sieht den ganzen Link als nen Redirect. Ergo wird aus dem Quellcode:

    <img src="http://abonda.de/" alt="">

    und das Bild nicht angezeigt. Natürlich könnte ich jetzt den Redirect Remover deaktivieren. Das Problem wird nur jeder Benutzer sein, der den Redirect Remover eingeschaltet hat und von diesem Bug keine Ahnung hat, der wird die Thumbs entsprechend nicht sehen.

    Gibt es irgendeine Möglichkeit dies zu unterbinden!? Bzw. warum decodiert mir Firefox den String obwohl es gar nicht die Befugnis dazu hat!?

    Danke schonmal...

    Zunächst mal eine Frage:
    Hast Du bewusst einen neuen Thread aufgemacht oder hast Du den bestehenden solchen (Redirect Remover - neueste Entwicklungen) nur übersehen, obwohl er auf der ersten Seite steht (und bei mir zur Zeit direkt unter deiner Anfrage)?

    Zitat von FF

    Gibt es irgendeine Möglichkeit dies zu unterbinden!?

    Man kann die Seite zur Whitelist hinzufügen; man kann in den Einstellungen die Dekodierung für Grafiken deaktivieren (zumindestens in den neueren Versionen - ich weiß nicht, wie lange das schon so möglich ist.); Du könntest den Aufruf der Thumbnails bei dir anders lösen ...

    Zitat

    Bzw. warum decodiert mir Firefox den String obwohl es gar nicht die Befugnis dazu hat!?

    Der Witz ist gut - welche Berechtigung hat der Redirect Remover überhaupt, URIs zu ändern? Und warum setzt Du ihn dann ein?

    Da siehst du mal wie gut RDR ist :) Es erkennt versteckte URLs da, wo sie keiner vermutet.
    Wenn du dir nicht sicher bist, was du in die Ausnahmen hinzufügen sollst, rechtsklicke einmal auf das Bild und wähle "Eigenschaften" im Kontextmenü ("Properties" im Englischen Firefox). Dort gibt es ein eigenes "Kästchen" für RDR zu dem Bild. Dort klickst du auf den "Seite zu den Ausnahmen hinzufügen" Knopf (Button) und RDR fügt automatisch eine Ausnahme hinzu.

    RDR verhält sich übrigens genau wie jede x-beliebige Regierung: Es wird zwar durch das Volk (den User) legitimiert etwas zu tun, hinterher beschwert sich aber trotzdem jeder, dass sie etwas machen und wie sie es machen ;)

    Grüße
    xeen

    Habe nun die Verschlüsselung geändert. Damit sind die Grafiken sicher vorm RDR. Mir ging es wie bereits gesagt nicht um mich, sondern um meine Besucher. Ich kann es ja nun auch nicht jedem Besucher zumuten an seinen Einstellungen rumzuspielen, immerhin muß meine Seite von Grund auf benutzerfreundlich sein.

    Speravir: Als ich den Fred hier aufgemacht hab habe ich nicht gerade darüber nachgedacht ob es nict schon einen Sammelfred dafür gibt. Das mit der Befugniss ist folgendermaßen gemeint:

    http://www.domain.de/out.php?url=http://www.google.de

    Ist z.B. ein Redirect, darf auch geändert werden, und den nutze ich den RDR auch.

    http://www.domain.de/thumb.php?url=A7fA727fskAS7SasfaS8=

    Ist z.B. KEIN redirect und darf entsprechend auch nicht angepackt werden. Ich sage der thumb.php dass Sie das Thumb zu der entsprechenden Seite anzeigen soll und wenn keins vorhanden ist es eben eins erstellt. Die Verschlüsselung war deshalb drin, um Probleme mit den suchmaschinenfreundlichen Links zu verhindern. Nur habe ich nie vom RDR verlangt, dass es mir diese deschifriert. Daher also keine Befugnis.

    Wobei okay, das hier war nur ein Beispiel. Im grunde kann ich die Thumbs auch so aufrufen:

    http://www.domain.de/thumbs/A7fA727fskAS7SasfaS8=.png

    Und der RDR würde mir den verschlüsselten Teil entschlüssel und das ganze wieder als Redirect betrachten.

    Aber wie gesagt, habe nun die Verschlüsselung verändert, damit laufen nun auch die Thumbnails. Von daher:

    Thema erledigt! :)

    Was du angibst sind alles Umleitungen -- dass sie hier einen anderen Sinn haben kann RDR ja nicht riechen, von daher IST der Zugriff berechtigt. Nur weil du das in base64 enkodierst (verschlüsseln ist was anderes) und die Datei thumbs.php nennst ist das noch lange kein Grund dass das keine Umleitung ist.
    Und selbstverständlich hast du mit der Installation verlangt, dass RDR alle Links und Grafiken von Umleitungen bereinigt. Das steht so schon seit einiger Zeit in der Beschreibung auf addons.mozilla.org und auf der RDR Seite auf MozDev, von "ungefragt" kann also nicht die Rede sein.
    Von Verschlüsselung, Codierung und sonstigem Quatsch kann ich dir nur abraten. Sowas löst man zur Designzeit der Parent-Datei und übergibt der thumb.php nur einen Parameter. Jedes mal wenn ein Thumb neu erstellt wird, kriegt es eine neue ID. Das hat gegenüber komischen Verschlüsselungsverfahren auch den Vorteil, dass das Problem mit veraltetem Cache umgangen wird wenn sich das Thumbnail geändert hat.
    Und mich würde mal interessieren, welches Kodierungsverfahren du verwendest, damit ich es die nächste Version von RDR bereinigen kann :twisted:
    Grüße
    xeen

    Zitat von FF

    Habe nun die Verschlüsselung geändert. Damit sind die Grafiken sicher vorm RDR. Mir ging es wie bereits gesagt nicht um mich, sondern um meine Besucher. Ich kann es ja nun auch nicht jedem Besucher zumuten an seinen Einstellungen rumzuspielen, immerhin muß meine Seite von Grund auf benutzerfreundlich sein.

    Hach, sowas lese ich unheimlich gerne. Wenn das nur so manch anderer Seitenbetreiber auch kapieren würde.

    Zitat von xeen

    Und mich würde mal interessieren, welches Kodierungsverfahren du verwendest, damit ich es die nächste Version von RDR bereinigen kann :twisted:
    Grüße
    xeen

    Ich glaube dafür würden dich viele Leute erschlagen: MD5! :mrgreen:

    werden base64 kodierungen eigentlich tatsächlich öfter für redirects verwendet? wenn sie meistens eh nur false positives erzeugen, wäre es gut wenn man das ganze abschalten könnte.

    Also mir wäre es nicht bekannt dass überhaupt irgendwer die Kodierung für Redirects einsetzen würde. Ich habs auch nur benutzt um mögliche Probleme mit meinen Links zu verhindern.

    Zugegeben -- ich kenne auch keine Seite die base64 Links benutzt, allerdings habe ich diese Anforderung mehr als einmal bekommen es zu unterstützen.
    Ob base64 entfernt wird oder nicht macht meines Erachtens auch keinen Unterschied -- ich denke das Verhältnis ist hier genauso wie bei "normalen" Redirects auch. (Sprich: es gibt genauso viel gute wie schlechte Gründe base64 enkodierte Links zu verwenden). Wenn man dann der Begründung folgt, könnte man RDR auch gleich sein lassen, weil es IMMER false Positives geben wird (bzw. gute Gründe für die Verwendung von "Redirects").
    Der Vorteil der jetzigen Aufstellung ist, dass base64 Links im Bedarfsfall auf die Ausnahmen gesetzt werden können, die grundsätzliche Möglichkeit zur Reinigung aber besteht. Es andersherum zu implementieren ist viel aufwendiger, zumal RDR (offiziell) auch gar keine "Blacklist" bietet. Wie man "optionales base64" mit einer Ausnahmenliste realisieren soll weiß ich auch nicht. Deswegen lasse ich es so :)
    (Außerdem wird 2.6 ja sehr einfache Funktionen enthalten um "defekte Seiten" schnell zu reparieren).
    Grüße