Probleme mit Authentifizierung - Apache als reverse Proxy

goerdy

Hey guys,

ich hab da Mal ein Problem.
Ich migriere gerade von einem Pi4 auf einen NUC und setze alle Dienste in Proxmox Containern auf.
Um von außen Zugriff zu haben geht eine Portweiterleitung einer DynDNS Adresse auf einen Container mit Apache und dort ist dann ein reverse Proxy eingerichtet der unter anderem auf den iobroker zeigt.

Bei der Config habe ich mich an dieser Anletung orientiert

nach etwas gefrickel habe ich auch zugriff auf VIS, auf meinen weiteren Container mit motioneye...

Was aber nicht funktioniert ist:

Admin - es kommt nur der Ladescreen, nichts weiter
die Authentifizierung
- weder über den Apache (basic auth)
  keine Ahnung wo ich den Fehler mache
- noch über die Autentifizierung über den Web adapter.
  hier klappt das mit der /login/ weiterleitung nicht.

Hat eine(r) von euch eine Idee was ich falsch mache?
Meine Apache Config habe ich angefügt

Also egal über welchen Weg, ich will erreichen das VIS nicht einfach so im Netz hängt

beste Grüße

root@NUC-APACHE:/var/www# cat /etc/apache2/sites-available/iobroker.conf 
# Folgende Module müssen in Apache mindestens installiert und aktiviert sein:
# - ssl
# - proxy
# - rewrite
# - proxy_wstunnel
# - mpm_prefork
# - mod_auth_basic
# - mod_authn_file  -- oder andere Authentifizierungsquelle
#
# Alle Einträge in eckigen Klammern [] sind durch die eigenen Daten zu ersetzen.
#
# Die Berechtigungsprüfung erfolgt durch Apache mittels HTTP-Basic Authentication oder Parameter an der URL.  Dies hat den Vorteil, das unberechtigte Anfragen erst gar nicht zu den Systemen gelangen.
# Da die Verbindung mit SSL/TLS gesichert ist, ist basic-Authentication vollständig ausreichend und am schnellsten.
# In den lokalen Systemen ist die Authentifizierung auszuschalten, da die Authentifizierungsdaten nicht durchgereicht werden.
# Die Skripte gehen davon aus, dass die lokalen Systeme mittels http angesprochen werden. Falls nicht, müssen die Zeilen entsprechend angepasst werden.

# Folgender Teil ist nur erforderlich, wenn man einen lokalen Bereich auf dem Webserver haben möchte, der unter der gleichen URL erreichbar ist (z.B. um statische Daten abzulegen) und bei dem ein Caching durch den Webserver erfolgen soll.
<IfModule mod_cache.c>
    LoadModule cache_disk_module modules/mod_cache_disk.so
    <IfModule mod_cache_disk.c>
        CacheRoot "/var/www"
        CacheEnable disk  "/"
        CacheDirLevels 5
        CacheDirLength 3
    </IfModule>

    # When acting as a proxy, don't cache the list
    CacheDisable "/ccu/"
    CacheDisable "/vis/"
    CacheDisable "/iobroker/"
    CacheDisable "/node-red/"
</IfModule>




# Oberste Modul-Deklaration für den kompletten durch ssl gesicherten Service
<IfModule mod_ssl.c>
   # Festlegung des Ports, über den der Server erreichbar sein soll.
   <VirtualHost _default_:443>

      ServerAdmin web@philipp-guerth.de
      ServerName ?????.myfritz.net

      # Stammverzeichnis des Webservers für lokale Inhalte
      DocumentRoot /var/www

        # Festlegung der Eigenschaften für das Root-Directory auf dem Webserver und alle Unterverzeichnisse
      <Directory />
         Options FollowSymLinks
         AllowOverride None

            # Festlegung der Authentifizierungseigenschaften
         # Hier wird basic-Authentification mit Liste der berechtigten User konfiguriert.
         # Anleitung zur Konfiguration von Benutzern siehe https://httpd.apache.org/docs/current/howto/auth.html
         AuthType basic
         AuthName "home"
         AuthBasicProvider file
         AuthUserFile /etc/apache2/ssl/httpsusers
        Require user goerdy

         # Festlegung, dass die Authentifizierung erfordlich ist. Speziell für die App kann kein Basic-Authentication verwendet werden, da diese Teile im Protokoll nicht enthalten sind.
         # Für die App kann alternativ auf die dort angegeben Daten für User und Password geprüft werden. Diese Werte werden in der URL als Parameter übertragen.
         # Die Werte werden nicht aus der Passwort-Datei ausgelesen sondern müssen hier statisch konfiguriert werden.
         # Wichtig: Nur der erste Request muss beim Öffnen der Verbindung authentifizieren.
         # Alle nachfolgenden Request über die gleiche http-Verbindung verwenden automatisch die gleichen Credentials. Deswegen ist beim Zugriff auf VIS die http-Authentifizierung für index.html ausreichend.
        # <RequireAny>
            # ZugriffURL-Authentifizierung
          #  <RequireAll> 
