WebIF - Entwicklung/Weiterentwicklung

Status
Für weitere Antworten geschlossen.
Er hat Zugriff auf einen eigens dafür erzeugten Branch. Dies wurde auch hier in dem Thread besprochen, den du nicht bereit warst, zu lesen.
Was deine Kritik an meinem Verhalten angeht: -> PN-Wechsel erklärte deine Zuständigkeit für mein Verhalten. Keinen.

Zu 5: Timeline != Roadmap. Ebenso ist ein Branch vorhanden. Auch wieder: -> lesen. Ist im Thread zu finden.
 
Off-Topic Post entfernt.

Weitere Kindergartenspielchen werden von mir kommentarlos gelöscht...

MfG Oliver

edit: Weitere 5 Post gelöscht. Leute erspart mir bitte diese lästige Arbeit und diskutiert zum Thema. Dileks sollte jetzt erkannt haben, dass das Webinterface noch nicht nutzbar ist.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Hallo Gero,

cool, hast ja was eingechecked :) Ich möchte dich allerdings bitten, etwas sprechendere Namen zu nutzen bei den Styles/themes/etc. Anscheinend bevorzugst du cryptische Namen. Ich find, ein wenig mehr schadet oft nicht :)
 
Anscheinend bevorzugst du cryptische Namen.
Davon kann keine Rede sein.
Allerdings schaue ich schon, in welcher Umgebung ich mich befinde und bei embedded systemen habe ich mir angewöhnt, möglichst platzsparend zu codieren, d.h. Variablennamen und Kommentare leiden möglicherweise darunter ;)

Wenn ich anders verfahren soll, kein Problem - verbose coding ist default bei mir.

Und es wäre toll, wenn du in Zukunft "svn move" oder "svn copy" verwendest
Ich gelobe Besserung. Ich muss gestehen, dass ich (zu) viel mit Krusader arbeite. Da ist schnell was verschoben, ohne dass ich mir Gedanken drüber gemacht habe, welche Konsequenzen das hat.
War keine böse Absicht, schlicht die Macht der Gewohnheit :(
(ich ärgere mich in meinen Projekten auch, wenn es mir passiert, also einfach wieder draufhinweisen bitte, wenn ich es mal wieder vergessen sollte)

Gruß Gero
 
Allgemein an die Devs: Passt denn dann der Branch (der basiert auf dem trunk) überhaupt zu den zugrunde liegenden Sachen noch? Da gab es wirklich grundlegende Änderungen an diversen Ecken. Ich kann mir vorstellen, dass es da zu Problemen kommen kann.

edit:
So wirr? ;) Das kommt davon, wenn man zu früh morgens nach einer durchgearbeiteten Nacht aus dem Bett geworfen wird....

Ok, noch einmal. Ich befürchte Probleme, wenn man das Webinterface anhand des trunks entwickelt, dieses aber mit der stabilen Version nutzt, weil sich doch extrem viel verändert hat im Laufe des Jahres...
 
Zuletzt bearbeitet von einem Moderator:
Dann ist das Web-Interface eben nicht mit der stabilen Version benutzbar. Besser als umgekehrt, daß es für die alte Version entwickelt wird und nachher nicht mehr zur neuen Version paßt.

Da wir hier aber in einem anderen Thread sind, könnte Oliver das mal dorthin schieben, wo es besser zum Thema paßt. :)
 
Nun, gero nutzt das so. Ich käme nicht auf den Gedanken, das zu mischen ;) Aber stimmt, der andere Thread wäre sinniger...
 
Ich finde nichts ungewöhnlich daran, eine stabile Version für den täglichen Gebrauch zu nutzen und eine andere für die laufende Entwicklung.
 
Ist es auch nicht. Nur dies zu mischen ist halt problematisch, wie oben geschrieben., denn er nutzt ja die stabile als Basis, und mountet per nfs den branch über, ohne die Basis zu verändern. Und darauf basiert meine Frage.
 
Hab die Beiträge wie gewünscht hier her verschoben.

MfG Oliver
 
Hi,

ich habe in den letzten Tagen einen kleinen Gegen-Prototypen für den Session-Unterbau eines neuen WebIF gebaut, unabhängig von Geros, aber in einigen Punkten inspiriert davon (positiv wie negativ).

