Neues AdminTool SecureForm Switcher

[Luisehahne]

Hallo,

ich habe mir mal Gedanken gemacht, wie das Thema SecureForm zu lösen ist. Da in einer der letzten RCs die Möglichkeit des Laden des Patches von Norhei eingebunden wurde, stelle ich hier ein AdminTool zur Verfügung mit der Möglichkeit zwischen den beiden Versionen hin und her zu schalten. Das Tool ist soweit selbsterklärend.

Systemvoraussetzung:
WebsiteBaker 2.8.2.RC6 Revsion 1467. (Download Release Candidates)

Hinweise zur Installation:
Das Admintool enthält den SecureForm Patch, der bei der Installation des Tools in den Ordner Framework kopiert wird. Auf Servern auf den Apache als Modul und nicht als CGI läuft kann aufgrund der Eigentumsrechte die notwendige Datei nicht vom Script ins framework Verzeichnis kopiert werden, Dann muss der Patch per FTP hochgeladen werden. Ein Fehlen des Patches wird im Tool angezeigt.

Bitte Testen. Version ist 0.4.0.alpha. Dank an alle Tester. Dank auch an instanstantflorian, der mir für die Gestaltung der Benutzerfreundlichk eit geholfen hat

Dietmar

Edit 2011/07/03
Neueste Version 0.6.0.alpha

[dbs]

Prima Sache, Multi-Tab funktioniert (auch schon mit 1465).

Deinstalliert man das Tool wieder, bleibt Multi-Tabbing erhalten. (?)
Die Erfolgreich-Meldungen bei Install oder Switching sind nur eine halbe Sekunde lang zu sehen und nicht lesbar.

dbs

[maverik]

Der erste Kurztest sieht positiv aus. Da der Thread und das Thema aber mit Sicherheit in der Versenkung verschwinden wird sollte man das Admin-Tool, um später unnötige Support-Anfragen mit Verweis auf das Tool zu vermeiden, mit in die Stable übernehmen.

Die Erfolgreich-Meldungen bei Install oder Switching sind nur eine halbe Sekunde lang zu sehen und nicht lesbar.

Unter Optionen "Weiterleitung nach" kontrolliert? Steht bei mir auf 1500 und die Meldung sind akzeptabel lesbar.

[dbs]

Unter Optionen "Weiterleitung nach" kontrolliert? Steht bei mir auf 1500 und die Meldung sind akzeptabel lesbar.

thx, war aus irgendeinem grund auf 0

um später unnötige Support-Anfragen mit Verweis auf das Tool zu vermeiden, mit in die Stable übernehmen.

schließe ich mich an.

[ruebenwurzel]

Hallo,

habs auch mal getestet und folgendes festgestellt:

1.) Auf Servern auf den Apache als Modul und nicht als CGI läuft kann aufgrund der Eigentumsrechte die notwendige Datei nicht vom Script ins framework Verzeichnis kopiert werden. Hier ist auf jeden Fall nachträgliche Handarbeit angesagt. Deswegen kann ich mich nur den Vorrednern anschließen, das Admin-Tool in das 2.8.2 Paket mit zu übernehmen, dann spielen die Berechtigungen keine Rolle mehr, da es eh per ftp hochgeschoben wird.

2.) Auf WB Installationen, die mit ISO-8859-1 laufen, funktioniert die DE.php nicht. Hier sollten die Specialchars noch durch Entities ersetzt werden.

Matthias

[Luisehahne]

Erstmal mal Danke fürs Testen und direkt eine neue gefixte Version. (SecureForm Switcher 9.6.0.alpha)

Auf WB Installationen, die mit ISO-8859-1 laufen, funktioniert die DE.php nicht

Für WB Installationen die nicht mit UTF-8 laufen, wird nunmehr die SecureForm Switcher Sprachdatei in das aktuelle CHAR_SET konvertiert. Zu beachten ist die Sprachdateien unbedingt als Utf-8 ohne BOM abgespeichern. Somit lassen sich die Entities vermeiden.

