WebIF - Entwicklung/Weiterentwicklung

[Silent-Tears]

Schreibrechte vergeben können nur die Trac-Admins (Lars, Alexander und ich).

Das geht auch aus dem trac heraus? Ich nannte uns beide, weil du auf dem Server ebenso wie ich Consolen-Zugriff hast.

 

[olistudent]

Ja. Trac Admin -> Subversion Access

MfG Oliver

 

[Silent-Tears]

Danke. Wieder was gelernt.

 

[Gero013]

Logo für Freetz

Hallo,

mein erster Logo-Entwurf ist bei Andreas in Ungnade gefallen.

Deshalb habe ich den Pinsel geschwungen und zwei neue Varianten erstellt, die ich gerne zur Diskussion stellen möchte.
Zum Einen: Freetz ohne Logo geht mal garnicht

Zum Anderen denke ich, das Logo sollte sich soweit abheben, dass man keine Copyright-Probleme bekommt, andererseits noch so nahe beim Original sein, dass man eine Assoziation zum Original findet.

Also wenn es der erste Entwurf nicht sein darf, dann gefällt mir der letzte besser, wo die ersten drei ersetzten Buchstaben noch erkennbar sind.
Was meint Ihr?

Gruß Gero

 

[dj1985]

Warum ist dein Konfig speicher 512kb groß?
Der von meiner 7270v3 hat nur 256kb

 

[dileks]

Hi,

ich bin im IRC auf #fritzbox über die Commit-Messages, die der Bot dort pasted, auf den "webif-prototype" SVN branch aufmerksam geworden.

Wie weit ist denn das Projekt?
Sind die gröbsten Kinderkrankheiten beseitigt, sprich kann man es ausprobieren?

Was sind denn die Vorteile gegenüber der Originalen AVM-UI (WebIF)?
Konkret, spart man Speicherplatz auf der Box?

Die Screenshots sehen sehr viel versprechend aus.

Zum Logo, das erste Logo würde mir zusprechen (warum sollte AVM da was dagegen haben?).
Bei den beiden anderen gefällt mir das abgehackte "Free" nicht in "Freetz".

My two cents .

 

[buehmann]

Hallo dileks,

Wie weit ist denn das Projekt?

der Branch existiert seit gestern (!) und ist ein Prototyp, um die technischen Grundlagen eines möglichen neuen Webinterfaces auszuprobieren. 99% der Links, die du auf den Screenshots siehst, führen auf leere Seiten (und um die Inhalte geht es momentan auch nicht). Das sollte deine Frage beantworten. Für Benutzer ist es nichts.

Andreas

 

[Silent-Tears]

Moin dileks: Wie wäre es mal mit lesen in diesem Thread, in dem du gepostet hast?

 

[dileks]

Moin dileks: Wie wäre es mal mit lesen in diesem Thread, in dem du gepostet hast?

Moin moin zurück,

das ganze hier ist WIP (Work-In-Progress) und ob Code und dieser Thread "in sync" sind, bezweifle ich stark aus eigener Erfahrung. Da der Code jetzt einen eigenen SVN Branch bekommen hat, ist dies für mich ein Zeichen, dass ein neuer Milestone erreicht wurde. Mir fällt da noch der Spruch unseres Ex-Rektors an die Erstsemestler ein: "Seien sie stets neugierig". Frage nach Status eines WIP Projektes sind bei mir erlaubt und an der Tagesordnung (IRC, Wiki, Mailing-List, etc.), sonst wär es ja kein WIP.

Darüber hinaus halte ich es für sinnvoll (so machen es auch ein paar Package-Maintainer hier im IPPF) auf der ersten Seite (des eigentliche Threads) den aktuellen Status per "Update $DATUM" auf dem Laufenden zu halten.
Deinem auf mich flappsig wirkenden "Lies den Thread" halte ich ein "Man erstelle eine Wiki-Seite auf trac und schreibe da rein" entgegen.

 