Die wesentlichen Eigenschaften orientieren sich dementsprechend an meiner oben geäußerten Kritik:
  • basierend auf Cookies
  • Login integrierbar in die Seite, Logout möglich
  • mehrere Benutzer (z.B. Admin und normaler Benutzer, der bestimmte Sachen nicht darf)
  • mehrere gleichzeitige Sessions
  • keine Java-Script-Links, keine Frames
  • keine Probleme beim Reload oder mit Bookmarks
(Es gibt noch keine Sicherung gegen Cross-Site Request Forgery (wie oben von Hermann bzgl. des Salzens angedeutet); das ließe sich aber selektiv hinzufügen. Ebenso gibt es weniger zu sehen als bei Gero; es geht ja nur um den technischen Unterbau. Darauf könnte man jede Art der Webseitengenerierung setzen, z.B. für eine Übergangszeit unser altes System oder eine Variante von Geros.)

Wer einen Blick riskieren will: Ich habe das ganze momentan noch nicht im Freetz-SVN untergebracht; aber die Installation beschränkt sich auf Entpacken und Starten:
Code:
tar xzf webif-r53.tar.gz; ./webif-r53/run-server

Ich freue mich auf Feedback; vielleicht bekommen wir so die Diskussion um "Was brauchen/wollen wir eigentlich?" wieder in Gang.

Viele Grüße,

Andreas
 

Anhänge

  • webif-r53.tar.gz
    6.8 KB · Aufrufe: 6
Hi,

habe gerade mal den Prototypen angeschaut - muss sagen ich bin überrascht, begeistert und enttäuscht.
Begeistert von Deiner virtuosen Shellprogrammierung - bei der ich Mühe habe, überhaupt was zu verstehen und enttäuscht, weil nicht ein Punkt meines Prototypen in Deinem auftaucht. Du hast nicht nur einen anderen Fokus, sondern auch alles weg gelassen, was mir wichtig war aufzuzeigen.

Mir ging es um Integration von AVM und Freetz und um Sicherheit. Dein Prototyp zeigt, dass ein upload mit haserl funktioniert und dass Du ein login hinbekommen hast.

Was ich vermisse:
  • ohne wirklich eine Seite anzuzeigen, kann weder die Anmeldung überprüft werden, noch die Sicherheit, dass die Seite nicht ohne Anmeldung erreichbar ist.
  • Du hast mehrere Formulare in der Seite, aber nicht gezeigt, wie die Daten trotzdem überprüft werden können
  • Mir war es wichtig, einen Weg zu finden, der den Paketentwicklern die Sorge um Berechtigung/Login abnimmt, sprich, der gewährleistet, dass jede Seite/jedes Formular den Front-Controller verwendet (ohne dass sich der Paket-Entwickler drum kümmern braucht), dass es keinen Weg daran vorbei gibt. Das sehe ich in Deinem Prototypen nicht gewährleistet, dass muss auf "freiwilliger" Basis geschehen
  • Als Konsequenz muss die Seite wieder selbst entscheiden, wie der Seitenaufbau auszusehen hat. Damit hat sich nix gegenüber dem jetzigen WebIF verbessert. Ein allgemeingültiges Layout-Handling ist damit nicht möglich.
  • der Upload funktioniert (?) ohne Login - das hat nichts mehr mit dem zu tun, was ich mir vorgestellt habe.

Sorry, aber ich sehe in dem Prototypen keine Alternative zu meinem oder eine Verbesserung des bestehenden Freetz-WebIFs.

Gruß Gero
 
Hi Gero,

