WebIF - Entwicklung/Weiterentwicklung

[Gero013]

Moin moin,

ich hatte mit dem Prototyp im Sinn, ein Ziel mit möglichst einfachen (Bordmitteln) zu erreichen, ohne viel Platz zu verschwenden. Probiert das mit der Session-ID doch einfach mal aus, ohne drüber zu theoretisieren, was denkbar/möglich wäre.
Einfach 2 Rechner an der Box anmelden, die Session-ID von einem Rechner auf den anderen kopieren und versuchen ne Seite zu bekommen ...

Ich weiß nicht, aber für mich ist der Einsatz von FB immer noch im privaten Umfeld. Wenn es natürlich für den Soho-Einsatz erweitert werden soll, macht das mit der Mehrbenutzer-Dingens vielleicht Sinn - obwohl es in Firmen meist einen Admin oder Admin-beauftragten gibt, sodass es wieder nur eine Person ist, die auf die Box zugreift.

Es ist kein Problem, die Session-VW so umzubauen, dass mehrere Benutzer sich anmelden können - aber ich würde dafür plädieren, dass jeder Benutzer sich nur einmal anmelden darf. Vielleicht würde es Sinn machen, es konfigurierbar zu gestalten, ob Single-Session oder Multisession erlaubt ist.

Was die Links angeht:
Wenn die Links offen sind (ohne JS), sodass sie "gebookmarkt" werden können, bedeutet das im Gegenzug, dass jede Seite mit Includes die Sitzungsverwaltung einbinden muss. Das bläht die Seiten auf, verschwendet also Platz und es erfordert, dass jede mögliche Seite kontrolliert werden muss. Jetzt ist es so, dass die Seiten "unbekannt" sind und schon aus dem Grund nicht aufgerufen werden (und wenn doch, gibt es eben eine Seite ohne Daten).
Mit den JS-Links könnte man anders arbeiten, indem man z.B. ein Template hat, was das optische Design vorgibt, sowie eine Inhaltszusammenstellung (Auflistung aller Module, die auf der Seite angezeigt werden). Ein zentraler Handler erstellt daraus die aktuelle Seite. So bräuchten die Inhaltsbausteine nix vom Layout oder von der Session-VW zu wissen.
Ich weiß nicht, ist die Ersparnis von einem Mausklick (Bookmarken) soviel Platz- und Mehraufwand wert?

Technisch gesehen ist die Variante der JS-Links etwas aufwändiger, dürfte aber platzsparender sein, wogegen die Variante ohne JS-Links mehr Adminstrationsaufwand bedeutet. Die Umstellung von "Blackbox" zu "Whitebox" dürfte technisch überhaupt kein Problem darstellen - also wenn Ihr es lieber so wollt ...

Gruß Geronimo

 

[buehmann]

Hallo Gero (und alle anderen),

ich hoffe, du bist nicht genervt, dass wir deinen Prototypen so auseinandernehmen bzw. als Anlass nehmen, alte Fragen ans Licht zu bringen. Dir gebührt auf jeden Fall die Anerkennung, den Stein der WebIF-Weiterentwicklung mal wieder ins Rollen gebracht zu haben.

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

Wie Hermann schon schrieb: Hat man das nicht, blockiert man sich entweder gegenseitig (oder sich selbst im Fehlerfall) oder man klaut sich gegenseitig die Session. Was ich sagen wollte: Wenn Multi-User, dann auch gleichzeitig. Ob überhaupt und warum wir verschiedene Benutzer brauchen, habe ich vergessen (ich brauche sie nicht); das sollte unbedingt in die Diskussion zu den Anforderungen.

Was die Javascript-Links angeht - sind die nur die Konsequenz aus dem vorgeschaltenem Frame.

Ich sehe da keinen Zusammenhang; übrigens habe ich den Prototypen ohne das Vorschalt-Frameset getestet, um besser sehen zu können, wie es funktioniert.

Wer die nicht haben will, sollte auch den Frame nicht wollen

Ich will den Frame und das Verstecken nicht! Noch ein Punkt für die Diskussion, zu dem von mir auch schon ein Freetz-Ticket existiert.

Nun, die ganzen Parameter werden von "meinem" Script doch bereits ins Environment geschrieben, bevor die CGI-Datei aufgerufen wird.