[buehmann]

Da der Code jetzt einen eigenen SVN Branch bekommen hat, ist dies für mich ein Zeichen, dass ein neuer Milestone erreicht wurde. Mir fällt da noch der Spruch unseres Ex-Rektors an die Erstsemestler ein: "Seien sie stets neugierig".

Hi dileks, der Spruch beschreibt ungefähr, warum der Code jetzt im SVN ist: Wir waren neugierig. Wir wollen uns anschauen, was Gero, der den Prototyp angestoßen/vorgeschlagen hat, so getrieben hat. Bisher war weder das Verfolgen von Änderungen von Tarball zu Tarball einfach noch deren Installation, um sie auszuprobieren.

Ich habe heute einige Zeit damit verbracht, zu versuchen, den Code zu verstehen und ihn dabei etwas zu vereinfachen. Dabei ist mir eine Reihe an konzeptionellen Dingen aufgefallen, die demnächst zur Sprache kommen müssen.

Viele Grüße,

Andreas

 

[dileks]

Hi dileks, der Spruch beschreibt ungefähr, warum der Code jetzt im SVN ist: Wir waren neugierig. Wir wollen uns anschauen, was Gero, der den Prototyp angestoßen/vorgeschlagen hat, so getrieben hat. Bisher war weder das Verfolgen von Änderungen von Tarball zu Tarball einfach noch deren Installation, um sie auszuprobieren.

Ich habe heute einige Zeit damit verbracht, zu versuchen, den Code zu verstehen und ihn dabei etwas zu vereinfachen. Dabei ist mir eine Reihe an konzeptionellen Dingen aufgefallen, die demnächst zur Sprache kommen müssen.

Ich bin von Haus aus neugierig.
Weiterhon sehe ich einen grossen Vorteil in einem eigenen einzelnen(?) WebIF (was jetzt AVM-UI und Freetz-UI darstellt). D.h. das Ganze "Rumgefrickel" an den einzelnen Dateien, die die AVM-UI repräsentieren entfällt und somit die Extra-Patches.
Wie gesagt, ich habe die Commits im IRC-Bot gesehen und ein wenig in den Dirs im SVN-Branch gestöbert.

Dank an deine aussagekräftigen & hilfreichen Antworten und klar Danke für den Review am Code. Es hat Potential. Falls das Ganze aus den "Kinderschuhen entwachsen ist" ping me.

Ich erinnere mich an meine ersten Schritte mit (damals) noch ds-mod und dem Zusammensuchen der Informationen für die W701v. Ich hab all mein gesammeltes Wissen dann in ein Posting gesteckt, IIRC Alexander bezeichnete es später als "Klassiker".
Auf "Friss den Thread" reagiere ich daher prinzipiell allergisch und Lesen, Reviewen, etc. tue ich eine Menge pro Tag... in anderen OSS-Projekten.

 

[Gero013]

Unglaublich!

da geh ich mal kurz wech zum Essen und schon geht dat ab hier

Warum ist dein Konfig speicher 512kb groß?
Der von meiner 7270v3 hat nur 256kb

Nun, abgesehen davon, dass ich vielleicht Glück auf eine Sondercharge hatte, besteht immer noch die Möglichkeit, dass ich mich verrechnet habe

Du könntest die Seiten ausprobieren und mir sagen, ob Deine Box auch unerwarteten Zuwachs erhalten hat, oder ob es bei Dir richtig angezeigt wird.

Wie weit ist denn das Projekt?
Sind die gröbsten Kinderkrankheiten beseitigt, sprich kann man es ausprobieren?

Hey, also ich würde mal sagen, die Kinderkrankheiten kommen erst noch.

Die Screenshots sehen sehr viel versprechend aus.

Danke, das freut mich!

Zum Logo, das erste Logo würde mir zusprechen (warum sollte AVM da was dagegen haben?).
Bei den beiden anderen gefällt mir das abgehackte "Free" nicht in "Freetz".

