WebIF - Entwicklung/Weiterentwicklung

Status
Für weitere Antworten geschlossen.

Gero013

Neuer User
Mitglied seit
5 Mai 2010
Beiträge
190
Punkte für Reaktionen
0
Punkte
0
Auf Anraten Iflands erstellen ich hiermit einen neuen Fred, in dem es um die Entwicklung des WebIFs gehen soll.

OK, es gibt einen neuen Prototypen.

Habe einige Varianten durchprobiert, von denen mich letztlich keine so richtig überzeugt hat. Dann habe ich den "komplizierten" Weg in Angriff genommen und plötzlich fügte sich ein Puzzleteil zum anderen ;)
Aus rein ästhetischen Gründen habe ich mich für die Beibehaltung des Frames (und der JS-Links) entschieden.

Funktional bin ich mit dem Jetztigen wesentlich glücklicher.
Was nicht geht, ist der Refresh der Seiten per F5 oder Refresh-Icon des Browsers. Da ich aber selbst jemand bin, der sehr häufig die refresh-Funktion des Browsers verwendet, habe ich das Freetz-Icon so gestaltet, dass eine Aktivierung des Icons dem Refresh des Browsers nachkommt und eben funktioniert (hat damit zu tun, dass ich die Session-Prüfung gesalzen habe).
Zuviel Salz in der Suppe ist eben auch nicht das wahre.

Naja - ich persönlich kann mit dem Ergebnis gut leben und hoffe, dass es dem einen oder anderen auch gefällt.

Den jetzigen Prototyp habe ich auf, bzw. mit der FB entwickelt. Danke nomml an Ralf Friedl für den Tip bzgl. nfs

Das Archiv enthält die Verzeichnisse wie sie im Freetz-Buildsystem verwendet werden (also root, source, etc.).
Da ich haserl gepanscht habe, verwende ich das aktuelle Paket (0.9.26), das aber auch mit dem freetz 1.1.3 problemlos zusammenspielt. Haserl und getText muss mit in die Firmware aufgenommen werden.

Das Verzeichnis /usr/mww habe ich manuell per nfs auf der FB eingebunden. Dazu habe ich mir ein Script startWork geschnitzt:
Code:
#!/bin/sh
/etc/init.d/rc.webcfg stop
modprobe nfs
mount <server-ip>:/proto-II/root/usr/mww /usr/mww -t nfs -o timeo=14,intr
/etc/init.d/rc.webcfg start

Damit der webserver beim Neustart auch die Konfiguration des Prototypen verwendet, habe ich folgende Links auf der FB gesetzt:
Code:
ln -s /usr/mww/conf/htmltext_de.fa   /var/htmltext.fa
ln -s /usr/mww/conf/fapasswd         /var/mod/etc/fapasswd
ln -s /usr/mww/conf/httpd_conf       /var/tmp/flash/httpd_conf

Das conf-Verzeichnis wird vom WebIF nicht verwendet und ist per Kennwort geschützt. In dem conf-Verzeichnis liegt auch die Datei mit den Sprachtexten, die mit dem beiliegenden Script ins Binärformat übersetzt werden kann.
Dazu muss vom Paket htmltext das Tuhl createDB (auf dem PC) übersetzt und nach /usr/local/bin kopiert werden.

Was tut:
- Login + Layout-Wechsel (admin und rednose)
- die Layouts unterscheiden sich nicht nur in Farben, sondern auch in Seitenverhalten und -Inhalt
- Statusseite (mit echten Daten)
- Netzwerk -> Dienste (echter Status)
- System -> Logausgaben (nur admin)

Jetzt hoffe ich, dass ich nix Wichtiges vergessen habe und wünsche viel Spaß beim Ausprobieren.

Gruß Gero
P.S.: Ackso: admin hat das Kennwort Freetz, der Benutzer "rednose" keines.

P.P.S: Noch ne Info zu den Änderungen/Erweiterungen:
haserl hat ein neues Sprach-Kürzel bekommen: <%m Schlüssel %> kann verwendet werden, um Texte aus der Sprachdatenbank zu lesen. Der aktuelle Stand erlaubt Schlüssel mit einer Länge von bis zu 5 Zeichen. Ich denke, das ist ein akzeptabler Kompromiss zwischen Lesbarkeit und Dateigröße.
Ich vermute mal, dass AVM die Schlüsseltabelle in den webcm kompiliert hat, sodass andere Schlüsselvarianten möglich sind.

Um die gleiche Funktionalität in haserl-Scripten und CGI-Shellscripten zu erreichen, gibt es das Paket htmltext, welches das kleine Werkzeug getText liefert. <%m Schlüssel %> entspricht einem "getText Schlüssel", wobei als Standard die Datenbank /var/htmltext.fa verwendet wird. Eine andere Datei kann über Parameter angegeben werden.
Messungen zum Seitenaufbau haben ergeben, dass die Unterschiede zwischen statischen Texten und Texten aus der Datenbank unterhalb der Messgenauigkeit liegen.

Vom Paket htmltext ist getText vorgesehen, in die Firmware gepackt zu werden, während createDB nur für die Verwendung am PC vorgesehen ist.

Zu den Bildern (von links nach rechts):
- Einstiegseite des WebIF
- Statusseite (Benutzer rednose)
- Statusseite (Benutzer admin)