Richtig, habe ich übersehen. Dass die Parameterbehandlung auch zentral gemacht wird, finde ich prinzipiell gut. Für Uploads müsste man sich noch eine Spezialbehandlung überlegen.

Bei informativen Webanwendungen gebe ich Dir recht, aber Links, die nach einem Login liegen, sollten nicht "gebookmarkt" werden können.

Wer sagt denn, dass alles hinter dem Login liegen muss: Ich kann mir gut vorstellen, dass einige (informative *g*) Statusseiten auch ohne Login erreichbar sind. Und auch bei anderen Seiten finde ich es hilfreich, wenn man seine auf häufigsten benutzte Seite direkt über eine URL erreichen kann. Wenn dort Authentifizierung gefordert ist, sollte die halt durchgeführt werden, bevor man die Seite zu sehen bekommt.

Wunderbar, jetzt seid Ihr auch an dem Punkt angekommen, wo ich eine nicht öffentliche Diskussion mit den Machern wollte

Nein, öffentlich! Ich dachte an ein gemeinsam erstelltes Dokument (z.B. ein Wiki-Seite in unserem Trac) mit Anforderungen, Begründungen und später Entwurfsentscheidungen und einen Thread mit der Diskussion zu einzelnen Punkten während dessen Erstellung.

Wenn die Links offen sind (ohne JS), sodass sie "gebookmarkt" werden können, bedeutet das im Gegenzug, dass jede Seite mit Includes die Sitzungsverwaltung einbinden muss. Das bläht die Seiten auf, verschwendet also Platz und es erfordert, dass jede mögliche Seite kontrolliert werden muss.

Falsch, wir können das Front-Controller-Pattern, das du eingesetzt hast (alle Requests laufen durch eine zentrale Instanz, die sich um Session-Management, Zugriffskontrolle etc. kümmert), auch in diesem Fall verwenden. (Am besten über Auswertung von PATH_INFO.)

Viele Grüße,

Andreas

 

[Gero013]

Hallo zusammen,

ich hoffe, du bist nicht genervt, ...

Nein, ganz im Gegenteil. Ich habe die Diskussion doch gesucht - und wenn es jetzt einen Fred zum WebIF gibt, bei dem man keine Angst um OT haben muss, dann finde ich das fruchtbar. Ich wollte das ursprünglich zwar nicht öffentlich, damit man keine OT-Zwischenrufe bekommt und auch mal über halbgares laut nachdenken kann, aber wenn das hier auch ok ist, dann bin ich auch zumfrieden damit.

Ob überhaupt und warum wir verschiedene Benutzer brauchen, ... (ich brauche sie nicht)

So geht mir es auch.
Selbst in meinem Bekanntenkreis, bei Familien mit erwachsenen Kindern im Haushalt steht die Box nicht jedem zur Bearbeitung zur Verfügung. Wenn jemand ne Änderung braucht, geschieht das auf Zuruf.

Hat man das nicht, blockiert man sich entweder gegenseitig (oder sich selbst im Fehlerfall) oder man klaut sich gegenseitig die Session.

Also bei meinem Ansatz gibt es kein Blockieren, Klauen - im eigentlichen Sinne auch nicht, denn wenn es 2 Benutzer sind, dann hat jeder "seine" Session (nur wird die des anderen eben beendet ohne dass der das wollte und unmittelbar merkt).
Wenn ich mal aus Versehen im URL-Fenster Enter gedrückt habe, statt F5 zu verwenden, musste ich mich neu anmelden. Ich empfand das nicht als störend.

Ich will den Frame und das Verstecken nicht!

Ok, kann ich mich auch mit anfreunden. Dann braucht es aber überhaupt keine Frames.

Wer sagt denn, dass alles hinter dem Login liegen muss: Ich kann mir gut vorstellen, dass einige (informative *g*) Statusseiten auch ohne Login erreichbar sind.

Damit könnte ich mich auch sehr gut anfreunden.
Man könnte die Startseite so gestalten, dass alle wichtigen Informationen dort zu finden sind - und die ist frei, d.h. ohne Login. Erst wenn Links betätigt werden, die die Konfiguration ändern oder z.B. die (Telefon-)logs anzeigen, wird ein Login zwischen geschaltet. Dies könnte sehr gut mit der Gruppen-Id und dem Freetz-Sicherheitslevel bewerkstelligt werden.