danke, du dass du einen Blick auf mein Machwerk geworfen hast. Ich glaube, es gibt da eine ganze Reihe von Missverständnissen:
enttäuscht, weil nicht ein Punkt meines Prototypen in Deinem auftaucht.
Wie ich oben vielleicht nicht deutlich genug sagte, lag mein Fokus nur auf dem Sessionmanagement + Authentifizierung (+ Zugriffskontrolle). Da ich dort vieles anders mache, habe ich mich entschieden, diesen Punkt herauszugreifen. Den Teil deines Frameworks, der sich mit der Auswahl der Seiten befasst, dem Templating, dem Zusammenbau aus Komponenten, die teilweise durch webcm geschickt werden, der Internationalisierung -- diesen Teil fasse ich überhaupt nicht an und stelle ihn durch das "Weglassen" auch nicht in Abrede. Der kann einfach hinter mein Sessionmanagement geschaltet werden. Vielleicht mache ich das mal als nächsten Schritt, damit das ganze etwas anschaulicher wird.
Mir ging es um Integration von AVM und Freetz und um Sicherheit.
Um Sicherheit geht es mir auch; Integration von AVM gehört zu dem Teil, mit dem ich mich überhaupt nicht befasst habe.
ohne wirklich eine Seite anzuzeigen, kann weder die Anmeldung überprüft werden, noch die Sicherheit, dass die Seite nicht ohne Anmeldung erreichbar ist.
Ich zeige unterschiedliche Seiten an (die alle fast gleich aussehen und aus der selben Quelle generiert werden, aber das ist ja nur zum Testen). Die Seiten /cgi-bin/freetz/private/... sind ohne Anmeldung nicht (in ihrer nicht-Verbots-orangenen Form) erreichbar.
Du hast mehrere Formulare in der Seite, aber nicht gezeigt, wie die Daten trotzdem überprüft werden können
Was meinst du genau mit "Überprüfen" der Daten? Natürlich wird überprüft, ob eine Session existiert, ob der Benutzer sich in dieser Session schon eingeloggt hat, ob er die Berechtigung hat, diese Seite aufzurufen.
[Front-Controller] dass es keinen Weg daran vorbei gibt. Das sehe ich in Deinem Prototypen nicht gewährleistet
Falsch, /cgi-bin/freetz agiert wie bei dir als Frontcontroller für alle Seiten, die unter ./page/ liegen (entspricht deinem ./html/). Auf anderem Wege sind diese Seiten nicht zugreifbar.
Ein allgemeingültiges Layout-Handling ist damit nicht möglich.
Stimmt nicht; ersetze die letzten paar Zeilen in ./controller (grob gesagt) durch deine prepare-template-serverPage-Lösung, und schon du hast dein Layout-Handling. Wie gesagt, es ist nicht eingebaut, weil das ein komplett unabhängiger Aspekt ist.
der Upload funktioniert (?) ohne Login
Der Upload auf den geschützten Seiten funktioniert nicht ohne Login. Lass dich nicht davon verwirren, dass auf jeder Seite die Formulare auftauchen; so lassen sich alle Fälle am besten durchspielen. Später werden natürlich abhängig vom Pfad unterschiedliche Seiten angesprochen, die unterschiedliche Zugriffsrechte benötigen, so dass es natürlich auch Seiten geben kann, zu denen ein Upload nur im eingeloggten Zustand möglich ist.

Fazit für mich: Ich führe mal die prototypische Anbindung an den Rest deines Frameworks durch. Wenn du deine eigenen Seiten siehst, wird das ganze vielleicht anschaulicher.

Viele Grüße,

Andreas
 
Wenn du deine eigenen Seiten siehst, wird das ganze vielleicht anschaulicher.
Nö, das muss nicht sein, soviel Abstraktionsvermögen ist schon da.

Nur jetzt gibt es ja garkeine Seiten. Es antwortet immer der Controller.
Interessant wird die Sicherheit doch erst, wenn es echte Inhalte gibt, die nicht vom Controller erzeugt werden.

... und was ich meinte mit "falschem Layout":
Jetzt steht in der aufgerufenen Seite ein "include controller", es müsste meiner Ansicht nach aber genau anders herum sein, nämlich dass der Controller die Seite zusammen baut, bzw. ein "include page" macht.

Gruß Gero
 
Jetzt steht in der aufgerufenen Seite ein "include controller"
Das (./htdocs/cgi-bin/{freetz,upload} (nur aus technischen Gründen zwei Dateien)) ist der Controller. Weitere Dateien in /cgi-bin/ braucht es nicht zu geben. Dass die Implementierung in ./controller (und ./lib/*) erfolgt, hat ja mit der logischen Funktion nichts zu tun.
nämlich dass der Controller die Seite zusammen baut, bzw. ein "include page" macht.
Das Äquivalent zu deinem "include page" steht in der letzten Zeile von ./controller.

Viele Grüße,

Andreas
 
hallo zusammen,

wie sieht denn der Stand der Dinge hier aus? Was ich vermisse ist im ersten Post ein Archiv des WebIF und im brunch vermisse ich den Port, oder bin ich nur blind?
 
Gero hat die Entwicklung eingestellt. Er war mit der Art der Kritik von einigen hier nicht einverstanden.

Gruß
Oliver
 
Status
Für weitere Antworten geschlossen.

Statistik des Forums

Themen
244,883
Beiträge
2,220,096
Mitglieder
371,612
Neuestes Mitglied
Cheffo
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.