Vorschau:
- Logausgaben (Benutzer rednose)
- Logausgaben (Benutzer admin)
- Übersicht der Netzwerk-Clients / Kindersicherung

Änderungen gegenüber dem bisherigen WebIF:
abgesehen von dem offensichtlichen, gibt es auch funktionale Unterschiede:
Beim Freetz-WebIF geht jedes CGI-Script davon aus, dass es die ganze Seite im Browser darstellt. Dafür gibt es dann ja auch libmodcgi, bzw. cgi_begin und sec_begin.
Dieser Ansatz entstammt dem üblichen Schnellschuss und ist leider sehr weit verbreitet (ich habe es in meinem ersten Prototypen ja genausso gemacht). Echte Layout-Unterstützung lässt sich aber nur durch IOC (inversion of control) erreichen. Das ist etwas aufwändiger im Konzept, dafür erreicht man alle Freiheiten in der Gestaltung.

Der jetzige Prototyp funktioniert so. Haserl ist der "Einstiegskontroller", sodass die Verarbeitung der CGI-Variablen schon erfolgte und diese einfach dem Environment entnommen werden können. Die eigentlichen CGI-Scripte können Shell- und/oder Haserl-Scripte sein. Wer die Statusseite anschaut, wird feststellen, dass die Inhalte unterschiedlich sind, je nach Layout. Gemeinsame Bereiche werden gemeinsam verwendet, eigene Bereiche einfach ergänzt. Ein Hoch auf die Links im Unix-Dateisystem :)

Für die Seiten bedeutet dies, dass sie keine Annahmen über das machen dürfen, was sie umgibt. Sie müssen davon ausgehen, dass sie einen Bereich zur Verfügung gestellt bekommen, in dem sie sich darstellen können.

Habe mir noch Gedanken über eine mögliche Migration gemacht. Ich denke, wenn man cgi_begin und Co zu Nops ändert, sollte das meiste schon funktionieren. Vielleicht müsste ich noch ein paar Anpassungen machen, um exec-Scripte vor der Anzeige zu ermöglichen.

Ich denke, das technische Fundament ist da, sodass ich mir eine Diskussion über das weitere Vorgehen wünsche.
Was ich nicht möchte, ist eine one-man-show - aber das sagte ich ja bereits an anderer Stelle.
 

Anhänge

  • FA04a.png
    FA04a.png
    224.3 KB · Aufrufe: 62
  • FA07a.png
    FA07a.png
    660.6 KB · Aufrufe: 45
  • FA10a.png
    FA10a.png
    202.9 KB · Aufrufe: 57
  • FA08a.png
    FA08a.png
    227.3 KB · Aufrufe: 33
  • FA09a.png
    FA09a.png
    193.1 KB · Aufrufe: 53
  • FA11a.png
    FA11a.png
    304.7 KB · Aufrufe: 45
Zuletzt bearbeitet:
@Gero013: Danke, dass du es abgetrennt und die Quellen gepostet hast! Ich hatte mir die Daten angeschaut, allerdings noch nicht auf der Box, sondern nur die Quellen. Ich habe gleich einige Fragen:
1. Kannst du bitte zu deinem Konzept mit .fat und .cgi - Dateien was sagen? So, wie es aussieht, sind fat-Dateien reine html-Dateien. Wo und wie willst du da drin die Shell-Variablen unterbringen, wie wir es klassisch von FREETZ-WebIF kennen? Oder willst du den einen anderen Weg gehen? Sehe ich es richtig, dass du dadurch verhinderst, dass die Dateien angezeigt werden, weil nur html und cgi erlaubt ist?
2. Läuft alles nur mit dem AVM-Webserver oder kann man es auch mit httpd ausprobieren?

Edit:
3. Heißt es nicht zufällig /usr/www ?
Edit2:
4. Ich kriege es auf der Box nicht zum laufen. Dann habe ich dich anscheinend doch missverstanden: Es läuft auf einem nativen Linux mit Apache. Denn AVM-WebIF erwartet index.html gar nicht dort, wo du sie hingepackt hast. Und mein manuelles Anlegen vom Unterverzeichniss "all" hat auch nicht gefruchtet: AVM-Webserver meldet 404-not-found.
Edit3:
5. Nachdem ich tinyWeb nicht nach /usr/www, sondern nach /usr/www/html gepackt hatte, wird nun eine leere Seite angezeigt. Inhalt des Frames:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<link rel="stylesheet" type="text/css" href="/skin/top.css"/>
<script type="text/javascript"><!--
function select(url) {
document.application.page.value=url;   
document.application.submit();
return false;
}
--></script>
</head>
<body>
<form action="/cgi-bin/loadpage" name="application" method="post" target="main">
<input type="hidden" name="errorpage" value="/notallowed"/>
<input type="hidden" name="page" value="/home"/>
</form> </body> </html>