Bleibt noch die Frage, wie man das WebIF absichert, bei denen, die die Box über's Internet konfigurieren wollen (ich bin da zwar auch kein Freund von, aber es soll ja auch solche geben).

Falsch, wir können das Front-Controller-Pattern, das du eingesetzt hast (alle Requests laufen durch eine zentrale Instanz, die sich um Session-Management, Zugriffskontrolle etc. kümmert), auch in diesem Fall verwenden. (Am besten über Auswertung von PATH_INFO.)

Ok, ich werde mal in die Richtung experimentieren.

Gruß Geronimo

 

[RalfFriedl]

Also bei meinem Ansatz gibt es kein Blockieren, Klauen - im eigentlichen Sinne auch nicht, denn wenn es 2 Benutzer sind, dann hat jeder "seine" Session (nur wird die des anderen eben beendet ohne dass der das wollte und unmittelbar merkt).

Mit Klauen war gemeint, daß man dem anderen die Session beendet, nicht, daß man dessen Session übernimmt.

 

[buehmann]

@Und wenn man von diesem AUTH-POPUP weg ist, kann man endlich ohne große Ängste WebIF per https nach draußen geben.

Hermann, könntest du das erläutern? Ich verstehe nicht, was gegen BasicAuth beim Freigeben des WebIF nach außen (über HTTPS) spricht bzw. welche Vorteile ein anderer Login-Mechanismus hätte.

Danke und viele Grüße,

Andreas

 

[Silent-Tears]

Im grossen und Ganzen: Wahrscheinlich die Optik.

 

[Gero013]

Hallo zusammen,

kleiner Status:
habe nfs am Laufen und die Seiten auf der Box ausprobiert. Funktioniert bei mich alles wie unter Linux und apache.

Dann habe ich meinem eingesperrten Windows (aus ner Virtualbox) Zugriff auf die Box erlaubt und mit Mozilla und IE-6 den Zugriff auf meinen Prototyp ausprobiert. Auch dies funktioniert wie unter Linux (abgesehen davon, dass die png-Bilder im IE Sch...ße aussehen) - will sagen, ich habe an keiner Ecke einen Windows-Zeilenumbruch bekommen, bzw. die Seiten funzen auch ohne den tr-Fix.

Was ich nicht probiert habe, ist tinyWeb auf USB, bzw. vfat auszuprobieren.
Könnte es sein, dass der Windowszeilenumbruch von vfat kommt?
Also jetzt bin ich wirklich neugierig geworden, wo der denn eingestreut wird.

Gruß Geronimo

P.S. Mich stört an basic auth auch "nur" die Optik

 

[Gero013]

Hallo zusammen,

habe eine neue Version des Prototypen hochgeladen.

Gruß Gero

 

[Gero013]

Hallo,

hatte heute etwas Zeit überig und so gibt es gleich das nächste Update.
Inzwischen funktionieren beide Layouts, wobei das Layout von "rednose" das Standardaussehen ist.
Nach der Anmeldung als Admin wechselt nicht nur das Layout, sondern auch Hauptmenü und Seiteninhalt.

Bin mit der Funktionalität soweit zufrieden, sodass ich mich als nächstes an die Umsetzung der Berechtigungsgruppen machen würde.

Wäre schön, wenn von Euch Input käme, welche Seiten denn für welche Gruppe (Berechtigung oder Menülevel, wie auch immer) erreichbar sein sollen.

Gruß Gero

 

[buehmann]

Hi Gero,

ich versuche gerade, deinen Prototyp Nr. 3 auszuprobieren, aber ich komme nicht weiter. Folgendes habe ich gemacht:

• Archiv auf Box entpackt, root/usr/mww über /usr/mww gemountet
• Die 3 genannten Symlinks angelegt
• Haserl mit Patch kompiliert und installiert
• rc.webcfg neugestartet
• cgi-bin/clientools.haserl auf cgi-bin/clientools gelinkt (falscher Name?)

Jetzt bekomme ich bei Aufruf des Web-IF den Login-Screen, aber ohne jeglichen Text (von der Versionnr. oben rechts abgesehen), dazu keinerlei Fehlermeldung.

Was mache ich falsch?

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.

Ich würde vorschlagen, dass wir den aktuellen Stand deines Prototyps ins Freetz-SVN-Repository importieren, damit das Ausprobieren, das Verfolgen von Änderungen, und die gemeinsame Weiterentwicklung einfacher werden.