Freut mich, dass ich mit meinem Standpunkt nicht alleine bin
Nachdem das erste als bedenklich eingestuft wurde, dachte ich, ich unterstreiche die Namensfindung auch optisch.

99% der Links, die du auf den Screenshots siehst, führen auf leere Seiten (und um die Inhalte geht es momentan auch nicht)

Wohl wahr - Inhalte sind noch Nebensache, allerdings sind die Seiten der Screenshots funktional auscodiert, d.h. sie zeigen die Echt-Daten der Box an. Wenn dort also schon Fehler auffallen (z.B. Größe des Konfigspeichers), würde ich die Punkte gerne erfahren und dem nachgehen.

das ganze hier ist WIP (Work-In-Progress)

Nö, wir sind noch nicht ganz so weit.
Bislang ist es noch PoC (Proof of concept), aus dem vielleicht WIP entstehen soll

Man erstelle eine Wiki-Seite auf trac und schreibe da rein

Puh - also da steht noch viel Diskussionsbedarf an, bevor es *imho* eine Wikiseite wert ist.
Mit dem Eröffnungsbeitrag gebe ich mir Mühe, den aktuell zu halten.

Ansonsten möchte ich zu bedenken geben, dass ich weder der HW-Blicker, noch der CGI-Guru bin. Java (oder auch perl und php) ist eher meine Welt und als ich letztens einen Installateur brauchte, habe ich mich in die Shellprogammierung eingelesen und (einen entsprechenden) geschnitzt. Kann durchaus sein, dass mein Programmierstil deshalb dem einen oder anderen strange vorkommt.
Ich habe eine ziemlich konkrete Vorstellung, wie das WebIF zu bedienen sein soll, bzw. wie es sich darstellen soll - um das jedoch zu erreichen, bin ich für jeden Tip, bzw. jede Unterstützung dankbar!

Gruß Gero

 

[Silent-Tears]

Auf "Friss den Thread" reagiere ich daher prinzipiell allergisch und Lesen, Reviewen, etc. tue ich eine Menge pro Tag... in anderen OSS-Projekten.

Was du anderweitig tust interessiert mich nicht die Bohne, ehrlich gesagt. Ob und wieviel Zeit und KnowHow du dort unterbringst, ist dein Ding und hat 0 mit Freetz zu tun.

"Friss den Thread" impliziert zumindest: Lies zuerst, und dann frag, und nicht deine Reihenfolge, die irgendwie sauer aufstösst: "Erst Fragen, dann irgendwie rummeckern, bis ne Antwort kommt". Du hättest wirklich alles hier erlesen können, incl. dem, was in der timeline zu dem von uns angelegten Branch steht, hättest du ein recht konkretes Bild haben können, was bisher ist und was nicht, und ganz evtl auch konkrete und angemessene fragen stellen. Leider aber hast du die Chence verpasst. Wobei dein weiteres Posting "ping me, wenns grösstenteils funktioniert" auch nur der "haben-wollen"-Mentalität entspringt, die meinem "erst-fragen-ohne-lesen"-Eindruck entspricht. Von daher...

 

[dileks]

Unglaublich!

da geh ich mal kurz wech zum Essen und schon geht dat ab hier
...
Bislang ist es noch PoC (Proof of concept), aus dem vielleicht WIP entstehen soll
...
Puh - also da steht noch viel Diskussionsbedarf an, bevor es *imho* eine Wikiseite wert ist.
Mit dem Eröffnungsbeitrag gebe ich mir Mühe, den aktuell zu halten.
...
Ansonsten möchte ich zu bedenken geben, dass ich weder der HW-Blicker, noch der CGI-Guru bin. Java (oder auch perl und php) ist eher meine Welt
...
Ich habe eine ziemlich konkrete Vorstellung, wie das WebIF zu bedienen sein soll, bzw. wie es sich darstellen soll - um das jedoch zu erreichen, bin ich für jeden Tip, bzw. jede Unterstützung dankbar!