Edit4:
Nach dem Abändern von base='/usr/www/html' bekomme ich nun die Login-Maske angezeigt. An sich scheint es zu funktionieren, allerdings komme ich nicht durch, weil
Code:
Jan  1 01:48:44 fritz user.notice root: loadpage initial page=[/home]
Jan  1 01:48:44 fritz user.notice root: loadpage nextpage=[/login]
Jan  1 01:48:44 fritz user.notice root: loadpage servePage(/usr/www/html/login.fat)
Jan  1 01:48:44 fritz user.notice root: loadpage check: fasid=[] - org=[123]
Jan  1 01:48:48 fritz user.notice root: loadpage initial page=[/home^M]
Jan  1 01:48:48 fritz user.notice root: loadpage ok, we got user and password
Jan  1 01:48:48 fritz user.notice root: loadpage well, login is ok
Jan  1 01:48:48 fritz user.notice root: loadpage nextpage=[/home^M]
Jan  1 01:48:48 fritz user.notice root: loadpage page does not exist? /usr/www/html/home^M.fat /usr/www/html/home^M.cgi
Jan  1 01:48:48 fritz user.notice root: loadpage servePage(/usr/www/html/login.fat)
Jan  1 01:48:48 fritz user.notice root: loadpage check: fasid=[501659d2bb7f68e84304f5e341e28936] - org=[501659d2bb7f68e84304f5e341e28936]

Da wird irgendwo Windows-Zeilenumbruch eingefangen. Dadurch schlägt deine Prüfung fehl und Login-Seite wird wiederholt angezeigt.

Edit5:
Ich hatte in deinem loadpage-Skript mir die Variable "page" loggen lassen. Interessanterweise kommt sie beim ersten Mal richtig durch, ohne 0x0D und nur beim zweiten Mal mit dem Windows-Zeilenumbruch:
Code:
00000000  2f 68 6f 6d 65 0a 2f 68  6f 6d 65 0d 0a           |/home./home..|

Edit6:
Code:
nextPage="$(echo "$page" | tr -d '\015')";
löst das Problem. Nun komme ich wenigstens auf deine Hauptseite. Log-Seite wehrt sich noch, eben wie der Benutzer "rednose" ohne Passwort.
Somit bin ich mit meinen ersten Tests durch und warte auf deine nächsten Schritte.

MfG
 
Zuletzt bearbeitet:
So, wie es aussieht, sind fat-Dateien reine html-Dateien. Wo und wie willst du da drin die Shell-Variablen unterbringen, wie wir es klassisch von FREETZ-WebIF kennen? Oder willst du den einen anderen Weg gehen? Sehe ich es richtig, dass du dadurch verhinderst, dass die Dateien angezeigt werden, weil nur html und cgi erlaubt ist?
Ich weiß nicht, ob letzteres zutrifft. Falls dies bei busybox der Fall ist (bei apache ist es nicht der Fall) wäre das ein zusätzliches Bonbon.
Das Konzept ist ansonsten schnell erklärt - die html-Dateien sind für den AVM-Part gedacht, die cgi-Dateien für den Freetz-Part.

Läuft alles nur mit dem AVM-Webserver oder kann man es auch mit httpd ausprobieren?
Ich verweise mal auf mein eigenes Geschreibsel, insbesondere den ersten Absatz.

Heißt es nicht zufällig /usr/www ?
auf der Box ja, auf dem PC nein.

Da wird irgendwo Windows-Zeilenumbruch eingefangen. Dadurch schlägt deine Prüfung fehl und Login-Seite wird wiederholt angezeigt.
Wo der Windows-Zeilenumbruch wohl herkommt?
Die ganzen Dateien haben bei mir kein Windows gesehen. Könnte es sein, dass Du selbst da was geändert hast?

Ich hatte in deinem loadpage-Skript mir die Variable "page" loggen lassen. Interessanterweise kommt sie beim ersten Mal richtig durch, ohne 0x0D und nur beim zweiten Mal mit dem Windows-Zeilenumbruch
Das riecht für mich danach, dass Du das Shellscript unter Windows editiert hast. An der Stelle, wo die Seite der Variablen nextpage zugewiesen wird, könnte noch ein Windoof-Umbruch mit gelesen werden ...

Edit6:
Code:
nextPage="$(echo "$page" | tr -d '\015')";
löst das Problem.
Yo, allerdings würde ich vorziehen, dass Du einen anständigen Editor nimmst und die überflüssigen Zeichen entfernst. Vim gibt es auch für Windows und dort ist es nur ein Befehl, alle ^M zu entfernen ;)

Log-Seite wehrt sich noch,
Was passiert bei der Anzeige der Logdateien?

eben wie der Benutzer "rednose" ohne Passwort.
Lies nochmal bitte meinen ersten Beitrag genauer durch ;)

Gruß Geronimo
 
Hi Geronimo,
ich hatte die gleichen Probleme wie Hermann.

1. Den Inhalt von tinyWeb hab ich nach /var/html verlinkt und base entsprechend angepasst.

2. Bei mir hat die Page-Variable auch einen Windows Zeilenumbruch hintendran.

3. Du prüfst in validateUser als erstes auf user und password. Da kann doch eine Anmeldung ohne Passwort nicht funktionieren?
Du vergleichst check mit key. Und key ist die md5sum von user und password. Wie kann das funktionieren?

