[gelöst] FHEMWEB verschiedene Seiten und Ports

[homa]

Hallo,

in den Beschreibungen stehen es gibt mehrere Seiten mit verschiedenen Ports. Ich bin jetzt erst seit ein paar Tagen dabei und habe default f18 aktiv. Es scheint auch bei einer neu Installation nur noch Port 8083 als default Port zu geben. So weit so gut. Jetzt habe ich diese Seite mit dem Passwordschutz versehen und kann hier auch alle Einstellungen etc. vornehmen.
Nun habe ich versucht eine weitere Webseite anzulegen, mit Port 8084. Hat soweit geklappt. Hier habe ich jetzt fast alles deaktiviert um es meiner Familie zu Verfügung zu stellen. Kein Passwortschutz etc. Aber leider kann man, wenn man die anderen Bereiche/Räume kennt trotzdem dorthin gelangen. Ich weiß, steht auch so in der Beschreibung, aber wie geht man hier besser vor? 
Grüße Matthias

Code Auswählen Erweitern


define homatic FHEMWEB 8084 global
attr homatic defaultRoom Heizung
attr homatic editConfig 0
attr homatic hiddenroom Unsorted,Everything,Schlafzimmer,Fritzbox,Logfile,Commandref,Remote doc,Edit files,Event monitor,Save config,Select style
attr homatic styleData {\
"f18": {\
  "Pinned.menu": "true",\
  "hidePin": "true",\
  "cols.bg": "FFFFE7",\
  "cols.fg": "000000",\
  "cols.link": "278727",\
  "cols.evenrow": "F8F8E0",\
  "cols.oddrow": "F0F0D8",\
  "cols.header": "E0E0C8",\
  "cols.menu": "D7FFFF",\
  "cols.sel": "A0FFFF",\
  "cols.inpBack": "FFFFFF",\
  "savePinChanges": true,\
  "hideLogo": true,\
  "hideInput": true\
}\
}
attr homatic stylesheetPrefix f18


[amenomade]

Mit allowed https://fhem.de/commandref_DE.html#allowed

[homa]

Super Hinweis - Danke! Klappt aber nicht
den Raum all kann ich z.B. immer noch betreten.

Und es ergibt sich noch ein Problem.
Ich habe folgende Zeilen hinzugefügt und vorher homatic in homaticWEB umbenannt,
an die default Zeilen bin ich nicht ran:

...
attr homaticWEB stylesheetPrefix f18

define homaticAllowed allowed
attr homaticAllowed validFor homaticWEB
attr homaticAllowed allowedCommands set,get
...
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define allowed_WEB allowed
attr allowed_WEB basicAuth GEHEIM
attr allowed_WEB validFor WEB
...


Jetzt kommt auch noch folgende Fehler, siehe Anhang.

Es liegt wohl an meinem Dummy mit dem tollen widgetOverride - fhem kann jetzt die Icons nicht mehr generieren ...

# HEIZUNG
define hz.alle.ba dummy
attr hz.alle.ba alias Alle Heizungen
attr hz.alle.ba devStateIcon 1:status_comfort2:2 2:status_standby2:3 3:status_night2:1
attr hz.alle.ba event-on-update-reading .*
attr hz.alle.ba icon taster
attr hz.alle.ba room Heizung
attr hz.alle.ba webCmd state
attr hz.alle.ba widgetOverride state:iconRadio,#808080,1,status_comfort2@FFA500,2,status_standby2@FFA500,3,status_night2@FFA500
#define hz.alle.ba.n notify hz.alle.ba set *.hz.ba $EVENT
define hz.alle.ba.n notify hz.alle.ba set bd.hz.ba,du.hz.ba,hwr.hz.ba,kjh.hz.ba,kkh.hz.ba,klh.hz.ba,sz.hz.ba,wr.hz.ba $EVENT

Gibt es hierfür auch eine Lösung und wie muss ich allowed anpassen?

[rudolfkoenig]

den Raum all kann ich z.B. immer noch betreten.

Mit allowed bzw. in diesem Fall allowedDevices kann man die Raeume nur indirekt authorisieren, indem man die erlaubten Geraete spezifiziert.
Mit "attr WEB hiddenRoom Everything" kann man all unterdruecken.

Jetzt kommt auch noch folgende Fehler, siehe Anhang.

fhemweb_icon verwendet direkte Perl-Abfragen, dafuer muss man perl zu allowedCommands hinzufuegen, mit allen Nebeneffekten.
Vulgo: mit perl sind fuer einen Kundigen alle Moeglichkeiten offen.

[homa]

Hallo Rudolf,