Wie du siehst besteht starkes Interesse an deinem initiierten Werk.

Ob PoC oder WIP sei mal dahingestellt, eine evtl. zu einem späteren Zeitpunkt erstellte Wiki-Seite und eine stets aktualisierte erste Seite im Thread wird sicherlich nicht nur die "Sexyness" an diesem Unterprojekt steigern.
Dokumentation ist ein den ganzen Software-Entwicklungs-Prozess begleitender Prozess. Da wird viel rumgedoktort in OSS-Projekten, Monate (und womöglich noch einige Developers das Projekt verlassen haben) später, muss man sich mühsam über den Code, MLs, Forum, etc. wieder in die Thematik einzuarbeiten. Das muss nicht sein. Nur ein von mir beherzigter Rat an dich.

Wenn du mehr aus der Ecke "Web-Developer" kommst, bist du doch genau richtig für das neue WebIF .
Die anderen Developers können beim Code (und -Styling) helfen.

 

[dileks]

Was du anderweitig tust interessiert mich nicht die Bohne, ehrlich gesagt. Ob und wieviel Zeit und KnowHow du dort unterbringst, ist dein Ding und hat 0 mit Freetz zu tun.

"Friss den Thread" impliziert zumindest: Lies zuerst, und dann frag, und nicht deine Reihenfolge, die irgendwie sauer aufstösst: "Erst Fragen, dann irgendwie rummeckern, bis ne Antwort kommt". Du hättest wirklich alles hier erlesen können, incl. dem, was in der timeline zu dem von uns angelegten Branch steht, hättest du ein recht konkretes Bild haben können, was bisher ist und was nicht, und ganz evtl auch konkrete und angemessene fragen stellen. Leider aber hast du die Chence verpasst. Wobei dein weiteres Posting "ping me, wenns grösstenteils funktioniert" auch nur der "haben-wollen"-Mentalität entspringt, die meinem "erst-fragen-ohne-lesen"-Eindruck entspricht. Von daher...

Du bist mir nicht das erste Mal mit flappsigen Einzeilern im IPPF aufgefallen. Diese sind schlichtweg nicht hilfreich. Ich will hier keine persönlichen Flamwar starten, aber was sollen jetzt noch böswillige Absichten zu unterstellen? Auch das ist nicht hilfreich.
Leider ist es so, dass man nicht auf allen Hochzeiten mittanzen kann oder will.
Die Idee, die AVM-UI auszutauschen ist nicht neu.
Der Ansatz von Gero ist unterstützenswert, das kann durch Code-Review, Testen des Codes, Dokumentation schreiben, etc. bestehen. Leider ist es bei WIP-Projekten so, dass manchmal (je nach Status), der Code gänzlich nicht funktioniert. Also, warum nicht zuerst nach dem funktionalen Status fragen und später testen?
Vergleiche mal deinen Einzeiler und die Ausführungen von buehmann.

 

[buehmann]

So, ich habe heute etwas Zeit mit dem Prototypen verbracht, und denke, ich habe einen guten Überblick. (Danke noch mal an Gero für einige private Erläuterungen.)

Ich gehe mal die Dinge durch, die mir aufgefallen sind:

Mir gefällt die Idee, Seiten aus wiederverwendbaren Komponenten zusammenzusetzen, die entweder statisch sein können, CGIs oder als Besonderheit "AVM-Skripte" (die durch AVMs webcm-Prozessor geschickt werden, um dessen Zugriffsmöglichkeiten auf die Box-Konfiguration zu nutzen).

Auch ein Session-Management zu haben, mit dem in die Seite integrierte Login-Formulare und vor allem der explizite Logout möglich sind, finde ich gut.

Am meisten gestört haben mich zwei Dinge:

