NEWS
IoBroker (und vis) über ReverseProxy
-
Hallo Homoran,
könntest du die Skripte für die Reverse-Proxy-Konfiguration in die Dokumentation aufnehmen? `
Ja, könnte ich ;-)Aber sag bitte einem js-Legastheniker (und bash + …), welche genau. ggf per PN und mit einem zweizeiler für die Skriptbeschreibung.
Gruß
Rainer
-
Hallo zusammen,
bin ganz neu im iobroker Forum und derzeit eigentlich nur stiller Mitleser.
Habe den Reverse Proxy soweit installiert, leider funktioniert bei mir der Zugriff auf den Reiter Skripte nicht.
Die Seite wird aufgerufen und dann steht oben links in der Ecke "Loading…." und nichts weiter passiert.
Ich habe nur den Eintrag default-ssl.conf übernommen, der für den iobroker.admin notwendig ist.
Alles andere funktioniert auch, nur leider die Skripte nicht.
Kann mir einer von euch vielleicht weiterhelfen?
Vielen Dank
Sascha
-
Ich hab den Javascript-Adapter bei mir nicht installiert. Deswegen ist in der Konfiguration hierfür bisher nichts vorgesehen.
Wahrscheinlich ist eine zusätzliche Regel für den Pfad erforderlich.
Ich kann mir das aber leider erst am Wochenende genauer ansehen.
-
-
Also ich denke es ist alles richtig installiert, und der Reiter ist auch da.
Im internen Netz kann ich meine Skripte ja auch bearbeiten.
Beim Aufruf von extern kommt dann aber nur ne leere Seite mit "Loading".
2863_2017-07-21_081131.jpg -
Hi nobody,
das wäre super nett.
Ich spreche aber nicht von einer zusätzlichen Installation, sondern von dem Standardreiter "Skript" der iobroker.admin Installation.
…nur damit wir vom Gleichen sprechen...
Vielen Dank schonmal
Gruß Sascha `
Hallo Sascha,
ich hab mir das mal etwas genauer angesehen.
Dass der Skript-Reiter beim Laden hängen bleibt, liegt an js-Dateien. Diese hab ich nun explizit für die Admin-Seite aufgenommen.
Leider klappt der Skript-Reiter so immer noch nicht.
Das Problem ist, das der Javascript-Adapter eine eigene Websocket-Verbindung über socket.io aufmacht. Hierfür verwendet er die URL /socket.io/. Diese ist leider identisch zum Verbindungsaufbau bei VIS. Da beim websocket-Aufbau auch im HTTP-Header keine Attribute drin sind, um zwischen Admin und VIS unterscheiden zu können, funktioniert leider nur entweder der Zugriff auf VIS oder auf Skripte.
Der Admin-Adapter selbst baut seine Websocket-Verbindung mittlerweile mit einem relativen Pfad auf, sodass dieser als /iobroker/socket.io/ beim Apache-Server ankommt und somit unterschieden werden kann.
Meine Bitte an Bluefox wäre es, den Pfad für socket.io entweder auch beim Javascript-Adapter relativ zu setzen oder in der URL ein zusätzliches Attribut aufzunehmen, wodurch die Ziele unterschieden werden können. Dann kann ich das Template entsprechend erweitern.
Viele Grüße
Markus
p.s.:
Ich hab das Template im Post 17 entsprechend erweitert.
-
Hi Markus,
vielen Dank.
Aber genau verstehen tue ich nicht, was ich jetzt machen muss…
Bin noch nicht so richtig in der Materie drin :-)
Gruß
Sascha `
Hallo Sascha,
zurzeit kannst du leider garnichts machen. Damit sowohl der Zugriff auf den Reiter Javascript als auch auf die VIS-Seite über denselben Reverse-Proxy-Server möglich ist, müssen alle eintreffenden Anfragen eindeutig dem richtigen Ziel zugeordnet werden können.
Dies ist eben bei der Websocket-Verbindung für die Hintergrundkommunikation des Javascript-Adapters zurzeit nicht möglich, weil die URL hier vollständig identisch mit der für VIS ist. Deswegen gehen die Requests zurzeit an den Webserver-Port für VIS, der sie aber nicht beantworten kann. Ohne eine Änderung an der Anwendung komme ich hier nicht weiter.
-
Ok, das habe ich jetzt verstanden.
Besteht denn die Hoffnung das Bluefox das ändern wird.
Du schreibst, du hast das Template angepasst….was hast du denn dann angepasst?
Grüße
Sascha `
Auch für den Zugriff auf die Admin-Seite wird jetzt die Websocket-Verbindung durchgeleitet. Dies war möglich, weil hier die URL relativ ist.
Die JS-Dateien für den Javascript-Adapter und einige Konfigurationsseiten der Adapter werden nun explizit weitergeleitet. Somit sollte auch der Reiter Skripte vollständig laden. Es werden jedoch keine Skripte angezeigt.
-
Hallo,
ich würde gerne mit dem IPhone von extern auf ein erstelltes vis zugreifen.
Dazu würde ich gerne die App "Vis Viewer" nutzen.
Kann mir einer sagen, was ich machen muss, um den Zugriff über den Apache hinzubekommen?
In der App kann man einen Link für extern eingeben.
In der Apache Konfig Datei gibt es ja die Möglichkeit im oberen Bereich Einstellungen für eine App zu machen.
Ist es das was ich suche? Wie sieht dann der Aufruf der URL aus, da ich ja irgendwie Nutzer und Password mit übergeben muss?
(Via VPN klappt der Zugang, ist nur etwas umständlich…)
Grüße
Sascha
-
Ok, das habe ich jetzt verstanden.
Besteht denn die Hoffnung das Bluefox das ändern wird.
Du schreibst, du hast das Template angepasst….was hast du denn dann angepasst?
Grüße
Sascha `
Auch für den Zugriff auf die Admin-Seite wird jetzt die Websocket-Verbindung durchgeleitet. Dies war möglich, weil hier die URL relativ ist.
Die JS-Dateien für den Javascript-Adapter und einige Konfigurationsseiten der Adapter werden nun explizit weitergeleitet. Somit sollte auch der Reiter Skripte vollständig laden. Es werden jedoch keine Skripte angezeigt. `
Hi nobody,
hast du eine Ahnung, ob das Problem gefixed wurde?
Grüße
Sascha
-
Hallo Sascha,
ich hab mit Bluefox gesprochen und wir haben doch eine Lösung für die Unterscheidung gefunden:
Die Socket-IO-Aufrufe für VIS haben den Parameter key, die für Javascript jedoch nicht. Deswegen habe ich das Skript entsprechend angepasst:
Hier der aktuelle Stand des Skripts:
# Dieses Template enthält Rewrite-Regeln für die Verwendung von Apache 2.4.x als Reverse Proxy mit SSL-Unterstützung für die folgenden Komponenten: # - ioBroker VIS/Flot/Rickshaw # - ioBroker Admin # - ioBroker node-red # - ioBroker socket-io im Web-Adapter # - Zugriff auf CCU1/2 # - ioBroker Javascript-Adapter # # 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 garnicht 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 [ Email des Administrators (Optional)] ServerName [ Externe URL des Servers ohne Protokoll, z.B. haus.meineurl.de] # 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 # 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># Zugriff über URL-Authentifizierung <requireall># Erlaubt auch noch die Einschänkung auf andere Eigenschaften Require expr %{QUERY_STRING} =~ /user=[ Benutzername in der APP ]&pass=[ Passwort in der APP ]/</requireall> # Für alle anderen Zugriffe ist http-Authentifizierung erforderlich Require valid-user</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/apache2/ssl/[ Name der Zertifikatdatei ].crt SSLCertificateKeyFile /etc/apache2/ssl/[ Name der Datei mit dem privaten Schnlüssel ].key SSLCertificateChainFile /etc/apache2/ssl/[ evtl Name der Datei mit der Key Chain bis zum Root-Zertifikat ].crt # 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://[ interne IP ]:1880/$1 [P,L] ProxyPass /node-red/ http://[ interne IP ]:1880/node-red/ ProxyPassReverse /node-red/ http://[ interne IP ]:1880/node-red/</ifmodule> # Prototyp für Foscam Webcam # Der Zugriff auf die Webcam dann extern über https://[ externe URL ]/video1 <ifmodule mod_proxy.c="">ProxyRequests off RewriteEngine On redirectmatch ^/video1$ /video1/ rewritecond %{REQUEST_URI} ^/video1/ rewriterule (.*) $1 [PT] # Referer Auswertung, falls eine lokale absolute Referenz auf den Seiten ist. In diesem Fall wird /video1 ergänzt, damit ProxyPass matched. rewritecond %{HTTP_REFERER} https://[ externe URL ]/video1/ rewriterule ^/(.*) /video1/$1 [PT] ProxyPass /video1/ http://[ interne IP ]/ ProxyPassReverse /video1/ http://[ interne IP ]/</ifmodule> # Rewrite-Regeln für Homematic CCU # Stammt ursprünglich aus Homematic Forum # Der Zugriff auf die CCU efolgt intern weiterhin über http://[ interne IP ] und extern über https://[ externe URL ]/ccu <ifmodule mod_proxy.c="">ProxyRequests off RewriteEngine On redirectmatch ^/ccu$ /ccu/ rewritecond %{REQUEST_URI} ^/ccu/ rewriterule (.*) $1 [PT] # Referer Auswertung, falls eine lokale absolute Referenz auf den Seiten ist. In diesem Fall wird /ccu ergänzt, damit ProxyPass matched. rewritecond %{HTTP_REFERER} https://[ externe URL ]/ccu/ [OR] rewritecond %{HTTP_REFERER} https://[ externe URL ]/webui/ [OR] rewritecond %{HTTP_REFERER} https://[ externe URL ]/pda/ [OR] rewritecond %{HTTP_REFERER} https://[ externe URL ]/api/ [OR] rewritecond %{HTTP_REFERER} https://[ externe URL ]/addons/xmlapi/ [OR] rewritecond %{HTTP_REFERER} https://[ externe URL ]/addons/cuxd/ rewritecond %{HTTP_REFERER} \?sid\=\@.+\@ [OR] rewritecond %{THE_REQUEST} \?sid\=\@.+\@ rewriterule ^/(.*) /ccu/$1 [PT] rewriterule ^/pda/(.*) /ccu/pda/$1 rewriterule ^/webui/(.*) /ccu/webui/$1 rewriterule ^/addons/db/(.*) /ccu/addons/db/$1 rewriterule ^/addons/xmlapi/(.*) /ccu/addons/xmlapi/$1 rewriterule ^/addons/cuxd/(.*) /ccu/addons/cuxd/$1 ProxyPass /ccu/ http://[ interne IP ]/ timeout=1200 ProxyPassReverse /ccu/ http://[ interne IP ]/ timeout=1200</ifmodule> # Rewrite-Regeln für ioBroker Admin # Der Zugriff auf die Admin-Seite efolgt intern weiterhin über http://[ interne IP ]:8081 und extern über https://[ externe URL ]/iobroker # Websocket Admin <ifmodule mod_proxy.c="">RewriteEngine On Redirectmatch ^/iobroker/socket.io$ /iobroker/socket.io/ RewriteCond %{REQUEST_URI} ^/iobroker/socket.io/ RewriteCond %{QUERY_STRING} transport=websocket RewriteRule ^/(.*) /iobrokerwss/$1 [PT] ProxyPass /iobrokerwss/iobroker/socket.io/ ws://localhost:8081/socket.io/ timeout=1200 Keepalive=On</ifmodule> <ifmodule mod_proxy.c="">ProxyRequests off RewriteEngine On redirectmatch ^/iobroker$ /iobroker/ rewritecond %{REQUEST_URI} ^/iobroker/ rewriterule (.*) $1 [PT] rewritecond %{HTTP_REFERER} https://[ externe URL ]/iobroker/ [OR] rewritecond %{REQUEST_URI} ^/css/adapter.css [OR] rewritecond %{REQUEST_URI} ^/js/translate.js [OR] rewritecond %{REQUEST_URI} ^/js/adapter/ [OR] rewritecond %{REQUEST_URI} ^/adapter/ [OR] rewritecond %{REQUEST_URI} ^/js/adapter-settings.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/jqGrid/ [OR] rewritecond %{REQUEST_URI} ^/lib/css/jquery.multiselect-1.13.css [OR] rewritecond %{REQUEST_URI} ^/lib/js/jquery-ui.min.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/loStorage.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/ace.js [OR] rewritecond %{REQUEST_URI} ^/js/selectID.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/loStorage.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/ace.js [OR] rewritecond %{REQUEST_URI} ^/js/selectID.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/mode-javascript.js [OR] rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/worker-javascript.js rewriterule ^/(.*) /iobroker/$1 [PT] ProxyPass /iobroker/ http://[ interne IP ]:8081/ timeout=1200 ProxyPassReverse /iobroker/ http://[ interne IP ]:8081/ 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://[ externe URL ]/vis/ rewritecond %{REQUEST_URI} !^/node-red/ rewritecond %{REQUEST_URI} !^/static/ rewritecond %{REQUEST_URI} !^/socket.io/ rewriterule ^/(.*) /vis/$1 [PT] ProxyPass /vis/ http://[ interne IP ]:8082/ timeout=10 ProxyPassReverse /vis/ http://[ interne IP ]: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://[ interne IP ]:8082/lib/ timeout=10 ProxyPassReverse /lib/ http://[ interne IP ]: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://[ interne IP ]/flot/ timeout=10 ProxyPassReverse /flot/ http://[ interne IP ]: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://[ interne IP ]:8082/rickshaw/ timeout=10 ProxyPassReverse /rickshaw/ http://[ interne IP ]/rickshaw/ timeout=10</ifmodule> # Rewrite-Regeln für die socket.io Websocket-Verbindung von VIS und APP sowie Javascript-Adapter # 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. # Websocket Javascript <ifmodule mod_proxy.c="">RewriteEngine On Redirectmatch ^/socket.io$ /socket.io/ RewriteCond %{REQUEST_URI} ^/socket.io/ RewriteCond %{QUERY_STRING} transport=websocket RewriteCond %{QUERY_STRING} !key= RewriteRule ^/(.*) /wss2/$1 [PT] ProxyPass /wss2/socket.io/ ws://[ interne IP ]:8081/socket.io/ timeout=1200 Keepalive=On</ifmodule> # Websocket VIS <ifmodule mod_proxy.c="">RewriteEngine On Redirectmatch ^/socket.io$ /socket.io/ RewriteCond %{REQUEST_URI} ^/socket.io/ RewriteCond %{QUERY_STRING} transport=websocket RewriteCond %{QUERY_STRING} key= RewriteRule ^/(.*) /wss/$1 [PT] ProxyPass /wss/socket.io/ ws://[ interne IP ]:8082/socket.io/ timeout=1200 Keepalive=On</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://[ interne IP ]:8082/_socket/ ProxyPassReverse /_socket http://[ interne IP ]:8082/_socket/</ifmodule> # Rewrite-Regeln für die socket.io Verbindung im Polling-Modus über HTTPS von VIS und APP sowie Javascript-Adapter # 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. # socket.io Javascript <ifmodule mod_proxy.c="">ProxyRequests off RewriteEngine On Redirectmatch ^/socket.io$ /socket.io/ RewriteCond %{REQUEST_URI} ^/socket.io/ RewriteCond %{QUERY_STRING} transport=polling RewriteCond %{QUERY_STRING} !key= RewriteRule (.*) /adminsocket/$1 [PT] ProxyPass /adminsocket/socket.io/ http://[ interne IP ]:8081/socket.io/ ProxyPassReverse /adminsocket/socket.io/ http://[ interne IP ]:8081/socket.io/</ifmodule> # socket.io VIS <ifmodule mod_proxy.c="">ProxyRequests off RewriteEngine On Redirectmatch ^/socket.io$ /socket.io/ RewriteCond %{REQUEST_URI} ^/socket.io/ RewriteCond %{QUERY_STRING} transport=polling RewriteCond %{QUERY_STRING} key= RewriteRule (.*) $1 [PT] ProxyPass /socket.io/ http://[ interne IP ]:8082/socket.io/ ProxyPassReverse /socket.io/ http://[ interne IP ]: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>Kannst du prüfen, ob dies so auch bei dir funktioniert?
Viele Grüße
Markus
821
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge