Plugin-Einstellungen

[bastibeckr]

Hallo,

ich stehe gerade vor dem Problem, eine Kategorieliste als Auswahl im Admin-Bereich zu erstellen. Der Nutzer ( Shop-Admin) soll die Möglichkeit haben, Kategorien an- oder abzuwählen.
Das Ausgeben der Kategorieliste usw stellt kein Problem dar, jedoch scheint es nicht so leicht zu sein, die Auswahl auch abzuspeichern.

Ich dachte mir, dass es über AJAX (Benutzer verändert eine Select-Box -> Wert wird in eine eigene PlugIn-Tabelle gespeichert) kein Problem sein sollte. Jedoch ist jQuery 1.4.4 fester Bestandteil des Admin-Bereichs. Mittlerweile ist 1.6 aktuell - seit 1.4.4 hat sich "ein bisschen" was getan. Ändern kann man das wohl so leicht nicht - im Admin-Bereich fehlen die im Frontend-Bereich eingeführten Hooks. Oder hab ich da etwas übersehen?

Um mein Problem zu lösen, müsste es eine Möglichkeit geben, eigene .js-Dateien in den Fuß- (oder Kopf-)Bereich des Admin-Bereichs zu laden. Geht das irgendwie? Ungern möchte ich alles in die .php-Datei reinschreiben.

Außerdem wäre eine Art Anbindung an die Plugin-Settings ganz gut - sodass sich o.g. Probleme etwas leichter lösen lassen. Wie bereits gesagt, wenn ich etwas übersehen haben sollte, tut's mir leid!

schönen Abend,


Basti

 

[ag-websolutions.de]

AW: Plugin-Einstellungen

Frontend-Bereich eingeführten Hooks. Oder hab ich da etwas übersehen?

richtig gesehen

eigene .js-Dateien in den Fuß- (oder Kopf-)Bereich des Admin-Bereichs zu laden

geht nicht ... weder über hook (s.o.) noch hart...da admin-Dateien verschlüsselt

ngern möchte ich alles in die .php-Datei reinschreiben.

wird dir kaum was anderes übrig bleiben

Außerdem wäre eine Art Anbindung an die Plugin-Settings ganz gut

versteh ich jetzt nicht

 

[bastibeckr]

AW: Plugin-Einstellungen

Zunächst mal danke für die Antwort.

versteh ich jetzt nicht

zB die Möglichkeit, dynmamische Settings zu erstellen, die aus ankreuzbaren Kategorien bestehen.
Es gibt momentan wenig Möglichkeiten, zu prüfen, ob der Benutzer die Settings überhaupt verändern darf. Auch wenn es nur einen Admin gibt, ist es nicht besonders sicher, wenn hier jeder sein eigenes "Sicherheits"-System erstellen muss - man könnte ja z.B. mit einer PHP-Datei direkt Formulardaten in die Datenbank schreiben usw.
Besser wäre es, wenn sich der Shop darum kümmert und ich nur noch eine Funktion

save_setting($plugin_name, $key, $value);

aufrufe, die zunächst prüft, ob ich überhaupt das Recht habe, die Settings zu ändern und dann potentielle Injections etc abwehrt.
Genau so, wie die "Standard-Settings", die in die XML-Datei reingeschrieben werden, (hoffentlich) abfragen und die Werte vor dem Schreiben in die Datenbank auf Gefahrenpotential hin überprüfen, sollte das auch für "Custom Links" möglich sein.

 

[exube]

AW: Plugin-Einstellungen

Moin,

mit den Settings habe ich mich gestern auch beschäftigt. Ich benötige für ein Plugin die Möglichkeit, alle im Shop verfügbaren Hersteller aufzulisten und auswählbar zu machen.
Das ist mit den XML Settings nicht machbar, sollte es meiner Meinung nach auch gar nicht sein.

Meine Lösung: ein Custom Link im Admin Backend. Kann man ja "Erweiterte Einstellungen" nennen. Hier hat der Nutzer die Möglichkeit, alle Hersteller über Checkboxen zu wählen. Um die Darstellung kümmer ich mich.
Der Trick bei der Speicherung ist folgender: durch den Status der Checkkoxen wird ein String erzeugt und in den einfachen Einstellungen in einem <input> gesetzt (per jQuery). In der gleichen Methode speichere ich auch die Einstellungen: einfach in den "Erweiterten Einstellungen" via jQuery das click Event für des Reiters der einfachen Einstellungen auslösen (faktisch ist das alles eine HTML Seite).

Hört sich etwas abenteuerlich an, aber: nutzt man jQuery und PHP richtig, kann man hier so ziemlich alles mit Anstellen. Sicher auch eine erweiterte Benutzerverwaltung. Und damit das nicht jeder neu schreiben muss: am besten als Plugin / Adminwidget herausgeben

Viele Grüße

 

[bastibeckr]

AW: Plugin-Einstellungen

Vielen Dank exube für die Ausführungen - einen ähnlichen Ansatz habe ich jetzt auch umgesetzt, die Kategorie-Selectbox wird verwendet, um ein Feld in den "XML-Settings" zu verändern.
Ich hab das betreffende Feld mit jQuery "versteckt" sodass es nicht falsch ausgefüllt werden kann. Damit könnte man auch umfangreiche "Custom Settings" realisieren - zunächst serialisieren und dann in ein verstecktes Text-Input-Feld einfügen.

