pb: Daten von Frame zu Frame übertragen

0 21

Daten von Frame zu Frame übertragen

pb
  • frames
  1. 0
    Raketenwilli
  2. 0
    Rolf B
    1. 0
      pb
      1. 0
        Rolf B
        1. 0
          Der Martin
          • browser
          • frames
          • usability
          1. 0
            pb
            1. 0
              Rolf B
            2. 0
              MudGuard
            3. 2
              Rolf B
              1. 0
                Der Martin
                1. 0
                  Rolf B
                  1. 0
                    Der Martin
                    • browser
                    • sicherheit
                    1. 1
                      Rolf B
                      1. 0
                        Der Martin
                        1. 0
                          Rolf B
                          1. 0
                            pb
                          2. 0
                            Der Martin
                            1. 0
                              Rolf B
                          3. 0
                            JürgenB
                2. 0
                  tk
SELF-Forum

Daten von Frame zu Frame übertragen

pb
– Informationen zu den Bewertungsregeln

Das Script auf zweite.html (frame 1) soll/te bei Ausführung eigentlich "x" in das Form-Feld "wert" auf/in frame 0 (erste.html) eintragen ... tut es aber nicht. Wo ist mein Denkfehler?

++++++++++++++++

index.html (frameset)

<html>
<frameset rows="*">
<frame src="erste.html">
<frame src="zweite.html">
</frameset>
</html>

++++++++++++++++

erste.html

<form>
<input type="text" name="wert" value="">
</form>

++++++++++++++++

zweite.html

<script type="text/javascript">
function uebertrag() {
parent.frames[0].document.forms[0].wert.value  = "x";
</script>
		     };
Beitrag melden
–
Informationen zu den Bewertungsregeln

  1. Daten von Frame zu Frame übertragen

    Raketenwilli (Versionen)
    – Informationen zu den Bewertungsregeln

    zweite.html

    <script type="text/javascript">
function uebertrag() {
parent.frames[0].document.forms[0].wert.value  = "x";
</script>
		     };
    1. Du schließt die Funktion außerhalb des Scriptes, also gar nicht.
    2. Ich sehe nicht, dass die (kaputte) Funktion „uebertrag()“ irgendwo aufgerufen wird.

    Noch ein Hinweis:

    • Was sich vielleicht erst später zeigt: Skript von „Server A“ soll keinen Frameinhalt von „Server B“ beeinflussen können.
    Beitrag melden
    –
    Informationen zu den Bewertungsregeln

  2. Daten von Frame zu Frame übertragen

    Rolf B
    – Informationen zu den Bewertungsregeln

    Hallo pb,

    Frames sind nicht mehr Teil von HTML und sollten vermieden werden.

    Wenn Du beide HTML Komponenten zusammenfügst, hast Du auch keine Probleme mit dem Zugriff.

    Wenn "erste" das Menü ist und "zweite" der Inhalt, und Du das Menü nicht auf alle Seiten kopieren willst, verwende Server-Side Includes oder PHP zum Integrieren der Komponenten auf dem Server. PHP bieten die meisten Hoster an, Serverside-Includes nicht unbedingt. VERWENDE KEINE FRAMESETS.

    Wenn Script nicht tut, was es soll, sollte die rechte Hand übrigens sofort zur F12 Taste zucken: die Entwicklertools des Browsers. Die fehlende geschweifte Klammer hätte als Syntaxerror in der Konsole erscheinen müssen.

    Und wenn keine Errors mehr kommen, kann man logischen Fehlern durch debuggen auf die Spur kommen: im Quellcode Breakpoints setzen und dann, wenn der Code anhält, die Variablen inspizieren.

    Einfach nur den Code angucken und grübeln, was wohl falsch sein könnte, ist Technik von 1960. Interaktive Debugger auf Sourcecodebasis gibt seit den 1980ern, und dein Browser kennt sowas seit mindestens 15 Jahren. Etwas schwieriger ist es im Handy. Browser auf Mobilchen brauchen einen Remote-Debugger auf einem Desktop.

    Rolf

    --
    sumpsi - posui - obstruxi
    Beitrag melden
    –
    Informationen zu den Bewertungsregeln

    1. Daten von Frame zu Frame übertragen

      pb
      – Informationen zu den Bewertungsregeln

      stimmt! Mea culpa!! Geschludert beim "vereinfachen" des Quellcodes. Da sind noch einige document.getElementById und setTimeout drin ... die tun hier aber nix zur Sache. So ists (natürlich) richtig:

      <script type="text/javascript">