1. die Art und Weise, wie Links zu neuen Seiten realisiert sind, nämlich per Javascript, mit dem ein in jede Seite eingebautes HTML-Formular ausfüllt und abschickt (damit u.a. die Session-ID mit übertragen wird).
2. dass ein Reload von Seiten unmöglich ist: Einmal F5 gedrückt, und man fliegt aus der Session. "Nur diesen Frame öffnen" -> dito, Lesezeichen für meinetwegen DSL-Status aufgerufen -> Session beendet. Das liegt unter anderem daran, dass momentan in jeder Seite ein "Sicherheits-Token" mitgeschickt wird, dass für den nächsten Aufruf zu verwenden ist. Das ist eine tolle Sache, um unerwünschte Anfragen abzuwehren, die etwas auf der Box ändern. Für die reine Darstellung von Informationen geht mir das zu weit; ich denke, in dieser Richtung sollte man differenzieren.

Bezüglich meines Punkts 1 denke ich, wir sollten ernsthaft gemeinsam darüber nachdenken, welche Argument für und gegen den Einsatz von Cookies zur Übertragung von Session-IDs sprechen. Das Token bei Punkt 2 sollte natürlich in der Seite verbleiben, aber sein Einsatz sollte meiner Meinung nach eingeschränkt werden.

Desweiteren stört mich der Ansatz, den Login-/Session-Mechanismus möglichst unverständlich (und damit unwartbar) zu kodieren, um Angreifer abzuwehren. Da wir ein Open-Source-Projekt sind und "security by obscurity" in meinen Augen selten etwas taugt, bin ich dagegen. (Ich bin mir sicher, Gero wird seinen Ansatz noch näher begründen; ich bin ihm leider etwas auf den Schlips getreten, als ich großzügig Variablennamen lesbar umgestaltet habe. Das war nicht meine Absicht; ich konnte mir nicht vorstellen, dass hinter unverständlichem Code ein Zweck steckt.)

Zuletzt noch eine lose Sammlung von verbesserungswürdigen Dingen, bei denen ich weiß, dass ein so junger Prototyp wie unserer sie noch nicht berücksichtigen kann und muss. Aber für die Zukunft sollten wir sie festhalten:

• Nachrichten, die in verschiedene Sprachen übersetzbar sind, sind momentan so eingebunden: <%m XYZ12%> So hat man kaum Anhaltspunkte, was sich dahinter verbirgt und muss Seiten "blind" bearbeiten (oder ständig nachschlagen). Das könnte man verbessern (z.B. ähnlich wie bei GNU gettext)
• Wir sollten daran denken, dass das Framework nicht nur HTML-Dateien ausliefern können muss, sondern auch Text, Binary, etc.
• Das Webserver-Verzeichnis sollte umstrukturiert werden: Alles, worauf kein direkter Zugriff notwendig ist, sollte auch nicht im Zugriffsbereich des Webservers liegen (Sachen wie ./conf/, viele Dateien in ./cgi-bin/, etc.)
• Das Stylesheet sollte nicht inline übertragen werden.
• Es sollten mehrere parallele Sessions möglich sein; sonst gibt es Chaos bei mehreren Benutzern.

Bei den folgenden Punkten sind die Geschmäcker verschieden:

• Ich mag keine Frames, schon gar nicht, wenn sie 100% des umgebenden Fensters einnehmen und erzwungen werden. Die URL-Zeile des Browsers ist dafür da, dass man dort mit den URLs arbeiten kann (bearbeiten, kopieren, Lesezeichen), nicht dafür, dass eine statische URL alles versteckt, was im Hintergrund passiert.
• Ich mag kein tabellenbasiertes Layout. Glücklicherweise lässt sich das ja mit dem Theme-/Skin-Mechanismus, der im Prototyp enthalten ist, individuell ändern.

Puh, das war eine Menge. Ich hoffe auf eine spannende Diskussion.

Andreas

 

[Gero013]

Hallo,

das Wichtigste zuerst:

ich bin ihm leider etwas auf den Schlips getreten, ...

