Upgrade 5.0 --> 5.1 Webfront Probleme mit Reverse Proxy

Hallo,

ich betreibe Symcon in einer Ubuntu / Docker-Installation mit vorgeschaltetem nginx Reverse-Proxy, der auch das SSL Handling übernimmt und die Verbindung dann unverschlüsselt auf Port 80 der Docker-IP mappt. Soweit alles kein Problem und langjährig erprobt.

Bei Upgrade auf Symcon 5.1 ist kein Zugriff auf passwortgeschützte Webfront-Seiten mehr möglich, sprich das Kennwort wird immer wieder angefordert.

Der Zugriff auf die Web-Konsole via /console URL klappt jedoch problemlos.

Wurde beim Umstieg auf 5.1 das Kennwort-Handling des Webfront geändert? Werden irgendwelche speziellen Header abgeprüft was bei 5.0 noch nicht implementiert war?

Unterstützt Dein Reverse Proxy WebSockets?

paresy

Ja bei entsprechender Konfiguration kann ich die passenden Header (Upgrade / Connection) setzen. Gesagt getan, und schon funktioniert es. Danke für den Zaunpfahl! :slight_smile:

Kannst du mir den Zaunpfahl auch zuwinken? Ich habe die nginx config auch entsprechend angepasst … Dennoch weiterhin kein Login möglich…

Kannst du die Beispielkonfig bitte posten, betreibe Symcon ebenfalls via Composer im Docker.

Hi,

ich hänge mich hier mal mit dazu…
Seit dem Update auf 5.1 funktioniert bei mir auch nichts mehr.

Selbst wenn ich kein Passwort im Webfront setze bekomme ich die Fehlermeldung „Benötige Passwort“.

Ich benutzt auch einen Reverse Proxy.
IIS10 mit URL rewrite was bis zur 5.0 auch perfekt geklappt hat.

Websockets habe ich schon nachinstalliert.
Kann mir jemand sagen was ich noch einstellen muß?

Gruß
Erik

Ich verwende bei mir nginx als Reverse Proxy und lasse ihn auch den SSL-Teil handhaben, d.h. nach nginx geht es mit unverschlüsseltem HTTP weiter zur Container-IP (auf gleicher Hardware).

Folgende Zeilen in der nginx-Konfiguration haben die „Probleme“ mit Web-Sockets bei mir gelöst:

    proxy_http_version 1.1;                                                                                                                                                                                             
    proxy_set_header Upgrade $http_upgrade;                                                                                                                                                                             
    proxy_set_header Connection "upgrade";

Ich bekomme das irgendwie nicht hin mit Symcon 5.1 :frowning:

Ich nutze IIS 10 (Server 2016).
Da der IIS noch andere Dinge macht will ich nicht wechseln.

ARR 3 ist installiert
WebSocket Protocol ist installiert

Der IIS macht das SSL Handling und den Zugriffsschutz

Symcon 5.0
Mit dieser Config funktioniert alles perfekt

<rule name="Symcon">
	<match url="home/(.*)" />
	<action type="Rewrite" url="http://192.168.0.3:82/{R:1}" />
</rule>

Alles über „https://home.meineadresse.de/home/“ geht auf den Rechner auf dem Symcon läuft.

Symcon 5.1
Geht mit der Config von oben nicht
Dies ist der aktuelle Stand

<rewriteMaps>
	<rewriteMap name="MapProtocol">
		<add key="https" value="http" />
		<add key="wss" value="ws" />
	</rewriteMap>
</rewriteMaps>				
<rules>
	<rule name="Symcon" stopProcessing="true">
		<conditions logicalGrouping="MatchAll" trackAllCaptures="true">
			<add input="{CACHE_URL}" pattern="^(.+)://" />
		</conditions>
		<match url="home/(.*)" />
       	        <action type="Rewrite" url="{MapProtocol:{C:1}}://192.168.0.3:82/{R:1}" />
	</rule>
</rules>

Das macht aus „http:“ „http“ und aus „wss“ „ws“
Geht aber auch nicht.

In der Console von Chrome sieht man diese Fehlermeldung:
WebSocket connection to ‚wss://home.meineadresse.de/api/wfc/16855‘ failed: HTTP Authentication failed; no valid credentials available