#Erlaubtauch noch die Einschng auf andere Eigenschaften
            #   Require expr %{QUERY_STRING} =~ /user=user&pass=user/
           # </RequireAll>
                # Fle anderen Zugriffe ist http-Authentifizierung erforderlich
            #Require user goerdy
        # </RequireAny>

      </Directory>

        # Eintrag falls noch lokale Scripte wie z.B. PHP unterstützt werden sollen (muss natürlich getrennt installiert und eingerichtet werden)
      ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
      <Directory "/usr/lib/cgi-bin">
         AllowOverride None
         Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
         Order allow,deny
         Allow from all
      </Directory>


      # Einrichtung der Zertifikate für die Verschlüsselung
      # Weitere Informationen siehe z.B. https://thomas-leister.de/apache2-webserver-ssl-verschluesselte-verbindungen-ermoeglichen/
      SSLCertificateFile /etc/letsencrypt/live/?????.myfritz.net/cert.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/?????.myfritz.net/privkey.pem
      SSLCertificateChainFile /etc/letsencrypt/live/?????.myfritz.net/chain.pem



      # Rewrite-Regeln
      # Wichtig: Bei den nachfolgenden Mod-Proxy-Einträgen ist die Reihenfolge relevant. Die Auswertung erfolgt von oben nach unten. Das erste passende ProxyPass-Statement gilt.


        # Weiterleitung für Node-Red
      # Wichtig: Damit die Websocket-Verbindung korrekt weitergeleitet werden kann, muss in den Adapter-Einstellungen von Node-Red in "http root directory" "node-red" eingetragen werden.
      # Ohne Websocket-Verbindung kann man trotzdem auf die IDE zugreifen, bekommt jedoch keine Debug-Information angezeigt.
      # Der Zugriff auf Node-erfolgt dann intern http://[ interne IP ]:1880/node-red und extern über https://[ externe URL ]/node-red
      <IfModule mod_proxy.c>
         RewriteEngine On
         redirectmatch ^/node-red$ /node-red/

         # Spezieller Eintrag für websocket-Verbindung
         RewriteCond %{REQUEST_URI} ^/node-red/comms [NC]
         RewriteRule /(.*) ws://192.168.178.10:1880/$1 [P,L]

         ProxyPass /node-red/ http://192.168.178.10:1880/node-red/
         ProxyPassReverse /node-red/ http://192.168.178.10:1880/node-red/
      </IfModule>

           # Rewrite-Regeln für ioBroker Admin
      # ToDo: Websocket-Kommunikation für Parameter in den Einstellungen fehlt.
      # Der Zugriff auf die Admin-Seite efolgt intern weiterhin über http://[ interne IP ]:8081 und extern über https://[ externe URL ]/iobroker
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/iobroker$ /iobroker/
         rewritecond %{REQUEST_URI} ^/iobroker/
         rewriterule (.*) $1 [PT]
         rewritecond %{HTTP_REFERER} https://?????.myfritz.net/iobroker/
         rewriterule ^/(.*) /iobroker/$1 [PT]

         ProxyPass /iobroker/ http://192.168.178.10:8081/ timeout=1200
         ProxyPassReverse /iobroker/ http://192.168.178.10:8081/ timeout=1200
      </IfModule>

<IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/motioneye$ /motioneye/
         rewritecond %{REQUEST_URI} ^/motioneye/
         rewriterule (.*) $1 [PT]
         rewritecond %{HTTP_REFERER} https://?????.myfritz.net/motioneye/
         rewriterule ^/(.*) /motioneye/$1 [PT]

         ProxyPass /motioneye/ http://192.168.178.11:8765/ timeout=1200
         ProxyPassReverse /motioneye/ http://192.168.178.11:8765/ timeout=1200
      </IfModule>


<IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/login$ /login/
         rewritecond %{REQUEST_URI} ^/login/
         rewriterule (.*) $1 [PT]
         rewritecond %{HTTP_REFERER} https://?????.myfritz.net/login/
      #   rewriterule ^/(.*) /login/$1 [PT]

         ProxyPass /login/ http://192.168.178.10:8082/login/ timeout=1200
         ProxyPassReverse /login/ http://192.168.178.10:8082/login/ timeout=1200
      </IfModule>



      # Rewrite-Regeln für ioBroker VIS
      # Die socket.io-Kommunikation und der Zugriff auf /lib wird nachfolgend getrennt geregelt (geht bestimmt auch einfacher hier lokal)
      # Wichtig: Im web-Adapter mit "Socket.IO Instance" auf integriert stehen.
      # Der Zugriff auf die Admin-Seite efolgt intern weiterhin über http://[ interne IP ]:8082/vis/index.html und extern über https://[ externe URL ]/vis/vis/index.html.
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/vis$ /vis/
         rewritecond %{REQUEST_URI} ^/vis/
         rewriterule (.*) $1 [PT]


         # Referer Auswertung, falls eine lokale absolute Referenz auf den Seiten ist. In diesem Fall wird /vis ergänzt, damit ProxyPass matched.
         # Referenzen auf node-red, static und socket.io werden explizit ausgeschlossen.
         rewritecond %{HTTP_REFERER} https://?????.myfritz.net/vis/
         rewritecond %{REQUEST_URI} !^/node-red/
         rewritecond %{REQUEST_URI} !^/static/
         rewritecond %{REQUEST_URI} !^/socket.io/
        rewriterule ^/(.*) /vis/$1 [PT]

         ProxyPass /vis/ http://192.168.178.10:8082/ timeout=10
         ProxyPassReverse /vis/ http://192.168.178.10:8082/ timeout=10
         </IfModule>

      # Rewrite-Regeln für einen direkten Zugriff auf das Verzeichnis /lib des Web-Servers von ioBroker VIS ohne Referer
      # Dürfte normalerweise nicht benötigt werden.
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/lib$ /lib/
         rewritecond %{REQUEST_URI} ^/lib/
         rewriterule (.*) $1 [PT]
         ProxyPass /lib/ http://192.168.178.10:8082/lib/ timeout=10
         ProxyPassReverse /lib/ http://192.168.178.10:8082/lib/ timeout=10
      </IfModule>


      # Rewrite-Regeln für einen direkten Zugriff auf auf flot ohne VIS
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/flot$ /flot/
         rewritecond %{REQUEST_URI} ^/flot/
         rewriterule (.*) $1 [PT]
         ProxyPass /flot/ http://192.168.178.10/flot/ timeout=10
         ProxyPassReverse /flot/ http://192.168.178.10:8082/flot/ timeout=10
      </IfModule>

      # Rewrite-Regeln für einen direkten Zugriff auf auf rickshaw ohne VIS
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         redirectmatch ^/rickshaw$ /rickshaw/
         rewritecond %{REQUEST_URI} ^/rickshaw/
         rewriterule (.*) $1 [PT]
         ProxyPass /rickshaw/ http://192.168.178.10:8082/rickshaw/ timeout=10
         ProxyPassReverse /rickshaw/ http://192.168.178.10/rickshaw/ timeout=10
      </IfModule>


      # Rewrite-Regeln für die socket.io Websocket-Verbindung von VIS und APP
      # Wichtig: Da socket.io im Webadapter auf intern steht, sollte hier auch auf den Web-Adapter und nicht auf einen separaten socket.io-Adapter referenziert werden.
      # Setzt externes WSS (Verschlüsselte Websocket-Verbindung) auf internen WS (ohne SSL/TLS) um.
      <IfModule mod_proxy.c>
         RewriteEngine On
         Redirectmatch ^/socket.io$ /socket.io/
         RewriteCond %{REQUEST_URI} ^/socket.io/
         RewriteCond %{QUERY_STRING} transport=websocket
         RewriteRule ^/(.*) /wss/$1 [PT]
         ProxyPass /wss/ ws://192.168.178.10:8082/ timeout=1200 Keepalive=On
         #ProxyPassReverse / ws://[ interne IP ]:8082/
      </IfModule>

      # Rewrite-Regeln für die Datei _socket im Hauptverzeichnis vom Web-Server
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         Redirectmatch ^/_socket$ /_socket/
         RewriteCond %{REQUEST_URI} ^/_socket/

         RewriteRule (.*) $1 [PT]
         ProxyPass /_socket/ http://192.168.178.10:8082/_socket/
         ProxyPassReverse /_socket http://192.168.178.10:8082/_socket/
      </IfModule>

      # Rewrite-Regeln für die socket.io Verbindung im Polling-Modus über HTTPS von VIS und APP
      # Wichtig: Da socket.io im Webadapter auf intern steht, sollte hier auch auf den Web-Adapter und nicht auf einen separaten socket.io-Adapter referenziert werden.
      <IfModule mod_proxy.c>
         ProxyRequests off
         RewriteEngine On
         Redirectmatch ^/socket.io$ /socket.io/
         RewriteCond %{REQUEST_URI} ^/socket.io/
         RewriteCond %{QUERY_STRING} transport=polling
         RewriteRule (.*) $1 [PT]

         ProxyPass /socket.io/ http://192.168.178.10:8082/socket.io/
         ProxyPassReverse /socket.io/ http://192.168.178.10:8082/socket.io/
      </IfModule>

      # Parameter für die Steuerung der Log-Ausgabe beim Rewrite
      # Die Logausgabe kann durch Entfernen der # aktiviert werden
      #LogLevel warn
      #LogLevel alert rewrite:trace8
      #CustomLog ${APACHE_LOG_DIR}/ssl_access2.log combined

      # Generelles Anschalten von SSL
      SSLEngine on


      # Sonderregeln für Scripte
      <FilesMatch "\.(shtml|phtml|php)$">
         SSLOptions +StdEnvVars
      </FilesMatch>
      <Directory /usr/lib/cgi-bin>
         SSLOptions +StdEnvVars
      </Directory>
   </VirtualHost>