ersteinmal vielen Dank für Deine Antwort. Ja um Perl und Co. zu vermeiden habe ich die Befehlszeile ausgeblendet. Eigentlich wollte ich auch die Detailseiten von den Geräten/Objekten ausblenden bekommen.
Und auf Raum Ebene einfach meine Familienmitglieder drauf lassen. Muss ich wirklich jedes einzelne Gerät wieder freigeben? Und wie verhinder ich die Detailseite?
Oder anders formuliert: Ich suche eigentlich eine Möglichkeit zwischen Administration und normaler Anwender zu unterscheiden. Dazu wollte ich eigentlich nichts weiteres installieren, aber wenn ich das jetzt richtig verstehe brauche ich ein anderes/weiteres Frontend dafür? Schade. Welches würdest Du empfehlen? Tablet UI, Infotablet? Oder lässt sich mein Wunsch doch mit relativ geringem Aufwand realisieren? Weil wenn ich ein weiteres Modul nachinstalliere muss ich die ganzen Schalter und Elemente erneut anlegen bzw. Verknüpfen, oder?
Fragen über Fragen. Entschuldigung dafür, aber es ist echt noch verwirrend für mich.

Grüße
Matthias
 

[rudolfkoenig]

Die Loesung haengt davon ab, welche Ansprueche Du an die Loesung stellst.

FHEMWEB ist nicht fuer reine Bedienung gedacht, und welche der vorhandenen FHEM-Frontends in deinem Fall am besten passt, kann ich mangels Erfahrung mit diesen nicht beantworten.

Wenn es bei FHEMWEB bleiben soll: ich wuerde eine "beschraenkte" FHEMWEB Instanz anlegen mit hiddenRoom (detail/input/save/etc kann man mit hiddenRoom auch verstecken, siehe commandref), und passenden allowed. Voraussetzung ist, dass keine Hacker in der Familie vorhanden sind, in diesem Fall wuerde ich FHEMWEB nicht freigeben.

[homa]

Ich habe versucht mich in die anderen Lösungen einzulesen und komme zu dem Schluß:

... , welche Ansprueche Du an die Loesung stellst.

Eigentlich ist FHEMWEB genau das was ich suche. Es ist auch so schön minimalistisch und brauch keine weitere Installation.

Könnte man FHEMWEB dahingehend erweitern, das es statt hiddenRoom ein forbiddenRoom bzw. permittedRoom einführt?
Wenn man diese Webinstanz dann noch in einen Kioskmodus schaltet, d.h. das der Detail Link nicht erscheint und die Funktion (?detail=sz.ro.aufab) nicht erlaubt wäre es perfekt!
Weil man hat ja schon alle Arbeit für ein Userfrontend damit erledigt. Ich wundere mich das ich der erste bin der nach soetwas fragt.

Ich war beim starten vor ein paar Tagen eigentlich davon ausgegangen das dies möglich wäre. Ich bin auf der Suche für einen Nachfolger von meinem alten knxweb2
Zudem suche ich auch eine Lösung nicht nur für mich, sondern auch für ein Gemeindehaus und dort wäre diese Frontend Bedienung mit den Räumen perfekt und völliog ausreichend.

[rudolfkoenig]

Könnte man FHEMWEB dahingehend erweitern, das es statt hiddenRoom ein forbiddenRoom bzw. permittedRoom einführt?

Vermutlich, ich schaue Implementierungsvorschlaege (Vulgo Patches) gerne an.

Solche Sicherheitsfeatures sind aufwendig zu testen, und es muss staendig geprueft werden, dass sie durch neue Features nicht angreifbar werden, insb. wenn die Grundstruktur nicht fuer sowas ausgelegt ist.

Ich habe aber gerade FHEMWEB erweitert, damit man Raeume aus hiddenroom nicht per modifizierten URL angezeigt bekommt.

[homa]

Ich habe aber gerade FHEMWEB erweitert, ...

Heißt nach einem UPDATE kann ich das direkt testen? Super!

Was ist mit dem Vorschlag die Detail Seite zu verhindern? Wo kann man den Vorschläge einreichen?

[rudolfkoenig]

Was ist mit dem Vorschlag die Detail Seite zu verhindern? Wo kann man den Vorschläge einreichen?

Nirgendwo, hiddenroom detail sollte jetzt schon funktionieren, ist sogar im commandref dokumentiert.

[Virsacer]

Mit Rev 17621 funktioniert das hier leider nicht mehr:

Code Auswählen Erweitern


attr WEB defaultRoom defaultRoom
attr WEB hiddenroom defaultRoom


Gibt es dafür eine Alternative?

[rudolfkoenig]

Was genau ist der Anwendungsfall fuer diese Kombination?

[Virsacer]

Naja, das ist sozusagen meine Startseite
Also wenn ich FHEM aufrufe, oder auf das Logo klicke, kommt dieser Raum...

Der Raum soll aber halt nicht extra nochmal im Menü sichtbar sein...

[rudolfkoenig]

Der Raum soll aber halt nicht extra nochmal im Menü sichtbar sein...

Habs als "Sonderfeature" fuer Dich wieder aktiviert.

[Virsacer]

Ah cool, vielen Dank

[homa]

Hallo Rudolf,

ja jetzt hab ich Dich verstanden. Also das mit dem hidenroom detail klappt. Auch das ich kein Detail in der URL direkt eingebe und somit doch ein Objekt bearbeiten kann - prima!
ABER einen anderen versteckten Raum kann ich immer noch via URL aufrufen - schade.

Ich habe aber gerade FHEMWEB erweitert, damit man Räume aus hiddenroom nicht per modifizierten URL angezeigt bekommt.

Habe ich Dich hier missverstanden?
Sonst wäre es ja genau wie von mir gewünscht. Wobei es sich ja mit dem Wunsch von Virsacer beißt. Daher meine Idee mit dem expliziten forbiddenRoom.

[rudolfkoenig]

ABER einen anderen versteckten Raum kann ich immer noch via URL aufrufen - schade.

Ist das mit dem aktuellen Code auch der Fall ? Aenderungen werden per update erst am naechsten Tag ab 8 verteilt.
Wenn ja, bitte was zum Nachstellen beschreiben.

[homa]

Hallo Rudolf.

Habe heute das Update nach 8:00 Uhr gemacht und es klappt!
Zuerst habe ich den Room all ausprobiert und war schon enttäuscht. Aber ich musste das Schlüsselwort all neben Everything im attr hinzufügen und schon klappte es!
Die anderen Räume gehen jetzt auch nicht via modifizieren der URL.

attr homaticWEB hiddenroom Unsorted,Everything,all,Schlafzimmer,Fritzbox,Logfile,Commandref,Remote doc,Edit files,Event monitor,Save config,Select style,detail

Sieht doch toll aus, so schön einfach ohne Befehlszeile und Details ...
Genauso habe ich mir das vorgestellt.
Danke für Deine Hilfe!

Grüße
Matthias

[Prof. Dr. Peter Henning]

Rudi,

leider hat diese Änderung negative Auswirkungen:

https://forum.fhem.de/index.php/topic,75206.msg851367.html#msg851367
https://forum.fhem.de/index.php/topic,26893.msg851050.html#msg851050

Alle ca. 400 Nutzer der Module

Alarm
YAAHM
Babble

stehen plötzlich vor leeren Räumen.

LG

pah

[rudolfkoenig]

Was ich nicht verstehe: wieso setzen sie alle ein Raum ins hiddenroom, und beschweren sich, wenn sie das nicht mehr sehen?

[Prof. Dr. Peter Henning]

Das machen die Module, nicht die Nutzer. Und nirgendwo steht geschrieben, dass dies "unerwünscht" ist.

Und zwar läuft das so, dass der Raum (z.B. ProfileRoom) zwar "hidden" ist und somit unter den normalen Räumen nicht mehr auftaucht. Aber per Link im oberen Menü eben doch erreichbar ist.

Dadurch, dass Du die Erreichbarkeit von hiddenrooms per modifizierter URL (auf Wunsch eines einzelnen Benutzers...) gesperrt hast, geht der Link auf den vorgeblichen hiddenroom eben nicht mehr.

Allerdings ist Deine Änderung auch nicht ganz konsistent. Denn der Link auf fhem/?room=hidden geht nach wie vor, also warum nicht auf fhem/?room=ProfileRoom

Vorschlag ?

LG

pah

[rudolfkoenig]

Denn der Link auf fhem/?room=hidden geht nach wie vor, also warum nicht auf fhem/?room=ProfileRoom

Mit hidden kann man temporaere Geraete (wie TCP Verbindungen) in allen FHEMWEB Instanzen vom Benutzer verstecken. Ich habe noch kein konkretes Argument gehoert, warum eine Anzeige dieser Daten per URL zu einem Problem fuehrt. Da ich hidden auch nicht dokumentiert habe, sollte der Benutzer es auch nicht als Alternative zu hiddenroom verwenden.

Mit dem dokumentierten hiddenroom verhindert der Benutzer, dass ein bestimmter Raum in einer FHEMWEB Instanz angezeigt wird. Der Wunsch ist mAn verstaendlich, dass wenn man es explizit untersagt, ihn auch nicht per URL aurfrufen kann.

Vorschlag ?

Geraet im Raum "hidden" zu packen, dann muss man auch nicht "global DEFINED" beobachten, um zu wissen, ob eine neue FHEMWEB Instanz angelegt wurde.

[Prof. Dr. Peter Henning]

Bitte bedenke, dass die ca. 300 Installationen von Alarm sicherheitsrelevant sind. Dass Du alle Betroffenen derzeit von der Oberfläche ihrer Alarmanlage abgekoppelt hast, kann ich deshalb nicht akzeptieren.

Alarm als ältestes dieser drei Module ist seit Jahren so implementiert. Es geht eben _nicht_ darum, Geräte zu verstecken. Sondern darum, einen Raum zu schaffen, in dem die Darstellung ganz anders ist, als in den normalen Räumen - und der darum nicht im zweiten Menü organisiert ist, sondern nur per URL erreichbar ist. Bei FLOORPLAN wird das schließlich auch gemacht, und nach genau diesem Muster agieren die drei genannten Module.

Der Wunsch ist mAn verstaendlich, dass wenn man es explizit untersagt, ihn auch nicht per URL aurfrufen kann.

Dem widerspreche ich: Etwas zu "verstecken" ist etwas Anderes, als etwas zu "untersagen".

Ich bitte Dich deshalb im Namen von 400 FHEM-Benutzern

a.) Deine Änderung vorläufig rückgängig zu machen, damit die Betroffenen wieder in ihre speziellen Räume können
b.) Dir etwas Anderes auszudenken. Im Sinne des oben Gesagten wäre es sinnvoll, ein globales Attribut "forbiddenroom" einzuführen - das kannst Du dann wirklich "hart" ausführen.

Falls Du dem nicht nachkommen willst: Eine so weitgehende Änderung, wie die von Dir durchgeführte bedarf eines Vorlaufs, mindestens drei Wochen halte ich für angemessen.

LG

pah

[rudolfkoenig]

Ich finde die Argumente teilweise merkwuerdig und teilweise falsch, aber ich akzeptiere, dass Du jetzt keine Zeit hast, die Module zu fixen, und habe deswegen den Bugfix temporaer entfernt.

[gamauf]

ich bin so frei und zitiere PAHs Post aus anderen Threads auch hier:

Edit: Rudi König hat die Änderung wieder rückgängig gemacht, möchte sie aber doch wieder einführen. Bitte deshalb hier an der

Abstimmung beteiliigen:

https://forum.fhem.de/index.php/topic,92615.0.html



LG

pah

[homa]

Wow, da ist man 2 Tage wieder arbeiten ...

Hallo Rudolf, hallo Peter.

Ich wollte hier keinen Zwist auslösen. Ich finde einen Kompromiss, wie von Dir Peter vorgeschlagen sinnvoll und finde es auch besser das alter Verhalten bei hidden (=versteckt) zu erhalten. Man gelangt also mit einer URL dahin und würde tatsächlich ein neues globales Attribut "forbiddenroom" einführen. Hier erreicht man die Räume nur wenn diese in anderen Instanzen erlaubt sind und auch nur in dieser!
Dadurch ist auch dem User bei der Nutzung mehr Flexibilität gegeben. Wobei ich zugeben muss genau diese mich momentan noch erschlägt, aber genau das reizt an eurem FHEM! Prima und danke dafür.
Ich finde daher die Abstimmung etwas voreilig aber wenn das hier so demokratisch zu geht auch wieder toll.

Viele Grüße
Matthias

[Prof. Dr. Peter Henning]

Hmmm.

Erstens gibt es keinen "Zwist" - wir haben Argumente ausgetauscht, das ist ein gelehrter Disput. Macht man seit Jahrhunderten so. Dass 300 sicherheitsrelevante Installationen negativ betroffen waren, war ein starkes Argument für eine temporäre Rücknahme der Änderung.

Zweitens gibt es keine "Demokratie". Jeder ist für seine Module verantwortlich, und was Rudi König letztlich aus einer Umfrage für Schlüsse zieht, bleibt seine Angelegenheit.

LG

pah

[dev0]

Bitte bedenke, dass die ca. 300 Installationen von Alarm sicherheitsrelevant sind.

Hmmm, nur so am Rande...
Sicherheitsrelevanten Anwendungen sollte man auch nicht ohne Tests aktualisieren, wenn sie keinem QM unterliegen. Und selbst dann nur mit Vorsicht...

[Prof. Dr. Peter Henning]

Sicherheitsrelevante Anwendungen sollte

Seufz. Wer erklärt den FHEM-Nutzern, dass sie mit dem Update vorsichtig sein sollen ? Wir sind in der Regel verwöhnt durch das gute Testen vor irgendwelchen Commits.

LG

pah