Weblogs und andere Internetseiten mit RSS-Feed werden wieder geframt!

20. Dezember 2004 | Kategorien: Internetrecht

Nachdem dieses, m.E. unrechtmäßige, Vorgehen einiger Webmaster bereits einmal unterbunden wurde, geht nun ein weiterer Betreiber nach dem selben Prinzip vor: es werden mittels RSS-Dateien Seiteninhalte ausgelesen (wogegen ja überhaupt nichts spricht, ganz im Gegenteil) und die Überschriften der Beiträge werden tabellarisch und thematisch zusammengetragen (wogegen wiederum nichts spricht). Die Inhalte jedoch beim Anklicken der Überschriften in einem neuen Fenster geframt mit Werbeeinblendungen darzustellen ist schon ganz schön dreist. Es sollte doch jeder Seite selbst überlassen werden, ob und wie geworben wird.
Betroffen sind wiederum viele Weblogs sowie auch die FAZ, DIE WELT, das Handelsblatt, Der Spiegel, heise, ZDNet, das Bundesverfassungsgericht uvwm.

Wenn jemand eine Möglichkeit kennt, solche Nutzungen (vielleicht mittels einer .htaccess) auszuschließen, wäre ich für Anregungen dankbar. Ich bin auch gerne bereit, eine entsprechende Datei zu pflegen und zur Verfügung zu stellen.

Gefunden wurde die fragliche Seite übrigens von Alexander Hartmann.

Tags:

