Sonderzeichen im MS-Passwort

[Christian Fenzl]

Servus Prof.Mobilux ,

das Problem mit MS-Sonderzeichen im LoxBerry konnte ich ermitteln: Die Credentials werden nie (weder im Wizzard noch im miniserver.cgi) URL-encoded.

Ich hab mir ein paar Plugins angesehen und es macht niemand URL-encoding bei User/Passwort, deswegen hab ich probiert, das Kennwort gleich im general.cfg url-encoded abzulegen.
Das funktioniert auch bei http-Calls wunderbar, nur dem Miniserver-Backup von Wörsty mit dem FTP-wget-Aufruf scheint das nicht zu gefallen.

Mit LoxBerry 0.2.x sollte da jetzt jedenfalls nichts angegriffen werden.

Für 0.3.x musst du dir überlegen, ob Sonderzeichen-Support hinein soll.

lg, Christian

Hier noch ein paar Infos zur Referenz (wenn's mal Thema wird)
Vorm Speichern in miniserver.cfg bzw. Setup-Step 2

${miniserveruser.$msno} = uri_escape(${miniserveruser.$msno});
${miniserverkennwort.$msno} = uri_escape(${miniserverkennwort.$msno});

Anzeigen im Formular:

use URI::Escape;
use HTML::Entities;
$miniserveruser = uri_unescape($miniserveruser);
$miniserverkennwort = uri_unescape($miniserverkennwort);
$miniserveruser = HTML::Entities::encode_entities($miniserveruser, "<>&");
$miniserverkennwort = HTML::Entities::encode_entities($miniserverkennwort, '<>&"');

[Prof.Mobilux]

Christian Fenzl Schläfst Du auch mal?

In der 0.2.x mache ich am Image nichts mehr. Eigentlich sollte das 0.3.0 schon längst fertig sein - da ist nur das Stats4Lox und das RCSwitch-Plugin auf Programmier-Seite und Dein Squeezelite-Plugin als Spielwiese dazwischen gekommen

Aber die Passwort/Sonderzeichen-Geschichte steht bei mir auf oberster Priorität. Das Quotemeta() ist dabei suboptimal, ich wollte damals Eingaben wie "rm -rf /" oder "cat /etc/passwd | mail" damit verhindern. Aber so richtig effektiv ist das auch nicht - Am Anfang des Skriptes nutze ich quotemeta() und dann oft später gleich wieder unquotemeta() kurz vor dem Speichern in die Config-Files. So richtig weiß ich noch nicht wie man das am Besten macht. "Früher" habe ich einfach händisch alle "/" und Backslashes gefiltert. Vielleicht ist das sogar der bessere Weg.

URLEncode hat glaube ich am Anfang keiner so richtig auf dem Schirm gehabt... Das Zusammenbauen der LoginURL des Miniservers wäre aber auch ideal in der LoxBerry-Lib. Dann könnte man gleich auch die CloudURL zusammenbauen, die ich jetzt noch über ein externes Skript zur Verfügung stelle: :~/bin/showclouddns.pl

Ich weiß - ich hab's schon öfter gesagt : Sobald wir beim Stats4Lox soweit sind, dass es in Grundzügen läuft (eine Grafikengine) werde ich mich ans 0.3.0 Image machen! Aber mehr zeit ist im moment bei mir einfach nicht drin, um das parallel zu bearbeiten.

[svethi]

Naja, das PW einfach URL encoded abzulegen ist wirklich keine gute Idee. Ich nutze auch curl und co, wo die PW's dann auch nicht urlencoded drin sein dürfen. Ich hatte bei mir auch erst an das URLEncoden gedacht und dann PW's mit Sonderzeichen so probiert, das problemlos funktioniert ... allerdings im PHP ... keine Ahnung ob PHP das sonst einfach automatisch macht. Ich denke, dass die PW's schon so bleiben sollten und jeder im Plugin das dann richtig verarbeiten muss. Die Plugins sind alle recht neu und die Programmierer noch da ... wenn da was nicht mehr richtig funktioniert muss da dann an den entsprechenden Stellen nochmal angepasst werden. Das URL Encoding hinzuzufügen sollte nicht das Problem darstellen.

[Prof.Mobilux]

Was man sich durchaus vorstellen könnte wäre eine zusätzliche Variable in general.cfg (ich glaube das meinte Christian Fenzl auch):

[MINISERVER1]
ADMIN=admin
IPADDRESS=192.168.3.210
NOTE=
CLOUDURLFTPPORT=
USECLOUDDNS=0
PASS=geheimes passwort
PORT=80
NAME=Miniserver_1
CLOUDURL=

Da ergänzt man jetzt einfach noch:

login="admin@geheimes%20passwort"

Dann würden die alten Plugins einfach weiter funktionieren oder man kann sich den Login auch weiterhin selbst zusammenbauen. Und die, die es sich einfach machen wollen, nehmen halt "login". Man kommt allerdings wohl trotzdem nicht drum herum die URL wirklich zu encoden, weil im Aufruf ja letztendlich auch Sonderzeichen/Leerzeichen stecken könnten.

Was ich oben geschrieben habe bezog sich auf Christian Fenzl Vorschlag einer eigenen LoxBerry Library, den ich richtig gut finde: https://github.com/mschlenstedt/Loxberry/issues/173 Da könnte man dann eine entsprechende Funktion einbauen: createURL($msno, $path) oder so ähnlich...

[Christian Fenzl]

Für optimale Kompatibilität würde ich es in LBv0.3.x so machen:
- User/Pass wird in General.cfg URL-encoded.
- Ein LoxBerry Modul bietet Funktionen zum direkten Abfragen, etwa
getmsuser($msnr); getmspass($msnr); getmscredentials($msnr); getmsuser_raw($msnr); getmspass_raw($msnr);

Das heißt:
- Ohne MS-Sonderzeichen ändert sich garnichts
- Mit MS-Sonderzeichen funktioniert es bei vielen Plugins weiter, bei einigen nicht.
- Wo's nicht geht, kann gleich auf die neuen Lib-Funktionen umgestellt werden, oder die angerufene Variable Uri_decoded.

Damit würden ohne Sonderzeichen auch mit LBv0.3 erst mal alle Plugins weiter funktionieren. Erst wenn Sonderzeichen ins Spiel kommen, kann das der LB bereits und die Plugin-Authoren müssen nachbessern.

lg, Christian

[svethi]

In Perl 😱
;-)
Na mal gucken. Ist die cfg eigentlich auf 600 oder müsste man sich auch Gedanken machen das PW dort auch verschlüsselt zu hinterlegen?

