SP Auth Proxy

      SP Auth Proxy

      Ich habe hier ein tool gebaut, was sich in den SPH einloggt und dann das WebUI ohne eigene Auth bereitstellt (verwende es hinter nginx mit http basic auth).
      Der Grund dafuer ist ganz einfach: Es kann immer nur ein "User" eingeloggt sein im SPH. Wenn ich also ein tool nutze, um Graphen zu erstellen (wie github.com/melle/l33tport), dann muss ich das erst stoppen, um die Einstellungen aendern zu koennen.

      Tool ist hier: github.com/Doridian/SPAuthProxy
      ( Authentifikationsteil gebaut aus dem JS des WebUI und mit hilfe von code von github.com/melle/l33tport )

      Installation:
      npm install
      config.js erstellen (Beispiel in config.example.js). Speedport host/password ist die IP des speedport bzw das Passwort. Proxy host/port ist der host/port an dem SP Auth Proxy laufen soll (localhost ist zu empfehlen, da der proxy selber keine Authentifikation erfordert). URL ist die URL, unter der der Proxy im Browser aufgerufen wird (mit Port falls nicht standard (80/443)) (Grund hierfuer ist, dass der Speedport alles absolut macht mit speedport.ip in vielen Links).
      node index.js

      Ebenfalls cachet dieser Proxy alle CSS/JS/Bild Dateien des Speedport. Den cache kann man dann bearbeiten, um das WebUI zu veraendern (falls gewuenscht, ich habe damit ein paar kleine Bugs im Telekom JS code gefixt)

      Achtung: Nicht ueber dieses UI ein Config restore durchfuehren oder Firmware update, sonst hilft nur noch ein Hard-Reset (button). Alles andere (inklusive Backup) funktioniert!

      Wenn gewuenscht, kann ich auch noch HTTP-Basic auth direkt in den Proxy einbauen als Einstellung.

      Sehr sehr nettes Tool für den SPH. Hat sich inzwischen etabliert.

      Habe mir dazu noch nen kleines init-Script (gentoo / OpenRC) für unseren FileServer gebaut, somit steht mir der sphProxy im LAN zur Verfügung - Benötigt allerdings "forever" (npm install -g forever):

      Quellcode

      1. #!/sbin/runscript
      3. depend() {
      4. need net
      5. after sshd
      6. }
      8. start() {
      9. ebegin "Starting sphProxy"
      10. cd /home/www/internal/speedport/
      11. start-stop-daemon --start --exec forever -- start -s index.js
      12. eend $?
      13. }
      15. stop() {
      16. ebegin "Stopping sphProxy"
      17. cd /home/www/internal/speedport/
      18. start-stop-daemon --start --exec forever -- stop -s index.js
      19. eend $?
      20. }​


      Nachdem das damit super läuft habe ich das ganze noch ein wenig auf die Spitze getrieben:

      Über unseren DNS-Server fahre ich eine Subdomain als DynDNS (home.silibum.de) und habe somit immer ein Host für meinen Anschluss und habe dort entsprechend auch nen Apache am laufen der unter anderem munin / l33tport (home.silibum.de/munin/) ausliefert und ein paar interne Tools bereitstellt (mailAliases @silibum.de, etc) und nun auch den sphProxy per Apache / ProxyPass(Reverse):

      Quellcode

      1. ​ ProxyPass "/sph/" "http://tomb.home.silibum.local:81/"
      2. ProxyPassReverse "/sph/" "http://tomb.home.silibum.local:81/"
      4. <Proxy "http://tomb.home.silibum.local:81/">
      5. Require ip 192.168.22.0/24
      6. Require ip 192.168.10.1/32
      7. Require ip 94.79.185.122
      8. </Proxy>


      Die Requires ersetzen dabei den nicht vorhanden Zugriffsschutz und beziehen sich auf lokale und eine statische IP aus dem Office. Das funktioniert soweit erste Sahne und macht mir ein Blick auf den SPH auch von ausserhalb sehr einfach ;)

      Einschränkung: /engineer/html/* -> Nur die DSL-Infos funktionieren per ProxyProxy ?(

      @doridian: Hast Du spontan vielleicht eine Idee wie ich das engineer-Menü unter diesen Umständen auch Vollständig ans laufen bekomme? Hatte spontan mal mit dem Host-Eintrag in der config gespielt, aber leider ohne Erfolg ;(

      shell schrieb:

      Einschränkung: /engineer/html/* -> Nur die DSL-Infos funktionieren per ProxyProxy ?(

      @doridian: Hast Du spontan vielleicht eine Idee wie ich das engineer-Menü unter diesen Umständen auch Vollständig ans laufen bekomme? Hatte spontan mal mit dem Host-Eintrag in der config gespielt, aber leider ohne Erfolg ;(


      Ich hatte bei dem engineer Menu oft ein Problem, weil das 404s generiert, und das vom SPAuthProxy als "logout" gewertet wurde... Das hatte ich korrigiert.

      Was genau passiert denn bei was anderem?

      Ganz wichtig: Die URL hier github.com/Doridian/SPAuthProx…ster/config.example.js#L9 muss die URL sein, ueber die durch den Browser zugegriffen wird, sonst kann der Proxy die hardcoded speedport.ip Entrys nicht korrekt umschreiben

      Was noch ganz wichtig ist: Der Proxy darf auf keinen Fall 30x redirects selber folgen, er muss diese an den Browser weitergeben.

      In der richtung hatte ich es vermutet, ja - ich bin nun auch ein wenig weiter: Hab da nochmal genau hingeschaut und musste festellen: Die JSONSource-URL ist nur bei DSL "brauchbar" für mein Fall:


      DSL:

      Quellcode

      1. <!-- Global script data -->
      2. <script type="text/javascript">
      3. var csrf_token = "EudzqzRLQZPP3AFJfU5vvCIB4WPmuzl";
      4. /* <![CDATA[ */
      5. var rootRelative = '../';
      6. var JSONSource = '../../data/dsl.json';
      7. /* ]]> */
      8. </script>


      ARP:

      Quellcode

      1. <!-- Global script data -->
      2. <script type="text/javascript">
      3. var csrf_token = "VeF/qNkuSZ58dBXnv86nFdGoBn2o4Oz";
      4. /* <![CDATA[ */
      5. var rootRelative = '../';
      6. var JSONSource = '/data/arp.json';
      7. /* ]]> */
      8. </script>


      Rewritest Du die an der Stelle, oder sind die schon kacke im WebInterface himself? Ich gehe von himself aus und habe nun wie folgt geschummelt:

      Quellcode

      1. Redirect /data/ https://home.silibum.de/sph/data/


      Das laeuft erstmal und macht das engineer auch per Proxylauffaehig, darf nun halt erstmal kein /data auf home.silibum.de geben - wirds es aber wohl auch nie :P

      shell schrieb:

      In der richtung hatte ich es vermutet, ja - ich bin nun auch ein wenig weiter: Hab da nochmal genau hingeschaut und musste festellen: Die JSONSource-URL ist nur bei DSL "brauchbar" für mein Fall:


      DSL:

      Quellcode

      1. <!-- Global script data -->
      2. <script type="text/javascript">
      3. var csrf_token = "EudzqzRLQZPP3AFJfU5vvCIB4WPmuzl";
      4. /* <![CDATA[ */
      5. var rootRelative = '../';
      6. var JSONSource = '../../data/dsl.json';
      7. /* ]]> */
      8. </script>


      ARP:

      Quellcode

      1. <!-- Global script data -->
      2. <script type="text/javascript">
      3. var csrf_token = "VeF/qNkuSZ58dBXnv86nFdGoBn2o4Oz";
      4. /* <![CDATA[ */
      5. var rootRelative = '../';
      6. var JSONSource = '/data/arp.json';
      7. /* ]]> */
      8. </script>


      Rewritest Du die an der Stelle, oder sind die schon kacke im WebInterface himself? Ich gehe von himself aus und habe nun wie folgt geschummelt:

      Quellcode

      1. Redirect /data/ https://home.silibum.de/sph/data/


      Das laeuft erstmal und macht das engineer auch per Proxylauffaehig, darf nun halt erstmal kein /data auf home.silibum.de geben - wirds es aber wohl auch nie :P


      Oh achso, du hostest das nicht vom root Ordner. Das ist sehr Problematisch, ja. Der SPH hat ueberall gehardcodeten Kram. Vor allem im /engineer ist das noch unsauberer gecodet als eh schon...

      Bei mir hat der SPH deswegen eine eigene Subdomain auf meinem "DynDNS".

      Jaein - der eigentlich proxy laeuft unter tomb.home.silibum.local auf Port 81 im Root - nur der Proxy übern Apache halt nicht, aber ich ueberlege mir tatsaechlich nen CNAME ala dslr.home.silibum.de anzulegen, damit der aus dem root laufen kann und ich den redirect nicht brauche... Muss ich nochmal schauen, ist ja nicht verkehrt und frisst nichts... Mal schauen - Danke soweit, erstmal.