Auf Vorschlag von DarkViper werden die in der Multitab Version (NorHei Patch) vorgebenen Konstanten mit den Standardwerten in die Settings eingetragen. In einer der nächsten Versionen werde ich diese mit in die Maske zum Ändern der Werte einbauen. Somit ist es nicht mehr nötig, wie von NorHei vorgeschlagen, die Konstanten in die config.php einzubinden. Evtl. bereits gsetzte Konstanten unbedingt wieder entfernen, da es sonst zu einer Fehlermeldung kommt, da die Einträge der Settings und Umwandlung, keine Prüfung auf bereits gleichnnamige Konstanten vorgenommen wird.

mit in die Stable übernehmen

Nein sicherlich nicht! Es handelt sich um ein Zusatztool welches nicht zum Core gehört und bitte jetzt keine Diskussionen. Wenn ihr die WB 2.8.2 entpackt habt, einfach den entpackten SecureFormSwitcher gleich mit in den Ordner Modules kopieren und zusammen hochspielen.

Weiterhin Viel Spass beim testen.

Dietmar

[ruebenwurzel]

Hallo,

Nein sicherlich nicht! Es handelt sich um ein Zusatztool welches nicht zum Core gehört

dann kann es aber auch nicht sein dass Files diese Patches in Core-Ordner (framework) kopiert werden müssen. Das ist unkonsequent. Richtiger wäre es dann meiner Meinung nach, dass alle Files dieses Admin-Tools ausschließlich in dem Ordner des Moduls untergebracht sind.  

Matthias

[DarkViper]

Falsche Aussage.
Konsequent wäre es jetzt, die vereinfachte Einbindungsmöglichkeit dieses Patches wieder zurückzunehmen und auf den überall(nicht nur bei WB) gültigen Grundsatz zu pochen: 'ein Fremd-Patch richtet sich nach dem Core... aber niemals richtet sich der Core nach irgendeinem Fremd-Patch' !

[Stefek]

Wie wärs dann damit, Dir eine Core-Lösung einfallen zu lassen, die nicht jeden auf den Beutel geht und nicht so lange dafür zu brauchen, dass man Dich als Core-Entwickler dann immer noch ernst nimmt?

[kweitzel]

Werner, es ist nicht unbekannt, dass Fremdpatches in einer OpenSource Umgebung auch in den Kern eines Projekts übernommen worden sind. Wäre das nicht so, dann wäre der Linux Kernel NICHT das was es heute ist ...

Gruß

Klaus

[ruebenwurzel]

Hallo,

mir gefällt die "vereinfachte" Einbindung des Patches von NorHei als AdminTool eigentlich super gut. So kann der User selbst entscheiden, ob er das nutzen will oder nicht.

Wenn man die Diskussion hier verfolgt, besteht ja anscheinend ein großer Wunsch, diesen Patch nutzen zu können. Was spricht also dagegen, wenn der Core soweit vorbereitet wird (ist ja glaub ich schon größtenteils erledigt), dass dieser Patch als AdminTool genutzt werden kann. Wenn man jetzt das AdminTool dann noch soweit verfeinert, dass es auf allen Servern auch einfach installiert werden kann, ist alles wunderbar. Das würde zwar dem von Werner angeprochenen Grundsatz:

'ein Fremd-Patch richtet sich nach dem Core... aber niemals richtet sich der Core nach irgendeinem Fremd-Patch'

wiedersprechen, denke aber für diesen speziellen Einzelfall halte ich es für den besten Kompromiss.

Matthias

[Stefek]

Grundsätze sind gut, solange sie keine neuen Willkürfaktoren heraufbeschwören.

Wer stellt solche "Grundsätze" auf?
Und warum sollte man sich hier überhaupt an diesen Grundsatz lehnen?

Hier würde eher der Grundsatz anwendung finden:
Was nicht passt wird passend gemacht.
Diese ganze FTAN Geschichte wird doch überbewertet.

