[vz-users] Login/Absicherung von VZ Installationen

[Frank Richter]

Hi Markus,

"total zerschossen" ist keine Fehlerbeschreibung, so kann man dir nicht
helfen.

Gruß
Frank

Am 21.10.2017 11:34 schrieb Markus Reiß <reiss.ma at web.de>:

> Hallo Frank / rest der Mailingliste,
>
> danke für die Schrit für schritt Anleitung.
> Aber leider habe ich mir nun die frontend totat zerschossen
> Zum glück hatte ich noch ein backup und hab es wieder mühselig zum laufen
> gebracht.
>
> kommt zwar ab und zu Fehler Networkerror
> aber so einigermaßen läuft es wieder.
> oder kann ich mir das verzeichniss WWW igendwo herunterladen und ersetzen?
>
> gruß Markus
>
> *Gesendet:* Freitag, 20. Oktober 2017 um 01:03 Uhr
> *Von:* "Frank Richter" <frank.richter83 at gmail.com>
> *An:* "volkszaehler.org - users" <volkszaehler-users at demo.volkszaehler.org
> >
> *Betreff:* Re: [vz-users] Login/Absicherung von VZ Installationen
> Hi Markus,
>
> so, dann wollen wir mal!
> Ich gehe davon aus, du betreibst eine Standardinstallation mit dem
> vz-Image?
>
> cd /var/www
> sudo git clone https://github.com/andig/volkszaehler.org
> volkszaehler.org-next
> cd volkszaehler.org-next
> sudo git checkout jwt
> sudo composer self-update
> sudo composer install --no-dev
> cd etc
> sudo cp volkszaehler.conf.template.php volkszaehler.conf.php
>
> in der volkszaehler.conf.php musst du dann:
> * deine DB-Passwörter wieder eintragen, falls du eigene vergeben hast
> * den auskommentierten DB-Admin-Zugang aktivieren (gibt sonst Ärger mit
> der Aggregation)
> * die zuvor schon beschriebenen Einstellungen für die Firewall eintragen
> (Regeln, secretkey, user/password)
>
> Danach kannst du in:
> /etc/apache2/sites-enabled/000-default.conf
>
> die Zeile:
> DocumentRoot /var/www/volkszaehler.org/htdocs/
>
> ändern zu:
> DocumentRoot /var/www/volkszaehler.org-next/htdocs/
>
> dann noch:
> sudo systemctl restart apache2
>
> Ab dann verwendest du die neue MW und das Frontend.
>
> Hoffe das hilft dir weiter.
>
> Viele Grüße
> Frank
>
> Am 19. Oktober 2017 um 15:06 schrieb "Markus Reiß" <reiss.ma at web.de>:
>>
>> OK Danke
>> was meinst du damit??
>>
>> Da ich absoluter Linux laie bin und außer copy and paste nicht viel davon
>> verstehe
>> köntest du mich da mal schrit für schritt an die Hand nehmen.
>> So wie du es unten schon mal gemacht hast .
>>
>> danke
>>
>>
>> *Gesendet:* Donnerstag, 19. Oktober 2017 um 13:51 Uhr
>> *Von:* "Frank Richter" <frank.richter83 at gmail.com>
>>
>> *An:* "volkszaehler.org - users" <volkszaehler-users at demo.
>> volkszaehler.org>
>> *Betreff:* Re: [vz-users] Login/Absicherung von VZ Installationen
>> Hallo Markus,
>>
>> der Pull Request ist ja schon ziemlich alt, deshalb könnte ich mir
>> vorstellen dass da die Abhängigkeiten nicht mehr passen.
>> Alternativ kannst du die branches jwt oder auch next aus dem fork von
>> Andreas verwenden, die sollten auf einem neueren Stand sein. Am besten in
>> separates Verzeichnis clonen, dann bleibt deine master-Installation wie sie
>> ist.
>>
>> Gruß
>> Frank
>>
>> Am 19.10.2017 13:27 schrieb Markus Reiß <reiss.ma at web.de>:
>>>
>>> Hallo,
>>> muss das mal wieder hoch holen :-(
>>> hab das heute mal probiert zu installieren bzw zum laufen zu bringen
>>> aber irgendiw schaff ich das nicht.
>>> hab dieses so  gemacht wie Frank es geschrieben hat:
>>>
>>> cd /var/www/volkszaehler.org
>>> sudo git pull
>>> sudo git fetch origin pull/551/head:auth
>>> sudo git checkout auth
>>> sudo composer update
>>> cd etc
>>> sudo mv volkszaehler.conf.php volkszaehler.conf.backup.php
>>> sudo 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
>>> 4) bei 'user' => 'pass' eigene Zugangsdaten eintragen (oder nur mal kurz
>>> testen und dann die Zeile löschen/auskommentieren, falls kein HTTPS
>>> vorhanden ist!)
>>> sudo systemctl restart apache2
>>>
>>>
>>> Als erste kam das ich kein Token habe.
>>> also einen generiert und abgespeichert unter /home/pi/.composer/auth.json
>>> danach schien die git  durch zu laufen (binn mir aber nicht sicher.
>>>
>>> Nun läuft er lockal wie gewohnt
>>> aber von extern nicht mehr:
>>> kommt EXTENSION: Invalid proxy access .
>>>
>>> was ist da nun schief gelaufen
>>>
>>> Danke für euere hilfe.
>>> Gruß Markus
>>>
>>> *Gesendet:* Freitag, 13. Januar 2017 um 19:31 Uhr
>>> *Von:* "Andreas Goetz" <cpuidle at gmail.com>
>>> *An:* "volkszaehler.org - users" <volkszaehler-users at demo.
>>> volkszaehler.org>
>>> *Betreff:* Re: [vz-users] Login/Absicherung von VZ Installationen
>>> Hallo Frank,
>>>
>>> s.u.- ist alles gefixt und der PR aktualisiert.
>>>
>>> Viele Grüße, Andreas
>>>
>>>
>>> On 12 Jan 2017, at 17:59, Andreas Goetz <cpuidle at gmail.com> wrote:
>>>
>>>
>>>
>>> On 12 Jan 2017, at 00:04, Frank Richter <frank.richter83 at gmail.com>
>>> wrote:
>>>
>>> Hallo Andreas,
>>>
>>> ich antworte mir mal selbst, jetzt hab ich das ganze nämlich doch
>>> getestet (auf einem Pi mit VZ-Image, auf dem normalerweise nur vzlogger
>>> läuft, weil meine DB woanders liegt).
>>> Ich bin dafür, das bald zu mergen, läuft schon recht gut und
>>> Einrichtungsaufwand hält sich ja sehr in Grenzen. Mein Test war jetzt ohne
>>> HTTPS, aber so lang das users-Array leer ist und die voreingestellten
>>> Firewallregeln verwendet werden, sollte da ja nix passieren.
>>>
>>>
>>> Sehe ich auch so. Vielleicht hat @Justin noch einen Kommentar dazu?
>>>
>>>
>>> Wer schreibenden Zugriff von Remote möchte, muss sich dann eben mit mit
>>> HTTPS befassen. Den default user würde ich dann allerdings wirklich aus der
>>> Konfiguration werfen.
>>>
>>>
>>> Check.
>>>
>>>
>>>
>>> 2 Sachen, die mir beim Testen aufgefallen sind:
>>> * 'action' => 'deny' sollte besser kein Login-Fenster bringen
>>>
>>>
>>> Good catch. Die Weiche baue ich ein.
>>>
>>>
>>> * wenn 'methods' => 'GET', action' => 'allow' gesetzt ist, wird das
>>> Frontend ja normal geladen. Dann kann ich Kanaleigenschaften bearbeiten,
>>> beim Speichern erscheint Login. Wenn ich mich dann einlogge, wird die ganze
>>> Seite neu geladen, gemachte Änderungen gehen aber verloren
>>>
>>>
>>> Mhm, das stimmt und wäre ein Issue wert. Nie getestet weil “das geht ja
>>> nicht”. Außerdem dachte ich immer der Fehler kommt beim laden der Seite-
>>> jetzt allerdings passiert er beim speichern.
>>>
>>> Man müsste also etwas einbauen dass quasi den Request aufhält,
>>> Credentials abholt und dann erneut ausführt. Bestimmt möglich aber tricky.
>>> Könnten wir fürs erste mit dem Istzustand leben? Gerade wenn man die
>>> Haltbarkeit der Token auf z.b. 1 Woche konfiguriert würde es aus dem
>>> Internet- wo heute gar nichts geht- ja ziemlich selten passieren???
>>>
>>>
>>>
>>> Grüße
>>> Frank
>>>
>>>
>>> Viele Grüße, Andreas
>>>
>>>
>>>
>>>
>>> Am 11. Januar 2017 um 18:27 schrieb Frank Richter <
>>> frank.richter83 at gmail.com>:
>>>>
>>>> Hallo Andreas,
>>>>
>>>> aus meiner Sicht ist die Absicherung per Login absolut wichtig und
>>>> sollte rein, denn private Kanäle sind auf Dauer/bei diversen verwendeten
>>>> Geräten einfach unbequem, und jedesmal eine VPN-Verbindung aufzumachen, um
>>>> kurz nach dem VZ zu schauen, finde auch eher unpraktisch.
>>>> Jetzt ging es im ganzen Thread fast ausschließlich um die High
>>>> Performance Middleware und nicht um das Login-Feature. Kannst du vielleicht
>>>> nochmal kurz darauf eingehen, wie sich ein Merge des Features auf neue (per
>>>> install.sh oder mit einem neuen Image erstellte) und bestehende (durch git
>>>> pull akualisierte) Installationen auswirken würde?
>>>> Laufen die dann noch out of the box oder sind zwingend zusätzliche
>>>> Schritte notwendig? Wenn ich das richtig sehe, muss für bestehende
>>>> Installationen auf jeden Fall die volkszaehler.conf.php angepasst werden.
>>>> Wie ist es mit HTTPS, ist das dann unbedingt erforderlich, oder geht es
>>>> mit der letzten Änderung ((=lesender public Zugriff auf VZ)) auch
>>>> ohne? Laut meiner Recherche klappt Let's Encrypt zusammen mit einer
>>>> DDNS-Adresse nicht immer reibungslos, weil Let's Encrypt die Zahl der
>>>> Registrierungen pro Domain beschränkt.
>>>> Ich bin leider noch nicht dazu gekommen, den PR selbst zu testen, weil
>>>> ich grad keine Installation auf aktuellem Stand habe - da bin ich aber
>>>> dran...
>>>>
>>>> Grüße
>>>> Frank
>>>>
>>>> Am 11.01.2017 09:21 schrieb "Andreas Goetz" <cpuidle at gmail.com>:
>>>>>
>>>>> Hallo Zusammen,
>>>>>
>>>>> 2017-01-03 20:33 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:
>>>>>>
>>>>>> Hallo,
>>>>>>
>>>>>> Frohes Neues Jahr Zusammen!
>>>>>>
>>>>>> Ihr wisst ja dass ich hartnäckig sein kann. In den letzten Tagen
>>>>>> haben ich nach dem mißglückten Merge daher massiv Arbeit darein gesteckt
>>>>>> alle VZ Komponenten wieder 100%ig funktionsfähig zu machen.
>>>>>>
>>>>>> Dazu gehören auch die High Performance Middleware (siehe
>>>>>> https://github.com/volkszaehler/volkszaehler.org/
>>>>>> tree/master/misc/tools) und der zuletzt nicht mehr korrekt
>>>>>> funktionierende push-server (gleicher Link).
>>>>>>
>>>>>> Apropos High Performance Middleware: ich muss nochmal Werbung dafür
>>>>>> machen dass die MW damit in der Lage ist Requests in wenigen (<10!)
>>>>>> Millisekunden zu beantworten. Wäre Klasse wenn wir das in das Image
>>>>>> einbauen könnten (@Udo: einmalig kann ich das gerne einrichten, ist im Link
>>>>>> aber auch recht gut dokumentiert).
>>>>>>
>>>>>> Auf der Basis habe ich dann auch gleiche die Testskripte renoviert
>>>>>> und User Authorization neu aufgesetzt (https://github.com/
>>>>>> volkszaehler/volkszaehler.org/pull/551). Aus meiner Sicht wäre das
>>>>>> Feature damit reif standardmäßig in VZ einzuziehen. Bei Bedarf könnte ich
>>>>>> noch eine Option einbauen es ggf. auch komplett abzuschalten falls sich die
>>>>>> individuelle Konfiguration der Firewall Regeln dafür als zu aufwändig
>>>>>> erweist.
>>>>>>
>>>>>
>>>>> Mittlerweile sind auchd ie Anforderungen von Klaus (=lesender public
>>>>> Zugriff auf VZ) in den PR 551 mit eingebaut. Wäre es nicht lagsam Zeit die
>>>>> Funktion zu mergen oder gibt es wirklich keinen Bedarf?
>>>>>
>>>>> Wenn wirs mergen wollen gäbe es zwei abschließede Punkte:
>>>>> - Default user (user/pass) aus der Konfiguration entfernen?
>>>>> - Gäbe es noch notwedige Anpassungen an den Firewall Regeln vor
>>>>> Release?
>>>>>
>>>>>
>>>>>>
>>>>>> Viele Grüße, Andreas
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27 Aug 2016, at 12:33, Andreas Goetz <cpuidle at gmail.com> wrote:
>>>>>>
>>>>>> Hallo Zusammen,
>>>>>>
>>>>>> das prinzipielle Feedback war zwar “brauche ich nicht”, ich habe mir
>>>>>> aber trotzdem mal den Spass gemacht, Firewall und User Authorization
>>>>>> prototypisch zu implementieren.
>>>>>>
>>>>>> Wer damit spielen möchte findet hier den Code: https://github.com/
>>>>>> volkszaehler/volkszaehler.org/pull/458
>>>>>>
>>>>>> Das Ganze basiert auf JSON Web Tokens für Bearer Authentication und
>>>>>> sollte tunlichst- da Username/ Passwort übertragen werden- _nur_ über HTTPS
>>>>>> Anwendung finden.
>>>>>>
>>>>>> Die Änderungen an der vz.conf Datei sollten eigentlich hinreichen
>>>>>> erklären was es zu konfigurieren gibt. Freue mich über Feedback im PR.
>>>>>>
>>>>>> Viele Grüße,
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 15.08.2016, at 11:36, Andreas Goetz <cpuidle at gmail.com> wrote:
>>>>>>
>>>>>> Ich mache Jacobs Mail mal als neues Thema auf:
>>>>>>
>>>>>>>
>>>>>>> Bei der Durchsicht der URL-Befehle habe ich gesehen, dass anscheinend
>>>>>>> auch schreibend auf die Datenbank zugreifen kann. Ist das nicht
>>>>>>> gefährlich, so einen Webserver ins öffentliche Netz zu stellen, wenn
>>>>>>> jeder daran herum fummeln kann?
>>>>>>
>>>>>>
>>>>>> Äh, ja, das ist das Prinzip von vz. Allerdings muß man ja die UUID
>>>>>> kennen, um Kanäle und deren Daten manipulieren zu können, deswegen sollte
>>>>>> man die UUID auch geheim halten (und Kanäle nicht einfach public machen,
>>>>>> sonst kann man sie einfach so auflisten). Neue Kanäle anlegen und nutzen
>>>>>> geht aber natürlich schon.
>>>>>> M.W. hatte Justin das so konzipiert, damit z.B. demo.volkszaehler.org
>>>>>> ohne Anmeldung (und Passwort-Recevory, Email etc. pp.) genutzt werden kann.
>>>>>> Faktisch ist es aber heute wohl so, daß die meisten ihren eigenen VZ-Server
>>>>>> laufen haben, da finde ich das eher ungeschickt (zumal die UUIDs auch etwas
>>>>>> unhandlich sind).
>>>>>>
>>>>>> -- snip --
>>>>>>
>>>>>> Ich sehe- wenn wir es einfach halten wollen- 2 Anwendungsfälle:
>>>>>>
>>>>>> a) Absicherung einer privaten Installation
>>>>>> b) Usermanagement für eine öffentliche Installation wie demo
>>>>>>
>>>>>> Letzteres klammere ich mal aus da es grundlegende Änderungen an VZ
>>>>>> erfordern würde. Für a) gibt es verschiedene Möglichkeiten von furchtbar
>>>>>> einfach bis etwas umfangreicher:
>>>>>>
>>>>>> 1) Basic Authentication, also Username + Password. Für ein Mindestmaß
>>>>>> an Sicherheit ist SSL erforderlich- das gilt ebenso aber auch für alle
>>>>>> weiteren Varianten. Das muss zusätzlich so konfiguriert werden dass
>>>>>> vzlogger (aus dem internen Netz) ohne Basic Auth weiterhin seine Daten
>>>>>> abliefern kann.
>>>>>>
>>>>>> 2) Token Authentication: initiales Login per U/P, ab da Token der
>>>>>> expired. Dabei hätten wir sogar die Möglichkeit einzelne User zu
>>>>>> definieren- imeinfachsten Falle per Konfigurationsdatei, sonst als
>>>>>> Datenbankerweiterung. Wenn Datenbankerweiterung dann können wir auch Rechte
>>>>>> vergeben (schreiben, löschen, lesen) und Kanäle zu Usern "gehören" zu
>>>>>> lassen.
>>>>>> Weiterhin wäre es ggf. sinnvoll authentifizierten Nutzern auch
>>>>>> "private" Kanäle ohne Kenntnis der UUID anzubieten.
>>>>>>
>>>>>> Gibts Bedarf?
>>>>>>
>>>>>> Viele Grüße,
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20171021/fd9f8676/attachment-0001.html>