4. Wenn ich auf die Logseite zugreife, dann ist die sid wieder leer.
Code:
May 19 08:36:25 freetz user.notice root: loadpage well, login is ok
May 19 08:36:25 freetz user.notice root: loadpage nextpage=[/home]
May 19 08:36:25 freetz user.notice root: loadpage servePage(/var/html/home.fat)
May 19 08:36:25 freetz user.notice root: loadpage check: fasid=[334154d2a5ee79d5ee7d56eaaddd073b] - org=[334154d2a5ee79d5ee7d56eaaddd073b]
May 19 08:36:33 freetz user.notice root: loadpage initial page=[/cgi-bin/logs]
May 19 08:36:33 freetz user.notice root: loadpage nextpage=[/login]
May 19 08:36:33 freetz user.notice root: loadpage servePage(/var/html/login.fat)
May 19 08:36:33 freetz user.notice root: loadpage check: fasid=[] - org=[123]
edit:
Code:
-local chksum=$(echo "$REMOTE_ADDR:$user:$gid:$uid:$SERVER_PROTOCOL:$HTTP_USER_AGENT" | md5sum)
+local chksum=$(echo "$REMOTE_ADDR:$user:$uid:$gid:$SERVER_PROTOCOL:$HTTP_USER_AGENT" | md5sum)


5. Warum wird mein Mouse-Cursor zu einem Eingabesymbol, wenn ich über die Links fahre? Normalerweise hab ich da ein anderen Cursor. Finde ich sehr verwirrend.

MfG Oliver
 
Zuletzt bearbeitet:
Hallo,

jetzt muss ich doch mal ganz provokativ fragen:
Was ein Prototyp ist, wisst Ihr aber schon?

Das heißt, dass ich mich nur um die Punkte gekümmert habe, die für mich von Interesse waren - und dazu hat mit Sicherheit nicht dazu gehört, wie der Mauszeiger aussieht. Das ist ne Übung, der ich mich bei einer möglichen Realisierung widmen würde ...

Den Inhalt von tinyWeb hab ich nach /var/html verlinkt und base entsprechend angepasst.
... und das Anpassen von base hast Du unter Windows gemacht?

Ich habe mir die Datei gerade mit einem Hex-Editor angeschaut - ich kann keinen Windows-Umbruch feststellen. Was ich mir noch vorstellen könnte, auch wenn ich es für unwahrscheinlich halte - wäre, dass der Zeilenumbruch beim Entpacken auf USB-Stick (vfat?) gekommen ist.

Wie gesagt, bei mir gibt es kein Windows und auch keinen Windows-Zeilenumbruch.

Du prüfst in validateUser als erstes auf user und password. Da kann doch eine Anmeldung ohne Passwort nicht funktionieren?
Das ist völlig korrekt und es gibt auch keinen Benutzer ohne Passwort ;)
Das Kennwort von rednose heißt "keines".


Wenn ich auf die Logseite zugreife, dann ist die sid wieder leer.
Ja, sorry, das war ein Fehler heute morgen. Hatte wohl noch etwas Schlaf in den Augen.

Der Patch ist nicht ganz richtig. Du hast zwar meinen Fehler gefunden, aber Zeile 68 ist korrekt. Bei Zeile 119 war ein Dreher drin.

Die richtige Zeile (119) lautet:
Code:
local chksum=$(echo "$FAABRIRA:$user:$FAABRIN:$gid:$FAABRIP:$FAABRIUA" | md5sum)


Warum wird mein Mouse-Cursor zu einem Eingabesymbol, wenn ich über die Links fahre? Normalerweise hab ich da ein anderen Cursor. Finde ich sehr verwirrend.
Wie ich schon schrieb, habe ich da kein Auge drauf geworfen.
Könnte sein, dass es daran liegt, dass ich kein href bei den Links habe.
Werde ich mit berücksichtigen, wenn ich die Seiten mit haserl ausprobiere.

Gruß Geronimo
 
Nein, ich hab nichts unter Windows angepasst. Ich bin doch kein Anfänger. :rolleyes:
Ich denke, dass der Zeilenumbruch vom Browser zurück kommt. Woher kommt denn die page-Variable?

Warum soll ich auch bei einem Prototyp sowas nicht anmerken, wenn es mir auffällt?

MfG Oliver
 
Warum soll ich auch bei einem Prototyp sowas nicht anmerken, wenn es mir auffällt?
Ok, sorry, dann habe ich Deinen Kommentar in den falschen Hals bekommen.
Ich gelobe Besserung :)

Nein, ich hab nichts unter Windows angepasst. Ich bin doch kein Anfänger. :rolleyes:
Ich denke, dass der Zeilenumbruch vom Browser zurück kommt. Woher kommt denn die page-Variable?
Also wenn ich mir die Logs von Herman anschaue, ist die erste Ausgabe der Seite in Ordnung, d.h. das ist der direkte Aufruf von index.html ...
Die fehlerhafte Ausgabe ist nach dem Login, d.h. hier wurde die Adresse der Seite in ein Formularelement gesteckt.

Kann es sein, dass meine Javascript-Funktion fehlerhaft ist?
Oder ist das bei Windows-Browsern so, dass der Wert eines Eingabefeldes mit Zeilenvorschub bedacht wird?

Könntet Ihr bitte mal unter Linux am PC mit apache probieren, ob es dort so tut, wie ich beschrieb? Vielleicht ist das Verhalten von busybox-httpd geringfügig anders als apache?!? - Das tr einzubauen ist kein Act, aber mich würde jetzt schon interessieren, woher der Windows-Zeilenumbruch kommt.

Ich seh schon - ich muss meine USB-Platte umstecken und auf der Box testen. Werde aber vermutlich erst am WE wieder dazu kommen.

