<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hallo alle zusammen,</p>
ich muss euch noch mal fragen wie ich das ganze testen kann.<br>
Kann mir jemand noch mal kurz zusammen fassen, was ich tun muss um
den PR <span class="js-issue-title">"Add basic login capabilities </span>
<span class="gh-header-number">#659" auszuprobieren?</span><br>
<span class="gh-header-number">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.</span><br>
<span class="gh-header-number">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.</span><br>
<span class="gh-header-number">Ich weiß, dass andi mir auch schon
mal geschrieben hat - ich finde diese infos aber nicht mehr.</span>
<p><span class="gh-header-number">Danke,</span></p>
<p><span class="gh-header-number">Michael<br>
</span></p>
<br>
<div class="moz-cite-prefix">Am 22.01.2018 um 23:48 schrieb Frank
Richter:<br>
</div>
<blockquote type="cite"
cite="mid:CAD+U_OBXUbhxYV_=NeQ7p5NJSu7cGdSzmCaN_TO7Nowd+bd7mQ@mail.gmail.com">
<div dir="ltr">Hi Frank,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Tokens generieren geht mit misc/tools/token-helper.php,
wenn du das doch mal brauchst.</div>
<div><br>
</div>
<div>Grüße</div>
<div>Frank</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Am 22. Januar 2018 um 23:30 schrieb F.
S. <span dir="ltr"><<a
href="mailto:mailing3000@googlemail.com" target="_blank"
moz-do-not-send="true">mailing3000@googlemail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Hallo vz-ler,</div>
<div dir="auto"><br>
<div dir="auto">und Danke Justin für die gute
Zusammenfassung! Ich bin softwaretechnisch nicht so
fit wie Ihr, aber jetzt verstehe ich die wichtigsten
Zusammenhänge.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto">Wenn mir noch jemand ein Tip gibt, wie
man sich denn die Token generiert, wäre ich auch damit
einverstanden.</div>
<div dir="auto">Bei mir fliegen die Cookies übrigens
auch nach jeder Firefox-Sitzung raus.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">VG</div>
<div dir="auto">Frank S.</div>
<div>
<div class="h5"><br>
<div class="gmail_extra" dir="auto"><br>
<div class="gmail_quote">Am 22.01.2018 10:44
nachm. schrieb "Justin Otherguy" <<a
href="mailto:justin@justinotherguy.org"
target="_blank" moz-do-not-send="true">justin@justinotherguy.org</a>>:<br
type="attribution">
<blockquote class="m_4835487412324640501quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Hi,<br>
<br>
Puh - ich versuch mal zusammenzufassen, was
ich verstanden habe:<br>
<br>
- 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<br>
- neu gibt es - Andreas sei Dank - die
Möglichkeit, sich per User+Pwd zu
authentisieren<br>
- das ist eine Option, die man - zB für einen
Betrieb im LAN - auch ungenutzt lassen kann<br>
<br>
Korrekt soweit?<br>
<br>
<br>
Frage: welche Optionen soll es künftig geben?<br>
<br>
Nach meinem Verständnis hat man heute doch
folgende Hierarchie:<br>
<br>
- User+Pwd stehen ganz oben - daraus kann man
sich alles weitere generieren<br>
<br>
- zB einen Token (vgl. API-Key/secret oder …)
für den Zugriff<br>
- welche Berechtigungen mit diesem Token
einhergehen, lässt sich im Prinzip
konfigurieren<br>
- ich könnte mir also mehrere Tokens
erstellen, die unterschiedliche Berechtigungen
haben:<br>
- read-only für mein Display (oder zur
Weitergabe an Leute, die die Datenreihe auch
sehen können sollen)<br>
- read-write für meinen Sensor<br>
- …<br>
- die Tokens kann ich jederzeit widerrufen
oder die Berechtigungen anpassen<br>
- das Token hat keine feste Gültigkeitsdauer;
potenziell zeitlich unbegrenzt<br>
<br>
<br>
- ganz unten in der Kette gibt es das Cookie<br>
- dieser wird aus dem Token generiert und ist
Client-spezifisch<br>
- bei einem Neustart des Clients wird dieser
ggf. gelöscht oder ungültig gemacht<br>
- dann muss er - aus dem Token oder User+Pwd -
neu erzeugt werden<br>
<br>
Soweit immer noch korrekt?<br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
Konkret:<br>
- für vzlogger würde ein Cookie nicht
ausreichen - der bräuchte einen Token, der
dauerhaft gilt.<br>
<br>
- wenn ich Token oder Cookie lösche oder
ungültig mache, muss ich es neu erzeugen
(Eingabe User+Pwd)<br>
<br>
- „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<br>
<br>
- „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<br>
<br>
<br>
Frage:<br>
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?<br>
<br>
<br>
Mein Vorschlag:<br>
- (weiterhin) keine Unterscheidung zwischen
„Auth-Code in Cookies" und „Tokens“; ein Token
kann auch per Cookie übermittelt werden<br>
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)<br>
<br>
- Tokens können mit Berechtigungen versehen
werden (read only/read-write/write-only?/we<wbr>itere?)<br>
<br>
- 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?<br>
<br>
Damit hätten wir:<br>
- weiterhin die Möglichkeit, alles so zu
belassen wie bisher (zB LAN-Installation)<br>
- die Möglichkeit, Daten Read-only weiter zu
geben<br>
- die Möglichkeit, einzelne Kanäle auch vor
lesendem Zugriff zu schützen<br>
- ggf. write-only Kanäle zu bauen<br>
<br>
Was meint Ihr?<br>
<br>
<br>
Gruß, J.<br>
<div class="m_4835487412324640501elided-text"><br>
<br>
> Am 21.01.2018 um 16:59 schrieb Andreas
Goetz <<a href="mailto:cpuidle@gmail.com"
target="_blank" moz-do-not-send="true">cpuidle@gmail.com</a>>:<br>
><br>
> Hallo,<br>
><br>
>> On 21. Jan 2018, at 15:50, Daniel
Lauckner <<a href="mailto:vz@jahp.de"
target="_blank" moz-do-not-send="true">vz@jahp.de</a>>
wrote:<br>
>><br>
>> Hallo,<br>
>><br>
>><br>
>> am Sonntag, 21. Januar 2018 um
15:42 hat Frank Richter geschrieben:<br>
>>> Wer seine Cookies löscht, muss
sich halt danach im Frontend neu<br>
>>> anmelden, aber das ist ja bei
anderen Seiten nicht anders.<br>
>><br>
>> Ja, und es nervt.<br>
><br>
> Dann tu’s nicht :)<br>
><br>
> Wie Frank schrieb:<br>
><br>
>> 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.<br>
><br>
> Also kein Problem. In der Diskussion
ging es darum wie man den Zugriff von außen
vernageln kann und trotzdem noch mit
vzlogger reinkommen.<br>
><br>
>><br>
>> Kann man User/Passwort auch mit der
URL übergeben?<br>
><br>
> Nein, sicher nicht. Weil das Passwort
bei absolut jedem Proxy im Logfile landen
würde.<br>
><br>
> @Frank: Cookie geht jetzt auch:<br>
><br>
> // authorization
header?<br>
> if (($header =
$request->headers->get('Author<wbr>ization'))
&& (0 !== strpos($header, 'Bearer
'))) {<br>
> $jwt =
substr($header, strlen('Bearer '));<br>
> }<br>
> // authorization
cookie?<br>
> elseif ($cookie =
$request->cookies->get('vz_aut<wbr>htoken'))
{<br>
> $jwt =
explode('@', $cookie)[0]; // split
@middleware portion<br>
> }<br>
> else {<br>
> throw new
\Exception('Missing authorization token');<br>
> }<br>
><br>
> Ich schiebs bei Gelegenheit in den PR.<br>
><br>
><br>
>> 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?<br>
>> Aus meiner Sicht damit “fertig”.<br>
><br>
> Brauchen wir egtl. alles nicht. Der
interne Zugriff geht auch ohne, extern
sollte man überlegen was man da tut.<br>
><br>
> 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.<br>
><br>
> Damit aus meiner Sicht “fertig”.<br>
><br>
>><br>
>> mfg Daniel<br>
>><br>
><br>
> Viele Grüße, Andreas<br>
><br>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>