[vz-dev] Testing Pull Request 659 / jwt - Add basic login capabilities

[F. S.]

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/20180122/0b5cb99f/attachment-0001.html>