Gruß Geronimo
 
@Gero013:
1. Bitte nimm unsere Anmerkungen nicht persönlich.
2. Weder ich, noch Oliver, noch Ralf sind Anfänger. Deswegen unterstelle uns bitte nicht elementare Fehler. Wenn wir es schon hier melden, dann hatten wir solche Sachen wie passende Zeilenenden beim Abspeichern einer Datei und einen geeigneten Editor als Notepad bereits überprüft. Zu meiner Zeit bin ich zu oft mit sowas auf die Nase gefallen, dass ich es natürlich als erstes im Verdacht hatte.
3. Dieses Zeilenende kommt mit Sicherheit vom Browser unter Windows. Das brauchen wir nicht zu überprüfen. Die Frage ist nur, an welcher Stelle wird es eingefangen: Im JavaScript oder wird es direkt vom Browser gemeldet. Wenn ich mal Zeit habe, kann ich versuchen es nachzustellen und verifizieren voher es kommt. Workarround bis dahin wäre meine Lösung mit tr. Viel interessanter wäre noch zu wissen, was da im Falle von MAC gemeldet wird. Nicht dass man dort überhaupt kein 0x0A und stattdessen nur 0x0D empfangen würde, wie es bei MAC ja üblich ist. Sowas hatte ich irgendwann mal erlebt, als ich meine betamax-Skripte geschrieben hatte. Die Webseiten von betamax scheinen von einem MAC-Fan geschrieben zu sein, sodass ich zunächst mal mächtige Probleme mit sed und Co. hatte.
4. Kannst du bitte sobald du ein Paar weitere Änderungen hast, deine aktuelle Version in #1 posten? Du könntest die alte damit überschreiben. Wünschenswert wäre eine Versionsnummer einzuführen. Von mir aus 0.01.
5. Bitte stell es auf die Box-WebIF um, so wie ich und Oliver angemerkt hatten. Es ist immer besser, dein Werk auf der Box zu testen, als irgendwo unter Linux und Apache. Bei deinem Linux kannst du einen entsprechenden Symlink anlegen oder irgendwie ähnlich das Problem lösen, dass du nicht immer zweigleisig fährst.
6. Schreib in #1 bitte einen Zweizeiler dazu, wie und wo man die Dateien entpackt (teilweise gibt es schon) und vor allem verlinkt. Z.B.
a) Alles entpacken nach var. Dann liegt tinyWeb direkt unter var (ja, es ist RAM und somit möglich) und configs/Passwörter landen automatisch unter mod.
b) (ungeprüft)
Code:
mount -o bind /var/tinyWeb /usr/www/html  #  anstatt AVM-WebIF einbinden
umount /usr/www/html # zurueck zu AVM-WebIF

MfG
 
Es ist immer besser, dein Werk auf der Box zu testen, als irgendwo unter Linux und Apache.

Wenn Du schon ein Linux-System hast (und wenn es eine VM ist), dann kannst Du die als NFS-Server einrichten und die Box als NFS-Client. Dann kannst Du bequem auf dem Linux-System Dateien bearbeiten und direkt auf der Box aufrufen.
 
Bitte nimm unsere Anmerkungen nicht persönlich.
Ich arbeite dran. Gleichzeitig möchte ich Euch um das gleiche bitten!
Ich bin neu hier und habe noch kein Gefühl für Euren Umgang miteinander.
Schätze aber, dass sich das von alleine ergibt.

Weder ich, noch Oliver, noch Ralf sind Anfänger.
Huch? - Sorry wenn der Eindruck entstand.
Wenn hier ein Anfänger, dann bin das doch wohl ich!

Die genannten Personen waren für mich recht bald die "alten Hasen", bzw. die Macher im Hintergrund.

Deswegen unterstelle uns bitte nicht elementare Fehler. Wenn wir es schon hier melden, dann hatten wir solche Sachen wie passende Zeilenenden beim Abspeichern einer Datei und einen geeigneten Editor als Notepad bereits überprüft.
Ok, sorry.

Der Fehler kam vielleicht daher, dass ich mir nix anderes vorstellen konnte und dass ich in anderen Foren eher mit Windows-Usern zu tun habe, die sich für alte Hasen halten :oops:

Dieses Zeilenende kommt mit Sicherheit vom Browser unter Windows. Das brauchen wir nicht zu überprüfen. Die Frage ist nur, an welcher Stelle wird es eingefangen: Im JavaScript oder wird es direkt vom Browser gemeldet. Wenn ich mal Zeit habe, kann ich versuchen es nachzustellen und verifizieren voher es kommt. Workarround bis dahin wäre meine Lösung mit tr.
Ok, Danke!

Kannst du bitte sobald du ein Paar weitere Änderungen hast, deine aktuelle Version in #1 posten? Du könntest die alte damit überschreiben. Wünschenswert wäre eine Versionsnummer einzuführen. Von mir aus 0.01.
Ok, dafür hatte ich das Datum im Dateinamen, aber wenn Euch eine Versionsnummer lieber ist - kein Problem ;)

Bitte stell es auf die Box-WebIF um ...
Yo - hatte ich ja schon angedeutet machen zu wollen.