Davon kann keine Rede sein.
Wir haben unterschiedliche Standpunkte ausgetauscht und ich habe auch gesagt, was mir gefällt oder nicht gefällt, mehr ist und war da nicht.

So, jetzt zur Sache

die Art und Weise, wie Links zu neuen Seiten realisiert sind, nämlich per Javascript, mit dem ein in jede Seite eingebautes HTML-Formular ausfüllt und abschickt (damit u.a. die Session-ID mit übertragen wird).

Yo, mir hat man beigebracht, dass ein Cookie leichter ausgelesen werden kann, als der Inhalt einer Seite in einem anderen Browsertab. Das ist aber schon ein paar Tage her, wenn also jemand aktuellere Fakten hat, lasse ich mich überzeugen.

dass ein Reload von Seiten unmöglich ist: Einmal F5 gedrückt, und man fliegt aus der Session.

Das kam erst auf Anforderung aus diesem Fred dazu.

Ich wurde aufgefordert, die Session zu salzen. Damit ist aber erheblicher Aufwand nötig, um einen Refresh von einer normalen Seitenanforderung zu unterscheiden. Den habe ich zwar angedacht, aber bislang keine Lust gehabt, dafür meine Zeit zu investieren.

Für die reine Darstellung von Informationen geht mir das zu weit; ich denke, in dieser Richtung sollte man differenzieren.

Völlig einverstanden.

Vielleicht sollte man nochmal über mögliche Angriffe nachdenken.

Ich habe mir die Angriffstechniken nochmal angelesen und bin der Meinung, dass mit meinem "ungesalzenen" Ansatz zwar die Vorbereitung für den Angriff ausgeführt werden kann, der Angriff an sich aber nur ein Login-Formular bringt.

Ich bin mir sicher, Gero wird seinen Ansatz noch näher begründen

Wen es von den Machern interessiert, dem erkläre ich meinen Standpunkt gerne per PN, aber hier im Forum möchte ich mich dazu nicht outen.

Nachrichten, die in verschiedene Sprachen übersetzbar sind, sind momentan so eingebunden: <%m XYZ12%> So hat man kaum Anhaltspunkte, was sich dahinter verbirgt und muss Seiten "blind" bearbeiten (oder ständig nachschlagen). Das könnte man verbessern (z.B. ähnlich wie bei GNU gettext)

An gnu-gettext habe ich auch schon gedacht, insbesondere da ihn viele Anwendungen sowieso schon einsetzen. Fehlt also "nur" noch das echte gettext.
Mein Ansatz, den Schlüssel auf 5 Zeichen zu begrenzen hat ausschließlich Platzgründe. Einmal wird der Schlüssel in den Quellen vom WebIF verwendet, zum anderen arbeitet die "Datenbank" mit konstanter Schlüssellänge, um eine schnelle Binärsuche auf dem Index zu ermöglichen. Jedes Byte, um das der Schlüssel vergrößert wird ist mit der Anzahl von DB-Einträgen und dem Aufkommen der Schlüssel zu multiplizieren.
Ich halte ein Offenhalten der Text-Quelle während der Entwicklung für einen akzeptablen Kompromiss (so arbeite ich auch, indem die Quellen immer offen sind).

Wir sollten daran denken, dass das Framework nicht nur HTML-Dateien ausliefern können muss, sondern auch Text, Binary, etc.

Meinst Du jetzt zum Sichern der Einstellungen oder wozu?

Das Webserver-Verzeichnis sollte umstrukturiert werden: Alles, worauf kein direkter Zugriff notwendig ist, sollte auch nicht im Zugriffsbereich des Webservers liegen (Sachen wie ./conf/, viele Dateien in ./cgi-bin/, etc.)

Das conf-Verzeichnis liegt in der Webroot, weil ich diese per NFS einbinde. In der Firmware gibt es nur Links, die die Dateien in conf referenzieren.
So kann ich ohne Aufwand zwischen Box und Entwicklung umschalten.
Selbstverständlich ist das kein Layout für stable (dann sollten die Dateien dorthin gepackt werden, wo jetzt die Links liegen) - aber davon ist der Prototyp ja noch weit entfernt.

