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?
Ja bei entsprechender Konfiguration kann ich die passenden Header (Upgrade / Connection) setzen. Gesagt getan, und schon funktioniert es. Danke für den Zaunpfahl!
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:
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.
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.
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?
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?
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?
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.
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.