tinyWeb direkt unter var (ja, es ist RAM und somit möglich) und configs/Passwörter landen automatisch unter mod.
Also dass var dem Ram entspricht ist mir schon klar. Genauso, wie die Dateien im Flash nicht so ohne weiteres änderbar sind.
Ich weiß, dass Flash nur eine begrenzte Zahl von Schreibzyklen überlebt und wenn ein Chip geflasht wird, wird ja immer der gleiche Speicherbereich überschrieben, d.h. die Haltbarkeit von USB-Sticks kann nicht als Basis dienen. Weil ich mir die Box nicht durch zu viele Schreibzyklen schrotten wollte, habe ich bislang nur auf dem PC getestet (ich wollte es mit busybox machen, hätte das dann aber wohl neu übersetzen müssen).

(ungeprüft)
Code:
mount -o bind /var/tinyWeb /usr/www/html  #  anstatt AVM-WebIF einbinden
umount /usr/www/html # zurueck zu AVM-WebIF
Das geht mal garnicht.
Das war mit das erste, was ich ausprobiert habe.
Der Kontrollmanager von AVM hat schon alle Seiten gelesen und hält die im Cache, sodass sich keine Änderung ergibt.
Wenn man das austauschen wollte, müsste man in die Boot-Reihenfolge eingreifen. Da ich nicht weiß, ob da was instabil würde, würde ich vorziehen,
den mount nach /usr/mww zu machen (vorher natürlich freetz nach tinyWeb kopieren).

Wenn Du schon ein Linux-System hast (und wenn es eine VM ist), dann kannst Du die als NFS-Server einrichten und die Box als NFS-Client.
Danke für den Tip!
Auf die Idee bin ich noch garnicht gekommen. Das wäre natürlich das genialste, da ich sowieso mit nfs arbeite ...

Gruß Geronimo
 
Das geht mal garnicht.
Das war mit das erste, was ich ausprobiert habe.
Der Kontrollmanager von AVM hat schon alle Seiten gelesen und hält die im Cache, sodass sich keine Änderung ergibt.
Wenn man das austauschen wollte, müsste man in die Boot-Reihenfolge eingreifen. Da ich nicht weiß, ob da was instabil würde, würde ich vorziehen,
den mount nach /usr/mww zu machen (vorher natürlich freetz nach tinyWeb kopieren).
Ich habe den Symlink /var/html geändert und die Seiten wurden sofort vom ctlmgr dargestellt. Vielleicht hast du irgendwas falsch gemacht.

MfG Oliver
 
Hallo Gero,

habe mir den Prototypen gerade angeschaut. Da es ein Prototyp ist, müssen wir über viele Unzulänglichkeiten im Detail nicht sprechen. Aber auf funktionaler Ebene ist mir folgendes aufgefallen bzw. missfallen:
Was tut: Anmeldung mit 2 unterschiedlichen Benutzern
Allerdings nur nacheinander; es kann max. eine Session zur Zeit existieren. Das sollten wir ändern, wenn wir schon mehrere Benutzer unterstützen wollen.
Session-ID und Kennwort wird jeweils mit md5 verschlüsselt, die Anmeldedaten werden allerdings in Klartext übertragen.
Welches Kennwort wird verschlüsselt?

Jeder Benutzer scheint genau eine Session-Id zu haben, die immer wieder verwendet wird (auch bei neuen Sessions dieses Benutzers) und die relativ einfach zu erraten ist. => Irgendwelche Zufallsdaten sollten in die Session-Id mit einfließen.
Weder Anmeldung, noch Sitzungsverwaltung benötigt cookies.
Ok, das kann vorteilhaft sein. Die Umsetzung gefällt mir allerdings nicht: Zum einen bin ich ein Feind von JavaScript-Links, zum anderen sollten Anfragen, die den Zustand der Web-Anwendung nicht ändern, nicht per POST gestellt werden, sondern per GET. (Beim Reload fragen sonst Browser wie Firefox jedes Mal nach, ob man die Aktion wiederholen möchte.)

Wie stellst du dir die Übergabe von weiteren Parametern an CGI-Skripte vor oder das Hochladen von Dateien?
wenn jedoch der angezeigte URL des Browsers neu aktiviert wird, wird die Sitzung beendet und eine neue Anmeldung ist notwendig (yepp, das ist so gewollt).
Ich bin ein Freund von sprechenden URLs, auf die man einfach Bookmarks legen kann. Bei dir heißt jede Seite gleich (loadpage), und Bookmarks sind unmöglich.
Der einzige weiterführende Link, der mit Funktionalität belegt ist, ist "Logdateien".
Da erscheint bei mir eine leere Seite ohne Log und Download- oder Refresh-Button. Ich bin dem nicht weiter nachgegangen.

Ich wäre dafür, dass wir vor weiteren Prototypen alle gemeinsam eine Liste von Anforderungen erarbeiten, damit wir wissen, was wir wollen (oder nicht) und was wir brauchen.

Viele Grüße,

Andreas
 
