[vz-dev] Testing Pull Request 659 / jwt - Add basic login capabilities
Michael Koch
princemichi at gmail.com
Sun Mar 18 16:05:11 CET 2018
So,
nachdem Frank mir mal wieder super geholfen hat (Vielen Dank!),
funktioniert das jetzt bei mir.
Ich sehe absolut nicht das Problem für die "User".
Das Script ist super. Funktioniert einwandfrei.
Ausschließlich müssen wir darauf achten, dass:
1. die Firebase PHP Extension installiert ist (composer update)
2. die config im firewall-default auf allow steht (post und get)
Jetzt meine Frage, warum können wir uns nicht dazu entschließen das
endlich zu mergen?
An PHP 7 sollte es doch mittlerweile nicht mehr liegen oder? Mitlerweile
haben alle wichtigen Distributionen auf PHP 7 einen aktuellen Release
veröffentlicht!
Liegt es nur an einem fehlenden Wiki aktikel, der bei diesen
Einstellungen hilfe bietet? Das bekommen wir doch sicher hin!
Ich schlage vor, das du Andreas in der Dev-Mailingliste mal einen neuen
Thread öffnest um über die endgültige Veröffentlichung abzustimmen.
Ich denke das dieses PHP7-Problem generell dem Projekt in letzter zeit
nicht gut tut...
Somit sollten wir über unseren Schatten springen und die Reqirements
anheben.
So könnten wir einfach einen neuen Release 0.8 veröffentlichen und wenn
jemand PHP5 hat auf den älteren release verweisen.
Weitere Features wie eine User Verwaltungen und Firewall-Verwaltung kann
man im späteren verlauf dazu entwickeln - oder nicht?
Gruß,
Michael
Am 18.03.2018 um 14:50 schrieb Frank Richter:
> 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
> <mailto: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 <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto: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 <mailto:cpuidle at gmail.com>>:
>>> >
>>> > Hallo,
>>> >
>>> >> On 21. Jan 2018, at 15:50, Daniel Lauckner
>>> <vz at jahp.de <mailto: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/4eb49f8d/attachment-0001.html>
More information about the volkszaehler-dev
mailing list