[vz-dev] Testing Pull Request 659 / jwt - Add basic login capabilities
Frank Richter
frank.richter83 at gmail.com
Sun Mar 18 14:50:56 CET 2018
Ok, dann nicht. Ich mach das wohl aus Gewohnheit lieber einmal öfter ;-)
Grüße
Frank
Am 18. März 2018 um 14:22 schrieb Andreas Goetz <cpuidle at gmail.com>:
> Apache restart ist nicht notwendig- wozu auch?
>
> Viele Grüße, Andreas
>
>
> On 18. Mar 2018, at 13:59, Frank Richter <frank.richter83 at 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 <princemichi at 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. <mailing3000 at 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" <
>>> justin at 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 <cpuidle at gmail.com>:
>>> >
>>> > Hallo,
>>> >
>>> >> On 21. Jan 2018, at 15:50, Daniel Lauckner <vz at 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
>>> >
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20180318/6b62d8be/attachment-0001.html>
More information about the volkszaehler-dev
mailing list