Zuletzt bearbeitet:
@Gero013:
1. Es funktioniert grundsätzlich mit mount -o bind und zwar sofort, wie Oliver berichtet hat. Ich hatte allerdings bei mir komplettes www übermounted und dadrunter ein Verzeichnis angelegt gehabt. Daher kam meine "ungeprüft", weil ich es exakt so nicht ausprobiert hatte.
2. Schließt euch bitte mit Andreas Bühmann zusammen, wie er vorschlägt. Dein Anfang und deine Motivation sind viel versprechend, allerdings lass dir bitte von unseren Profis hier ein Paar Tipps geben, bevor du selbst anhand eigener Fehler was lernst und Zeit verschwendest. Andreas hat schon Recht, dass man sich von vorne an ein Paar Grundgedanken machen sollte. Denn nachträglich etwas einzupflegen ist immer aufwändiger.
3. Über Lebensdauer vom Flash brauchst du dir keine Gedanken machen. Ich kenne hier noch keinen, der es geschafft hat Flash seiner Box in den letzten 5 Jahren zu zerschrotten. Das Gleiche gilt für die USB-Sticks. Nur, wenn du USB-Stick als SWAP benutzt und ständig Logs darauf speicherst, kann es dir passieren, dass nach einem Jahr so ein Stick einige Inkonsistenzen zeigt. Frag mich aber nicht, wieviele Millionen Schreibzyklen in diesem Jahr auf diesem USB-Stick ausgeübt werden.
Die gängige Praxis für Entwicklung ist jedoch deine Daten im RAM abzulegen und mit mount -o bind übermounten. Auf die Dateien kann man dann z.B. per scp zugreifen. Oder du machst es mit NFS-Mount, wie es oben empfohlen wurde.

MfG
 
OT: Die ct hat mal versucht, gezielt einen USB-Stick durch dauernde Schreibvorgänge kaputt zu bekommen. Sie haben es irgendwann aufgegeben. Und mal kann davon ausgehen, daß die dafür gesorgt haben, daß wirklich ununterbrochen Schreibvorgänge stattfinden, im Gegensatz zur Aktivität beim Swappen oder Speichern von Logs, die sicher weniger häufig sind.
 
Ich habe den Symlink /var/html geändert und die Seiten wurden sofort vom ctlmgr dargestellt. Vielleicht hast du irgendwas falsch gemacht.
Letzteres will ich nicht ausschließen, aber habt Ihr auch eigene Inhalte probiert, oder nur den Link auf AVM-Inhalte geändert?
Ich hatte versucht, AVM-Seiten zu modifizieren und die Änderungen wurden nicht angenommen. Dazu habe ich (auf der Box) die Seiten nach /var kopiert, dort modifiziert und dann nach /usr gemountet. Ich habe es nicht geschafft, geänderte Seiten angezeigt zu bekommen.

Allerdings nur nacheinander; es kann max. eine Session zur Zeit existieren. Das sollten wir ändern, wenn wir schon mehrere Benutzer unterstützen wollen.
Dass es nur eine Sitzung geben kann, schrieb ich ja schon. Allerdings empfinde ich das eher als Vorteil.

Mehrere Benutzer ist eine Sache, aber mehrere gleichzeitig auf der Box - wollte ich z.B. nicht haben!

Jeder Benutzer scheint genau eine Session-Id zu haben, die immer wieder verwendet wird (auch bei neuen Sessions dieses Benutzers) und die relativ einfach zu erraten ist. => Irgendwelche Zufallsdaten sollten in die Session-Id mit einfließen.
Wenn Du Dir das loadpage Script mal anschaust, siehst Du, dass die Session-ID nicht "nur" vom Benutzer abhängt und anhand der Parameter, die in die Berechnung einfließen fand ich es unerheblich, ob die SID erraten werden kann oder nicht - sobald jemand die Sid übernimmt, ist die Sitzung beendet.

Zum einen bin ich ein Feind von JavaScript-Links, zum anderen sollten Anfragen, die den Zustand der Web-Anwendung nicht ändern, nicht per POST gestellt werden, sondern per GET. (Beim Reload fragen sonst Browser wie Firefox jedes Mal nach, ob man die Aktion wiederholen möchte.)
Zumindest bei letzerem gebe ich Dir recht. Ich hatte beide Varianten ausprobiert und da get leichter zu handeln war, hatte ich das zuerst gemacht, sodass der Stand noch auf Post war. War aber selbst schon genervt von den Abfragen, sodass ich da selbst was ändern wollte.
Was die Javascript-Links angeht - sind die nur die Konsequenz aus dem vorgeschaltenem Frame. Wenn ich so einen Frame habe, will ich Internas der Webseite verbergen - und genau für den Zweck sind auch die JS-Links.
Wer die nicht haben will, sollte auch den Frame nicht wollen ;)

Wie stellst du dir die Übergabe von weiteren Parametern an CGI-Skripte vor oder das Hochladen von Dateien?
Nun, die ganzen Parameter werden von "meinem" Script doch bereits ins Environment geschrieben, bevor die CGI-Datei aufgerufen wird. Das funktioniert für Get und für Post, wobei ich keinen Upload probiert habe.
Aber da haserl die Funktionalität bietet, wollte ich das Script sowieso umstellen.

Ich bin ein Freund von sprechenden URLs, auf die man einfach Bookmarks legen kann. Bei dir heißt jede Seite gleich (loadpage), und Bookmarks sind unmöglich.
Hm, also das sehe ich anders.
Bei informativen Webanwendungen gebe ich Dir recht, aber Links, die nach einem Login liegen, sollten nicht "gebookmarkt" werden können. Deshalb finde ich es wichtig, dass alles wichtige von der Einstiegsseite aus erreichbar ist.
Ich bin davon ausgegangen, dass der vorgeschaltete Frame genau dafür da ist, dass man die Links eben nicht bookmarken kann.

