<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hallo Zusammen,<div class=""><br class=""></div><div class="">hier ist ja wieder richtig Leben in der Bude- sehr schön :) </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Jan 2017, at 18:27, Frank Richter <<a href="mailto:frank.richter83@gmail.com" class="">frank.richter83@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hallo Andreas,<br class=""><br class="">aus meiner Sicht ist die Absicherung per Login absolut wichtig und sollte rein, denn private Kanäle sind auf Dauer/bei diversen verwendeten Geräten einfach unbequem, und jedesmal eine VPN-Verbindung aufzumachen, um kurz nach dem VZ zu schauen, finde auch eher unpraktisch.<br class=""></div></div></blockquote><div><br class=""></div>Coole Idee! Eigentlich…. braucht es die privaten Kanäle dann (fast) nicht mehr. Es sei denn es wäre notwendig “leuten” Zugriff zu geben die aber nicht alles sehen sollen. Da wir keine vollwertige Userverwaltung haben wäre das immer noch ein Fallback.</div><div><br class=""></div><div>Im Sinne von Nutzerorientierung würde ich die privaten Channels aber lieber rauswerfen- ein relativ komplexes Feature (eher eine Krücke) das immer wieder zu Nachfragen führt wo der Kanal denn hin ist.</div><div><br class=""></div><div>Andererseits verwende ich sie bei meinen ca. 50 Channels gerne dafür die seltenen oder in Gruppen enthaltenen überhaupt auszublenden. Aber auch dafür ließe sich sicher eine bessere Lösung bauen.</div><div><br class=""></div><div>Meinungen?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Jetzt ging es im ganzen Thread fast ausschließlich um die High Performance Middleware und nicht um das Login-Feature. </div></div></blockquote><div><br class=""></div>Die Diskussionen zur High Performance Middleware sollten wir aber vielleicht in einen zweiten Thread auslagern- da habe ich etwas ungeduldig Beides vermischt.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Kannst du vielleicht nochmal kurz darauf eingehen, wie sich ein Merge des Features auf neue (per install.sh oder mit einem neuen Image erstellte) und bestehende (durch git pull akualisierte) Installationen auswirken würde?</div></div></blockquote><div><br class=""></div>Erstmal ist die Grundkonfig wie heute, lediglich im Internet verfügbare VZ würden keine Änderungen mehr erlauben bis die Firewall Regeln geändert werden.</div><div><br class=""></div><div>Nicht getestet habe ich was passiert wenn die config template nicht in die config übertragen wird. Aber andererseits: wer keine Angst vor git und composer hat sollte auch ein config File ändern können?!</div><div><br class=""></div><div>Was noch entfallen könnte:</div><div>- DB User ohne Schreibrechte bräuchte es dann nicht mehr</div><div>- ggf private Kanäle</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Laufen die dann noch out of the box oder sind zwingend zusätzliche Schritte notwendig? Wenn ich das richtig sehe, muss für bestehende Installationen auf jeden Fall die volkszaehler.conf.php angepasst werden.</div></div></div></blockquote><div><br class=""></div>S.o.- ja, das wäre notwendig. Workaround im Code möglich aber das möchte ich eigentlich nicht.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Wie ist es mit HTTPS, ist das dann unbedingt erforderlich, oder geht es mit der letzten Änderung (<span style="font-size:12.8px" class="">(=lesender public Zugriff auf VZ)</span>) auch ohne? </div></div></div></div></blockquote><div><br class=""></div>Geht auch ohne. HTTPS ist nur aus Sicherheitsgründen zwingend bevor man User/Passwort darüber schickt. Verifizieren/ abfangen kann ich das aber nicht.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Laut meiner Recherche klappt Let's Encrypt zusammen mit einer DDNS-Adresse nicht immer reibungslos, weil Let's Encrypt die Zahl der Registrierungen pro Domain beschränkt.</div></div></div></div></blockquote><div><br class=""></div>M.e. ist das behoben- LE hat zumindest <a href="http://ddns.net" class="">ddns.net</a> als Dyn Hoster mit aufgenommen und damit ohne Beschränkung.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Ich bin leider noch nicht dazu gekommen, den PR selbst zu testen, weil ich grad keine Installation auf aktuellem Stand habe - da bin ich aber dran…</div></div></div></div></div></blockquote><div><br class=""></div>Na dann wirds Zeit ;)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Grüße</div><div class="">Frank </div></div></div></div></div></blockquote><div><br class=""></div>Viele Grüße, Andreas</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class="">
<div class="gmail_quote">Am 11.01.2017 09:21 schrieb "Andreas Goetz" <<a href="mailto:cpuidle@gmail.com" target="_blank" class="">cpuidle@gmail.com</a>>:<br type="attribution" class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hallo Zusammen,<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-01-03 20:33 GMT+01:00 Andreas Goetz <span dir="ltr" class=""><<a href="mailto:cpuidle@gmail.com" target="_blank" class="">cpuidle@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Hallo,<div class=""><br class=""></div><div class="">Frohes Neues Jahr Zusammen!</div><div class=""><br class=""></div><div class="">Ihr wisst ja dass ich hartnäckig sein kann. In den letzten Tagen haben ich nach dem mißglückten Merge daher massiv Arbeit darein gesteckt alle VZ Komponenten wieder 100%ig funktionsfähig zu machen. </div><div class=""><br class=""></div><div class="">Dazu gehören auch die High Performance Middleware (siehe <a href="https://github.com/volkszaehler/volkszaehler.org/tree/master/misc/tools" target="_blank" class="">https://github.com/volk<wbr class="">szaehler/volkszaehler.org/tree<wbr class="">/master/misc/tools</a>) und der zuletzt nicht mehr korrekt funktionierende push-server (gleicher Link).</div><div class=""><br class=""></div><div class="">Apropos High Performance Middleware: ich muss nochmal Werbung dafür machen dass die MW damit in der Lage ist Requests in wenigen (<10!) Millisekunden zu beantworten. Wäre Klasse wenn wir das in das Image einbauen könnten (@Udo: einmalig kann ich das gerne einrichten, ist im Link aber auch recht gut dokumentiert).</div><div class=""><br class=""></div><div class="">Auf der Basis habe ich dann auch gleiche die Testskripte renoviert und User Authorization neu aufgesetzt (<a href="https://github.com/volkszaehler/volkszaehler.org/pull/551" target="_blank" class="">https://github.com/volkszaehl<wbr class="">er/volkszaehler.org/pull/551</a>). Aus meiner Sicht wäre das Feature damit reif standardmäßig in VZ einzuziehen. Bei Bedarf könnte ich noch eine Option einbauen es ggf. auch komplett abzuschalten falls sich die individuelle Konfiguration der Firewall Regeln dafür als zu aufwändig erweist.</div></div></blockquote><div class=""><br class=""></div><div class="">Mittlerweile sind auchd ie Anforderungen von Klaus (=lesender public Zugriff auf VZ) in den PR 551 mit eingebaut. Wäre es nicht lagsam Zeit die Funktion zu mergen oder gibt es wirklich keinen Bedarf?<br class=""><br class=""></div><div class="">Wenn wirs mergen wollen gäbe es zwei abschließede Punkte:<br class=""></div><div class="">- Default user (user/pass) aus der Konfiguration entfernen?<br class=""></div><div class="">- Gäbe es noch notwedige Anpassungen an den Firewall Regeln vor Release?<br class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Viele Grüße, Andreas</div><div class=""><div class="gmail-m_-4078475045481625896m_-4751800326164236203h5"><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 Aug 2016, at 12:33, Andreas Goetz <<a href="mailto:cpuidle@gmail.com" target="_blank" class="">cpuidle@gmail.com</a>> wrote:</div><br class="gmail-m_-4078475045481625896m_-4751800326164236203m_8307850780852583600Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class="">Hallo Zusammen,<div class=""><br class=""></div><div class="">das prinzipielle Feedback war zwar “brauche ich nicht”, ich habe mir aber trotzdem mal den Spass gemacht, Firewall und User Authorization prototypisch zu implementieren.</div><div class=""><br class=""></div><div class="">Wer damit spielen möchte findet hier den Code: <a href="https://github.com/volkszaehler/volkszaehler.org/pull/458" target="_blank" class="">https://github.com/volks<wbr class="">zaehler/volkszaehler.org/pull/<wbr class="">458</a></div><div class=""><br class=""></div><div class="">Das Ganze basiert auf JSON Web Tokens für Bearer Authentication und sollte tunlichst- da Username/ Passwort übertragen werden- _nur_ über HTTPS Anwendung finden.</div><div class=""><br class=""></div><div class="">Die Änderungen an der vz.conf Datei sollten eigentlich hinreichen erklären was es zu konfigurieren gibt. Freue mich über Feedback im PR. </div><div class=""><br class=""></div><div class="">Viele Grüße, </div><div class="">Andreas</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 15.08.2016, at 11:36, Andreas Goetz <<a href="mailto:cpuidle@gmail.com" target="_blank" class="">cpuidle@gmail.com</a>> wrote:</div><br class="gmail-m_-4078475045481625896m_-4751800326164236203m_8307850780852583600Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Ich mache Jacobs Mail mal als neues Thema auf:<br class=""><br class=""><span class="gmail-m_-4078475045481625896m_-4751800326164236203m_8307850780852583600im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Bei der Durchsicht der URL-Befehle habe ich gesehen, dass anscheinend<br class="">
auch schreibend auf die Datenbank zugreifen kann. Ist das nicht<br class="">
gefährlich, so einen Webserver ins öffentliche Netz zu stellen, wenn<br class="">
jeder daran herum fummeln kann?<br class="">
</blockquote>
<br class=""></span>
Äh, ja, das ist das Prinzip von vz. Allerdings muß man ja die UUID
kennen, um Kanäle und deren Daten manipulieren zu können, deswegen
sollte man die UUID auch geheim halten (und Kanäle nicht einfach public
machen, sonst kann man sie einfach so auflisten). Neue Kanäle anlegen
und nutzen geht aber natürlich schon.<br class="">
M.W. hatte Justin das so konzipiert, damit z.B. <a href="http://demo.volkszaehler.org/" rel="noreferrer" target="_blank" class="">demo.volkszaehler.org</a>
ohne Anmeldung (und Passwort-Recevory, Email etc. pp.) genutzt werden
kann. Faktisch ist es aber heute wohl so, daß die meisten ihren eigenen
VZ-Server laufen haben, da finde ich das eher ungeschickt (zumal die
UUIDs auch etwas unhandlich sind).<br class=""><br class=""></div><div class="">-- snip --<br class=""><br class=""></div>Ich sehe- wenn wir es einfach halten wollen- 2 Anwendungsfälle:<br class=""><br class=""></div>a) Absicherung einer privaten Installation<br class=""></div>b) Usermanagement für eine öffentliche Installation wie demo<br class=""><br class=""></div>Letzteres klammere ich mal aus da es grundlegende Änderungen an VZ erfordern würde. Für a) gibt es verschiedene Möglichkeiten von furchtbar einfach bis etwas umfangreicher:<br class=""><br class=""></div>1) Basic Authentication, also Username + Password. Für ein Mindestmaß an Sicherheit ist SSL erforderlich- das gilt ebenso aber auch für alle weiteren Varianten. Das muss zusätzlich so konfiguriert werden dass vzlogger (aus dem internen Netz) ohne Basic Auth weiterhin seine Daten abliefern kann.<br class=""><br class=""></div>2) Token Authentication: initiales Login per U/P, ab da Token der expired. Dabei hätten wir sogar die Möglichkeit einzelne User zu definieren- imeinfachsten Falle per Konfigurationsdatei, sonst als Datenbankerweiterung. Wenn Datenbankerweiterung dann können wir auch Rechte vergeben (schreiben, löschen, lesen) und Kanäle zu Usern "gehören" zu lassen. <br class="">Weiterhin wäre es ggf. sinnvoll authentifizierten Nutzern auch "private" Kanäle ohne Kenntnis der UUID anzubieten. <br class=""><br class=""></div><div class="">Gibts Bedarf?<br class=""><br class=""></div>Viele Grüße,<br class=""></div>Andreas<br class=""><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div>
</blockquote></div>
</div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>