Apache restart ist nicht notwendig- wozu auch? Viele Grüße, Andreas
> On 18. Mar 2018, at 13:59, Frank Richter <frank.richte...@gmail.com> wrote: > > Hallo Michael, > > versuch's mal damit: > > git fetch origin pull/659/head:auth > git checkout auth > composer update > cd etc > sudo mv volkszaehler.conf.php volkszaehler.conf.backup.php > cp volkszaehler.conf.template.php volkszaehler.conf.php > sudo nano volkszaehler.conf.php > 1) falls erforderlich, DB-Einstellungen und -Passwort wieder anpassen > 2) Firewallregeln checken (im Lieferzustand ist im lokalen Netz alles > erlaubt, von Remote geht lesender Zugriff (GET) ohne, alles andere nur mit > Login) > 3) bei 'secretkey' ein paar zufällige Zeichen einsetzen (= salt) > 4) bei 'user' => 'pass' eigene Zugangsdaten eintragen (oder nur mal kurz > testen und dann die Zeile löschen/auskommentieren, falls kein HTTPS vorhanden > ist!) > systemctl restart apache2 > > zurück zum Stand vorher geht es mit: > git checkout master > mv volkszaehler.conf.backup.php volkszaehler.conf.php > systemctl restart apache2 > > Viele Grüße > Frank > > Am 18. März 2018 um 13:29 schrieb Michael Koch <princemi...@gmail.com > <mailto:princemi...@gmail.com>>: > Hallo alle zusammen, > > ich muss euch noch mal fragen wie ich das ganze testen kann. > Kann mir jemand noch mal kurz zusammen fassen, was ich tun muss um den PR > "Add basic login capabilities #659" auszuprobieren? > Sprich: Was miss ich an git befehlen ausführen und wie muss ich die config > ändern? Außerdem habe ich etwas von einem salt in Erinnerung. > Ich habe in der zwischenzeit meinen Server auf PHP7 geupdatet und möchte jtzt > endlich weiter machen - entschuldigt das ich so lange benötigt habe. > Ich weiß, dass andi mir auch schon mal geschrieben hat - ich finde diese > infos aber nicht mehr. > Danke, > > Michael > > > Am 22.01.2018 um 23:48 schrieb Frank Richter: >> Hi Frank, >> >> im lokalen Netz juckt dich das alles nicht. Das einzige, was du machen >> musst, wenn der PR gemergt ist, ist beim nächsten Update (git pull) deine >> volkszaehler.conf.php auf den aktuellen Stand zu bringen. Ansonsten ändert >> sich nix für dich. >> >> Tokens generieren geht mit misc/tools/token-helper.php, wenn du das doch mal >> brauchst. >> >> Grüße >> Frank >> >> Am 22. Januar 2018 um 23:30 schrieb F. S. <mailing3...@googlemail.com >> <mailto:mailing3...@googlemail.com>>: >> Hallo vz-ler, >> >> und Danke Justin für die gute Zusammenfassung! Ich bin softwaretechnisch >> nicht so fit wie Ihr, aber jetzt verstehe ich die wichtigsten Zusammenhänge. >> >> Also wenn im LAN kein höheres Sicherheitslevel platziert wird, wäre ich sehr >> dafür. Ich gehe von außen nur per VPN rein. >> Wenn mir noch jemand ein Tip gibt, wie man sich denn die Token generiert, >> wäre ich auch damit einverstanden. >> Bei mir fliegen die Cookies übrigens auch nach jeder Firefox-Sitzung raus. >> >> Btw - wer zahlt eigentlich aktuell den Server? Gibt es eine Möglichkeit, >> Euch finanziell zu unterstützen? Ihr investiert hier derart viel Zeit, dass >> einem ganz unwohl wird. Vielen Dank dafür! Viele wissen das zu schätzen. >> >> VG >> Frank S. >> >> >> Am 22.01.2018 10:44 nachm. schrieb "Justin Otherguy" >> <jus...@justinotherguy.org <mailto:jus...@justinotherguy.org>>: >> Hi, >> >> Puh - ich versuch mal zusammenzufassen, was ich verstanden habe: >> >> - derzeit gibt es (alt) keine Auth, sondern nur eine UUID, mit der alles >> möglich ist; das ist doof, weil jeder der die UUID alles tun kann >> - neu gibt es - Andreas sei Dank - die Möglichkeit, sich per User+Pwd zu >> authentisieren >> - das ist eine Option, die man - zB für einen Betrieb im LAN - auch >> ungenutzt lassen kann >> >> Korrekt soweit? >> >> >> Frage: welche Optionen soll es künftig geben? >> >> Nach meinem Verständnis hat man heute doch folgende Hierarchie: >> >> - User+Pwd stehen ganz oben - daraus kann man sich alles weitere generieren >> >> - zB einen Token (vgl. API-Key/secret oder …) für den Zugriff >> - welche Berechtigungen mit diesem Token einhergehen, lässt sich im Prinzip >> konfigurieren >> - ich könnte mir also mehrere Tokens erstellen, die unterschiedliche >> Berechtigungen haben: >> - read-only für mein Display (oder zur Weitergabe an Leute, die die >> Datenreihe auch sehen können sollen) >> - read-write für meinen Sensor >> - … >> - die Tokens kann ich jederzeit widerrufen oder die Berechtigungen anpassen >> - das Token hat keine feste Gültigkeitsdauer; potenziell zeitlich unbegrenzt >> >> >> - ganz unten in der Kette gibt es das Cookie >> - dieser wird aus dem Token generiert und ist Client-spezifisch >> - bei einem Neustart des Clients wird dieser ggf. gelöscht oder ungültig >> gemacht >> - dann muss er - aus dem Token oder User+Pwd - neu erzeugt werden >> >> Soweit immer noch korrekt? >> >> >> Wir haben im Moment ein Token, welches im Cookie abgelegt wird. Da müssen >> wir uns nach meinem Verständnis entscheiden, ob wir wollen, dass es sich >> eher wie ein Token (unbeschränkte Laufzeit, Client-übergreifend) oder eher >> wie ein Cookie (beschränkte Laufzeit, Client-spezifisch) verhält. >> >> >> Egal welche Ebene (User+Pwd, Token, Cookie): solange diese gültig sind, >> sollte ich auf diese gut aufpassen. Sind sie in falsche Hände geraten, >> können sie missbraucht werden und sollten daher geändert/ungültig gemacht >> werden. >> >> >> Konkret: >> - für vzlogger würde ein Cookie nicht ausreichen - der bräuchte einen Token, >> der dauerhaft gilt. >> >> - wenn ich Token oder Cookie lösche oder ungültig mache, muss ich es neu >> erzeugen (Eingabe User+Pwd) >> >> - „Token aus dem Cookie auslesen“: ergibt für mich keinen Sinn (vllt. habe >> ich etwas falsch verstanden); entweder wir unterscheiden nicht - dann können >> wir hin- und herwandeln (bzw. -kopieren) oder wir unterscheiden - dann aber >> kann man aus dem Token zwar das Cookie generieren, aber nicht umgekehrt >> >> - „Token ungültig machen“ - kommt m.E. ebenfalls daher, dass wir nicht >> zwischen Token und Cookie unterscheiden; anderenfalls könnte man Tokens (die >> dann Server-seitig gespeichert würden) ungültig machen - Cookie hingegen >> nicht:; durch die begrenzte Laufzeit wäre das aber auch tolerierbar >> >> >> Frage: >> Sind die Tokens derzeit Kanal-spezifisch? Also: gilt ein Token immer nur für >> einen Kanal oder kann ein Token (so wie User+Pwd) auch für mehrere Kanäle >> berechtigt sein? >> >> >> Mein Vorschlag: >> - (weiterhin) keine Unterscheidung zwischen „Auth-Code in Cookies" und >> „Tokens“; ein Token kann auch per Cookie übermittelt werden >> Das würde das Thema nur aufblähen, ohne einen deutlichen Gewinn (ich lass >> mich vom Gegenteil überzeugen - eine Unterscheidung wäre m.E. sauberer) >> >> - Tokens können mit Berechtigungen versehen werden (read >> only/read-write/write-only?/weitere?) >> >> - jedes Token kann für mehrere Kanäle berechtigt werden; wenn wir das gebaut >> bekommen: auch unterschiedlich: Token A darf Kanal n lesen und Kanal m >> schreiben; vermtl. ist das aber verzichtbar, weil anderenfalls in vzlogger >> eben für jeden Kanal ein separates Token mitgegeben wird - auch kein >> Beinbruch, oder? >> >> Damit hätten wir: >> - weiterhin die Möglichkeit, alles so zu belassen wie bisher (zB >> LAN-Installation) >> - die Möglichkeit, Daten Read-only weiter zu geben >> - die Möglichkeit, einzelne Kanäle auch vor lesendem Zugriff zu schützen >> - ggf. write-only Kanäle zu bauen >> >> Was meint Ihr? >> >> >> Gruß, J. >> >> >> > Am 21.01.2018 um 16:59 schrieb Andreas Goetz <cpui...@gmail.com >> > <mailto:cpui...@gmail.com>>: >> > >> > Hallo, >> > >> >> On 21. Jan 2018, at 15:50, Daniel Lauckner <v...@jahp.de >> >> <mailto:v...@jahp.de>> wrote: >> >> >> >> Hallo, >> >> >> >> >> >> am Sonntag, 21. Januar 2018 um 15:42 hat Frank Richter geschrieben: >> >>> Wer seine Cookies löscht, muss sich halt danach im Frontend neu >> >>> anmelden, aber das ist ja bei anderen Seiten nicht anders. >> >> >> >> Ja, und es nervt. >> > >> > Dann tu’s nicht :) >> > >> > Wie Frank schrieb: >> > >> >> Aber wenn du nichts an der Standardconfig änderst, sind GET-Requests eh >> >> nicht betroffen, du wirst also beim normalen Zugriff aufs Frontend nicht >> >> von einer Passwortabfrage behelligt. >> > >> > Also kein Problem. In der Diskussion ging es darum wie man den Zugriff von >> > außen vernageln kann und trotzdem noch mit vzlogger reinkommen. >> > >> >> >> >> Kann man User/Passwort auch mit der URL übergeben? >> > >> > Nein, sicher nicht. Weil das Passwort bei absolut jedem Proxy im Logfile >> > landen würde. >> > >> > @Frank: Cookie geht jetzt auch: >> > >> > // authorization header? >> > if (($header = >> > $request->headers->get('Authorization')) && (0 !== strpos($header, 'Bearer >> > '))) { >> > $jwt = substr($header, strlen('Bearer ')); >> > } >> > // authorization cookie? >> > elseif ($cookie = >> > $request->cookies->get('vz_authtoken')) { >> > $jwt = explode('@', $cookie)[0]; // split >> > @middleware portion >> > } >> > else { >> > throw new \Exception('Missing authorization >> > token'); >> > } >> > >> > Ich schiebs bei Gelegenheit in den PR. >> > >> > >> >> Anpassung des Installscripts bzgl. Firewall-Einstellungen sollten wir >> >> dann auf die Agenda setzen. Zusätzlich sollten wir diesen Part vielleicht >> >> als Extra-Script liefern, damit die Image-User sich das passend >> >> konfigurieren können, ohne das komplette Installscript nochmal >> >> durchzuackern. Das Image sollte dann am besten ohne eingetragenen >> >> secretkey geliefert werden, oder? >> >> Aus meiner Sicht damit “fertig”. >> > >> > Brauchen wir egtl. alles nicht. Der interne Zugriff geht auch ohne, extern >> > sollte man überlegen was man da tut. >> > >> > Weil ich im PV Forum gesehen habe: wenn irgendwer mit HTTP 500 ankommt >> > lautet die Frage immer was in /var/log/apache2/error.log steht- das kann >> > man dann auch hier zur Diagnose gebrauchen. >> > >> > Damit aus meiner Sicht “fertig”. >> > >> >> >> >> mfg Daniel >> >> >> > >> > Viele Grüße, Andreas >> > >> >> >> > >
