WebsiteBaker 2.8.2 RC - Tests und Vorschläge

[Stefek]

1.) Eine Funktion die einem vor Verlassen einer Seite daran erinnert, dass man die Änderungen speichern sollte, ist längst überfällig und sollte auch zeitnah umgesetzt werden.

2.) Eine Funktion, die einem bei jedem Verlassen einer Seite oder einer Section mit ner Meldung nervt, das man doch bitte die Änderungen speichern sollte, obwohl man nix geändert hat, und die noch dazu nicht richtig dargestellt wird, braucht kein Mensch.

Ich stimme mit Matthias überein.

Aber es gibt noch mehr dazu.
Vor allem, wenn es sich um die WYSIWYG Abschnitte handelt, gibt es gewiß eine bessere Lösung.

Das gegenwärtige (2.8.1 und kleiner) Szenario ist, dass wenn ich eine Seite mit mehreren WYSIWYG Abschnitten habe und in den Editiermodus der Seite mit den Abschnitten gehe, alle Abschnitte OFFEN stehen. Soll heißen -> alle Wysiwyg Abschnitte zeigen ihren Editor, den Save und den Cancel Button.
Das ist eine Quelle für mehr Ärger als dass man mal nicht Speichert und woanders hingeht.
Weil - die User geben hier und da mal was ein, drücken auf einen der [Speichern] Buttons und nur dieser wird gespeichert.

Eine einfache Abhilfe hat bereits vor etwa 2 Jahren ein User mit dem Namen lousou76
https://forum.WebsiteBaker.org/index.php/topic,12988.0.html

Die von ihm gestartete Umfrage sagt eigentlich alles.

Und das einzubauen ist nun wirklich kein Hexenwerk.

Und, wenn dann eine der WYSIWYG Sections "AUF" ist, kann keine weitere geöffnet werden, bis sie geschloßen wurde und dann macht die Notification, "Please save before... blabla" auch Sinn, sobald eine der Sections offen ist.

Gut, für andere Module weiß ich nicht.
Aber bei denen gibts ja meistens keine direkten Eingabefelder in der modify.php

Übrigens, die oben verlinkte Lösung hat zusätzlich den Vorteil, dass die ganzen Editoren nicht sofort geladen werden, was die Ladezeit sparsamer gestaltet.
Hat mir schon damals gefallen das Ding und ich fand es schade, dass es "irgendwie untergegangen" war.

Gruß,
Stefek

[ruebenwurzel]

Hallo,

-offtopic-

Also wenn ich das richtig im Ohr habe sollte die 2.8.2 ein reines Bugfix-Release ohne neue Funktionen / Features sein.
Die hier angesprochene Meldungsfunktion wäre aber doch ein neues Feature oder nicht?

Muss da Maverik Recht geben. Entweder hält man sich dran, dass 2.8.2 keine neuen features enthält oder nicht. Jahrelang wurde hier in der communitiy gemeckert, dass es keine klaren Richtlinen bezüglich der Weiterentwicklung von WB gibt. Jetzt gibt es welche (bitte jetzt hier keine Grundsatzdiskussion starten, threadthema bitte beachten), da sollte man sich dann auch dran halten.

.. Eine einfache Abhilfe hat bereits vor etwa 2 Jahren ein User mit dem Namen lousou76
https://forum.WebsiteBaker.org/index.php/topic,12988.0.html ...

Beides zusammen, dass man nur eine section bearbeiten kann + der Hinweis beim Verlassen das Speichern nicht zu vergessen, das wär richtig gut. Bin auch einer der geschädigten, die auf Seiten mit mehreren section schon gemachte Änderungen verloren haben, weil sie den verkehrten speichern Button gedrückt haben. Das Ganze ist wohl aber eher was für 2.9 und hat deswegen in diesem thread eigentlich nix mehr verloren.

-offtopic Ende-

Happy Baking

Matthias

[testör]

Muss da Maverik Recht geben. Entweder hält man sich dran, dass 2.8.2 keine neuen features enthält oder nicht. Jahrelang wurde hier in der communitiy gemeckert, dass es keine klaren Richtlinen bezüglich der Weiterentwicklung von WB gibt.