Allerdings ist das alles schon wieder eine Rumtrickserei, die eigentlich nicht sein müsste, wenn das sehr gute Konzept der Hooks auch im Backend konsequent umgesetzt wäre.
Mein Appell wäre immer noch, dass diese Code-Verschlüsselung rückgängig gemacht wird.
Wer an den Quellcode will, kann das tun - für ein paar $ kann man den Quellcode entschlüsseln lassen. Der verschlüsselte Code bringt nur Nachteile - z.B. kann keine aktuelle Version z.B. von jQuery oder anderen Frameworks eingesetzt werden. Auch evtl. Sicherheitslücken können nicht nachvollzogen werden. Wer genügend kriminelle Energie aufbringt kann jedoch problemlos an den Quellcode, Sicherheitslücken finden und ausnutzen.
Ich finde, dass das Shopsystem in den letzten Jahren wirklich viel professioneller geworden ist - aber eine verpflichtende Verwendung veralteter Frameworks gehört nicht zu den Features, die Entwickler sich wünschen.

 

[david]

AW: Plugin-Einstellungen

Hi,

Mein Appell wäre immer noch, dass diese Code-Verschlüsselung rückgängig gemacht wird.

Es sind nur wenige Teile vom Shop verschlüsselt, siehe Kategorie:Shop-FAQ . Der Admin-Bereich jedoch komplett, weil wir möchten, dass das Admin-Backend bei allen Kunden gleich arbeitet und nicht von (möglicherweise fehlerhaften) Plugins manipuliert/unbrauchbar gemacht wird. Mit Verschleierung von theoretisch möglichen Sicherheitslücken hat das nichts zu tun, das wäre auch ein falscher Ansatz.

 

[bastibeckr]

AW: Plugin-Einstellungen

Servus, versteh mich nicht falsch ich möchte hier auch nicht rum nörgeln. Ich find es sehr gut, was sich die letzen Jahre getan hat und hoffe darauf, dass auch weiter viel passiert.

Aber: Der Hinweis im Adminbereich ("Sicherheitshinweis: Plugins haben Zugriff auf die gesamte Datenbank des Shopsystems!") steht doch im Widerspruch zu dem, was du gerade gesagt hast.
Gerade weil entsprechende Funktionen und Hooks fehlen, muss jeder, der "mehr" will, sein eigenes Sicherheit-System bauen und kann durchaus Schaden anrichten...

Ich unterstelle überhaupt nicht, dass die Verschlüsselung dazu dient, irgendwas zu verschleiern. Sinnvoll wäre aber doch die Offenlegung des Codes, da so logischerweise eine wesentlich größere Zahl an Benutzern sehen kann, was vielleicht sonst niemandem auffällt.

 

[ag-websolutions.de]

AW: Plugin-Einstellungen

Der Hinwies ist vollkommen zutreffend....

selbstverständlich kann ich ... heute bereits...ohne jeden Hook ... auf jegliche Tabellen des Shops innerhalb der Datenbank aus einem Plugin heraus zugreifen ... was passt daher nicht an der Warnung?

 

[Thomas Lisson]

AW: Plugin-Einstellungen

hi,

Mein Wunsch wäre:
ein System, mit dem man umfangreichere Plugin-Settings realisieren kann

Definier bitte Plugin-Settings. Die Plugin-Schnittstelle bringt von haus aus eine umfangreiche Einstellungsverwaltung für eigene Plugins mit.

 

[bastibeckr]

AW: Plugin-Einstellungen

Servus,

aber nur dann, wenn ich die Werte nicht dynamisch anzeigen möchte.

Angenommen, ich hab eine Liste mit Kategorien / Herstellern / Produkten als Selectbox, wird's schon schwierig, mit der eingebauten Schnittstelle zu arbeiten.
Oder übersehen wir hier was?

Es wäre schön, wenn es eine Art PHP-API geben würde, die so sensible Aufgaben wie "Speichere Einstellung" erledigt. Einfach so in die Datenbank zu schreiben, halte ich hier für keine gute Idee. Auch der Umweg über jQuery ist nicht besonders elegant.

 

[Thomas Lisson]

AW: Plugin-Einstellungen

hi,

Angenommen, ich hab eine Liste mit Kategorien / Herstellern / Produkten als Selectbox, wird's schon schwierig, mit der eingebauten Schnittstelle zu arbeiten.

Mach mehrere Tabs daraus. In einem packst du die festen Einstellungen rein, die global für das Plugin gelten sollen. Und ein Tag mit einer Custom Seite, die du selbst aufbaust mit den Kategorien und Herstellern. Die Infos, die hier gespeichert werden müssen, musst du in eigene Tabellen unterbringen.

 

[bastibeckr]

AW: Plugin-Einstellungen