</IfModule>

goerdy

@goerdy

habs raus gefunden...

einfach noch

<proxy>
         AuthType basic
         AuthName "home"
         AuthBasicProvider file
         AuthUserFile /etc/apache2/ssl/httpsusers
         Require user goerdy
</proxy>

einfügen und schon klappt es mit der Autentifizierung.

vielleicht hilft es ja dem nächsten der vor dem gleichen Problem steht.

XxJooO

@goerdy,

hallo, stehe vor dem gleichen Problem, möchte aber Nginx als Reverse Proxy verwenden bzw. ist der schon mit anderen Servern zusammen lauffähig. Hast Du es mit Nginx auch mal versucht, oder weißt Du vielleicht, warum ich auch nur den Ladescreen sehe...

Danke

Meister Mopper

@xxjooo sagte in Probleme mit Authentifizierung - Apache als reverse Proxy:

stehe vor dem gleichen Problem, möchte aber Nginx als Reverse Proxy verwenden

Da ich Null Ahnung von server block u. co habe, läuft es bei mir mit dem Nginx Proxy Manager (gibt es als docker container und auch Promox LXC) prima.

NEWS

Probleme mit Authentifizierung - Apache als reverse Proxy

Support us

1.5k
Online

30.5k
Users

76.7k
Topics

1.2m
Posts

NEWS

Probleme mit Authentifizierung - Apache als reverse Proxy

Support us

1.5kOnline

30.5kUsers

76.7kTopics

1.2mPosts

1.5k
Online

30.5k
Users

76.7k
Topics

1.2m
Posts