Ach komm Matthias, du weißt doch am Besten, dass immer gemeckert wird, egal was getan wird.
Dann streitet man sich eben drum, was ein Feature ist. Ich sage dann "SecureForm" ist ein Feature und ebenso "[tooltip] in SM2, und schon ist die 2.8.2 tot diskutiert und kommt am St.-Nimmerleinstag heraus.
Und würde man sich streng an einmal gesagte "Richtlinien" halten, dürfte es die 2.8.2er gar nicht geben - es sollte sie ja eine Zeitlang gar nicht geben, sondern nur Patches für die 2.8.1er. Aber jetzt hat man einmal die Chance, wieder die Community nach langer Zeit wieder mit einzubinden und das wird jetzt auch wieder angezweifelt. Manchmal fragt man sich schon, was Statler und Waldorf dazu sagen würden.

[Stefek]

Macht fertig die Kiste.

Was fehlt denn da noch?

Am schlimsten finde ich das "Feature", keine mehrere Fenster vom Backend mehr auf haben zu können.

Und ja, gemeckert wird fast immer.
Zu fast jedem Anlass.

Es ist sowie so ein Wunder, dass WB noch lebt

Möge dieses Wunder lange aufrecht erhalten werden.
 

Stefek

[NorHei]

Das CSRF Problem muss auf jeden Fall gelöst werden es kommen immer mehr Hacks raus die genau darauf aufsetzen und die werden zum Teil mit anderen Techniken gemixt so das sie immer unangenehmer werden.

Das ist halt alles nicht so ganz einfach, bei ein paar Gesprächen mit Viper haben wir festgestellt das im Endeffekt 3 Möglichkeiten existieren. 

1. Wir lassen das so wie es ist und erhalten gute Sicherheit aber verlieren eine ziemlich oft benutzte Technik um mit WB komfortabel zu arbeiten. Eventuell gibt es da auch noch Probleme mit Multipage Forms
und dem Back Button.

2. Wir erweitern die Sicherheitsklasse so, das sozusagen eine FTAN Verwaltung eingebaut bekommt die verschiedene TANs für verschiedene Seiten erlaubt und  diese Verwaltet. Dabei müssen aber noch fragen geklärt werden wie: Was passiert wenn ein Fenster lange offen bleibt , oder wenn es geschlossen wird ohne das das Formular versendet wurde.
Diese Variante würde gleiche Sicherheit, aber einen fast vollständig erhaltenen Komfort bedeuten, man würde nur noch Probleme mit dem Back Button haben, und wenn man die gleiche Seite in 2 Fenstern bearbeiten will(man muss sich dann für ein Fenster entscheiden in dem man Änderungen speichert).
Der Nachteil ist das das schon eine Relativ komplexe Lösung ist, die durchaus noch ein wenig Zeit beanspruchen würde.

3. Wir nehmen ein vereinfachtes TAN System bei dem die TANs eine gewisse Lebensdauer haben (12h).
Das hat den Vorteil, das der Komfort voll erhalten bleibt. Aber die Sicherheit wird fragwürdiger.
Um genauer zu sein ist Viper grade dabei das noch mit einigen anderen Sicherheitsexperten zu besprechen. Tatsache ist das andere CMS , z.B. Wordpress das genauso nutzen. Allerdings heißt das natürlich noch lange nicht das es auch sicher ist.
Rein Theoretisch müsste das bei  Angriffen über gefakte Webseiten ausreichen, aber die Angrifsvektoren werden immer bunter. Über Browserlücken, fehlerhafte HTML Anzeigen im Mailprogrammen aller Arten ist es eventuell möglich an die FTAN zu kommen und dann den Angriff zu starten. 
Hier besteht also noch Klärungsbedarf.

Ich denke Wenn die Sicherheitsexperten die Lösung für vertretbar halten währe Lösung 3 das Mittel der Wahl für die 2.8.2  und Lösung 2 währe geeignet für 2.9.0.