function uebertrag() {
parent.frames[0].document.forms[0].wert.value  = "x";
            		 };
</script>

      Aufgerufen wird das Script über ein (Button-)OnClick-event (auf zweite.html). Die Seiten laufen mit mehr 'Drumherum' (dann als PHP mit XAMPP) ausschließlich lokal; ich weiß: Frames sind so was von ober-out, aber ... es sollte trotzdem 'laufen', oder? Muss für meine Bastelarbeit wohl in die HTML-Anfänge zurück ... komme aber nicht dorthin.

      Beitrag melden
      –
      Informationen zu den Bewertungsregeln

      1. Daten von Frame zu Frame übertragen

        Rolf B
        – Informationen zu den Bewertungsregeln

        Hallo pb,

        ja, laufen tun die Frames noch. Aber es gibt keine Garantie, dass sie nicht irgendwann doch noch aus dem Standard fliegen.

        Und ohne Frames ist es zumeist einfacher.

        Rolf

        --
        sumpsi - posui - obstruxi
        Beitrag melden
        –
        Informationen zu den Bewertungsregeln

        1. Daten von Frame zu Frame übertragen

          Der Martin
          – Informationen zu den Bewertungsregeln

          Hallo Rolf,

          ja, laufen tun die Frames noch. Aber es gibt keine Garantie, dass sie nicht irgendwann doch noch aus dem Standard fliegen.

          das ist schon richtig, aber ich halte es für eher unwahrscheinlich, dass die Browserhersteller einmal implementierte Funktionen wieder rausschmeißen ("backwards compatibility").

          Und ohne Frames ist es zumeist einfacher.

          Das auf jeden Fall. Vor allem für die Besucher, die dann z.B. auch wieder gezielt Unterseiten bookmarken können.

          Einen schönen Tag noch
           Martin

          --
          Prostituierte zum Stammgast: Schön, dass du mal wieder gekommen bist.
          Beitrag melden
          –
          Informationen zu den Bewertungsregeln

          1. Daten von Frame zu Frame übertragen

            pb
            – Informationen zu den Bewertungsregeln

            Noch mal: das ist ein privates Bastelprojekt das auf einem Raspi läuft für das ich Frames brauche; SSI und php-includes geht aus div. Gründen nicht. Wahrscheinlich bin ich hier im selfhtml-forum schlicht falsch mit meiner -ich dachte einfachen- Javascript-Frage:

            parent.frames[0].document.forms[0].wert.value = "x";

            Natürlich hab ich's auch schon mit window statt parent und Frame- und Form-Namen probiert und statt Namen auch mit ID's rum gespielt ... es funzt einfach nicht. Trotzdem danke für die Kommentare und Hinweise!! Einen schönen Sonntag noch.

            Beitrag melden
            –
            Informationen zu den Bewertungsregeln

            1. Daten von Frame zu Frame übertragen

              Rolf B
              – Informationen zu den Bewertungsregeln

              Hallo pb,

              nein, bist Du natürlich nicht. Aber nachdem das Syntaxproblem mit den geschweiften Klammern gefunden war, dachte ich, dass Du damit erstmal weiter kämst.

              Und es sind auch nicht immer alle online. Gestern hatte der Selfhtml Verein eine interne Aktion zur Wiki-Modernisierung, und wer dafür keine Zeit hatte, war anderweit verpflichtet.

              Sehe ich das richtig, dass der Raspi der Server für das Ganze ist?

              Welcher Browser ist es?

              Und auf die wichtigste Frage bist Du nicht eingegangen: Haben die beteiligten Frame-Inhalte den gleichen Origin? Kommen sie von verschiedenen IPs, oder verschiedenen Ports, oder verwenden nicht beide http oder https, dann ist der Origin verschieden und der Browser separiert die Frame-Inhalte voneinander. In diesem Fall könnte es sein, dass Du mit Messaging weiterkommst

              https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

              Im Selfwiki ist dieser Teil leider nur rudimentär beschrieben. Ob das mit Framesets funktioniert, muss man schauen, das weiß ich nicht. Aber im Frameset könnte man damit einen Verteiler bereitstellen, der zwischen den Frameinhalten vermittelt.

              Rolf

              --
              sumpsi - posui - obstruxi
              Beitrag melden
              –
              Informationen zu den Bewertungsregeln

            2. Daten von Frame zu Frame übertragen

              MudGuard Homepage des Autors
              – Informationen zu den Bewertungsregeln

              Hi,

              parent.frames[0].document.forms[0].wert.value = "x";

              Natürlich hab ich's auch schon mit window statt parent und Frame- und Form-Namen probiert und statt Namen auch mit ID's rum gespielt ... es funzt einfach nicht.

              Was sagt denn die Console des Browsers?

              Rein intuitiv würde ich vermuten, daß das frames-Objekt im Dokument und nicht im Window liegt.

              cu,
              Andreas a/k/a MudGuard

              Beitrag melden
              –
              Informationen zu den Bewertungsregeln

            3. Daten von Frame zu Frame übertragen

              Rolf B (Versionen)
              +2 Informationen zu den Bewertungsregeln

              Hallo pb,

              ich habe jetzt auch mal rumgespielt. Die Seiten werden in einem IIS gehostet (auf meinem Windows PC) und ich zeige sie mit Chrome an.

              DAMIT gelingt der Zugriff beispielsweise über

              <frameset>
   <frame name="frame1" src="file1.html">
   <frame name="frame2" src="file2.html">