Interessant ist das ich kein Passwort in Symcon gesetzt habe und die Adresse wahrscheinlich falsch ist.
Es müsste doch eigentlich in meinem Fall „wss://home.meineadresse.de/home/api/wfc/16855“ sein, oder?
home.meineadresse.de/api“ existiert auch und gehört aber zu etwas anderem.

Wäre super wenn einer eine Lösung für den ISS hat.

Erik

Ich habe leider keine Ahnung vom IIS, aber deine Vermutung mit der falschen URL ist korrekt - denn diese Fehlermeldung werfen wir nicht :slight_smile:

paresy

Ich vermute du willst zwei regeln machen. Die eine mit HTTP scheint ja zu gehen und dann die zweite für WS, welche dann in der URL dein /home noch drin hat.

paresy

Bei mir übernimmt ein Apache2 den Reverse Proxy. Ich musste auch die Konfiguration für die WebSockets erweitern:


<VirtualHost *:443>
...
  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /(.*) ws://localhost:3777/$1 [P,L]

  ProxyPass / http://127.0.0.1:3777/
  ProxyPassReverse / http://127.0.0.1:3777/
...
</VirtualHost>

Es scheint wirklich an der URL zu liegen
Statt „wss://home.meineadresse.de/home/api/wfc/16855“ ruft Symcon „wss://home.meineadresse.de/api/wfc/16855“ auf.
Als „quick&dirty“ Lösung habe ich mal in der webfront.js folgende Zeile hinzugefügt.(bei Zeile 3027 vor var u=new WebSocket(a,b))
a = a.replace(„meineadresse.de/api/“, „meineadresse.de/home/api/“)

Und schon geht es…
Aber das kann ja keine Dauerlösung sein.

Hilft das um herauszufinden was beim IIS noch eingestellt werden muss?

Gruß
Erik

Hi, Ich hänge nun auch fest seit dem Umstieg auf 5.1

Ich kann von außen nicht mehr auf das Webfront drauf. Wenn ich auf den Link der auf ipmagic verweist klicke, geb ich mein Kennwort ein und dann muss ich es immer wieder eingeben. Muss dazu sagen das ich keine Ahnung von Proxy oder sonst was hab. Ging ja vorher auch alles. Woran kann das noch liegen?

Du nutzt also den normalen Connect Dienst? Hat dein Kennwort irgendwelche Sonderzeichen? Kannst du mal probieren ein einfaches Kennwort zu setzen?

paresy

Kann es sein das Symcon doch nicht ganz unschuldig ist?

Hat jemand einen Reverse Proxy mit 5.1 laufen bei dem ein Unterverzeichnis benutzt wird?
d.h. Zugriff von außen z.B. meineadresse.de/symcon/ statt meineadresse.de/

Auf jeden Fall baut Symcon in der webfront.js die URL vom WebSocket falsch zusammen.
Fragt sich nur warum…
Mein Webfront ist von außen über https://home.meineadresse.de/home/#16855" erreichbar
Statt „wss://home.meineadresse.de/home/api/wfc/16855“ ruft Symcon „wss://home.meineadresse.de/api/wfc/16855“ auf.

@paresy
Wie ermittelt Symcon die URL für den WebSocket?

Gruß
Erik

Das wird so sein, aber warum machst du das?
Ich habe für jeden Dienst eine eigene Subdomain. Somit flutscht das perfekt.
Michael

Ich habe zum nächsten Update mal etwas mehr Logik eingebaut, sodass wir den Pfad mit einbeziehen bei der Berechnung der WebSocket URL. Du kannst ja berichten ob es hilft. Es sollte dann Log der Entwicklerkonsole vom Browser auch eine passende Ausgabe geben.

paresy

Geht leider immer noch nicht.

webfront.js:1120 Rewriting URL with path segment: /home/
webfront.js:3027 WebSocket connection to 'wss://home.meineadresse.de/api/wfc/16855' failed: Error during WebSocket handshake: Unexpected response code: 404

Es erscheint etwas mit „path segment“, berücksichtigt für die URL wir es aber nicht.

Erik

Vielen Dank für dein Feedback. Ich habe noch einen kleinen Fehler gefunden. Zum nächsten Update sollte der erkannte Pfad dann auch sauber genutzt werden.

paresy

Der Fix ist leider nicht im aktuellen Update mit dabei - kommt aber zum nächsten Beta-Update.

paresy