Da erscheint bei mir eine leere Seite ohne Log und Download- oder Refresh-Button. Ich bin dem nicht weiter nachgegangen.
Ok, das dürfte das bekannte Problem mit dem Windows-Zeilenumbruch sein.

Ich wäre dafür, dass wir vor weiteren Prototypen alle gemeinsam eine Liste von Anforderungen erarbeiten, damit wir wissen, was wir wollen (oder nicht) und was wir brauchen.
Wunderbar, jetzt seid Ihr auch an dem Punkt angekommen, wo ich eine nicht öffentliche Diskussion mit den Machern wollte ;)

Über Lebensdauer vom Flash brauchst du dir keine Gedanken machen.
Nun, als ich für nen Kumpel meine erste Firmware schrieb, habe ich selbst viel experimentiert und gedacht, die Anzahl Schreibzyklen schaffe ich nicht, aber plötzlich war der Chip hin. War zwar nur ein Attiny - aber das Prinzip ist immer noch das Gleiche. Ich hatte den USB-Stick als Gegenteil der Lebensdauer angeführt!
Aber der Tip von Ralf war genial, den werde ich als nächstes umsetzen.

Gruß Geronimo
 
Ich möchte mla kurz anmerken, dass die Sicherheit zwar ein allgemein nettes Gut ist, aber mal ehrlich: Jahrelang reicht die Basic-Auth des Busybox-httpd aus, und ganz plötzlich wird über Session-Management, multisession und was weiss ich alles. Wir sollten die Kirche ma im Dorfe lassen, finde ich, denn normalerweise kommt man von Außen nicht an dieses Webinterface, und im besten Falle, eben wenn doch, ist es noch getunnelt und benötigt ein Zertifikat. Bitte also nicht übertreiben, denke ich mal.

Btw hat buehmann keine nicht öffentliche diskussion angeregt, sondern eine Sammlung angeregt der ERfordernisse. Dies kann durchaus öffentlich passieren, und ich denke, ich hielte eine öffentliche diskussion dafür sogar für gut. Wieso alles unter der Haube über dne Haufen werfen? User sollen es mitlesen können und sogar ne Meinung dazu haben. Wobei ich allerdings dann 2 Threads vorschlagen würde. Einen mit der Sammlung, und ein weiterer zum Diskutieren. Alles andere wird unübersichtlich.
 
Dass es nur eine Sitzung geben kann, schrieb ich ja schon. Allerdings empfinde ich das eher als Vorteil.
Mehrere Benutzer ist eine Sache, aber mehrere gleichzeitig auf der Box - wollte ich z.B. nicht haben!
Warum das? Wenn man schon verschiedene Benutzer hat, sollen sie sich dann absprechen, wer wann auf die Box darf?

sobald jemand die Sid übernimmt, ist die Sitzung beendet.
Wie das? (Ich habe das Skript noch nicht angeschaut).

Was die Javascript-Links angeht - sind die nur die Konsequenz aus dem vorgeschaltenem Frame. Wenn ich so einen Frame habe, will ich Internas der Webseite verbergen - und genau für den Zweck sind auch die JS-Links.
Wer die nicht haben will, sollte auch den Frame nicht wollen
Und wieso sollte das mit normalen Links nicht gehen? Oder willst Du mehrere Frames gleichzeitig ändern?

aber Links, die nach einem Login liegen, sollten nicht "gebookmarkt" werden können.
Ich bin davon ausgegangen, dass der vorgeschaltete Frame genau dafür da ist, dass man die Links eben nicht bookmarken kann.
Warum sollte man das aktiv verhindern wollen? Wenn ich einen Link auf die Seite xy aufrufe und statt dessen eine Paßwortabfrage kommt, finde ich es gut, wenn man nach Eingabe des Paßworts auf die Seite xy kommt und nicht auf die Startseite.
 
@Silent-Tears: Doch, doch. Eine vernünftige Benutzerverwaltung für WebIF halte ich für sinnvoll. Und wenn man von diesem AUTH-POPUP weg ist, kann man endlich ohne große Ängste WebIF per https nach draußen geben.
@Gero013: Ich bin mit Ralf und Andreas in Sachen parallele Benutzeranmeldung und direkte Links völlig einverstanden. Wenn schon, dann schon. Gründe:
a) Durch multi-Tabs kann dir schnell passieren, dass Benutzer1 im WebIF "sitzt", ohne es zu wollen. Dadurch eine zweite Anmeldung verhindern oder umgekehrt den ersten Benutzer rausschmeißen wäre schlecht.
b) Direkte Links sind allgemein nützlich und können zudem von automatischen Curl-basierten Programmen genutzt werden. Deswegen sollte man sie ermöglichen.

Zu den eindeutigen SIDs. Es geht nicht darum, dass jemand die SID erraten kann. Es besteht jedoch rein theoretisch die Gefahr (wie mit AUTH-PopUP), dass dir durch fremde Seiten in irgendwelchen Frames etc. die Session "geklaut" werden kann. Deswegen sollte man Session-Id "salzen".

MfG
 
Status
Für weitere Antworten geschlossen.
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.