(20) Kommentar(e)

 

  1. ich habe bei alexander in den kommentaren eine möglichkeit aufgezeigt, wie man per .htaccess sowas unterbinden kann. würde auch mal helfend zur seite stehen. 😉

  2. Peter sagt:

    Mein Problem mit dem von Dir verlinkten .htaccess-Inhalt ist, dass mein Provider kein mod_rewrite unterstützt und ich eine .htaccess in dieser Form daher nicht nutzen kann.

    Ic habe deshalb bei selfHTML die .htaccess Instruktionen durchgesehen und danach eine (glaube ich) entsprechende .htaccess angefertigt und auf den Server gespielt. Leider war die Seite danach überhaupt nicht mehr erreichbar ?!

    # Datei zum Regeln von IP-Bereichen
    Order deny,allow
    Deny from .nachrichtenmann.de

    Leider weiss ich nicht woran es liegt…

  3. "Deny from" ist hier auch eine falsche anweisung. das betrifft nicht den ausschluss von referrern, sondern den ausschluss von providern oder IP-adressen, was nachrichtenmann.de in dem sinn ja nicht ist.

    du müsstest schon mod_rewrite dafür benutzen. eine andere lösung kenne ich bisher auch nicht, aber mit mod_rewrite klappt es wunderbar.

  4. Matthias sagt:

    # Kein Nachrichtenmann (81.209.184.216)
    Order deny,allow
    Deny from 81.209.184.216

    Das sollte an für sich schon funktionieren – allerdings nur zum Unterbinden des Auslesens der RSS-Datei.. dazu muss die .htaccess im Verzeichnis der vom Nachrichtenmann genutzen RSS-Datei liegen..

    Wenn du Zugriff auf die Apache-Logfiles hast, kannst du ja mal schauen, ob du die Anfrages des Nachrichtenmanns auf deine RSS-Datei findest..

  5. Peter sagt:

    Leider funktioniert es noch nicht so recht…

    Folgende Fehlermeldung:

    Internal Server Error
    The server encountered an internal error or misconfiguration and was unable to complete your request.

    Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

    More information about this error may be available in the server error log.

    Apache/df-exts 1.1 Server at http://www.muepe.de Port 80

  6. CK sagt:

    N-mann und die Ableger mit den verschiedenen Domainnamen setzen seit dem Sommer wohl einfach dasselbe Skript ein.

    Belustigend sind die rechtlichen Erlaeuterungen bei N-mann, die ausdruecklich die Uebernahme der Inhalte in fremde Frames verbieten.

    Neben der Ausblendung von N-mann und Konsorten aus der Referrer-Liste habe ich ein Modul geschrieben, das in meine Eintraege einen Hinweis auf den Ursprungsort einfuegt. Bei Klauern (z.B. kkndPunktde/recht.html) sieht man dann diesen Hinweis, wenn der Besucher mit der Maus ueber den Eintrag faehrt. Kode stelle ich gern zur Verfuegung.

  7. Matthias sagt:

    ..mhh, dazu fällt mir eigentlich nur ein, dass die .htaccess auf jeden Fall im ASCII-Mode hochgeladen werden muss..

    Ansonsten würd ichs auf den Provider schieben – fänd ich aber schwach, wenn ne .htaccess nicht zugelassen werden würde..

  8. Peter sagt:

    .htaccess-Unterstützung habe ich eigentlich schon bei meinem Provider.

    Habe ich es richtig verstanden, dass der alleinige Inhalt der .htaccess der Folgende ist:

    # Kein Nachrichtenmann (81.209.184.216)
    Order deny,allow
    Deny from 81.209.184.216

    Wie kann ich feststellen, ob mein FTP-Client in ASCII-Mode überträgt?

  9. Matthias sagt:

    ja, nur die drei Zeilen müssen rein..

    Meist gibt es bei FTP-Clients eine Option, die Datei im "Auto-Mode" upzuloaden – dann überprüft der FTP-Client anhand einer Liste mit Dateiendungen, ob die Datei als ASCII oder binär übertragen werden muss.

    Es gibt aber meist auch eine Option, mit der eine Datei manuell im ASCII-Mode hochgeladen werden dann..

    Wichtig ist auch zu prüfen, ob dein Provider nicht nur Passwort-Optionen in der .htaccess erlaubt, sondern auch eine Zugriffskontrolle über IP-Adressen..

    Zum überprüfen kannst du auch mal folgende .htaccess testen:

    # Passwortprüfung
    AuthType Basic
    AuthName "Passwortprüfung"
    AuthUserFile /
    require valid-user

    Wenn du jetzt deine Seite aufrufst, müsste ein Fenster aufgehen und du nach einem Passwort gefragt werden.. wenn das funktioniert, sind erweiterte Funktionen per .htaccess durch den Provider unterbunden, wenn es nicht funktioniert.. mhh.. hatte ich schon den ASCII-Mode erwähnt? ;-))

  10. Peter sagt:

    Das Fenster mit der Passwortabfrage ging auf…

  11. Matthias sagt:

    Dann hat dein Provider – warum auch immer – leider unterbunden, dass du per .htaccess die Zugriffe nach IP beschränktst.. zumindest wissen wir nun, woran’s liegt.. Na dann mal nen guten Start in den Dienstag!

  12. ck sagt:

    Alternativ: Ein Plugin/Modul als Blacklist-Sperre in Nucleus einstellen? Gibt’s doch bestimmt. Oder ging das auch nicht?

  13. Peter sagt:

    Ich werde mich im NucleusWiki nach einem entsprechenden PlugIn umsehen. Das dürfte wahrscheinlich das einfachste sein. In der Zwischenzeit werde ich überlegen, ob man diesen Schmarotzern nicht auch anders Herr werden kann als nur zu reagieren…

  14. CK sagt:

    Ich habe mir gestern so ein Plugin gebastelt; war nicht schwer. Perl – wenn’s Ihnen nuetzen koennte, schick ich es gern rueber.

  15. Peter sagt:

    @CK: Sehr gerne. Vielen Dank für die Hilfe!

  16. R. Langenhan sagt:

    @ CK: Lieber Herr Kochinke, ich hätte auch Interesse an dem Plug-In …

  17. ck sagt:

    Bereits abgesandt, doch eine professionellere Loesung findet sich hier: http://blosxom.ookee.com/bl

    Mich wuerde nicht wundern, wenn dieselbe Loesung auch in PHP usw. fuer andere Blog-Systeme verfuebar ist. Da sie auf eine einfache TXT-Datei zugreift, koennten wir Abwehrdaten blawg-gemeindeweit verwalten.

  18. CK sagt:

    skylab*akademie*de#~kollitsch#portaldemo/module#news#administration#index*php
    Die schon frueher aufgefallene Newsgrabber-Technik, scheinbar weiter ausgebaut. Ob sich dort Vergleichbares anbahnt?

  19. Peter sagt:

    Ich habe gerade ein weiteres Script gefunden, das ohne .htaccess und mod_rewrite läuft: http://www.qxm.de/webdesign
    Der Vorteil für mich ist, dass das Ganze in PHP geschrieben ist, und ich mich darin etwas besser auskenne, als in Perl.
    Ich werde über die Feiertage mal ein wenig ausprobieren (endlich mal ein wenig mehr Zeit) und die Ergebnisse dann berichten.

  20. BryanReads sagt:

    NFL Jerseys
    craCheap Jerseys china spjb d r d z

Antworten

Abmahnung Domain | Abmahnung wegen Markenrechtsverletzung | Domainpfändung | Domainrecht | Domains / Domainnamen | eCommerce | Markenanmeldung | Markenrecht | Traffic Protection | Uniform Domain Name Dispute Resolution Policy (UDRP) | usTLD Dispute Resolution Policy (usDRP)