Alles richtig, aber ich schreibe direkt mit SQL in die Datenbank, was ich grundsätzlich für den falschen Weg halte. So muss sich jeder Plugin-Entwickler selbst überlegen, wie die Settings gespeichert werden. Man kann das Problem so oder so lösen - im Zweifelsfall gehe ich davon aus, dass man sich ganz einfach keine Gedanken über Sicherheit macht und auf diese Weise entstehen Sicherheitslücken.
Aufgefallen ist mir das nur, weil das "etwas angestaubte" jQuery 1.4 verwendet wird und ich das nicht ändern kann.

 

[ag-websolutions.de]

AW: Plugin-Einstellungen

was hat denn bitte schön die Verwendung eines javascript-frameworks mit der Art und Weise des Datenhandlings in Bezug zur DB zu tun?

Lad dein framework aus dem Plugin heraus; prüfe vorher ggfls. noch, ob nicht schon (durch ein anderes Plugin) jqeury in höherer Version geladen ist

 

[Thomas Lisson]

AW: Plugin-Einstellungen

Hi,

Man kann das Problem so oder so lösen - im Zweifelsfall gehe ich davon aus, dass man sich ganz einfach keine Gedanken über Sicherheit macht und auf diese Weise entstehen Sicherheitslücken.

Egal, wie du es löst, warum sollte deswegen eine Sicherheitslücke entstehen? Eigene Einstellungen müssen selbst abgelegt werden. Du willst Kats und Hersteller hinterlegen - evtl mit 1:n Relationen zu anderen Daten. Andere Leute brauchen vielleicht n:m Relationen oder anderer evtl. selbst durch das Plugin erzeugter Daten. Für solche Fälle kann man einfach nichts vorbereiten.

 

[bastibeckr]

AW: Plugin-Einstellungen

OK, ich schreib mal meine Erkenntnisse zu diesem Thema hier rein. Kann sein dass ich es überlesen habe. Vielleicht gibt's ja die Möglichkeit einer Ergänzungs- bzw. Kommentarfunktion im Entwickler-Wiki. Das spart sicher einigen Leuten viel Zeit und Nerven.

Maximale Textlänge eines Werts bei den Standard-Settings: 255 Zeichen
Grund: VARCHAR als Datentyp in der Datenbank
Abhilfe: Eine SQL-Datei ins PlugIn integrieren, die folgenden Befehl bei Installation ausführt:

ALTER TABLE `tplugineinstellungen` CHANGE `cWert` `cWert` TEXT  NOT NULL;

Gibt's irgendwo eine Liste mit Feld-Typen, die für die XML-Settings erlaubt sind? (z.B. "textarea" geht schonmal nicht, s.u.)

<Setting type="[COLOR=#ff0000]textarea[/COLOR]" initialValue=" " sort="7" conf="Y">
	<Name>All Data</Name>
	<Description>Hier soll alles gespeichert werden? Mal sehn.</Description>
	<ValueName>sb_startcat_alldata</ValueName>
</Setting>

"sort" ist ja noch selbsterklärend, aber was bewirkt "conf" ? Gibt's sonst noch irgendwelche Parameter / Einstellungen? Irgendwie wäre eine Referenz super, dann müsste man nicht bei anderen PlugIns schauen, was es noch so geben könnte.
Vielleicht kann man ja - wenn schon der gesamte Admin-Quelltext verschlüsselt ist - zumindest die Doc-Blöcke über den Funktionen irgendwo veröffentlichen. Das macht keine Arbeit und ist fast schon eine vollwertige Dokumentation.

Fortsetzung folgt.

 

[ag-websolutions.de]

AW: Plugin-Einstellungen

ich finde es nicht gerade als gute Sitte, die Shop-core-Tabellen zu verändern. Wenn das jeder macht...mehr oder weniger korrekt....können wir das supporten sein lassen und sind bei osc angekommen

wenn einem die 255 zeichen nicht reichen, dann macht man eine eigene Plugin-Tabelle und eine eigene Einstellungsseite und gut ist

 

[bastibeckr]

AW: Plugin-Einstellungen

Wie oben ausführlich diskutiert gibt es 2 Möglichkeiten:

1. Mich drum kümmern, dass vom Benutzer eingegebene Daten sicher und unter Beachtung von evtl. eingeschränkten Benutzerrechten in eine eigens erstellte Tabelle geschrieben werden. Zuvor müssen die Eingaben natürlich validiert werden und ich bezweifle, dass sich jeder PlugIn-Autor diese Mühe macht. Besonders, wenn man dran denkt, dass es diese Funktionalität ja schon gibt, allerdings Entwickler keinen Zugriff darauf haben, ist das mühsam.
2. Über Umwege, aber meiner Meinung nach mit weniger Fehlerquellen, die "eingebaute" Schnittstelle zum Speichern der Settings benutzen. Auch nicht elegant.

Anzumerken ist auch, dass man aufgrund von Einschränkungen in einer .htaccess-Datei (im "includes"-Verzeichnis) sehr gut überlegen / suchen muss, bevor man es hinbekommt, benutzerdefinierte Settings sicher zu validieren, verarbeiten oder speichern, ohne einen übertriebenen Aufwand zu betreiben.

<Files *.php>
Order Deny,Allow
Deny from all
</Files>