Das Stylesheet sollte nicht inline übertragen werden.

Warum nicht?
Wenn ich es inline übertrage, kann es in einem Kennwort-geschützten Bereich liegen (ist jetzt der Fall). Wenn es offline angefordert werden soll, muss der Bereich frei zugänglich sein.

Es sollten mehrere parallele Sessions möglich sein; sonst gibt es Chaos bei mehreren Benutzern.

Die Forderung gab es schon, ist einfach noch nicht umgesetzt.

Ich mag keine Frames, schon gar nicht, wenn sie 100% des umgebenden Fensters einnehmen und erzwungen werden. Die URL-Zeile des Browsers ist dafür da, dass man dort mit den URLs arbeiten kann (bearbeiten, kopieren, Lesezeichen), nicht dafür, dass eine statische URL alles versteckt, was im Hintergrund passiert.

Hier sollten wir deutlich zwischen Entwickler und geplanten Anwendern unterscheiden. Für Entwickler kann ich mich dem Standpunkt von Andreas anschließen, nicht jedoch für geplante Endanwender.
Hier wirkt ein url mit Querystring verwirrend und ich empfinde es schlicht als unprofessionell.

Ich mag kein tabellenbasiertes Layout.

Nun, mit div kann man inzwischen schon einiges machen, aber ein Layout zu erstellen, welches bei unterschiedlichen Browsern gleich angezeigt wird und welches auch Font- / -größenänderungen nicht aus dem Tritt bringt, ist imho noch nicht möglich.

Mein erster Layouttest besteht immer darin, in firefox Strg-+ und Strg-- bis zum unterstützten Maximum auszuprobieren und schauen, wie sich das Layout verhält.

Das silbergraue (Tabellen-)layout ist stabil, d.h. auch für Menschen mit Sehbehinderung bedienbar.

Das Layout mit der FB im Hintergrund besteht aus absoluten Divs und ist eher was für klicky-bunti-Anhänger

Gruß Gero

 

[buehmann]

mehr ist und war da nicht.

Schön, dass das geklärt ist.

Yo, mir hat man beigebracht, dass ein Cookie leichter ausgelesen werden kann

Ja, das war ein Problem, aus JavaScript kommt man leicht an die Cookies heran. Als Gegenmaßnahme wurde das HttpOnly-Flag bei Cookies eingeführt, wie ich gelesen habe.

Ich wurde aufgefordert, die Session zu salzen.

Aha, ich glaube, da hast du den Hinweis (von Hermann und mir?) etwas "überinterpretiert". Wenn ich mich recht erinnere, war der Auslöser für den Hinweis, dass in deinen ersten Versionen die Session-ID immer wieder die gleiche war, egal, wieviele Sessions der gleiche Benutzer (nacheinander, ein paar Tage später) etabliert hat. An die Forderung nach einer so stark gesalzene Suppe ;-), dass man jeden Request vorausplanen muss, kann zumindest ich mich nicht erinnern.

Mein Ansatz, den Schlüssel auf 5 Zeichen zu begrenzen hat ausschließlich Platzgründe.