Außerdem sprechen wir hier von einer WB Version, die bald eigentlich der Geschichte angehören soll - laut den Core-Entwicklern, denn die Planen jetzt schon den 2.9.2

Welcher Grundsatz spricht eigentlich dagegen, die Lösung von NorHei zu nehmen?
Die Extra(übertriebene)sicherheit kann man dann über ein Patch dazustellen.

Grundsätze... sollten nich willkürlich runtergeplappert werden, wie es einem passt.
Grundsätze sollen dem Zweck und Ziel der Kiste dienen.
Es wäre also besser, erstmal diese zu postulieren.

Dann kann man die Grundsätze auf Tauglichkeit prüfen.
Und: welchen Zweck fördert der besprochene Grundsatz jetzt?
Einfachheit? Zufriedenheit? Sicherheit? Popularität?

Oder gibts da noch andere Zwecke, die im Verborgenen liegen?

Stefek

[maverik]

besteht ja anscheinend ein großer Wunsch, diesen Patch nutzen zu können.

Ich sage es jetzt mal ein wenig überspitzt: Ohne Patch ist die 2.8.2 schlicht unbrauchbar und hat mit der ehemaligen Einfachheit von WB nichts mehr am Hut.

Was sind Grundsätze, wer legt sie fest und wer muss sich dran halten?

Ist es nicht Grundsätzlich so das eine RC eine "Stable" ist aus der nur noch die letzten "Fehlerchen" ausgebügelt werden?

Das was die RC hier von Anfang des Jahres bis jetzt, RC1 - RC6, duchläuft ist in meinen Augen eine Beta-Phase.

Hier wird wenig auf die Community und vorhandene Ressourcen reagiert, hier wird von einem ein Weg gegangen und den kann man mitgehen oder es bleiben lassen.

Schade eigentlich.

[testör]

Dass der Grundsatz von WebsiteBaker erst einmal "Einfachheit für den Benutzer / Designer" lautet steht außer Frage. Ansonsten wäre WB eines der Xten Mambo und Typo3 Abklatsche, die reihenweise die letzten Jahre gekommen (und oft auch wieder gegangen) sind. Hierüber zu diskutieren wäre darüber zu diskutieren, ob man die Leiche beerdigen soll. Denn durch codetechnische Finessen, "Anonymus" geprüfte Sicherheit und Facebook Integration glänzt WB nicht und wird es auch in Zukunft nicht tun.

Das alles darf aber nicht darüber hinweg täuschen, dass WB (das Projekt) seine Aufgaben erledigen sollte. Sicherheit gehört dazu - niemand will sich Software zulegen, die als unsicher eingestuft wird. Kompatibilität gehört ebenfalls dazu - die DAUs stellen die größte Gruppe (Einfachheit!) von WB dar, und sie möchten sicher nicht ihren historisch bedingten Webhoster wechseln.

Warum es eine RC gibt (und ja, ich war einer der Schlawiner, der das damals der WB Community eingebrockt hab, ich steh dazu) seit einem halben Jahr ist schlicht und einfach darauf zurückzuführen, dass es der kleinste gemeinsame Nenner war, auf den wir uns einigen konnten. Es sollte ja nicht einmal mehr eine 2.8.2 geben sondern nur noch Patches - für mich ein Graus, wie will man das dem WB-Benutzer erklären, wenn neben Versionen und neuerdings auch Revisionen noch Patchinstanznummern hinzukommen. Dass das ganze RC getauft wurde war eine Kurzschlussreaktion (und ich nehme mich da gar nicht aus), die darauf zurückzuführen war, dass man einfach keinen genauen Überblick hatte, was für Auswirkungen und Reaktionen die Änderungen seit 2.8.1 überhaupt hervorrufen werden. Dass eine Minorversion wie die 2.8.2 so viele RCs hat ist ein Unding, aber da es eh kaum feste Regeln gibt mit den Nummern sollte man sich nicht unbedingt da dran aufhängen.