[svethi]

Wörsty hat ja keine Zeit. Der muss doch das SML Plugin fertig machen. Da hatte doch einer gefragt wo dies denn endlich bleibt.

[svethi]

Prof.Mobilux wo hast Du denn die Libraries, bzw. wo soll sowas in der Art hin?

[Christian Fenzl]

Prof.Mobilux Stimmt: Library-Pfad.
Die Struktur müsste wie bei den Daemons sein.

Ein Libs-Pfad, wo eine LoxBerry.pm liegt (für allgemeine System-Sachen)
Darin einen Ordner LoxBerry, wo dann die Plugin-Libs hinkopiert werden. Z.B.

libs/LoxBerry.pm
libs/LoxBerry/Squeezelite.pm
libs/LoxBerry/Fritzbox.pm

Die System-Lib würde man dann einbinden mit:
use LoxBerry;

Die Plugin-Libs mit
use LoxBerry::Squeezelite;
use LoxBerry::Fritzbox;

In LoxBerry müsste per Default der libs-Pfad in Perl eingebunden werden.

So müsste das glaub ich funktionieren. Das Setup kopiert die Plugin-Library wie den Daemon in das Verzeichnis.
Die System-Library müsste im Wiki immer mitdokumentiert werden.

Ein guter Pfad wäre /opt/loxberry/libs ?

[svethi]

Wolltest Du da jetzt loslegen? Ich hatte mir den Loxberry vorhin auch schonmal geforkt

[Christian Fenzl]

Prof.Mobilux
Wenn LoxBerry beim Systemstart

export PERL5LIB=/home/foobar/code

setzen soll, wo platziert man das?
Vermutlich https://github.com/mschlenstedt/Loxb...oxberryinit.sh ?

[svethi]