Andreas

 

[Gero013]

Hi Andreas,

freut mich, dass Du es probieren willst.
Ich dachte schon, das Thema hätte sich erledigt

Was mir spontan auffällt:
In der Liste Deiner Aktivitäten fehlt mir das Erstellen der Texte-Datenbank.
Hast Du createDB ausgeführt?

Gruß Gero

P.S. Wenn Du das Thema weiter verfolgen magst, dann kann ich ja nomml ein Update hochladen.

 

[buehmann]

Nein, muss ich? Ich dachte, htmltext.fa ist schon vorkompiliert dabei. (?)

 

[Gero013]

Nö, nur die Quellen sind dabei, htmltext.fa ist nur ein Link (wenn ich mir nicht irre).

 

[buehmann]

Ok, hab's gefunden: htmltext.fa war schon vorhanden, aber ich musste "getText" noch installieren ... Ich schaue mal weiter und melde mich dann wieder.

 

[Gero013]

Yo - sorry.

Habe mich die Woche mehr mit der FW an sich, mit switch und firewall etc. beschäftigt, sodass das WebIF liegen blieb und natürlich nimmer so present war.
Hast natürlich recht - im neuen Prototyp-Format ist alles onboard - inclusive einer fertigen Textdb.

Habe Dir mal (ungeprüft) meinen Arbeitsstand hochgeladen. Falls Du es aktuell anschauen magst ...

Über Feedback würde ich mir riesig freuen tun!

Gruß Gero

 

[buehmann]

Hat sich dort viel geändert (am Framework)? Sonst spare ich mir die Installation und schau in 0.03 weiter.

Könntest du bitte kurz die Bedeutung folgender Variablennamen erläutern?

FAABRIRA
FAABRIN
FAABRIG
FAABRIUA
JAMESCOOK
FA_SID
mySID
SKOTTOWE

Der Buchstabensalat ;-) bereitet mir sonst Kopfschmerzen beim Lesen ...

 

[Gero013]

Hat sich dort viel geändert (am Framework)?

Naja, manches habe ich aufgeräumt, anderes umbenannt, bzw. weiter entwickelt ...

Sonst spare ich mir die Installation und schau in 0.03 weiter.

Na, Du müsstest ja nix mehr installieren (Firmware hat sich nicht geändert).
Nur eben das neue /usr/mww mounten

Der Buchstabensalat ;-) bereitet mir sonst Kopfschmerzen beim Lesen ...

Oups, das will ich natürlich nicht
Schau einfach mal die client-Tuhls an ...

Gruß Gero

 

[buehmann]

Da habe ich die ganzen Namen her. Mit JAMESCOOK oder SKOTTOWE oder FAABRI kann ich beim besten Willen nichts anfangen ...

 

[Gero013]

*Lach* - ok

Also die Verwendung ist Dir klar, nur nicht die Bedeutung?!?
Es fing an mit 'FA' für Freetz advanced und der Rest ergab sich im Laufe der Zeit aus Wortspielen und ähnlichem. Da die intuitiven Namen bereits verwendet sind (sei es von Haserl, avm oder freetz), habe ich mir teilweise Namen ausgedacht, die überhaupt nichts mit der Materie zu tun haben.

Also wenn Dich die Benamsung stört - Namen sind Schall und Rauch

Gruß Gero

 

[buehmann]

Also die Verwendung ist Dir klar, nur nicht die Bedeutung?!?

Ich habe wenig Lust, die Verwendung zu analysieren, um auf die Bedeutung zu schließen. Gute, lesbare Variablennamen gehören zu guten Code; und wenn der Variablenname nicht selbsterklärend ist, gehört ein Kommentar dazu. Sorry für die harten Worte ... (und ja, ich verstoße auch dann und wann gegen diese Prinzipien).

Noch mal: Was hältst du von der Idee, die Codebasis ins SVN-Repository zu legen (vorerst in einen recht isolierten Bereich)? Dann könnten ich und andere solche fehlenden Kommentare (oder andere kleine Verbesserungen) gleich einpflegen. (Als nächsten Schritt könnten wir den Prototyp zum einfachen Experimentieren als Freetz-Paket einbinden und es parallel zum aktuellen Web-IF betreiben.)

Viele Grüße,

Andreas