Ankündigung

Einklappen
Keine Ankündigung bisher.

htaccess-Code gegen Hotlinking

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #31
    Zitat von Martin11 Beitrag anzeigen
    Folglich müsste ich bis zur eigenen https-Umstellung die erste Referrerzeile eigentlich auskommentieren, ansonsten kann fast jeder Hotlinking betreiben. Oder gibt es eine Code-Möglichkeit, beides abzudecken: Egal, ob Referrer vorhanden oder nicht, das Rewrite soll in jedem Fall immer greifen? Oder existiert diese Möglichkeit bereits durch das Auskommentieren/Verzichten auf die Referrerzeile, d.h., es wird beides abgedeckt?
    Es kann wie gesagt auch andere Gründe geben. Entscheidet sich jemand, den Refer(r)er zu blocken (also z. B. in der Browserkonfiguration zu deaktivieren), weil er meint, dass es einen Websitebetreiber einen feuchten Käse angeht, über welchen Link er auf die Site gekommen ist, ist das IMHO völlig legitim. Dieser Besucher würde dann aber auch auf Deiner Site keine Bilder sehen. Das mag nur wenige Besucher betreffen, ist aber der Grund dafür, einen leeren Referer immer zuzulassen, auch wenn man dadurch ein paar unerwünschte Zugriffe in Kauf nimmt.

    Entscheiden kannst Du das natürlich selbst.

    Bleibt die Zeile auskommentiert, hast Du ja genau das, was Du beschreibst - die Bilder werden auch dann geblockt, wenn der Referer leer bleibt. Dass das funktioniert, hast Du ja bereits ausprobiert.

    Zitat von Martin11 Beitrag anzeigen
    2. Mit aktivierter Referrerzeile würde der Code dann das Hotlinking wie gewünscht unterbinden, wenn ich von einer anderen http-Site von mir mich selbst testweise "hotlinken" würde. Oder gibt es noch einen anderen Grund, warum das dann trotzdem nicht klappen sollte?
    Mir fällt kein anderer Grund ein.

    Aber masterframe hat natürlich Recht - ein Zertifikat kostet nicht die Welt, also warum gönnst Du Dir nicht einfach eines?

    Gruß
    Jan
    Two hours of trial and error can save ten minutes of manual reading.

    Kommentar


      #32
      Zitat von Enigma Beitrag anzeigen

      Es kann wie gesagt auch andere Gründe geben. Entscheidet sich jemand, den Refer(r)er zu blocken (also z. B. in der Browserkonfiguration zu deaktivieren), weil er meint, dass es einen Websitebetreiber einen feuchten Käse angeht, über welchen Link er auf die Site gekommen ist, ist das IMHO völlig legitim. Dieser Besucher würde dann aber auch auf Deiner Site keine Bilder sehen. Das mag nur wenige Besucher betreffen, ist aber der Grund dafür, einen leeren Referer immer zuzulassen, auch wenn man dadurch ein paar unerwünschte Zugriffe in Kauf nimmt.

      Entscheiden kannst Du das natürlich selbst.

      Bleibt die Zeile auskommentiert, hast Du ja genau das, was Du beschreibst - die Bilder werden auch dann geblockt, wenn der Referer leer bleibt. Dass das funktioniert, hast Du ja bereits ausprobiert.

      Verstehe. Dann habe ich die Wahl zwischen auskommentierter Zeile mit umfassendem Hotlinking-Schutz, aber evtl. einige wenige Besucher, die ihren Referer absichtlich deaktiviert haben und dann keine Bilder sehen. Wobei meine Klientel wenig technikaffin ist und ich nicht glaube, dass das nennenswert viele wären. Vielleicht einige ganz wenige, die im Browser ein Add-On nutzen, das per einfachem Klick solche Einstellungen zwecks Datenschutz herstellt.
      Oder mit aktivierter Zeile, aber dann habe ich, solange ich http habe, praktisch keinen Hotlinking-Schutz und könnte mir das Ganze auch gleich sparen.

      Zitat von Enigma Beitrag anzeigen



      Aber masterframe hat natürlich Recht - ein Zertifikat kostet nicht die Welt, also warum gönnst Du Dir nicht einfach eines?
      Im Tarif ist nur eines dabei und ich habe drei Sites. Wenn, dann möchte ich alle drei auf https umstellen. Da mein Tarif (als einziger) kürzlich teurer geworden ist, was mich ein wenig ärgert, geht es mir gegen den Strich, jetzt auch noch Zertifikate dazu zu kaufen, zumal es die mittlerweile bei fast allen Hostern im Tarifpaket mit dazu gibt (also mehr als nur eines).

      Der wichtigere Grund ist aber, dass ich mich dann als Webmaster und Techniklaie mit der Umstellung wieder mit der ganzen Thematik auseinandersetzen muss, insbesondere: Wo muss oder sollte ich meine URLs (und Codes) auf https anpassen. In Frage kommen hier:
      - htaccess
      - Wordpress-Einstellungen
      - Theme-Einstellungen
      - DF-Einstellungen im Kundenmenü
      - robots.txt
      - in der Webseiten selbst
      - Google Search Console
      + weitere? Das sind nur die Sachen, die mir jetzt ganz spontan einfallen. Wahrscheinlich kann ich an vielen Stellen http lassen, an einigen kann ich es belassen, aber es wäre vielleicht besser, manuell auf https anzupassen, z.B. Verlinkungen zwischen meinen Seiten.
      Alleine das alles rauszufinden, ist schon wieder ein Act für mich. Das werden dann ungefähr fünf solcher langer Forumsdiskussionen , mit Ausprobieren und Hin und Her, weil dann doch etwas nicht gleich klappt usw. usw.

      Und das alles, obwohl ich eh schon am Überlegen bin, den Hoster zu wechseln... und dort dann wieder eine ganz andere Zertifikate-Situation hätte. Das wäre dann der dritte Grund, wobei mir das im Moment auch zu viel Stress ist.
      Grüße,

      Martin

      Kommentar


        #33
        So, ich hab's jetzt mal mit auskommentierter Referrerzeile gemacht, damit der Hotlinkingschutz umfassend gilt.

        Ich hätte noch zwei Verständnisfragen, also falls du noch da bist, Enigma und Lust hast.

        1. Erfasst der Code entsprechend der "Conditions" eigentlich nicht alle Anfragen, anstatt sich nur auf Bilder zu beschränken?
        Müsste man da eigentlich nicht am Anfang eine Bedingung haben, die besagt "wenn Anfragen für Bilder (.jpg ect.) kommen"?
        Ich sehe schon, dass das in der RewriteRule am Schluss mitdrinsteckt, fände es aber irgendwie naheliegend, das (auch oder stattdessen) in den Conditions zu haben.

        2. Müsste der Code nicht eigentlich auch bei Bilderanfragen von normalen Besuchern greifen?
        Es gibt so Analysetools wie ScreamingFrog, die die Website crawlen und statistisch auswerten. Die Bilder haben da alle ein 403. Das Tool betreibt kein Hotlinking in dem Sinne, sendet aber natürlich Bilderanfragen an den Server.

        Das bringt mich auf Folgendes: Wenn der htaccess-Code im Grunde bei "allen Bilderanfragen an den Server" greift , was ist dann der Unterschied zu all den Bilderanfragen, die von ganz normalen Besuchern im Web kommen? Ich habe ein paar Ausnahmen definiert, o.k., aber es gibt ja viele Wege, wie und von wo die Seiten mit den Bilder-URLs aufgerufen werden können. Manche klicken z.B. auf irgendeiner Site einen Link zu mir, manche tippen die URL manuell in den Browser, manche kommen über kleine unbekannte Sumas, manche nutzen Bookmarks usw. usw. Und es ist immer die gleiche Bild-URL, mit der am Server angefragt wird...

        Wo ist mein Denkfehler und warum bestätigt ScreamingFrog meinen Denkfehler?
        Zuletzt geändert von Martin11; 22.11.2019, 13:01.
        Grüße,

        Martin

        Kommentar


          #34
          Ich glaube, ich habe meinen Denkfehler zur 2. Frage gerade selbst entdeckt: Normale Besucheranfragen gelten zunächst mal der Seite, also der Seiten-URL, nicht direkt den Bilder-URLs. Zwar werden dann im nächsten Schritt die Bilder-URLs aufgerufen, aber das kommt dann sozusagen von mir selbst und ist von der ersten Ausnahme im Code erfasst.
          ScreamingFrog wird vermutlich die Seite aufrufen, die Bilder-URLs feststellen und dann gesondert diese über deren Bilder-URL aufrufen wollen. Dieser gesonderte Aufruf ist dann eine direkte Serveranfrage von außen und ergibt 403. Vermute ich.
          Grüße,

          Martin

          Kommentar


            #35
            Zitat von Martin11 Beitrag anzeigen
            1. Erfasst der Code entsprechend der "Conditions" eigentlich nicht alle Anfragen, anstatt sich nur auf Bilder zu beschränken?
            Müsste man da eigentlich nicht am Anfang eine Bedingung haben, die besagt "wenn Anfragen für Bilder (.jpg ect.) kommen"?
            Ich sehe schon, dass das in der RewriteRule am Schluss mitdrinsteckt, fände es aber irgendwie naheliegend, das (auch oder stattdessen) in den Conditions zu haben.
            Du könntest das einfügen, aber das hätte keinen Mehrwert. Die RewriteRule regelt das, und da die RewriteCond-Zeilen extrem schnell abgearbeitet werden, macht das auch performancemäßig kaum einen Unterschied. Möchtest Du partout wenige (!) Millisekunden einsparen, könntest Du als erste Zeile des Blocks

            Code:
            RewriteCond %{REQUEST_URI} \.(jpe?g|png|gif|svg|pdf|mp3)$ [NC]
            hinzufügen. Damit Du bei Änderungen (z. B. beim Hinzufügen weiterer Dateiendungen) nicht immer zwei Zeilen ändern musst, solltest Du die RewriteRule dann in

            Code:
            RewriteRule ^.*$ - [F]
            ändern. Falls Du die bisherige Variante beibehalten möchtest, solltest Du übrigens vorsichtshalber das NoCase-Flag zur RewriteRule hinzufügen (habe ich bisher übersehen):

            Code:
            RewriteRule \.(jpe?g|png|gif|svg|pdf|mp3)$ - [NC,F]
            Zitat von Martin11 Beitrag anzeigen
            2. Müsste der Code nicht eigentlich auch bei Bilderanfragen von normalen Besuchern greifen?
            Diese Frage hast Du Dir ja bereits selbst beantwortet.

            Gruß
            Jan
            Two hours of trial and error can save ten minutes of manual reading.

            Kommentar


              #36
              Zitat von Enigma Beitrag anzeigen

              Du könntest das einfügen, aber das hätte keinen Mehrwert. Die RewriteRule regelt das, und da die RewriteCond-Zeilen extrem schnell abgearbeitet werden, macht das auch performancemäßig kaum einen Unterschied. Möchtest Du partout wenige (!) Millisekunden einsparen, könntest Du als erste Zeile des Blocks

              Code:
              RewriteCond %{REQUEST_URI} \.(jpe?g|png|gif|svg|pdf|mp3)$ [NC]
              hinzufügen. Damit Du bei Änderungen (z. B. beim Hinzufügen weiterer Dateiendungen) nicht immer zwei Zeilen ändern musst, solltest Du die RewriteRule dann in

              Code:
              RewriteRule ^.*$ - [F]
              ändern. Falls Du die bisherige Variante beibehalten möchtest, solltest Du übrigens vorsichtshalber das NoCase-Flag zur RewriteRule hinzufügen (habe ich bisher übersehen):

              Code:
              RewriteRule \.(jpe?g|png|gif|svg|pdf|mp3)$ - [NC,F]
              Nein, um die Millisekunden geht es mir nicht, dann lasse ich das so, wie es offenbar auch alle anderen haben.
              Mir schien es nur irgendwie logischer, das in die Bedingungen reinzupacken, um von vorneherein alle anderen (nicht anvisierten) Anfragen aus dem Spiel rauszunehmen.

              Das NoCaseFlag nur bei der RewriteRule ergänzen?
              Was ich auf die Schnelle gegoogelt habe: deckt den nicht auszuschließenden Fall ab, dass die URL in Großbuchstaben ankommt?



              Wegen der 2. Frage: Das ist "aktives Lernen" , für das ich noch nicht zu alt bin. Laut sprechen und schreiben aktiviert mehr Verknüpfungen im Gehirn und so bin ich irgendwie drauf gekommen, kurz nach dem Schreiben und nochmal Lesen.
              Da mir der Ablauf einer Serveranfrage als autodidaktischer Gelegenheitswebmaster aber nicht geläufig ist, war es nur eine Vermutung.

              Grüße,

              Martin

              Kommentar


                #37
                Zitat von Martin11 Beitrag anzeigen
                Das NoCaseFlag nur bei der RewriteRule ergänzen?
                Ja, die RewriteCond-Zeilen haben es schon.

                Zitat von Martin11 Beitrag anzeigen
                Was ich auf die Schnelle gegoogelt habe: deckt den nicht auszuschließenden Fall ab, dass die URL in Großbuchstaben ankommt?
                Ja, in diesem speziellen Fall werden somit auch Dateien abgedeckt, deren Dateierweiterungen Großbuchstaben enthalten.

                Gruß
                Jan
                Two hours of trial and error can save ten minutes of manual reading.

                Kommentar


                  #38
                  Okidoki, danke für deine Geduld.
                  Grüße,

                  Martin

                  Kommentar

                  Lädt...
                  X