[gelöst] "file:" blocken

  • Der Titel sagt eigentlich schon alles :wink:

    Bei einem LTSP Projekt, soll dem User das aufrufen der Struktur und einzelner Datein durch den Firefox verboten werden.

    Einträge in der user.js mit network.protocol-handler.externel.file zeigte keine Wirkung.
    Die Google Suche blieb bis jetzt erfolglos...

    Hoffentlich kann mir einer helfen
    greetz Fred

    Einmal editiert, zuletzt von ich-fred (7. Januar 2008 um 08:06)

  • Spontaner Vorschlag: file:// als AdBlock Plus-Filter hinzufügen.

    Theoretisch könnte man auch den Registry-Schlüssel HKEY_CLASSES_ROOT\file umbenennen (nicht löschen), aber das führt wahrscheinlich zu Komplikationen mit lokalen Programmen, die den IE-Renderer verwenden. Ich rate davon eher ab.

  • Vielen Dank für diese schnelle Antwort. Ich muss noch hinzufügen, dass es sich um einen Firefox unter Ubuntu handelt (also fällt der Registry Eintrag schon mal weg :D )
    So, ich habe mal eben schnell AdBlock installiert. Leider blockt es nicht file// :?

    greetz Fred

  • Zitat von ich-fred

    So, ich habe mal eben schnell AdBlock installiert. Leider blockt es nicht file//


    ... vielleicht Doppelpunkt: file:// vergessen?

    ... und vielleicht auch mal mit NoScript versuchen!?

    Gruß - doubletrouble

    "Der Kopf ist rund, damit das Denken die Richtung wechseln kann." (Francis Picabia)

  • hmm... nein der ":" hat nicht gefehlt , also im AdBlock.. nicht im Post :D

    Bei NoScript konnte ich leider keine Einstellungsmöglichkeiten dies bezüglich entdecken...

    greetz Fred

  • ich-fred schrieb:

    Zitat

    Bei einem LTSP Projekt, soll dem User das Aufrufen der Struktur und einzelner Datein durch den Firefox verboten werden.


    Dürfen wir davon ausgehen, dass Du Dich im Zuge dieses "Linux Terminal Server Projekts" innerhalb eines geschlosenen GNU/Linux Netzwerks wähnst? Dann hätte sich Deine Frage netzwerktechnisch eigentlich schon von selbst beantwortet.

    Abhilfe könnte z.B. durch vorgeschaltete routergesteuerte Netzwerk-Selektoren (z.B. Firewalls) erfolgen - und zwar Netzfilter, die nicht nur die TCP/UDP-Ports zu blocken vermögen, sondern darüberhinaus auch noch Informationen aus der Schicht 7 (OSI) "abgeifen" können, die normalerweise über separate Filter-Proxies gelenkt werden müssen. Über ein Blacklisting-Verfahren könntest Du somit einen allgemeingültigen Filterstamm erstellen - Je nachdem, was Du planst...

    Sofern jedoch an den einzelnen Stationen verschiedene Nutzer arbeiten sollen, kann es m. A. nach schwierig werden eine allg. Firewall-Regelbasis für alle Benutzer und Gruppen anstelle von Quell-IP-Adressen als Kriterium zu verwenden und darüberhinaus auch noch die bereits genannten Layer-7-Daten mit einzubeziehen.

    Schau mal hier und da:
    http://www.linux-tip.net/cms/content/view/277/27/
    http://www.tecchannel.de/netzwerk/manag…187/index2.html

    Ich glaube jedoch kaum, dass alleine der FF (und seine Erweiterungen) Deinen Ansprüchen dabei gerecht werden könnte.


    Oliver

  • ich frage mich, ob man überhaupt file:// blocken kann beim FX, denn die chrome etc.. Dateien des FX sind doch auch nix
    anderes als file-dateien ? *grübel*

    ...:AOD:...

    HP Chromebook 15a-nb0225ng, i3N-305, 8 GB LPDDR5-4800 MHz RAM (integriert), 256GB UFS, - chromeOS 132 (Stable Channel) - Linux Debian Bookworm: Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)

  • *vornkopphau* ne iss klar ;)

    chrome:// /= file://

    Manchmal sieht man den Wald vor lauter Bäumen nicht mehr ...

    ...:AOD:...

    HP Chromebook 15a-nb0225ng, i3N-305, 8 GB LPDDR5-4800 MHz RAM (integriert), 256GB UFS, - chromeOS 132 (Stable Channel) - Linux Debian Bookworm: Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)

  • so aufgepasst... hier kommt die sensationelle Lösung:

    man sucht sich den Firefox-"Haupt"Ordner .
    Unter Ubuntu etwa da:
    -> /usr/share/firefox/

    dort ist ein Ordner namens "chrome". In diesem befindet sich eine browser.jar. Diese muss man mit einem Archivprogramm öffnen.

    Darin findet man folgende Ordnerstruktur mit der browser.js :
    -> content/browser/browser.js

    Diese browser.js Datei mit einem Editor seines Vertrauens öffnen.
    Dort mussm an nach:
    -> "onLocationChange : function(aWebProgress" suchen und bis ans Ende scrollen.

    Am Ende der Funktion steht etwas von:
    -> setTimeout("updatePageTheme();", 0);

    Hinter dieser Zeile schreibt man nun folgende Anweisung (aber immer noch innerhalb der function"}"):

    Code
    if ((!location.match(/file:\/\/\/\/pfad\/zu\/einer\/Denied.html/) && location.match(/^file:/)) ||
    location.match(/^\//) ||
    location.match(/^resource:/) ||
    (!location.match(/^about:blank/) && location.match(/^about:/)))
    {
    loadURI("file:////pfad/zu/einer/Denied.html");
    }

    Das funktioniert wunderbar und kann beliebig erweitert werden...
    Die Idee wurde so über die Zeit auf MozillazineForum entwickelt...

    greetz Fred

  • Und beim nächsten Update macht man das ganze wieder von vorne ..
    Da die browser.jar bei einem Update überschrieben wird.

    ...:AOD:...

    HP Chromebook 15a-nb0225ng, i3N-305, 8 GB LPDDR5-4800 MHz RAM (integriert), 256GB UFS, - chromeOS 132 (Stable Channel) - Linux Debian Bookworm: Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)

  • Ich glaube da ist BlockSite mit file://* als Filter deutlich eleganter.

    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1 (Gentoo Linux)