Zum Debuggen Javascript Files durch lokale Kopien ersetzen

  • Ich betreibe einen "digitalSTROM" Server zur Haussteuerung. Im Web-Interface zur Konfiguration gibt es leider einen Bug, der mich sehr stört, den die Jungs bei digitalSTROM aber nicht willens oder in der Lage sind zu fixen. Daher wollte ich mir das selber mal anschauen und mein Glück versuchen ;-).


    Wenn ich die entsprechende Seite des Servers aufrufe bekomme ich sowas:

    Die einzelnen *.js Files kann ich mir mit wget auf die lokale Platte laden. Allerdings läuft das Ganze natürlich nicht lokal, weil die Funktionen versuchen, Daten vom Server zu laden, was natürlich nicht geht, wenn ich es lokal aufrufe.


    Weiß vielleicht jemand hier, ob es möglich ist, dem Browser (Firefox, würde aber auch jeden anderen nehmen, wenn er das kann) zu sagen "hol dir javascript Files nicht vom Server, sondern von einem lokalen Verzeichnis"? Dann könnte ich die Verbindung zum Server (HTTPS) ganz normal aufbauen, aber meine lokalen Kopien der *.js Files verwenden und in diesen Veränderungen vornehmen, um den Bug zu lokalisieren und evtl. zu fixen.


    Klaus

  • Am einfachsten vermutlich indem du einen Proxy aufsetzt. Das kann z.B. ein Apache HTTPD sehr gut. Da drauf dann nicht nur die Javascript-Dateien sondern auch die HTML-Datei und die originale Server-API wird vom HTTPD auf den Original-Server durchgereicht.


    Im Browser dürfte knifflig werden. Es würde mich wundern wenn von HTTP(S) aus via "FILE:"-Protokoll eine lokale Datei eingebettet werden dürfte. Wenn das wirklich geht, dann wäre es eine Sicherheitslücke.

  • Danke für den Tipp mit dem Proxy.


    In dem Zusammenhang bin ich auf das Thema "Automatic proxy configuration" gestoßen: https://en.wikipedia.org/wiki/Proxy_auto-config.

    Damit soll es möglich sein, ausgwählte Requests an einen Proxy zu schicken und den Rest direkt zu holen.

    Wenn ich, um das mal auszuprobieren, ein File "proxy.pac" folgenden Inhalts erstelle

    Code
    1. function FindProxyForURL(url, host)
    2. {
    3. return "PROXY myproxy.de:1234";
    4. }

    (wobei "myproxy.de:1234" durch konkrete, funktionierende Werte ersetzt sind) und dieses im Firefox in den "ConnectionSettings" unter "Automatic proxy configuration URL" als "file:///home/kls/proxy.pac" angebe, dann müssten eigentlich alle Request über den Proxy gehen. Es geht aber nach wie vor alles direkt (sehe ich an den nicht erfolgenden Log-Meldungen des Proxies). Der Proxy als solcher funktioniert und wird auch benutzt, wenn ich ihn im Firefox unter "Manual proxy configuration" eingebe.


    Übersehe ich da was? Mir würde diese Variante gut gefallen, weil ich auf meinem lokalen Rechner eh einen kleinen Web-Server am Laufen habe und so genau die Requests für eines der Javascript Files auf diesen umleiten könnte.


    Klaus

  • Wenn du die ganze Seite lokal herunterlädst und über deinen lokalen Webserver einsteigst, werden doch auch die lokalen JS verwendet - sind ja relative Pfade im HTML, oder? Die Aufrufe der Serverfunktionen in den (lokalen) JS-Dateien müsstest du ggf. auf absolute Pfade (inkl. URL) umstellen.

    Aber wahrscheinlich verstehe ich die Anforderung falsch.

    MyVDR (Hardwareliste) : yaVDR 0.6 - softhddevice-openglosd - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 17.1 - inputstream - amazon prime vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 3 TB HDD

  • Die Aufrufe sind leider ziemlich tief verschachtelt.

    Ausserdem wird auch mit Cookies gearbeitet, die natürlich vom Server kommen müssen.

    Den größten Teil direkt laufen zu lassen und nur die betreffenden Dateien lokal zu laden dürfte schon der richtige Weg sein.

    Momentan verstehe ich nur nicht, warum das mit der proxy.pac Datei überhaupt nicht greift...


    Klaus

  • Wenn so eine umfangreiche proxy.pac funktioniert, sollte es mein simples Beispiel eigentlich auch tun.

    Muss man noch irgend etwas Spezielles tun, das nicht offensichtlich ist?


    Klaus

  • Die hat immer funktioniert. Das einzig offensichtlich andere ist:


    function FindProxyForURL(url, host) {


    Die Klammer in der erste Zeile - vielleicht muß dies da so sein?

    Und der Browser kann auch zugreifen (Rechte), falls die Datei nicht von einem (internen) Webserver kommt?


    Grüße,

    42

  • Die Position der Klammer ist egal, das ist Javascript.


    Hast du mal Redirect probiert?

    https://chrome.google.com/webs…kippcccflcoddckhjjfgnfhnp


    Würde für die Entwicklung ja erst mal reichen. Https im Proxy aufbrechen (Dummy-Zertifikat usw.) ist auch nicht so einfach.


    Lars

  • Gibt es auch für Firefox.

    https://addons.mozilla.org/de/firefox/addon/redirector/


    Benutze ich, um von Google aus immer im englischen MSDN zu landen.


    Lars

  • Würde für die Entwicklung ja erst mal reichen. Https im Proxy aufbrechen (Dummy-Zertifikat usw.) ist auch nicht so einfach.


    Ach, so kompliziert ist das nicht. Und man kann dann per elsquid Werbung filtern.

    Code
    1. ==> /var/log/squid/access.log <==Oct 3 08:43:03 40192 192.168.1.3 TCP_MISS/200 438 GET https://256-trouter-neu-b.drip.trouter.skype.com/socket.io/1/xhr-polling/225bb2dd461afe1b-42874fa8c1561374? - HIER_DIRECT/168.63.43.207 text/plainOct 3 08:43:09 146 192.168.1.3 NONE/200 0 CONNECT www.vdr-portal.de:443 - HIER_DIRECT/85.93.89.140 -Oct 3 08:43:10 141 192.168.1.3 NONE/200 0 CONNECT www.vdr-portal.de:443 - HIER_DIRECT/85.93.89.140 -Oct 3 08:43:10 303 192.168.1.3 TCP_MISS/200 1454 POST https://www.vdr-portal.de/index.php? - HIER_DIRECT/85.93.89.140 application/jsonOct 3 08:43:10 500 192.168.1.3 TCP_MISS/200 21766 GET https://www.vdr-portal.de/forum/index.php? - HIER_DIRECT/85.93.89.140 text/htmlOct 3 08:43:10 240 192.168.1.3 TCP_INM_HIT/304 290 GET https://www.vdr-portal.de/images/styleLogo-296c03f7c3faa38016f25bc8475f2bb67fc15e55.gif - HIER_NONE/- image/gif



    Stichworte: "Squid SSL-Bump", z.B.
    https://wiki.squid-cache.org/C…Intercept/SslBumpExplicit

    Man muß den Squid nur mit

    --enable-ssl \

    --enable-ssl-crtd \

    --with-openssl \


    übersetzen, sowie ein CA-Cert erzeugen, das man dann den Intranet Browsern als gültige CA mitteilt.

    Dann braucht die squid.conf noch sowas in der Art:



    In nobumpSites.txt dann Seiten, die früher per https gesichert worden wären: Banken, Elster und Co.
    In BrokenTrustedSites.txt kaputte Seiten (Zertifikat abgelaufen / Ketten defekt..), wie das Portal hier - sonst verbietet der Proxy den Zugriff.


    Ganz "Kaputtes", aka gepinnte Certs kann man per z.B. proxy.pac über den extra "nobump" Port routen, falls man ohne proxy keinen Netzzugriff erlauben will.


    Grüße,

    42

  • Ich betreibe einen "digitalSTROM" Server zur Haussteuerung. Im Web-Interface zur Konfiguration gibt es leider einen Bug, der mich sehr stört, den die Jungs bei digitalSTROM aber nicht willens oder in der Lage sind zu fixen. Daher wollte ich mir das selber mal anschauen und mein Glück versuchen ;-).

    ...

    Weiß vielleicht jemand hier, ob es möglich ist, dem Browser (Firefox, würde aber auch jeden anderen nehmen, wenn er das kann) zu sagen "hol dir javascript Files nicht vom Server, sondern von einem lokalen Verzeichnis"? Dann könnte ich die Verbindung zum Server (HTTPS) ganz normal aufbauen, aber meine lokalen Kopien der *.js Files verwenden und in diesen Veränderungen vornehmen, um den Bug zu lokalisieren und evtl. zu fixen.

    V.a. Chromium/Chrome erlaubt auch recht weitgehend, geladene Seiten & DOM im Browser zu patchen: evtl. ebenfalls hilfreich?

  • Das sieht schon mal sehr gut aus.

    Ich hab das mal installiert und im Prinzip funktioniert es, zumindest für normale Webseiten.

    Wenn ich aber eines der Javascript-Files redirecten möchte (mit dem Redirector im beiliegenden Screenshot), dann wird vom Web-Server "dolphin" nichts angefordert und die Seite baut sich auch nicht auf wie normal. Das heißt, der Redirector macht zwar anscheinend was, aber nicht richtig.

    Mache ich was falsch?


    Klaus

  • Hab's gefunden.

    Mein lokaler Webserver benutzt kein HTTPS, daher blockierte Firefox diesen "mixed content".

    Wenn ich security.mixed_content.block_active_content auf false setze, dann klappt es!


    Klaus