Das ist das Servicestartscript. Wird das einfach hinzugefügt? Von Pfadangaben kenne ich das so, dass die Variable selbst vorn noch mit ran muss, dass der Pfad zu den anderen hinzugefügt wird.

[Christian Fenzl]

Die Environmentvariable ist am LB per Default nicht gesetzt, also sollte das passen.

[Christian Fenzl]

Könnte man dort nicht gleich ein LBHOMEDIR setzen?
Das Gefummel, herauszubekommen, wo man installiert ist, geht mir immer ziemlich auf die Nerven.
Im Web ist's richtig, im Daemon wieder nicht (File::HomeDir ist beim root anders), in der Bash braucht's wieder eine eigene Funktion...
Beim Plugindir ist es auch so.

So könnte man hier gleich Variablen setzen, z.B.
LBHOMEDIR=/opt/loxberry
und gleich für alle installierten Plugins
LBPLUGINSQUEEZELITE=squeezelite

In Perl wär dann nur ein

$ENV{LBHOMEDIR}
$ENV{LBPLUGINSQUEEZELITE}

notwendig.

[svethi]

könnte man natürlich machen :-)

[Christian Fenzl]

Hier mal Beispiele, wie die Libraries aussehen bzw. funktionieren könnten:

https://github.com/christianTF/Loxberry/tree/loxberry-0.3.0-saruman/perllib/LoxBerry

und

http://www.loxwiki.eu:80/x/uAzL

[svethi]

Mensch, das sieht doch schon gut aus. Wirst noch Perlprofi ;-)
Warum habe ich mir nur das repository geforkt? ;-)

[svethi]

Da ich auch nicht der Perlprofi bin, möchte ich mal vorsichtig anfragen, ob das so richtig ist, oder ob mich mein Schein der Merkwürdigkeiten nicht trügt. Christian Fenzl für mich sind die Teile, die die Miniserver aus der Config lesen auch sub's müsste da nicht vor dem Namen auch ein sub stehen? Genau wie bei is_enabled etc.?
Die Variablennamen sollten natürlich immer nicht zu lang sein, doch im draft heißen die derzeit lbirgendwas und liefern aber lbpluginirgendwas. Da sollten wir uns über die Namensgebung nochmal Gedanken machen.
Mit diesem PM ist sicher ne feine Sache und ich würde das wirklich ausbauen. Wenn man dies Modul schon läd, dann würde ich darüber auch gleich die general.cfg bereitstellen. Dann kann man sich das Öffnen der Datei auch sparen. Du bist das sicher noch stark am Basteln und ein Pull noch zu früh?

[Christian Fenzl]

svethi
Stimmt! Da hab ich ein paar mal "sub" vergessen. Ist noch ein Draft.

Bei den Variablen weiß ich nicht, was du meinst. Namenskonventionen sind wichtig. Ich habe globale Variablen mit lb ge-prefixt, damit sie nicht gleich mit bestehenden Variablen kollidieren. Das muss man alles noch anschauen.

Die MS aus der General.cfg werden bereitgestellt. Es macht natürlich Sinn, gleich alles aus der General.cfg über Funktionen bereitzustellen (Sprache gibt's schon), die anderen Sachen hab ich mir noch nicht genauer angesehen.
Beispielsweise passiert immer irgendwas mit dem Cloud-DNS, was ich auch immer nur kopiert, aber nie wirklich angesehen hab. Wenn das irgendwas für die Zugangsdaten oder IP ist, macht es Sinn, das gleich im Modul erledigen zu lassen, damit ich als Plugin-Entwickler daran nicht denken muss, sondern das richtige zurückbekomme.

In LoxBerry::Web würde ich dann beispielsweise auch das Header- und Footer-Sub bereitstellen, sodass das nur noch ein Aufruf im Plugin ist.

Ich würde sogar so weit gehen, dass mir das Web-Modul beim Zusammenbauen von Forms hilft, z.B. die lästigen, immer wiederkehrenden Dropdowns wo eine Option "selected" ist und die anderen nicht.

Ich kanns schon mal pullen. Verwendet ja noch keiner. Getestet ist noch nichts! (Siehe "sub" :-)

[svethi]

Brauchst es ja noch nicht zu Michael pullen ... ich kann mir es sonst auch von Dir holen