Erstellt vor 4 Jahren

Geschlossen vor 4 Jahren

Zuletzt geändert vor 3 Jahren

#2559 closed enhancement (fixed)

Session id für Freetz

Erstellt von: MaxMuster Verantwortlicher:
Priorität: normal Meilenstein: freetz-next
Komponente: unknown Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

In r12516 habe ich den ersten Versuch für ein Session-ID basiertes Login eingecheckt.

Das ist erstmal sicher nicht viel mehr als ein "proof of concept" und kann noch einiges an Korrektur undOptimierung usw. vertragen

Hier bitte Erfahrungen, Fehler, nennen.

Für das Passwort dürften Sonderzeichen problematisch sein (wegen der Zeichenkodierung im Browser).

MD5-Hashes sind nun auch nicht das nonplusultra, aber ich fands besser als Klartext…

Anhänge (1)

settings.pdf (225.0 KB) - hinzugefügt von Whoopie vor 4 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (25)

comment:1 Geändert vor 4 Jahren durch oliver

In r12516:

Webgui: First try to implement session id and timeout

Uses Cookie (to much work to add sid to all menu entries [cache …])
Disabled by default
Option on freetz Web config page to enable session id
will store passwords md5 hash
default pasword is "freetz", can be changed on web config page after enabling session ids