Das Problem ist halt das solche Probleme erst auftauchen wenn intensiv getestet wird und dann oft erst mal Forschung betrieben werden muss um andere Lösungsansätze zu finden oder um bestehen auf Ihre Sicherheit hin abzuklopfen. Dazu kommt noch das alleine das Thema CSRF  unglaublich komplex ist und man sich tagelang damit beschäftigen kann, von den weiteren Sicherheitsfragen mal völlig abgesehen. 
   

[maverik]

Wer die Reeperbahn in Hamburg besucht setzt sich dem Risiko aus das ihm etwas passieren kann . Trotz Ordnungsmacht und Sicherheitsvorkehru ngen. Das gleiche kann ihm aber auch auf einem großen Hauptbahnhof passieren.

Wer das Internet besucht und darin auch noch arbeitet geht das gleiche Risiko ein.

Wer mit dem Auto fährt lebt mit dem Kompromiss das ihn der Gurt und die Airbags schützen, er verzichtet auf feuerfesten Anzug und Helm.

Man sollte die Kirche im Dorf lassen und kann bzw. sollte dem Individuum Mensch nicht alles abnehmen, eine gewisse Eigenverantwortlich keit und das Benutzen der brain.exe sollte Bedingung sein.


Somit sollte auch hier ein gesunder Kompromiss aus Komfort und Sicherheit gefunden werden.

[testör]

Und wer eine Software benutzt, wo Leaks herumschwirren im Netz schreit als erster, dass die Software Mist ist.

So, dann haben das Thema auch abgehakt.

OnTopic zu NorHei: Wenn wirklich Lösung 3 sind 12 Stunden übertrieben. Normalerweise sind "7200 Sekunden" sinnvoll, aber warum nicht per Benutzereingabe in der Administration änderbar? Jeder Session werden eine gewissen Zahl (max. sagen wir 20) Tans zugeordnet und jeweils nach der eingegebenen Zeit, aber spätestens mit den ablaufen der Session gelöscht. Die Session selber sollte ein Maximum von 6 oder besser einstellbaren Stunden bekommen.

[susigross]

Na das mit mehreren TANs hate ich ja auch schon angefangen einzubauen in rev1357 - das wurde aber auch wieder restlos entfernt.
Übrigens soll noch ein bekanntes Scherheitsloch in der 2.8.2 drin bleiben:
Für den Mediaordner wird eine viel zu kurze Blacklist statt Whitelist verwendet, d.h. jeder, der da was hochladen kann, kann ausführbare Dateien hochladen und ausführen und damit den kompletten Server übernehmen. Es sei denn der Installateur macht sich kundig, welche Dateiendungen überhaupt auf seinem Server ausführbar sind und trägt die alle in die Liste ein, was aber mindestens 90% des Zielpublikums nicht auf die Reihe bringen werden. Oder wer von Euch weiß auf Anhieb, welche Scriptsprachen sein Apache überhaupt unterstützt und welche Dateiendungen in jeder Sprache akzeptiert werden?

[NorHei]

Ui, das ist aber ein böses Löchlein, dabei sollte das doch mit Leichtigkeit zu Patchen sein.





 

[testör]

Ui, das ist aber ein böses Löchlein, dabei sollte das doch mit Leichtigkeit zu Patchen sein.

Nein. Es wird erst mit 2.9 erledigt, das wurde schon sehr oft gesagt.

[NorHei]

Gibts irgendwelche Gründe dafür ? Das muss doch eine Kleinigkeit sein?

OnTopic zu NorHei: Wenn wirklich Lösung 3 sind 12 Stunden übertrieben. Normalerweise sind "7200 Sekunden" sinnvoll, aber warum nicht per Benutzereingabe in der Administration änderbar? Jeder Session werden eine gewissen Zahl (max. sagen wir 20) Tans zugeordnet und jeweils nach der eingegebenen Zeit, aber spätestens mit den ablaufen der Session gelöscht. Die Session selber sollte ein Maximum von 6 oder besser einstellbaren Stunden bekommen.

War nur die Beispielzeit aus Wordpress. Und einstellbar wäre am besten ist richtig.

[testör]

Gibts irgendwelche Gründe dafür ? Das muss doch eine Kleinigkeit sein?