Der Grundsatz lautet: Die Community hat im Core und deren Bereitstellung nichts zu suchen, aus, fertig. Die Community darf sich woanders vergnügen, meinetwegen noch auf AMASP, im Addons Repository oder im Forum. Die Tester und Ideengeber sucht man sich persönlich aus. Man kann es drehen und wenden wie man will, es ist die Haltung und - so schlimm es für ein OpenSource Projekt auch klingen mag - durchaus auch ein gangbarer Weg, der ab und an zu andauernden Erfolg führte. Das ist kein Grund diesen Grundsatz zu Tode zu diskutieren, sonst sind die Entwickler weg - und das will auch keiner wieder verantworten.

FTAN hin oder her - den WB-Benutzer interessiert's nicht. Ihn interessiert, ob WB sicher ist oder nicht. Ob es läuft, ob es einfach ist. Und schon dreimal interessieren ihn keine Ankündigungen - nur Bereitstellungen mit Release notes.

[BlackBird]

Ich verstehe wirklich nicht, warum so auf die vorhandene Lösung gepocht wird. Der sogenannte "Patch" von NorHei ist nicht unsicherer - eher im Gegenteil - und löst zudem alle Probleme des Originals. Daß er nicht einfach übernommen wird, ist mir völlig unverständlich. Das würde Zeit, Arbeit, Emotionen und noch viel mehr sparen und dem Ansehen des Projektes deutlich mehr nutzen, als diese völlig sinnfreie Debatte.

[BlackBird]

Der Grundsatz lautet: Die Community hat im Core und deren Bereitstellung nichts zu suchen, aus, fertig. Die Community darf sich woanders vergnügen, meinetwegen noch auf AMASP, im Addons Repository oder im Forum. Die Tester und Ideengeber sucht man sich persönlich aus. Man kann es drehen und wenden wie man will, es ist die Haltung und - so schlimm es für ein OpenSource Projekt auch klingen mag - durchaus auch ein gangbarer Weg, der ab und an zu andauernden Erfolg führte. Das ist kein Grund diesen Grundsatz zu Tode zu diskutieren, sonst sind die Entwickler weg - und das will auch keiner wieder verantworten.

Das ist nicht Dein Ernst, oder? Bitte bitte sag mir, daß das nicht Dein Ernst ist. Das könnte live und unverändert aus dem Workshop "Warum Projekte scheitern" stammen.

_Alle_ nennenswerten OS-Projekte leben davon, daß nicht nur Ideen, sondern auch Code aus der Community übernommen werden. Das ist bei Linux so, bei phpBB, bei .... Da bricht man sich keinen Zacken aus der Krone. Jeder von uns kann noch was dazu lernen. Jeder ist manchmal etwas betriebsblind und braucht einen Schubs von außen.

[kweitzel]

Ein Hinweis hier: Testör spricht NICHT für das Projekt!

Gruß

Klaus

[testör]

Ein Hinweis hier: Testör spricht NICHT für das Projekt!

Das ist falsch geschrieben, ich korrigiere: Ich habe zur Zeit keine Position im Projekt / Verein noch aktiven Kontakt zu Leuten die solch eine Position innehaben.
Für das Projekt spricht keiner, jeder - auch ein Aktiver - spricht nur seine eigene Meinung aus. Es gab zumindest in vergangener Zeit solch ein Projektsprachrohr nicht und ich zweifle stark an, dass es bis heute eines gibt.
Edit: Allerdings finde ich es gut, dass Dietmar durch das Modul dem Benutzer mehr Möglichkeiten ermöglicht.

[Luisehahne]

Die nächste Version ist bereits im Test, Bei Betrieb in Mutlitab erscheint eine Maske zum Bearbeiten der Einträge für die Konstanten im Multitab Patch. Diese wird auch gerade durch Norbert überarbeitet.

Dietmar

[dbs]

Der Thread hier muss nicht mehr "sticky" sein, oder?

[kweitzel]

Danke für den Hinweis ... ich denke Du hast Recht.

Gruß

Klaus