uses js md5 version from "blueimp" (​https://github.com/blueimp/JavaScript-MD5)
might use avms md5 js in future (not available on old boxes), we'll have to check it during building the firmware

comment:2 Geändert vor 4 Jahren durch MaxMuster

In 12517:

Webgui:

  • refs #2559
  • ad some hints and force change of default password
  • fix pwchange.cgi was not executable

comment:3 Geändert vor 4 Jahren durch MaxMuster

In 12518:

Webgui:

  • refs #2559
  • next try to fix pwchange.cgi was not executable

comment:4 Geändert vor 4 Jahren durch SaschaBr

Nachdem ich mir gestern nach langer Zeit mal wieder ein erstes Image gebaut habe (für eine 7490 mit 23er Firmware), habe ich beim Konfigurieren die Option "Neue Loginversion mit Session-ID" entdeckt, welche ich dann auch gleich ausprobieren wollte. Schon beim anklicken bekomme ich aber eine Fehlermeldung mit dem Inhalt "error: language not set". Da ich mutig war, habe ich dies mit OK quittiert, und nach dem Übernehmen hatte ich mich erfolgreich aus dem WebIF ausgesperrt (konnte dies aber mit Telnet, aktiviert via Telefon, da Dropbear noch nicht eingerichtet, wieder auf normale Anmeldung umschalten).

comment:5 Antwort: Geändert vor 4 Jahren durch MaxMuster

Hm, "language not set" kenne ich nur, wenn die Lokalisierung nicht funktioniert hat. Sollte aber nur den Text in der GUI betreffen.

"Ausgesperrt" hieß jetzt bei dir genau was?

EDIT:
Ach so, da du den Text nicht lesen konntest, ist das Aussperren vielleicht verständlich: Es wird dann wieder ein "Standardpasswort" gesetzt ("freetz").

Zuletzt geändert vor 4 Jahren von MaxMuster (vorher) (Diff)

comment:6 als Antwort auf: ↑ 5 Geändert vor 4 Jahren durch SaschaBr

Replying to MaxMuster:

"Ausgesperrt" hieß jetzt bei dir genau was?

Ich konnte mich halt nicht mehr am WebIf anmelden: "Passwort falsch" (ja, in deutsch). Und "freetz" habe ich natürlich auch probiert.

comment:7 Geändert vor 4 Jahren durch Whoopie

Kann ich reproduzieren. Irgendwas stimmt an der folgenden Zeile nicht:

var conftext='$(lang de:"Noch in der Erprobung!\nZur Sicherheit sollte ein anderer Zugang zur Box vorhanden sein (telnet/ssh)\nStandard PW ist "freetz"!\n" en:"Still under development!\nPlease make sure, you have an alternate way to access your box (telnet/ssh).\nDefault password is "freetz"!\n")'

OK, die Anführungszeichen im Text müssen "escaped" werden, und \n funktioniert auch nicht.

Zuletzt geändert vor 4 Jahren von Whoopie (vorher) (Diff)

comment:8 Geändert vor 4 Jahren durch Whoopie

In 12827:

webgui: fix popup message (refs #2559)

comment:9 Geändert vor 4 Jahren durch SaschaBr

OK, das ist ein Fehler in der Meldung, aber anmelden konnte ich mich ja auch nicht. Gab es hierdurch dann sowas wie eine Art Überlauf?

comment:10 Geändert vor 4 Jahren durch Whoopie

In 12829:

webgui: fix typo (refs #2559)

comment:11 Antwort: Geändert vor 4 Jahren durch Whoopie

Also bei mir klappt's auch nicht so recht.

  1. Die WebGUI sieht nach Aktivierung bisschen komisch aus, da kommt ein echo in files/root/usr/mww/cgi-bin/login_page.sh in die Quere, nämlich die Zeile echo "Set-Cookie: SID=$SENDSID;Path=/", siehe angehängtes PDF.
  1. Die Passwortänderung geht nicht.
  1. Feature Request: Benutzername auch bei neuem Login.
Zuletzt geändert vor 4 Jahren von Whoopie (vorher) (Diff)

Geändert vor 4 Jahren durch Whoopie

comment:12 als Antwort auf: ↑ 11 Geändert vor 4 Jahren durch MaxMuster

Esrtmal vielen Dank, dass sich das doch mal jemand angesehen und "zurückgemeldet" hat!

Zum "Testen" sollte es möglich sein, die Seiten auch mit dem "normalen" login zu testen und einfach direkt aufzurufen mit:

http://fritz.box:81//cgi-bin/login.cgi
http://fritz.box:81/cgi-bin/pwchange.cgi

eventuell mit etwas merkwürdigen Ergebnisseiten ;-), aber ob das PW angenommen wird und eine PW-Änderung möglich ist sollte klar werden.

Replying to SaschaBr:

OK, das ist ein Fehler in der Meldung, aber anmelden konnte ich mich ja auch nicht. Gab es hierdurch dann sowas wie eine Art Überlauf?

Wenn du mal das Passwort geändert hattest, nachdem das schon aktiv war, müsste "<user><pw>" das Kennwort sein (also sowas wie "admingeheim" ;-)

In "/usr/mww/cgi-bin/passwd_save.sh"

echo -n "$MOD_HTTPD_USER$MOD_CGI_PASSWORD" | md5sum | sed 's/[ ]*-.*//' > /tmp/flash/mod/webmd5

So kannst du auch "von Hand" ein Passwort für dieses Login auf der Box setzen:

echo -n "MEINgeheimesPASSWORD" | md5sum | sed 's/[ ]*-.*//' > /tmp/flash/mod/webmd5
# ggf noch 
modsave flash

Ist halt noch nicht so wirklich stringent, was ich da gemacht habe ;-)

Replying to Whoopie:

  1. Die WebGUI sieht nach Aktivierung bisschen komisch aus, da kommt ein echo in files/root/usr/mww/cgi-bin/login_page.sh in die Quere, nämlich die Zeile echo "Set-Cookie: SID=$SENDSID;Path=/", siehe angehängtes PDF.

Das sollte/kann aber nur einmal direkt nach der "Umschaltung" auftreten?!? Mal schauen, ob (wie) man das abfangen kann.

  1. Die Passwortänderung geht nicht.

Hmm, was ich da eingecheckt habe?!? Fehler im JS hab ich gefunden und die werden korrigiert.

  1. Feature Request: Benutzername auch bei neuem Login.

Mal sehen, wäre aber (so wie ich mir das vorstelle) nur "Kosmetik", indem man "<user><ggf Trenner><pw>" als ganzes "hashed" oder zwei Hashes nutzt…

comment:13 Geändert vor 4 Jahren durch MaxMuster

In 12837:

webgui (session id):

  • fix javascript code (allow password change)
  • Refs #2559

comment:14 Geändert vor 4 Jahren durch PrinzVonBillAir

Hallo allerseits, ich habe folgendes Problem mit den Session IDs festgestellt:

Hat man den Session ID Login aktiviert und hat sich noch nicht eingeloggt bzw. ist außerhalb des eingestellten Zeitfensters, kann man das WOL-Webinterface auf Port 84 nicht DIREKT erreichen (sprich über http://IP:84/). Es erscheint zwar das freetz Login Fenster für die Session ID Einwahl, aber nach der Eingabe des (richtigen!) Passworts kommt ein 404 Fehler: Die Webseite wurde nicht gefunden.

Hat man sich hingegen vorher über das normale freetz-Interface eingeloggt und/oder befindet sich in dem Session ID Zeitfenster, kann man das WOL-Interface auf Port 84 DIREKT ansurfen.

Zusammengefasst:

Das ansurfen über freetz-Interface → Wake on LAN → WOL-Webinterface funktioniert zu jeder Zeit, die direkte Anwahl des WOL-Webinteface auf Port 84 (außerhalb des Session ID Zeitfensters) funktioniert jedoch nicht und produziert einen 404 Fehler, auch nach korrekter Passworteingabe.

Zuletzt geändert vor 4 Jahren von PrinzVonBillAir (vorher) (Diff)

comment:15 Geändert vor 4 Jahren durch MaxMuster

Danke für die Meldung.
Ich schaue mir das mal an, wird aber etwas dauern, bis ich dazu komme…

comment:16 Geändert vor 4 Jahren durch MaxMuster

In 12927:

Webgui with session id:

comment:17 Geändert vor 4 Jahren durch MaxMuster

Könntest du es bitte mit dieser Änderung nochmal versuchen?

comment:18 Geändert vor 4 Jahren durch PrinzVonBillAir

Hallo,
habe den Fix erst jetzt bemerkt. Funktioniert jetzt wie gewünscht, Danke.

comment:19 Geändert vor 4 Jahren durch er13

Gibt es noch bekannte Bugs oder kann hier zu?

comment:20 Geändert vor 4 Jahren durch MaxMuster

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

Nutze das selbst jetzt seit Monaten ohne Probleme. Daher kann es wohl erst mal zu, denke ich.

comment:21 Geändert vor 4 Jahren durch BonoOtt

  • Lösung fixed gelöscht
  • Status von closed nach reopened geändert

Bitte optional im menüconfig abwählbar machen. Dann braucht man die Dateien nicht im Image zu haben wenn man es nicht nutzen will

comment:22 Geändert vor 4 Jahren durch er13

  • Lösung auf fixed gesetzt
  • Status von reopened nach closed geändert

Bitte einen fertigen / fertig getesteten Patch anhängen und nur dann das Ticket wieder öffnen.

comment:23 Geändert vor 4 Jahren durch BonoOtt

Ich würde mich ärgern wenn ich meine Zeit dazu opfere und das dann nachher ignoriert würde. Hab das nur als custom script

comment:24 Geändert vor 3 Jahren durch MaxMuster

In 13344:

Webgui with session id:

  • refs #2559
  • ad some more hints about password
  • focus to password field
  • fix message for wrong password
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.