Dann könnte man einen Vorverarbeitungsschritt einführen, der lesbare Texte nimmt, sie in die DB steckt und einen Schlüssel vergibt; so ähnlich wie unser $(lang). (Ich muss auch ganz ehrlich sagen, dass mir die Sprachauswahl beim Erstellen der Firmware wie bisher völlig ausreicht; ich brauche keine Laufzeit-Umschaltung. (Gab's noch einen anderen Grund für die htmltext-DB?) Was sagen die anderen dazu?)

[non-HTML] Meinst Du jetzt zum Sichern der Einstellungen oder wozu?

Ja, im aktuellen Webif haben wir mehrere Stellen, wo Konfigurationsdateien oder Logs als Text heruntergeladen werden können oder das ganze Backup als Tar-Archiv (da darin alle Passwörter stecken, muss das natürlich in den Passwort-geschützen Bereich). Aber so eine Erweiterung des Frameworks ist ja kein Problem.

Das conf-Verzeichnis liegt in der Webroot, weil ich diese per NFS einbinde.

Gut, dachte mir fast, dass Bequemlichkeit die Ursache war. Nur sollten wir nicht vergessen, das irgendwann zu ändern.

[CSS inline] Warum nicht?

Aufgeblähte Seiten, kein Caching im Browser. CSS-Stylesheets enthalten wie die meisten anderen statischen Dateien wie Bilder meist keine schützenswerten Dinge, so dass man sie ohne weiteres in einem offenen Bereich ablegen kann (und selbst wenn: Sobald das Framework auch Nicht-HTML ausliefern kann ... ;-))

Hier wirkt ein url mit Querystring verwirrend und ich empfinde es schlicht als unprofessionell.

Richtig entworfen kann man die Querystrings auf ein Mindestmaß reduzieren (d.h. oft leer, und da wo sie auftauchen, erfüllen sie ihren ureigenen Zweck, nämlich Parameter für die Darstellung der Seite zu liefern). Trac ist da ein recht schönes Beispiel.

Viele Grüße,

Andreas

 

[Gero013]

Als Gegenmaßnahme wurde das HttpOnly-Flag bei Cookies eingeführt

Nun, soweit mir bekannt ist das eine Erweiterung von Mickeysoft und es gibt zahlreiche Warnungen (teilweise mit Exploits), sich nicht darauf zu verlassen.

Gab's noch einen anderen Grund für die htmltext-DB?) Was sagen die anderen dazu?

Eher allgemeine Ablehnung - es gibt auch eine Umfrage dazu.
Ich bin überzeugt, wenn man nur eine Datei übersetzen muss, dass dann entsprechende Leute ganz alleine für Übersetzungen sorgen
... und man könnte die Datei auch in den external-Bereich legen, sodass ein Austausch ohne Flashen möglich wäre.

Gut, dachte mir fast, dass Bequemlichkeit die Ursache war. Nur sollten wir nicht vergessen, das irgendwann zu ändern.

Aus dem Grunde wird keine Datei aus dem Verzeichnis direkt angesprochen, sondern nur über ihre Links in /etc oder /var

Gruß Gero

 

[dileks]

README_webif-prototype.txt

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.

Ich hatte mit Silent-Tears noch Diskussion per PM:
@Silent-Tears:
Generell zu deinem Support-Verhalten:
Ein herzliches "You are welcome!" kommt besser an und animiert die Menschen eher etwas für freetz zu tun.

Es gab auch ein paar konstruktive Ideen meinerseits aus diesem Diskussionsaustausch:

Was haltet Ihr von einem "README_webif-prototype.txt" im SVN-root im VCS (Versions-Kontroll-System) [1]?
1. Hinweis: Was ist das Ziel vom WebIF(-Prototype)?
2. Wer sind die Ansprechpartner?
3. Hinweis zum Status: z.B. Code befindet sich im Alpha-Stadium, nicht funktional
4. Hinweis auf den Thread im IPPF [2], wo die Diskussion stattfindet
5. Laut Silent-Tears sei "WebIF-Prototype" auch in der freetz-Roadmap erwähnt, evtl. Link zu dieser Seite.
6. Hinweis auf der ersten Seite von [2] zum "README_webif-prototype.txt".

K.A. ob Gero013 schon SVN-Zugriff auf das VCS hat, wäre natürlich in erster Linie seine Sache, das einzupflegen. Evtl. sind hier Developer mit SVN-Access bereit auszuhelfen, damit weitere Kommunikationsmissverständnisse ausbleiben.

[1] http://trac.freetz.org/browser/branches/webif-prototype
[2] http://www.ip-phone-forum.de/showthread.php?t=215953