</frameset>

              In file1:

              const otherFrame = parent.frames.frame2;
const dings = otherFrame.document.getElementById("dings");
dings.textContent = "bums";

              Edit: Bugfixing nach Martins Hinweis

              Natürlich geht das auch mit Forms und Form-Elementen.

              Und es geht NICHT, sobald der Origin von file1 und file2 nicht übereinstimmt. Ich habe ein zweites Web gemacht, das nicht auf localhost hört, sondern auf 127.0.0.2. Es zeigt aber auf den gleichen Ordner. Und schon mault Chrome rum, dass er den Cross-Origin Zugriff unterbunden habe.

              Beachte auch: Wenn Du die HTML Seiten nicht von einem Webserver lädst, sondern über file:///, wird der Zugriff grundsätzlich als cross-origin klassifiziert. Eine Demo für Messaging mache ich auch noch, dazu fehlt in unserem Wiki ohnehin noch ein Beispiel.

              Rolf

              --
              sumpsi - posui - obstruxi
              Beitrag melden
              +2
              Informationen zu den Bewertungsregeln

              1. Daten von Frame zu Frame übertragen

                Der Martin
                – Informationen zu den Bewertungsregeln

                Hallo Rolf,

                const otherFrame = parent.frames.frame2;
frame2.document.getElementById("dings");
dings.textContent = "bums";

                da fehlt wohl noch was - nämlich eine Zuweisung an dings. Und otherFrame wird nicht benutzt.

                Beachte auch: Wenn Du die HTML Seiten nicht von einem Webserver lädst, sondern über file:///, wird der Zugriff grundsätzlich als cross-origin klassifiziert.

                What?! Willst du damit sagen, file:// und file:// ist generell was Verschiedenes?
                Dabei ist doch gerade da das Vertrauensniveau am größten, wenn alles im eigenen Filesystem liegt.

                Einen schönen Tag noch
                 Martin

                --
                Prostituierte zum Stammgast: Schön, dass du mal wieder gekommen bist.
                Beitrag melden
                –
                Informationen zu den Bewertungsregeln

                1. Daten von Frame zu Frame übertragen

                  Rolf B
                  – Informationen zu den Bewertungsregeln

                  Hallo Martin,

                  autsch - ja. Edith hat gefixt. Äh. Hat's gefixt.

                  Zu file:// will ich gar nichts sagen, und zu file:/// sage ich: Ja, definitiv. Zwei file:///-URLs sind grundsätzlich cross-origin.

                  Dass LocalMachine die am wenigsten vertrauenswürdige Instanz ist, hat Tradition seit dem Zonenmodell des Internet Explorers und ist auch durchaus verständlich. User sind eine Gefahr! Misstraue allem, was auf deren Festplatte kreucht und fleucht.

                  Dass in diesem Bad ein paar Kinder plantschen, die man mit ausschüttet, wird hingenommen. Das Denkmodell dabei dürfte sein: Wer Webseiten von file:/// betreibt, ist eh nur Laie und braucht keine komplexen Funktionen.

                  Ein Webserver ist schnell aufgesetzt. Unter Windows kann man den IIS aktivieren, oder man kann PHP -S verwenden, oder verwendet drei Gehirnzellen darauf, einen lokalen Apache oder nginx einzurichten. Falls ein User auf einem gemanagten Gerät arbeitet, dass all das nicht zulässt - nun ja, dann ist es sehr wahrscheinlich auch nicht im Sinne der Gerätemanager, dass dieser User sich eigene HTML Seiten mit aktiven Inhalten bastelt.

                  Vermutlich gibt's Anwendungsfälle, die ich übersehe und die mir

                  😡💨💩😲

                  einbringen. Was nichts nützt, denn ich habe ja nur spekuliert, was Motive sein könnten und bin nicht daran schuld, dass file:/// nicht vertraut wird.

                  Rolf

                  --
                  sumpsi - posui - obstruxi
                  Beitrag melden
                  –
                  Informationen zu den Bewertungsregeln

                  1. Daten von Frame zu Frame übertragen

                    Der Martin
                    – Informationen zu den Bewertungsregeln

                    Hi,

                    Zu file:// will ich gar nichts sagen, und zu file:/// sage ich: Ja, definitiv. Zwei file:///-URLs sind grundsätzlich cross-origin.

                    wie bescheuert!

                    Dass LocalMachine die am wenigsten vertrauenswürdige Instanz ist, hat Tradition seit dem Zonenmodell des Internet Explorers und ist auch durchaus verständlich. User sind eine Gefahr! Misstraue allem, was auf deren Festplatte kreucht und fleucht.

                    Ich sehe das komplett anders. Was auf meinem lokalen System abläuft, unterliegt komplett meiner Kontrolle und kann daher als vertrauenswürdig gelten (soweit ich mir selbst vertraue). Fragwürdig sind für mich nur Inhalte, die nicht meiner Kontrolle unterliegen. Also die wilde Welt da draußen.

                    Einen schönen Tag noch
                     Martin

                    --
                    Prostituierte zum Stammgast: Schön, dass du mal wieder gekommen bist.
                    Beitrag melden
                    –
                    Informationen zu den Bewertungsregeln

                    1. Daten von Frame zu Frame übertragen

                      Rolf B
                      +1 Informationen zu den Bewertungsregeln

                      Ach Martin,

                      soweit ich mir selbst vertraue

                      wir beiden gehören (hoffentlich) zu den paar Millionen Menschen dieser Welt, die ihren Computer soweit im Griff haben, dass dieses Vertrauen gerechtfertigt ist.

                      Die übrigen dagegen sind froh, wenn sie eine Office-Anwendung erfolgreich bedienen können.

                      Diese Wissensdifferenz sichert unseren Lebensunterhalt…

                      Und im Gegensatz zu früher sind Browser für "die anderen" gemacht. Ich hatte auch eine Phase, in der ich mich darüber aufgeregt habe. Aber das ist 20 Jahre her.

                      Auf file:/// liegen viel zu viele vertrauliche Sachen herum, als dass man dort cross-origin Zugriffe einfach erlauben könnte. Stell Dir vor, du bist Marty McSure, Sachbearbeiter in einer Versicherung, und du bekommst von Trixi Tannen (die böse Schwester von Biff Tannen, natürlich) eine tolle HTML Datei mit einem Script drin, um einfacher irgendwelche Beiträge ausrechnen zu können.

                      Du bist begeistert und lässt sie täglich laufen (die HTML-Seite, nicht die Trixi). Und nun stell Dir vor, alles auf file:/// wäre der gleiche Origin. Boshafte Komponenten in Trixis Script können nun per fetch-API deinen ganzen PC ausforschen. Trixis Seite könnte auch noch Script vom Netz, aus file:///corp/public/trixtan/superscript.js nachladen. Und irgendwann ganz stiekum den echten Schnüffler scharfschalten.

                      Ja, ich weiß, Trixis Schwester Conny Swindleman-Tannen hat eine Excel-Datei erstellt, die diese Berechnungen noch viel besser ausführt. Und dank VBA kann sie Martys PC vieeel effizienter ausspionieren. Weil Excel überhaupt keine Hürden aufstellt, was VBA anrichten kann, sobald man es erlaubt hat.

                      Aber die Browser wollen sich diesen Mist nicht zuschreiben lassen müssen. file:/// ist nicht vertrauenswürdig. Punkt.

                      Rolf

                      --
                      sumpsi - posui - obstruxi
                      Beitrag melden
                      +1
                      Informationen zu den Bewertungsregeln

                      1. Daten von Frame zu Frame übertragen

                        Der Martin
                        – Informationen zu den Bewertungsregeln

                        Hallo Rolf,

                        soweit ich mir selbst vertraue

                        wir beiden gehören (hoffentlich) zu den paar Millionen Menschen dieser Welt, die ihren Computer soweit im Griff haben, dass dieses Vertrauen gerechtfertigt ist.

                        ja, und trotzdem ...

                        Stell Dir vor, du bist Marty McSure, Sachbearbeiter in einer Versicherung, und du bekommst von Trixi Tannen (die böse Schwester von Biff Tannen, natürlich) eine tolle HTML Datei mit einem Script drin, um einfacher irgendwelche Beiträge ausrechnen zu können.

                        Du bist begeistert und lässt sie täglich laufen (die HTML-Seite, nicht die Trixi). Und nun stell Dir vor, alles auf file:/// wäre der gleiche Origin. Boshafte Komponenten in Trixis Script können nun per fetch-API deinen ganzen PC ausforschen. Trixis Seite könnte auch noch Script vom Netz, aus file:///corp/public/trixtan/superscript.js nachladen. Und irgendwann ganz stiekum den echten Schnüffler scharfschalten.

                        Deswegen plädiere ich ja dafür, dass Dokumente von localhorst auch nur auf andere Informationen von localhorst zugreifen dürfen und auf nichts anderes außerhalb davon. Egal ob via file:/// oder http://. Zugriffe auf eine andere IP-Adresse im lokalen Netz sind schon wieder heikel. Die können im Einzelfall erwünscht sein, aber ich möchte sie nicht pauschal erlauben.

                        Ja, ich weiß, Trixis Schwester Conny Swindleman-Tannen hat eine Excel-Datei erstellt, die diese Berechnungen noch viel besser ausführt. Und dank VBA kann sie Martys PC vieeel effizienter ausspionieren. Weil Excel überhaupt keine Hürden aufstellt, was VBA anrichten kann, sobald man es erlaubt hat.

                        Das ist noch eine ganz andere Baustelle. Immerhin warnen die MS-Office-Programme ja auch ganz laut davor, dass sie möglicherweise schädliche Macros enthalten.

                        Fun Fact: MS Outlook auf meinem Work-PC warnt mich regelmäßig beim Öffnen von PDF-Attachments: Achtung, gefährlich! Das muss ich dann jedesmal noch bestätigen; die Checkbox "Diesen Dateityp immer zulassen" (oder so ähnlich) ist dabei deaktiviert. Aber Word- oder Excel-Anhänge darf ich ohne jegliche Umschweife direkt öffnen. *kopfschüttel*

                        Aber die Browser wollen sich diesen Mist nicht zuschreiben lassen müssen. file:/// ist nicht vertrauenswürdig. Punkt.

                        Wie gesagt: Bescheuert.

                        Einen schönen Tag noch
                         Martin

                        --
                        Prostituierte zum Stammgast: Schön, dass du mal wieder gekommen bist.
                        Beitrag melden
                        –
                        Informationen zu den Bewertungsregeln

                        1. Daten von Frame zu Frame übertragen

                          Rolf B
                          – Informationen zu den Bewertungsregeln

                          Hallo Martin,

                          Deswegen plädiere ich ja dafür, dass Dokumente von localhorst auch nur auf andere Informationen von localhorst zugreifen dürfen und auf nichts anderes außerhalb davon. Egal ob via file:/// oder http://

                          localhost ≠ file:///

                          localhost-Dokumente dürfen durchaus auf jede andere Information von localhost zugreifen (solange Schema und Port gleich sind).

                          Es ist zwar ekelig, aber ich muss einen Teil meiner Worte wohl runterschlucken. Ich habe diese Stackoverflow-Seite gefunden:

                          https://stackoverflow.com/questions/48313084/what-is-the-same-origin-policy-for-file-uris/52508086#52508086

                          Demnach ist das SOP Verhalten von file:/// browserabhängig bzw kann von command-line Optionen beeinflusst werden. Inwieweit das heute noch stimmt habe ich nicht evaluiert.

                          Rolf

                          --
                          sumpsi - posui - obstruxi
                          Beitrag melden
                          –
                          Informationen zu den Bewertungsregeln

                          1. Daten von Frame zu Frame übertragen

                            pb
                            – Informationen zu den Bewertungsregeln

                            Danke Rolf, das war's: same origin!! Problem gelöst. Und warum komm ich da nicht selbst drauf .-)

                            Beitrag melden
                            –
                            Informationen zu den Bewertungsregeln

                          2. Daten von Frame zu Frame übertragen

                            Der Martin
                            – Informationen zu den Bewertungsregeln

                            Hallo Rolf,

                            Deswegen plädiere ich ja dafür, dass Dokumente von localhorst auch nur auf andere Informationen von localhorst zugreifen dürfen und auf nichts anderes außerhalb davon. Egal ob via file:/// oder http://

                            localhost ≠ file:///

                            ja, ich weiß. Aber m.E. sollte man das Verhalten (also ob Zugriff erlaubt oder nicht) eher an den Host als an das (Pseudo-)Protokoll knüpfen. Übrigens meine ich mich zu erinnern, dass man File-Zugriffe im alten Netscape sogar als file://localhost/ notieren musste, insofern ist eine Vermischung der Begriffe nicht ganz unlogisch.

                            Es ist zwar ekelig, aber ich muss einen Teil meiner Worte wohl runterschlucken. Ich habe diese Stackoverflow-Seite gefunden:

                            https://stackoverflow.com/questions/48313084/what-is-the-same-origin-policy-for-file-uris/52508086#52508086

                            Demnach ist das SOP Verhalten von file:/// browserabhängig bzw kann von command-line Optionen beeinflusst werden. Inwieweit das heute noch stimmt habe ich nicht evaluiert.

                            Oh je ...

                            Einen schönen Tag noch
                             Martin

                            --
                            Prostituierte zum Stammgast: Schön, dass du mal wieder gekommen bist.
                            Beitrag melden
                            –
                            Informationen zu den Bewertungsregeln

                            1. Daten von Frame zu Frame übertragen

                              Rolf B
                              – Informationen zu den Bewertungsregeln

                              Hallo Martin,

                              Aber m.E. sollte man das Verhalten (also ob Zugriff erlaubt oder nicht) eher an den Host als an das (Pseudo-)Protokoll knüpfen.

                              Das Verhalten hängt am Origin, und der ist als schema-abhängig spezifiziert.

                              Und für file: ist die Spec ziemlich gemein:

                              Unfortunate as it is, this is left as an exercise to the reader. When in doubt, return a new opaque origin.

                              Heißt für mich: Die Leute bei WhatWG konnten sich nicht einigen. Abgesehen davon gibt's bei file:/// keinen Host, gelle? Andererseits ist file://localhost/ genauso zulässig, und wenn www.example.org auf die Maschine zeigt, auf der file://www.example.org/C:/foo angesprochen wird, ist das ebenfalls okay. Sagt RFC8089. Wie soll man da einen validen und eindeutigen Origin bilden?!

                              Rolf

                              --
                              sumpsi - posui - obstruxi
                              Beitrag melden
                              –
                              Informationen zu den Bewertungsregeln

                          3. Daten von Frame zu Frame übertragen

                            JürgenB Homepage des Autors
                            – Informationen zu den Bewertungsregeln

                            Hallo Rolf,

                            Demnach ist das SOP Verhalten von file:/// browserabhängig bzw kann von command-line Optionen beeinflusst werden. Inwieweit das heute noch stimmt habe ich nicht evaluiert.

                            beim Firefox habe ich es mit

                            about:config öffnen
security.fileuri.strict_origin_policy auf false setzen

                            abgeschaltet.

                            Gruß
                            Jürgen

                            Beitrag melden
                            –
                            Informationen zu den Bewertungsregeln

                2. Daten von Frame zu Frame übertragen

                  tk
                  – Informationen zu den Bewertungsregeln

                  Moin,

                  What?! Willst du damit sagen, file:// und file:// ist generell was Verschiedenes?
                  Dabei ist doch gerade da das Vertrauensniveau am größten, wenn alles im eigenen Filesystem liegt.

                  Jein: html-Anhänge an Phishing-Mails o.ä. werden beim Öffnen ebenfalls über das file-Protokol geöffnet – evtl. wurden deswegen die Möglichkeiten was in solchen Dateien erlaubt ist deutlich eingeschränkt.

                  Gruß
                  Tobias

                  Beitrag melden
                  –
                  Informationen zu den Bewertungsregeln