SVN-Editor auf Fremdhardware

[makki]

Solange dir das Kontextfreie gesabber ohne Leistung dafür nicht langweilig wird: nein

Makki

[netzkind]

Ist angedacht irgendwann mal die dependencies zum WireGate etwas aufzulockern?
Die GAs könnte man ja über ein script aus einem ets-csv/whatever in das eibga.conf Format quetschen ... ow_sensors evtl. auch ... naja wenn ich mal Luft hab schau ich mir die genauen Abhängigkeiten mal an.

Diese dependencies bestehen ja nurnoch durch die dataprovider im Editor, soweit ich weiß. Da kann man sich sicher Gedanken darum machen, ob man für andere Plattformen andere dataprovider entwickeln will. Der Code ist in PHP, und sollte eigentlich relativ ordentlich dokumentiert sein. Der eigentlichen Visu ist relativ egal, wo es die Daten herbekommt.
Alternativ kann man die dataprovider auch erst mal so umstellen, dass sie im Falle fehlender Dateien nicht gleich ausflippen, sondern eine leere Antwort liefern. Damit wäre die depencide aufgebrochen, zu Lasten der UX.

[JuMi2006]

Hallo Julian,

was heißt zulasten der UX ? Hier fehlt mir einfach das Wort hinter der Abkürzung.
Ich könnte mir eine (optionale) cometvisu.conf vorstellen die dann den Pfad in den benötigten dataprovidern einstellen lässt.

Um an der Syntax innerhalb der Provider nicht mehr schrauben zu müssen könnte man ja auch ein perl/php/cgi Script bauen das z.B. einen ETS-Export parst. Für mich ist die ETS (auch wenn ich die 4er noch nicht nutze) eben erstmal der zentrale Sammelpunkt für alle Gruppenadressen. Alles was (in)direkt aus der ETS "fällt" und gleich verwendet werden kann ist daher Gold Wert.

Dies soll jetzt keine Aufforderung sein das zu tun! Für mich wäre es mittlerweile kein Problem die Abhängigkeiten entsprechend zu beseitigen, zumal ich eine gepflegte eibga.conf und owsensors.conf ja auf meinem WireGate zu liegen habe.
Bezüglich der Konfiguration und usability hat m.M. nach die CometVisu immernoch die Nase vorn und ich würde, egal wie sich meine Hardware mal entwickelt dieser gern treu bleiben.

Ich sehe es immer als endlosen Kreis: Mehr User => mehr "Freaks" => mehr Features => große Community

Vor einem Jahr hätte ich auch nie gedacht mal selbst was zu kompilen, eigene Scripte zu schreiben und halbwegs sinnvoll eine FireBug Ausgabe zu interpretieren. Durch andere Baustellen konnte ich dem letzten Vierteljahr dem SVN aber nur noch bedingt folgen.

Grüße
Mirko

[Robert]

user-xperience

[prz]

Diese dependencies bestehen ja nurnoch durch die dataprovider im Editor, soweit ich weiß. Da kann man sich sicher Gedanken darum machen, ob man für andere Plattformen andere dataprovider entwickeln will. Der Code ist in PHP, und sollte eigentlich relativ ordentlich dokumentiert sein. Der eigentlichen Visu ist relativ egal, wo es die Daten herbekommt.
Alternativ kann man die dataprovider auch erst mal so umstellen, dass sie im Falle fehlender Dateien nicht gleich ausflippen, sondern eine leere Antwort liefern. Damit wäre die depencide aufgebrochen, zu Lasten der UX.

Da haette ich gerne etwas fundierte Meinung von den Gurus hier, da ich gerade auf neue Platform portiere (wie schon gesagt, mehr detail in paar wochen).

Ich habe hier eine platform, da kann ich ganze address configs einfach ueber ajax von der platform holen & viele andere Zauber & brauche keine php magic dafuer eigentlich. Soll ich den manager fixen, damit der mehrere providers zulaesst.

Wie mache ich das ? mache ich dataprovider einfach zu einem array, da gibt's ein $each(DataProviderConfig, ... ?? Der momentane DataProviderConfig ist nichts dergleichen, der erlaubt einfach eine '*' wildcard und einzelne Elemente. Mir ist die Architektur da nicht ganz klar.

Zu Graphen werde ich dann noch spaeter kommen.

[netzkind]

Da haette ich gerne etwas fundierte Meinung von den Gurus hier, da ich gerade auf neue Platform portiere (wie schon gesagt, mehr detail in paar wochen).

Ich habe hier eine platform, da kann ich ganze address configs einfach ueber ajax von der platform holen & viele andere Zauber & brauche keine php magic dafuer eigentlich. Soll ich den manager fixen, damit der mehrere providers zulaesst.

Wie mache ich das ? mache ich dataprovider einfach zu einem array, da gibt's ein $each(DataProviderConfig, ... ?? Der momentane DataProviderConfig ist nichts dergleichen, der erlaubt einfach eine '*' wildcard und einzelne Elemente. Mir ist die Architektur da nicht ganz klar.

Ja nein vielleicht.
Ich versteh die Frage nicht.

Wenn der User im Editor eine Eigenschaft zum Bearbeiten auswählt, wird in der DataProviderConfig geschaut, ob es zu diesem speziellen Element und der Eigenschaft einen Provider gibt, inkl. Fallback per Wildcard. Ist dem so, werden die Daten ermittelt und dem Editor für dessen Auswahllisten übermittelt.

Die Dataprovider sind ein genereller Ansatz um Daten aus beliebiger Quelle zu einzelnen Elementen des Editors zu ermitteln. Nicht alle Daten sind statisch, und vor allem stammen nicht alle Daten vom Server, sondern ein Teil wird live aus der Config generiert.

Wenn du jetzt sagst, du kannst das alles statisch vom Server laden, dann verstehe ich die Frage noch viel weniger.

(ich hab aber auch nicht verstanden wieso du sagst PHP < 5.4 sei unsicher, also vielleicht fehlt mir da grundsätzlich der Draht zu deinem Ansatz)

Grüße,
Julian

[prz]

Ja nein vielleicht.
Ich versteh die Frage nicht.

Wenn der User im Editor eine Eigenschaft zum Bearbeiten auswählt, wird in der DataProviderConfig geschaut, ob es zu diesem speziellen Element und der Eigenschaft einen Provider gibt, inkl. Fallback per Wildcard. Ist dem so, werden die Daten ermittelt und dem Editor für dessen Auswahllisten übermittelt.

Die Dataprovider sind ein genereller Ansatz um Daten aus beliebiger Quelle zu einzelnen Elementen des Editors zu ermitteln. Nicht alle Daten sind statisch, und vor allem stammen nicht alle Daten vom Server, sondern ein Teil wird live aus der Config generiert.

Wenn du jetzt sagst, du kannst das alles statisch vom Server laden, dann verstehe ich die Frage noch viel weniger.

(ich hab aber auch nicht verstanden wieso du sagst PHP < 5.4 sei unsicher, also vielleicht fehlt mir da grundsätzlich der Draht zu deinem Ansatz)

Grüße,
Julian

OK, ich versuche klarer zu sein:

so wie man backends aus-swappen kann, muesste man vielleicht dataproviders ausswappen koennen (ich weiss, das ist dann NICHT configuration file spezifisch sondern CV spezifisch, so ein 'global' setting halt). Momentan heisst das DataProviderManager, eigentlich aber gibt's nur property & wildcard von EINEM DataProvider, der halt ueber solche phps implementiert wird.

Wenn ein DataProvider e.g. ueber JSON die ganzen address configs laden kann
vom server dann muss man halt diese eine DataProviderConfig (mache ich gerade)
umbiegen. Oder Ihr versteht unter Manager einen PropertyManager unter EINEM
moeglichen proiver and nicht Manager von mehreren DataProviders (wie es der Name suggeriert fuer mich).

Hoffe dies etwas klarer nun


wegen PHP:

PHP PHP version 5.3.3 : Security vulnerabilities

[netzkind]

Momentan heisst das DataProviderManager, eigentlich aber gibt's nur property & wildcard von EINEM DataProvider, der halt ueber solche phps implementiert wird.

Also ich sehe da (in der DataProviderConfig) ein halbes Dutzend DataProvider, unter anderem einen für RRDs, einen für Gruppenadressen, einen für Designs, einen für DPTs, Stylings, Mappings,...

DataProvider sind jeweils die Skripte/Dateien welche die Daten zu einem "Feld" liefern (vgl. vorgenannte Liste). Der DataProviderManager verwaltet auf Editor-Seite "nur" den Zugriff, Prefetching und das Caching dieser Provider.

Irgendwo gibt es also eine Diskrepanz zwischen dem wie du den Code liest, und wie ich ihn lese (und geschrieben habe), wenn du nur einen einzigen DataProvider siehst.

Zum Thema PHP hast du mit 5.3.3 aber auch wahrlich keine aktuelle Version gewählt. Hatte mir schon Gedanken gemacht, da ich beruflich viel mit 5.3 zu tun habe, aber die Sorge ist für mich dann doch unberechtigt :-)

Grüße,
Julian

[prz]

OK, ja, dann habe ich einfach missverstanden was Du unter 'DataProvider' versteht.

Fuer Dich ist ein 'Field-data-provider' ein Dataprovider, fuer mich war es eher ein 'dataprovider' fuer alle felder (eben halt data). Das ist ok, design decision.

Ich loese es jetzt indem ich 'monkey-patching' mache am schluss und gewaehlte providers ueberschreibe am ende des files. Nicht elegant aber was besseres ist mir
nicht eingefallen.

PHP, bin kein grosser kenner davon, habe aber paar server in betreung und da wurde von 4.x bis 5.3 aufgebrochen wie rohe eier ueber irgendwelche shops & admin apps, seit 5.4 ist etwas besser, darum tendiere ich zu 5.4.

[swiss]

Naja...
Da die CometVisu selbst absolut sicherheitsfrei ist, und auch nicht direkt in's Internet durch geschaltet werden sollte!, hallte ich das Sicherheitsproblem von PHP für Gering. Da müsste erst jemand den VPN hacken und dann braucht er auch nicht mehr PHP zu knacken sondern ist eh schon drin...

[Chris M.]

Naja...
Da die CometVisu selbst absolut sicherheitsfrei ist, und auch nicht direkt in's Internet durch geschaltet werden sollte!, hallte ich das Sicherheitsproblem von PHP für Gering. Da müsste erst jemand den VPN hacken und dann braucht er auch nicht mehr PHP zu knacken sondern ist eh schon drin...

Ja und Nein.

Die CometVisu hat keinerlei Sicherheitsfeatures eingebaut, da das der falsche Level ist:
Man kann aber (wenn man kann!) den Web-Server entsprechend absichern (-> HTTPS, Authentifizierung) über den dann die CometVisu läuft.

Das sollte gleich sicher sein wie ein VPN - aber man muss schon wissen was man macht! Dann wäre aber auch jegliches mögliche PHP Problem damit gelöst.

Davon unabhängig: das CometVisu-Protokoll unterstützt eine Authentifizierung (im CometVisu-Client nur sehr rudimentär umgesetzt, in der CometVisu Visualisierung ungenutzt). Das dient aber nicht dem Schutz vor externen Angreifen - dazu ist VPN oder HTTPS gedacht! Das könnte man dazu verwenden auf Bus-Adress-Ebene zu filtern und vor z.B. Fehlbedienungen zu schützen.
Da im Privat-Haus egal, ist's bisher noch nicht detaillierter implementiert. Und wer's schon jetzt brauchen sollte, ist vermutlich mit Filtern auf dem KNX selbst deutlich besser beraten (-> interner Filter vs. dedizierter Firewall).

[prz]

Ja und Nein.

Die CometVisu hat keinerlei Sicherheitsfeatures eingebaut, da das der falsche Level ist:
Man kann aber (wenn man kann!) den Web-Server entsprechend absichern (-> HTTPS, Authentifizierung) über den dann die CometVisu läuft.

Das sollte gleich sicher sein wie ein VPN - aber man muss schon wissen was man macht! Dann wäre aber auch jegliches mögliche PHP Problem damit gelöst.

Davon unabhängig: das CometVisu-Protokoll unterstützt eine Authentifizierung (im CometVisu-Client nur sehr rudimentär umgesetzt, in der CometVisu Visualisierung ungenutzt). Das dient aber nicht dem Schutz vor externen Angreifen - dazu ist VPN oder HTTPS gedacht! Das könnte man dazu verwenden auf Bus-Adress-Ebene zu filtern und vor z.B. Fehlbedienungen zu schützen.
Da im Privat-Haus egal, ist's bisher noch nicht detaillierter implementiert. Und wer's schon jetzt brauchen sollte, ist vermutlich mit Filtern auf dem KNX selbst deutlich besser beraten (-> interner Filter vs. dedizierter Firewall).

Bin mit Chris im weitesten einverstanden. VPNs sind recht muehsam in Konfiguraiton und ueberfordern Leute ziemlich schnell (*aus eigener Erfahrung mit Installationen). Und CV ist sicher nicht fuer sicherung der visu gegen BUS zustaendig selber.

Wenn aber ein Protokoll unter CometVisu laeufen kann das die Schnittstelle gegen den 'server' sichert, authentiziert, cryptet etc. dann ist es ohne weiteres moeglich CometVisu von aussen zu betreiben mit einem einfachen 'port punch through' auf der firewall (oder wenn server direkt am internet, sogar ohne). Die Konfiguration in CV fuer server/port ist entweder local zum device (man will ja eben das nicht in der visu datei haben) oder man koennte eine kleine login box der visu verpassen, die merkt, dass eibd-server != lokaler server in javascript & die aufpoppt. Jemand schon daran gearbeitet oder Lust ? Protokoll bringe ich ;-)

[henfri]

Hallo,

das hier ist doch die Lösung, oder?

Sehr gut.

Änder mal Zeile 72 des Skriptes von

$arrData = json_decode(stripslashes($strJson), true);

in

if (true === function_exists("get_magic_quotes_gpc") && 1 == get_magic_quotes_gpc()) {
    // magic_quotes are on, so we have to remove those unneccessary slashes from input
    $arrData = json_decode(stripslashes($strJson), true);
} else {
    $arrData = json_decode($strJson, true);
}

So verstehe ich das hier zumindest..

Perfekt!
Kann so ins SVN und kommt mit aufs Raspberry-Image ... besten Dank.

Es ist aber noch nicht im SVN, oder?

Gruß,
Hendrik

[JuMi2006]

Doch ist mit Rev. 1601 rein und sollte auch noch drin sein.

SourceForge.net Repository - [openautomation] Diff of /CometVisu/trunk/src/editor/bin/save_config.php

[henfri]

Tatsache. Ist drin.

Dennoch habe ich das Problem, das du vor der Änderung hattest (unexpected token).
Werde bei Gelegenheit mal gucken, ob ich mehr Infos schicken kann.

Gruß,
Hendrik