Es wird gegen eine ungeschriebene Regel verstoßen die heißt: Keine Datenbankänderungen (wo ja eine gebraucht wird, um auf 2.8.2 überhaupt upzudaten) in Minor-Versionen. Das wird keiner verstehen, aber es ist halt so.

[NorHei]

Hmmm... Filterfunktion umkehren,  eingetragene Dateiendungen ändern .. keine Änderung an der DB...

[susigross]

Hmmm... Filterfunktion umkehren,  eingetragene Dateiendungen ändern .. keine Änderung an der DB...

Ja sehe ich auch so, aber andere sehen es halt anders. Und wenn ich es korrigiere, machen sie das wieder rückgängig, das hab ich ja nun gelernt.
Aber ich kann mir ja dann für den Hausgebrauch eine 2.8.3 machen

[DarkViper]

Ja sehe ich auch so, aber andere sehen es halt anders. Und wenn ich es korrigiere, machen sie das wieder rückgängig, das hab ich ja nun gelernt.

Wenn schon, dann bitte vollständige Sätze:

Ja sehe ich auch so, aber andere sehen es halt anders. Und wenn ich es, entgegen der Absprachen, ohne Rücksprache mit dem DEV-Team eigenmächtig korrigiere, machen sie das wieder rückgängig, das hab ich ja nun gelernt.

[NorHei]

Dann bitte jetzt in Absprache korrigieren und seid lieb zueinander . Und wir  alle freuen uns dann über die verschwundene Lücke 

[Stefek]

Hallo,

wollte mal fragen, ob das "Superfeature", dass man eine WB Installation nur einmal in seinem Browser anzeigen kann irgendwie korrigiert wurde.


Wann können wir mit dem 2.8.2 rechnen?
Das sah für mich um die Jahreswende so aus, als wenn es sich nur noch um Stunden handeln sollte.

Gruß,
Stefek

[fischstäbchenbrenner]

Ich hatte unlängst das Problem, dass bei einer 2.8.2 RC5 Site sehr häufig das Speichern nicht funktioniert hat und dass das Cookie verloren ging (Sorry für die laienhafte Ausdrucksweise): Im Backend konnte ich eine "private" Seiten noch bearbeiten, mit Klick auf "Anzeigen" hatte ich plötzlich keine Berechtigung mehr.

WB_URL war auf "/kunde" (Unterverzeichnis, kein http:// + Domain) eingestellt.
Ärgerlich war, dass es zu 90% funktioniert hat - aber restlichen 10% waren sehr nervig.

[NorHei]

Wenn du dich mit SVN auskennst würde ich empfehlen die Aktuelle SVN mal zu versuchen. Da sollte das eigentlich behoben sein.

[Sgt.Nops]

Lol , erst hieß es um Weihnachten rum, dann Ende Januar, ich wette das dauert noch ein halbes Jahr.
Minimum.   

[BlackBird]

Eigentlich war es schon für Ende März (letzten Jahres) angekündigt.

[ChrusR]

Hab gestern als SVN Version 2.8.2.RC5 Revision 1433 geladen und installiert. Install lief ohne Probleme. Nachdem ich einiges hier gelesen habe, stelle ich mir vor allem 2 Fragen:
1) Ist es noch empfehlenswert 2.8.1 für ein Projekt zu verwenden (Sicherheit)?
2) wie sieht die Roadmap für 2.8.2 und 2.9 derzeit aus?

Aktuelle Aussagen der DEVs habe ich leider keine gesehen und so steigt die Unsicherheit wieder.
Ein stabiles Update in den nächsten 6 Wochen könnte vielleicht eine Frischzellenkur für das Projekt bewirken. Ich verfolge das ganze seit fast einem Jahr und seither hat es kein Core-Update mehr gegeben.
LG

[susigross]

Eventuell läuft dieses Forum jetzt auch unter WB 2.8.2??
Beim Versuch zu antworten bekam ich erst mal das:

Sitzungs-Check fehlgeschlagen. Bitte loggen Sie sich aus und versuchen Sie es erneut.

Einen Logout-Button fand ich nicht, wildes Herumklicken half aber.

1) Ist es noch empfehlenswert 2.8.1 für ein Projekt zu verwenden (Sicherheit)?

Definitiv nicht.
Vor 10 Monaten (im Mai 2010) wurde ein riesiges Sicherheitsloch gemeldet (anonymer User kann sich Vollzugriff verschaffen), und das hat aus der 2.8.1 (aktuell wird die Rev 1287 vom Aug 2010 angeboten) noch keiner rausgemacht, wobei der Aufwand, das zu tun, nur die Änderung von 2 Zeilen Code erfordert. Man bastelt lieber parallel an 2 neuen Versionen 2.8.2 und 2.9 und lässt die Community mit einem ziemlich unsicheren System im Regen stehen.

Ich wurde gebeten, mich für 2.8.2 um die gemeldeten Sicherheitsprobleme zu kümmern und hatte diese Dez+Jan innerhalb einiger Tage auch fast beseitigt. Nachdem meine Änderungen aber mehrfach (teils absichtlich, teils "versehentlich", weil die Bedienung eines SVN ja soo kompliziert ist) von Luisehahne wieder entfernt wurden, habe ich mich dazu entschlossen, die Arbeit an dem Projekt erst mal ruhen zu lassen.

Leider kann man momentan nicht sagen, daß das Projekt in guten Händen wäre. Im Gegenteil, 10 Monate lang als Verein wissentlich eine hochgradig unsichere Software anzubieten ist in meinen Augen nicht gemeinnützig, sondern fast schon kriminell.

[NorHei]

Was die Roadmap betrifft, bei der 2.8.2 SVN fehlt noch ein neuer schöner Installer, an dem ist Viper jetzt drann. Dann wird er sich möglicherweise nochmal kurz die Secure Form Klasse vornehmen weil sich doch etliche darüber beschwert haben, das man nicht mehr problemlos in mehreren Fenstern arbeiten kann.
Kann aber auch sein das das als Patch nachgeliefert wird. 

Leider war vor allem Viper in letzter Zeit ein wenig überlastet mit Brötchen verdienen.

1) Ist es noch empfehlenswert 2.8.1 für ein Projekt zu verwenden (Sicherheit)?

Ganz klar: JEIN
Wenn du nur vertrauenswürdige Benutzer hast ist die Gefahr sehr gering.
Wenn Benutzer sich einfach registrieren können solltest du definitiv die SVN benutzen, die habe ich hier auch schon im Produktiv Einsatz. In der SVN sind meines Wissens nach alle diese Lücken gepatcht. Wenn jemand mit SVN Probleme hat stelle ich hier auch gerne einen Snapshot zur Verfügung.

@Frank 
Deine Patches wurden entfernt weil sie nicht den Erwartungen entsprachen (Was jetzt KEINE Aussage über die Qualität deiner Patches ist!) und Du sie wohl ohne vorheriges Testen und ohne Absprache ins SVN hochgeladen hast .  Ich vermute mal das das an fehlerhafter Kommunikation lag. Auf jeden Fall fände ich es Sinnvoller wenn Du einfach mal zum Telefonhörer oder zu Skype greifen tätest und die Sache direkt mit Viper oder Luise klären würdest. (Du kannst auch gerne erst einmal mich kontaktieren und mach dann den Vermittler.)  Das hier wieder und wieder im Forum zu Posten führt  doch zu nichts.

[Stefek]

@Frank 
Deine Patches wurden entfernt weil sie nicht den Erwartungen entsprachen ... und Du sie wohl ohne vorheriges Testen und ohne Absprache ins SVN hochgeladen hast .

Ich kann beim besten Willen nicht nachvollziehen, wie so eine Lappalie so viel Wind aufwirbeln kann.
Auf der einen Seite die Erwartung, wie es richtig sein soll auf der anderen Seite der gute Wille, beizutragen.
Ich verstehe nicht, wo die Schwierigkeit ist, sich in der Mitte zu treffen.

Und ich verstehe auch nicht, warum man kein System mit Branches einführen kann.
Warum alles direkt ins SVN übernehmen?
So kommen wir nie dahin, sinvolle Entwicklungen im Testbetrieb zu begutachten, um sie anschließen in eine Subversion einfließen zu lassen.

Stefek