WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => Modules => Topic started by: bbs2 on February 22, 2019, 09:11:03 AM
-
Hallo,
ich benutze weiterhin unter WB 2.12.x die swift gallery. Immer nachts gegen 0 Uhr treten lt. error-log folgende Fehler auf
Thu, 21 Feb 2019 13:28:34 +0000 [E_NOTICE] /modules/swift/view.php:[83] from /framework/frontend.functions.php:[225] require "A non well formed numeric value encountered"
$i = 0;
if( is_dir( $gallery_path ) ) {
if( $handle = opendir( $gallery_path ) ) {
$all_images = array();
while( ( $file = readdir( $handle ) ) !== false ) {
if( is_file($gallery_path.$file) && $file!='index.php') {
$image = WB_URL.$gallery.$file;
$all_images[$i] = $image;
$i++;
}
}
closedir( $handle );
}
}
if( isset( $_REQUEST['start'] ) ) {
$start = $_REQUEST['start'];
}
else {
$start = 0;
}
$images = array();
$a=intval($i);
if ($a>0) {
$images = array_slice( $all_images, $start, $settings['thumbs_per_page']); ///Dies ist die Fehlerzeile 83
}
Für den user tritt kein Fehler auf. Alle galeries werden fehlerfrei angezeigt.
Kann es sein, dass der Fehler nur bei scans einer Suchmaschine auftritt?
Viele Grüße
Heinz
-
Hallo, da es keine Swift Gallery im Add-ons Repo gibt und du keine Modulversion nennst, könntest du das Modul hier mal als Anhang reinsetzen.
-
hallo,
es ist ein sehr schönes, jedoch altes Modul aus der Zeit WB 2.8. Es läuft für den Normaluser
jedoch gut unter WB 2.12.x und PHP 7.2
Swift Version 0.6
Siehe Anlage
-
Das Modul, so wie du es hier anbietest, kann icht installiert werden.
Wo ist das Modul her?
-
Ok, scheint von Github zu sein
Konnte es nach "umformatieren" installieren.
Schmeißt ne Menge Fehler in php 7.3
Fri, 22 Feb 2019 11:04:11 +0000 [E_NOTICE] /modules/swift/save.php:[45] from /modules/swift/save.php:[45] bin\Exceptions\ErrorHandler::handler "Undefined index: default"
Fri, 22 Feb 2019 11:04:55 +0000 [E_NOTICE] /modules/swift/save.php:[45] from /modules/swift/save.php:[45] bin\Exceptions\ErrorHandler::handler "Undefined index: default"
Fri, 22 Feb 2019 11:06:38 +0000 [E_WARNING] /modules/swift/view.php:[80] from /templates/DefaultTemplate/index.php:[34] page_content "count(): Parameter must be an array or an object that implements Countable"
Fri, 22 Feb 2019 11:07:09 +0000 [E_NOTICE] /modules/swift/save.php:[45] from /modules/swift/save.php:[45] bin\Exceptions\ErrorHandler::handler "Undefined index: default"
Fri, 22 Feb 2019 11:07:12 +0000 [E_WARNING] /modules/swift/view.php:[80] from /templates/DefaultTemplate/index.php:[34] page_content "count(): Parameter must be an array or an object that implements Countable"
Fri, 22 Feb 2019 11:07:31 +0000 [E_WARNING] /modules/swift/view.php:[80] from /templates/DefaultTemplate/index.php:[34] page_content "count(): Parameter must be an array or an object that implements Countable"
Fri, 22 Feb 2019 11:07:33 +0000 [E_WARNING] /modules/swift/view.php:[80] from /templates/DefaultTemplate/index.php:[34] page_content "count(): Parameter must be an array or an object that implements Countable"
Fri, 22 Feb 2019 11:07:38 +0000 [E_WARNING] /modules/swift/view
-
es ist ein sehr schönes, jedoch altes Modul aus der Zeit WB 2.8. Es läuft für den Normaluser
jedoch gut unter WB 2.12.x und PHP 7.2
jau, mag sein, aber mehr darfst du dem Modul auch nicht mehr zumuten, PHP 7.3.x ist nicht drin und ein NeuInstall unter Normalbedingungen auch nicht mehr
vom Code her gibt es keine Zeile 83 im Zip und der Code stimmt dann auch nicht mit obigem Code überein, von daher schlecht zu sagen, was da passiert
Allerdings.... frontend.functions. php ~ Zeile 225 (wenn sie denn noch original ist) betrifft die Suche über das Frontend, hier speziell das Highlighting der Suchbegriffe. Die Kombination wäre im Normalfall mein Ansatzpunkt. Ich denke, da würde ich mir mal gezielt ein paar Messages in die error.log schreiben lassen, was denn von dieser Zeile 83 im Script auch ankommt
$images = array_slice( $all_images, $start, $settings['thumbs_per_page']);$all_images ist der Array mit den Bildern
$start eine numerische Zahl (bzw soll eine numerische Zahl sein),
$settings['thumbs_per_page'] ebenfalls eine numerische Zahl
lt der Fehlermeldung ist eine der beiden wohl keine Zahl
Gehe ich davon aus, das die Einstellung der settings auf jeden Fall richtig ist, bleibt mir dieses Stück Code als Fehlerquelle
if( isset( $_REQUEST['start'] ) ) {
$start = $_REQUEST['start'];
}
else {
$start = 0;
}
Hier fehlt jegliche Absicherung in Bezug auf numerische Werte. $_REQUEST['start'] kann alles mögliche sein, von einer echten Zahl bis hin zu Parametern, die du nie im Leben erwartest, um jetzt mal nix von möglichen Anweisungen per SQL- oder Code-Injections zu sagen. Du glaubst garnicht, was da alles möglich ist
-
Anhang:
swift_gallery_v0.6_ origin.zip
swift_gallery_v0.6_ BBS2.zip
-
Hallo,
ich hatte das Modul vor ca. 10 Jahren installiert und von der damals offiziellen
WB_Seite geladen. Leider habe ich die damalige zip-Datei nicht mehr.
Die von mir im vorigen post gelieferte zip-Datei war lediglich der komprimierte Swift-Ordner
aus der Installation.
Ich habe jedoch nun noch folgenden Link gefunden:
http://www.websitebakers.com/pages/modules/image-galleries/swift-gallery.php
Viele Grüße
Heinz
-
Es ist schon erstaunlich, dass das alte Teil noch läuft und sich sogar installieren lässt (nicht strict).
Habe in der Adresszeile mal eine gallery_id eingegeben, die es nicht gibt. Da zeigt er statt einer Galerie die URL zum WB upgrade-script.
In der view.php Zeile 83 hab ich leider eine Leerzeile. Das scheint nicht die gleiche Version zu sein, die du benutzt, oder?
-
@bbs2
Der Link zeigt auf v0.6.6.0,
$module_name "Swift Gallery 2"
$module_directory = "swift2";
Ist also eine andere Baustelle.
Betreff v0.6
Mit ein paar Korrekturen sind Fehlermeldungen wie "Parameter must be an array or an object that implements Countable" unter php7.2 nicht mehr zu sehen.
Ob unter v7.3 Lauffähig wurde noch nicht getestet.
Es gäbe auch noch Änderungen Funktionen betreffend zu tätigen. (Z.B. sectionID wegen mehreren Modulen auf einer Seite)
Da das Teil bis dato bei "uns" funktioniert, kommt der nächste Aufschrei evtl. mit dem Wechsel zur nächsten PHP-Version.
-
Danke für die viele Hinweise.
Ich habe mal die Variabel $start generell auf 0 gesetzt.
$start=0;
Ob dies in allen Nutzungsumgebungen funktioniert kann ich leider nicht beurteilen.
Bisher läuft es bei mir fehlerfrei.
Gruß
Heinz
-
Was ist denn nun installiert, v0.6 oder v0.6.6.0?
Und "PHP Fehlerberichte: Development" unter Optionen eingestellt?
MfG. Evaki
-
Es ist 0.6 installiert.
-
Und "PHP Fehlerberichte: Development" unter Optionen eingestellt?
Falls ja, mal die Galerie im Frontend aufrufen, und dann im error-log reinschauen.
ps.Ich muß jetzt erstmal an den Backofen: Käse mit Preiselbeeren in Blätterteig. Sind schön anzusehen und schmecken!
Sehe gerade, daß jacobi22 online ist. Der kann Dir dazu viel mehr sagen als ich.
MfG. Evaki
-
Hallo,
der Hinweis im Forum auf den möglichen Fehler mit der Variable $start war wohl richtig.
Mit der festen Belegung $start=0 scheint es zu funktionieren.
Ich habe alle swift-Galleries im frontend aufgerufen. Die error-log bleibt bis jetzt leer.
Vielleicht hat jemand im Forum Interesse, das Modul, evtl. die Version Swift2, 0.66, auf den heutigen Stand zu ertüchtigen.
Meine php-Kenntnisse reichen dazu leider nicht aus. Das Modul wäre es wert.
Viele Grüße
Heinz
-
Ich stell das hier mal rein...
Auf Basis der letzt bekannten Module-Version SwiftGallery v0.6 hab ich das Modul mal neu aufgesetzt. Minimum WB-Version ist WB 2.12.0, eine zweite Version, die ebenfalls fertig ist, setzt auf die demnächst erscheinende WB 2.12.2 auf. Diese bietet u.a. andere Möglichkeiten im Dateihandling innerhalb der neuen Module.
Da diese WB-Version aber noch nicht offiziell ist, mußte ich hier noch einmal rückbauen. Die Nachfolgeversionen werden aber als Minimum WB 2.12.2 haben.
Bei den PHP-Versionen habe ich bis PHP 5.6.1 getestet, aufwärts bis PHP 7.3.1
Idee des Moduls
Mit diesem Modul können Verzeichnisse unter /media ausgelesen werden. Die ermittelten Grafiken werden in einer Galerie dargestellt, das jeweils erste Bild als großes Bild, alle weiteren als Thumbnails je nach CSS daneben oder darunter. Die Bildgrößen vom Hauptbild und den Thumbnails ist definierbar, ebenso die Anzahl der Bilder pro Seite. Möglich ist ein Galerie-Name und eine Galeriebeschreibung . Beides kann über die Moduleinstellungen ein- und ausgeschaltet werden.
Das Modul benutzt keine Third-Party-Scripte wie z.b. JQuery-Effekte
Unterschiede zur Vorgänger-Version 0.6:
- Positionen der Galerien in der Reihenfolge veränderbar - damit wäre die Menü-Darstellung weiterer Galerien in dieser Sektion veränderbar
- Möglichkeit zum Anlegen einer Bildtitelliste (kann auch als kurze Bildbeschreibung verwendet werden). Die Beschreibung erscheint im title-Attribute des großen Bildes
- Galerien können aktiv/inaktiv geschaltet werden
- das Modul legt beim Install einen Ordner "swift" unter media an, in dem neue Bilder abgelegt werden können, einen Zwang zur Nutzung gibt es aber nicht
- bei der Galeriebeschreibung wird ein Wysiwyg-Editor eingesetzt
- die Standard-Galerie kann in der Übersicht und auch in den Moduleinstellungen geändert werden
Die neue Moduleversion ist kompatibel zur Ausgangs-Version 0.6. Die vorhandenen Einstellungen werden übernommen
Zum Bild-Titel noch:
in den Gallery-Einstellungen gibt es ein Textfeld - pro Zeile ein Eintrag. Das Textfeld bezieht sich auf alle Bilder im gewählten Verzeichnis, also 100 Bilder = 100 mögliche Zeilen. Eine Leerzeile macht den Titel für dieses Bild leer - Ist dieser Bildtitel leer oder wurde überhaupt keiner angegeben, erscheint der Dateiname
Ein paar Bilder
Modulübersicht - Backend -> https://i.gyazo.com/511e2040a37e6f116e313ebd853eface.png
Galerie bearbeiten -> https://i.gyazo.com/baee10304b5d080e9dfa3f0b034dbc00.png
Galerie Einstellungen -> https://i.gyazo.com/cd5c6fef52ce1a7c2ca7ca9278b82dae.png
Frontend-Ausgabe -> https://i.gyazo.com/3408b8f31edf45f3e22d76aa0e881b9e.png
Wie gehts weiter?
Das Modul läuft z.Z. noch in ein paar privaten Test's auf verschiedenen Servern. Vergessen hab ich wohl die Absicherung auf Grafiken, war im alten Modul auch nicht drin, ist aber schnell gemacht. Nach Abschluß meiner Testerei geht es noch an ein paar andere Tester und je nach Rückmeldungen werde ich es dann zeitnah hier veröffentlichen. Wer Interesse hat, kann sich ja per PN melden. Ich bin mir zwar sicher, das alles so läuft, wie erwartet und habe mittlerweile auch schon diverse und auch komplexe Uprades gefahren, empfehle aber dennoch für den Test eine nicht öffentliche Version und keine Produktiv-Seite
Wie auch das Vorgänger-Modul, verwendet die neue Version keinerlei Fremdscripte, z.b. für JQuery-Effekte. Es kann aber, das nötige Wissen vorausgesetzt, mit wenig Aufwand und auch überschreibungssich er bei Upgrades mit wenig Aufwand erweitert werden, z.b. mit einer Colorbox.
Für Anregungen, Erweiterungsvorschl äge etc ruhig auch eine PN nutzen
-
Hallo,
ich haben heute eine neue Swift-Gallery eingestellt. Diese läuft testweise mit der neuesten view_09dev und der
save-Version vom 9.3.2019 (1a)
Im frontend und backend zeigt sich bis jetzt kein Fehler. Siehe:
https://bbsiikl.de/pages/schulleben/unterrichtsprojekt-gemeinsam-lernen/bildergalerie-gemeinsam-lernen.php?gallery_id=91&start=10
Schön wäre es, wenn die Pfadangabe je nach Wunsch deaktiviert werden könnte.
Viele Grüße
Heinz Werner
-
gehst du in view.php
zeile: echo $SWIFTTEXT['PATH'].': ',$gallery_url;
echo "<br>";
machst du
//echo $SWIFTTEXT['PATH'].': ',$gallery_url;
//echo "<br>";
färtisch
MfG. Evaki
-
Anbei für'n Test das komplette Modul: swift_gallery_v0.7. 1-dev
Wäre nicht schlecht, wenn ich damit dann "durch wäre".
Unter sql strict wurde das Modul von mir übrigens nicht getestet.
MfG. Evaki
-
Die swift_gallery_v0.7. 1-dev hat gegenüber den bisherigen Fixes noch einen korrigierten Tabelleneintrag, der den fehlerhaften Zustand nach Installation/Unnamed Gallery betrifft.
(Das betraf das an anderer Stelle erwähnte Verhalten bei Ersterstellung einer Galerie, was mich irritierte.)
Sieht so aus, als wenn der Fehler schon länger durchgeschleppt wurde, was ja nicht so selten vorkommt.
Man könnte das default Verzeichnis /media auch auf /media/swift ändern. Wäre "eleganter", weil leer. Kann ja ein Nachfolger machen, falls gewünscht...
MfG. Evaki
-
Moin, hab 2 Galerien erstellt. Fehlermeldungen vorn oder hinten nicht zu sehen. Galerien funktionieren.
Aber der Pfad bleibt nicht erhalten, nach Speichern ist er leer. Nochmaliges Speichern würde also das vorher gewählte Verzeichnis entfernen.
-
Aber der Pfad bleibt nicht erhalten
Du meinst im BE? Falls ja, hätte es m.E. sich schon in der 0.6 so verhalten. Das wäre dann etwas für die Coder, zu schauen ob das so überhaupt programmiert wurde. Hatte ich schon unter anderen Topic mal erwähnt - glaub ich wenigstens...
Aber ansonsten funktionieren die Galerien? (Bei mir zumindest schon :-D )
Nochmaliges Speichern würde also das vorher gewählte Verzeichnis entfernen.
Hat mich auch irritiert wg. Reihenfolge. Wenn, dann immer neue Galerie und dann Vergabe. Mußte mal durchprobieren. So ganz konsequent in der Handhabung scheint das nicht an jeder Stelle durchdacht zu sein, oder es ist noch'n Fehler offen - neu oder durchgeschleppt - :evil:
MfG. Evaki
-
Du meinst im BE? Falls ja, hätte es m.E. sich schon in der 0.6 so verhalten.
In einer Vorversion fiel mir das nicht auf. Aber ich würde da nicht drauf wetten.
Aber ansonsten funktionieren die Galerien? (Bei mir zumindest schon :-D )
Moin, hab 2 Galerien erstellt. Fehlermeldungen vorn oder hinten nicht zu sehen. Galerien funktionieren.
;)
Nochmaliges Speichern meint zB wenn der Galerie Titel geändert wird.
-
Nochmaliges Speichern meint zB wenn der Galerie Titel geändert wird.
Das habe ich aktuell zumindest nicht mehr gemacht, ::hu::
Meine mich aber zu erinnern, daß auch schon vorher.....
Da es nicht wirklich etwas kaputt macht, könnte man es so lassen - wenn schon auch vorher...
Manche Sachen entdeckt man erst, wenn man dran rumfummelt -ähm...
Die "eigentlichen" Funktionen - bis auf count() und ein zusätzlicher Tabelleneintrag - wurden nicht angetastet! Alles andere über "feindliche Übernahme" geregelt, also bestehende Variable in eine neue kopiert/übernommen, und damit eigenständig weitergearbeitet/ergänzt.
Hoffentlich wird jetzt kein Rattenschwanz draus.
Vielleicht kann BBS2 mal den Vergleich OLD/NEU starten.
MfG. Evaki
-
Falls nix besonderes mehr kommen sollte - hab' ich selbst noch 'ne Überraschung.
Anscheinend ist das Teil noch nie auf Sicherheit getestet worden, nun schon.
Mal schauen, ob ich dafür 'nen Fix hinbekomme. Falls nicht, werde ich 'nen DEV drum bitten.
Was nun konkret vorliegt, wird natürlich erst nach 'nem Fix bekannt gegeben.
Aber keine Panik bitte, wenn von 2006 bis heute nichts Aufregendes passiert ist...
MfG. Evaki
-
Anscheinend ist das Teil noch nie auf Sicherheit getestet worden
Da solltest du dich an unseren Sicherheitsbeauftra gten evaki wenden. Aber der macht eigentlich was er will. 8-)
-
Hab dat Dingens anscheinend gefunden.
view.php
<?php
if ($number_of_galleries>1) {
$i=0;
foreach($db_array as $gall) {
echo("<a href=\"?gallery_id={$gall['gallery_id']}\">{$gall['name']}</a>");
$i++;
if ($i<$number_of_galleries) echo(" - ");
}
}
?>
Das (echo("<a href=\"?gallery_id ) muß nach erstem Eindruck wohl mit "htmlspecialchars" gesichert werden.
Hat jemand färtisch, bevor ich färtisch?
Jo >>>>>>> Ich habe anscheinend färtisch
MfG. Evaki
-
hab eigentlich nicht mehr vor, mich da rein zu hängen und die Tips um natsort() blieben ja auch ungelesen
übergeben wird per Get die Gallery-ID und der Start-wert - beides hat Null Absicherung aktuell (hab gestern das letzte Mal in eure scripte geschaut)
aus dem Code der Vers.2.0.0.dev1, die grad im Test bei ein paar Leuten ist. Der Code müßte dann auf die Varablenamen der alten Swiftversion angepasst werden
if (isset($_GET['gallery_id']) AND is_numeric($_GET['gallery_id'])) {
$iGalleryId = (int)$_GET['gallery_id'];
} else {
$iGalleryId = $aTwigdata['settings']['default_gallery'];
}
if (isset($_GET['start']) AND is_numeric($_GET['start'])) {
$iStart = (int)$_GET['start'];
} else {
$iStart = 0;
}
-
natsort() blieben ja auch ungelesen
Nein, da irrst Du. Lokal ist das hier drin, aber mehrfach nicht übernommen worden.
Soweit ich erinnere, gab es eine Fehlermeldung wg. Klammer, wobei dann versehentlich nicht nur die Klammer weg war. Passierte komischerweise heute schon wieder. Kommt am Ende aber wieder rein !
So, nun mach ich erstmal Pause.
-
Deine Lösung bezog sich aber nicht auf mein Problem, oder?
Da wäre die modify.php der richtige Ort, denn es geht ja um das ausgewählte Verzeichnis. Dieses ist nach Speichern nicht mehr ausgewählt, weshalb nochmaliges Speichern wegen zB Änderung des Titels, ein leeres Verzeichnis speichert. Hab ich wohl schlecht ausgedrückt und war vlt. auch vorher schon so.
-
Dieses ist nach Speichern nicht mehr ausgewählt, weshalb nochmaliges Speichern wegen zB Änderung des Titels, ein leeres Verzeichnis speichert.
Genau das war mMn schon in der Vorlage so.
Wenn man aber das zum Galerienamen gehörende Verzeichnis anwählt, und dann den Titel ändert, scheint es zu funktionieren, wenn ich recht erinnere. Ist natürlich doof, wenn man dafür erst ins FE gucken muß. Das war aber genau das, was mir schon früh auffiel.
Da ich nun den Sicherheitsschei... an der Backe habe, geht das erstmal vor.
"htmlspecialchars" war ein Schnellschuß, da der mir anscheinend wg. der Konvertierung die Syntax zerhaut. Ich weiß genau, warum ich mir das php-Zeugs im "normalen" Leben nicht antue.
Mit'm Hammer und Nägel kann man ein ganzes Haus zusammenbauen. (ich weiß, mit php auch :-D :-D :-D )
-
@jacobi22
Dein Beispiel kam gerade recht, als ich merkte, daß ich direkt bei der gallery_id ansetzen muß,
- (Schlußfolgerung aus dem "ich probier das mal mit Filtern"-Schnellschuß) -
Schön, daß ich mich nun mit den Unterschieden von $_REQUEST, $_GET und $_POST beschäftigen darf, statt Schoppen zu gehen :roll:
Das Leben könnte soooo schön sein.
Da kommt noch was: Sehe soeben, daß -ich habs über request gemacht, - die XSS + injection Meldungen ausblieben. Das wichtigste scheint an dieser Stelle wohl die Verknüpfung/Bedingung (AND is_numeric) zu sein (da jaulte der Scanner) Falls die Galerie jetzt noch immer funktioniert, könnte es das gewesen sein. Nochmal 'nen kompletten Durchlauf machen.
MfG. Evaki
-
nur mal theoretisch - $REQUEST ist beides, GET und POST. Bekannt ist die Funktion der beiden Variablen, es wird die Galerie-ID und der Startwert übergeben, jeweils eine Zahl. Wir wissen weiterhin, das dies nur per GET vom Original-Script kommen kann, also macht man die POST-Tür schon mal zu, indem man kein $REQUEST nimmt.
Ohne die Festlegung auf numerisch kann jeder Wert gesendet werden, also auch eine SQL-Injection, ein Javascript usw. Diese würde aber nicht gehen ohne Buchstaben und/oder Sonderzeichen. Auf Anhieb kenn ich da keine, die so funktionieren würde.
Natürlich ließe sich auch der obige Code noch weiter optimieren, in dem man z.b. die in Frage kommenden Gallery-ID und die Range der möglichen Startwerte ausliest, dann dürfte als Beispiel gallery_id nur die Werte 1,2,4 und 5 haben (weil ich nur diese Galerien angelegt habe), nicht etwa 3 und auch nicht 6 und Start dann nur 1,11,21, 31 usw, nicht aber 32 oder 38.
Und kommt ein Wert falsch an, weil bewußt versucht, etwas anderes als das Erlaubte zu versuchen, oder fehlerhaft übermittelt, am Schluß dann die Absicherung auf die Default_Gallery-ID und den Startwert 0 bzw 1
Aber wie du oben schon sagtest, ist seit 2006 so und vom Grundprinzip arbeiten alle Module mit Seiten-Pagination ähnlich - heißt aber nicht, das es so bleiben muß ;-)
-
heißt aber nicht, das es so bleiben muß
Weshalb Du ja was neues machst, und ich "nur" versuche - man vergesse nicht, daß ich Laie bin - das 2006er-Modul an die aktuelle Umgebung anzupassen. Wobei dann immer wieder so'n büsschen Lerneffekt dabei ist. Programmieren überlaß ich sinnvollerweise denen die's können.
(Das hatte ich mal gaaaanz früher, auf 'ner komplett anderen Schiene, weshalb das Mitdenken an einigen Stellen noch fruchtbar ist. Das isses dann aber auch schon.)
MfG. Evaki
-
War das nicht gut geschrieben zum Verstehen? :wink:
War kein Vorwurf an Niemanden und auch an keinen speziellen Empfänger gerichtet. Solang das Zeugs OpenSource ist und es dementsprechend auch viele Altlasten gibt, wird man damit leben müssen, das Leute auch ihr eigenes Kram machen, auch dafür bietet WB ja ideale Voraussetzungen. Vielleicht hätte man es in den Anfangsjahren schon strenger limitieren müssen, speziell diese Sache war ja damals auch schon relevant
-
War das nicht gut geschrieben zum Verstehen?
Das ist alles so in Ordnung. (Y)
Bringt mich ja auch stückchenweise weiter, muß ich nicht jedesmal das Netz neu durchsuchen, bzw. weiß dann wo ich nachschauen muß, wenn ich weiß wo's langgeht, langgehen soll.
Besser als zig fruchtlose Verirrungen. So haben wir alles was davon.
So wie es aussieht, funktioniert der Sicherheitsfix und die Galerie funktioniert wie gehabt.
Da könnte ich ja mal auf weitere Dinge schauen :-D 8-)
1.) Es gibt 2 Notices, wenn man die Einstellungen vor dem Erstellen einer Galerie tätigt.
2.) Die fehlende Pfadangabe, die mehrmals erwähnt wurde.
Ich glaub, erstmal den Sicherheitsfix raushauen, dann 'ne Pause zum Nachdenken einlegen.
Bin ja schon froh, daß ich soweit gekommen bin.
MfG. Evaki
-
noch zur Info, ich weiß nicht, ob ich es schon geschrieben hatte - bin mit der neuen Version jetzt bei 2.0.0dev2 - da sollte dann genug Platz dazwischen sein.
Kannst ja auch noch weiter unterteilen, z.b. 0.7.145.299 oder 0.7dev1234567889
P.S.: der Heinz (bbs2) hat diese Version zum Test, ging natürlich in die Hose. War bei Strato. Weiß nicht, ob da ein Cache System oder PHP Booster aktiv sind. Lt error.log suchte er Dateien, die lt FTP aber vorhanden sind. Der Rest waren Folgefehler. Ich hab das jetzt bei 5 Anbietern laufen (u.a. strato, AllInkl, One.com) und funktionierte alles mit Ausgangsbasis 0.6 oder 0.7
-
Betrifft: XSS und sql injection
Unbedingt installieren/updaten
swift_gallery_v0.7. 2-dev-secufix01.zip
Und wenn möglich Rückmeldung, möchte keinen Schrott hinterlassen.
@jacobi22
Kannst ja auch noch weiter unterteilen
Genauso dachte ich mir das auch. Denke, daß sich das irgendwann auch von selbst erledigt, allein wg. unflexiblem Design. Wie wir wissen, halten sich Templates manchmal ganz schön lange, eben auch die von 2006 :-o , was aber manchenorts noch durchaus seine Berechtigung hat. Hatte ich mal bei 'ner Kirchensite. Da ist's halt auch gut, daß nur auf der technischen Seite "upgedatet" wird.
Gut ist ja, daß Du so umsichtig bist, und das auf mehreren recht unterschiedlichen Plattformen laufen läßt.
MfG. Evaki
-
Denke, daß sich das irgendwann auch von selbst erledigt, allein wg. unflexiblem Design. Wie wir wissen, halten sich Templates manchmal ganz schön lange, eben auch die von 2006 :-o , was aber manchenorts noch durchaus seine Berechtigung hat. Hatte ich mal bei 'ner Kirchensite. Da ist's halt auch gut, daß nur auf der technischen Seite "upgedatet" wird.
die neue Modulestruktur gibt es ja her, das dann das eigene Design nicht mehr überschrieben wird und man könnte sich auch für jede Page ein eigenes Template im Modul bauen, das dann auch im Moduleupgrade sicher ist und nicht überschrieben wird. Der Haken ist halt, das man nicht weiß, was sich der Anwender vielleicht selbst angepasst hat - aber irgendwann muß man den Schritt ins Neue mal gehen. Ist beim UTF8 genauso. Einmal umgestellt, ist erstmal Ruhe für eine lange Zeit
-
war nix. dumm gelaufen
-
So, nochmal. Da war noch'n Fehler drin.
Anbei modify.zip für die Anzeige des Pfades unter "Galerie wählen".
Der Punkt "Pfad zu den Bildern" ist tatsächlich nur zum Setzen einer Galerie gedacht/vorgesehen.
Doof, aber ist so.
Bitte testen und mitteilen, ob das als nützlich angesehen wird. Dann wird's im nächsten Paket drin sein.
MfG. Evaki
Evaki:
Da könnte ich ja mal auf weitere Dinge schauen :-D 8-)
1.) Es gibt 2 Notices, wenn man die Einstellungen vor dem Erstellen einer Galerie tätigt.
2.) Die fehlende Pfadangabe, die mehrmals erwähnt wurde.
Punkt 2 wäre damit erledigt
Punkt 1 tritt jederzeit unter "Einstellungen" auf
Hoffe, daß ich dafür noch Zeit (hier, gibt ja auch noch anderes...) bekomme.
-
Mach mal deine letzten Änderungen wegen dem Pfad rückgängig und ändere nur in Zeile 121 zweimal <? zu <?php
Dann wird der Pfad bzw. das Verzeichnis angezeigt.
-
Ich häng dir mal 2 Dateien ran. settings.php & backend.css
Der Validator sagte da sind ungeschlossene Divs und ein streunendes end form.
Bereinigt, obwohl ich nicht verstehe wie da die end divs fehlen können.
Außerdem Tannebaumansicht, also die Werte nicht am rechten Rand, sondern links bei den labels.
-
da fehlt der settings ein print_footer(), deshalb macht er die in der admin/pages/modify.php geöffneten Div's nicht zu
sieht man besonders im Quelltext, der nach der settings abbricht, aber auch im Backend am fehlenden Footer
am Schluß der settings.php diese Zeilen
<?php
if ($print_info_banner) { ?>
<?php
}
// Print admin footer
$admin->print_footer();
ein Tipfehler war noch in Zeile 96 - Leerzeichen vor styles
<td class="setting_name"style="width: 30%;">
das schließende </form> aus Zeile 124 dann hinter das Ende des </table> in Zeile 131, aber das war ja schon in der zuletzt geposteten Datei.
Die drei eingefügten div gehören da aber nicht rein
-
Guten Morgen.
Hat also doch noch'n Rattenschwanz.
Alles Dinge, die nicht überprüft wurden, oder auch zum aktuellen Zeitpunkt nicht überprüft werden konnten.
Vielleicht braucht es bei alten oder generell bei Modulen eine andere Strategie, wenn Updates anstehen.
Nämlich zuerst auf alles mögliche wie html und Logik prüfen, bevor man sich den eigentlichen - gemeldeten - Fehlern zuwendet.
Das würde dem entsprechen, was ich sonst bei html- und Serverchecks auch mache.
Apropos Logik, die kann ich selbst nur an einzelnen und wenigen Stellen nachvollziehen, weshalb dies das Feld für die Programmierer sein/bleiben sollte. Denn wie man hier gut sehen konnte, führt dies zu Fehlinterpretatione n bzw. falschen Schlüssen, wenn man ohne solide Kenntnisse herangeht. Hatte hier nicht die Notwendigkeit gesehen, die Scripte einem Codecheck (Tool) zu unterziehen, was ich schon allein wg. drohender Überforderung äußerst selten mache. Tja, und scheinbar war ja alles auch in Ordnung.
Kurz gesagt, ohne Zutun aus der Programmierecke würde ich jetzt feststecken.
Aus unserem Anwenderkreis konnte auch nicht mehr kommen, wie man jetzt feststellen kann; sind ja auch alles Laien, wenn auch mit - Danke sei wem auch immer - viel Phantasie.
MfG. Evaki
-
Zeitlimit hatte zugeschlagen
....auch alles Laien, wenn auch mit - Dank sei wem auch immer - viel Phantasie.
Schön, daß es bei diesem Teil nun doch zu einem Abschluß kommen kann.
MfG. Evaki
-
Mach mal deine letzten Änderungen wegen dem Pfad rückgängig und ändere nur in Zeile 121 zweimal <? zu <?php
Dann wird der Pfad bzw. das Verzeichnis angezeigt.
Hat bei mir (noch) nix gebracht. Werde es aber im Laufe dea Tages nochmal komplett neu installieren.
Außerdem habe ich den Eindruck, daß da was (settings) durcheinander gerät, wie z.B.
v01.) if ($print_info_banner) {
v02.) class="w3-btn w3-blue-wb"
Hab' nun $admin->print_footer(); aus 01 übernommen, ohne if ($print_info_banner) {
MfG. Evaki
-
Es gibt aber noch ein dringliches Anliegen.
Hat man das (egal ob altes oder neues ) Modul und noch keine Gallerie installiert , werden bei Eingabe von z.B. http://localhost/4-seite.php?gallery_id=1 die Dateien in root (localhost/) gelistet. Sowas meldet kein Scanner :evil:
Bevor ich mir nun wieder den Wolf suche, und möglicherweise nur Rotkäpchen finde, hätt' ich für 'ne Lösung ein offenes Ohr.
MfG. Evaki
ps. falls das mit der "Pfadgeschichte" nicht aufgeht, lege ich zumindest 'ne alternative modify bei.
-
Es muss durcheinanderkommen, wenn jeder eine settings.php postet.
Du könntest es aber auseinanderfummeln bzw. die jeweiligen Änderungen erkennen.
ZB bei meiner settings die letzten drei div entfernen und dafür jacobis admin print footer nehmen.
Alles andere hatte ich schon gemacht. Mit der backend.css sollte es dann (nur) dort gut aussehen.
v02.) class="w3-btn w3-blue-wb"
Die Klassen machen blaue Buttons. Kannst du beide weglassen.
-
drei div entfernen und dafür jacobis admin print footer nehmen.
Habe soeben mal reingeschaut v.0.7.xxx, ist so auch drin :lol:
Am "alten Aussehen" soll bei der "alten" Version auch nix mehr geändert werden.
Jacobi überarbeitet auch das ja mit seiner neuen.
-
Es gibt aber noch ein dringliches Anliegen.
Hat man das (egal ob altes oder neues ) Modul und noch keine Gallerie installiert , werden bei Eingabe von z.B. http://localhost/4-seite.php?gallery_id=1 die Dateien in root (localhost/) gelistet. Sowas meldet kein Scanner
Hatte ich auch schon mal auf Seite 1 erwähnt:
Habe in der Adresszeile mal eine gallery_id eingegeben, die es nicht gibt. Da zeigt er statt einer Galerie die URL zum WB upgrade-script.
edit: jacobi hatte dafür ja einen Lösungsansatz glaube. Wenn ID nicht vorhanden, schicke zur ersten vorhandenen o.ä..
-
Falls das im Zusammenhang mit der XSS/SQL inject.-Prävention stand, gucke ich mir das nochmal an.
Unter diesem Aspekt hatte ich es zu diesem Zeitpunkt nicht gesehen.
ps. Jetzt hamwer hier bei uns auch 'ne Bezeichnung für das Codeschnippeln gefunden:
"Betreutes Basteln"
MfG. Evaki
-
ich verstehe zwar den Sinn dieser Aktion hier nicht mehr, aber egal
Hat man das (egal ob altes oder neues ) Modul und noch keine Gallerie installiert , werden bei Eingabe von z.B. http://localhost/4-seite.php?gallery_id=1 die Dateien in root (localhost/) gelistet
Zur Erklärung (sämtlicher Code basiert auf vers 0.7.2
view php
$get_content = $database->query("SELECT path,name,description FROM ".TABLE_PREFIX."mod_swift WHERE gallery_id = '".$_REQUEST['gallery_id']."'");
$this_gallery=$get_content->fetchRow();
$gallery_id=$_REQUEST['gallery_id'];
$gallery='/'.$this_gallery['path'];
$gallery wäre der Pfad. Wurde er gesetzt, steht mindestens /media drin, ansonsten mindestens ein / - damit in keinem Fall leer und dieser Code hier wäre wirkungslos
if (!empty($gallery)) {
echo '';
}
else {
$gallery = ' ';
}
ein paar Zeilen tiefer
$gallery_path=WB_PATH.$gallery;
$gallery ist nun leer bzw ein /, es bleibt also das Rootverzeichnis über und die nachfolgende Abfrage ist ebenfalls gültig, da der Pfad zum Root ja existiert
if( is_dir( $gallery_path ) ) {
wenn du das verhindern willst, gäbe es zahlreiche Möglichkeiten, eine wäre z.b. diese Zeile hier als Ergebnis aus obiger Abfrage (immernoch mit REQUEST :-o )
$gallery_id=$_REQUEST['gallery_id'];Verwendest du hier statt der übergebenen ID die aus dem Abfrageergebnis, könnte man die weiteren Dinge an diese ID koppeln, z.b. Abfragen, ob ein numerischer Wert und ob er größer Null ist
Eine andere Möglichkeit wäre es, alle weiteren Anfragen an das Ergebnis der Zählung etwas weiter oben zu koppeln, dann kommst du aber in die gleiche Falle bei einer ungültigen ID, also wenn wohl Galerien angelegt wurden, die übermittelte ID aber nicht dabei ist
bei mir läuft der Spass so
$sql = 'SELECT * FROM `'.TABLE_PREFIX.'mod_swift` '
. 'WHERE `section_id` = '.$iSectionId.' '
. 'AND `gallery_id` = '.$iGalleryId.' '
. 'AND `active` = 1 '
. '';
if (($oGalleryItem = $oDb->query($sql))) {
$iLastGalleryId = 0;
while($aGalleryItem = $oGalleryItem->fetchRow(MYSQLI_ASSOC)) {
der Wichtige Punkt ist die 3. Zeile von unten - auf "deutsch": es geht nur weiter im Code, wenn obige Abfrage ein gültiges Ergebnis liefert. Innerhalb dieses If erfolgt meine komplette Output-Generierung. Wäre das Ergebnis hier ein false (also nix), wird ein leerer Array übergeben - ist somit die sicherste Methode
-
ich verstehe zwar den Sinn dieser Aktion hier nicht mehr, aber egal
Jetzt sind wir genau an dem Punkt wo wir wiederholt waren.
Da wirkst Du nur noch demotivierend auf Menschen, die sich mit WB und Code beschäftigen wollen.
Ich selbst mach das nicht zur persönlichen Freude, wie bekannt, sondern weil ich entsprechende Anfragen bekam.
Das war von meiner Seite das letzte Engagement.
Anfragen und Antworten reiche ich ab sofort nur noch ans Forum weiter, und ansonsten halte ich mich raus. Möglich auch, daß sich jemand aus der Gruppe einen Account holt.
MfG. Evaki
-
Ganz vergessen. "Natürlich trotzdem einen großen Dank für die Erläuterungen" (Y)
Soweit ich erinnere, war
if (!empty($gallery)) {
echo '';
}
else {
$gallery = ' ';
}nur dazu gedacht, einer der ersten php-Warnungen zu beseitigen, also zu sonst nix. Zu diesem Zeitpunkt dachte noch niemand an den folgenden Rattenschwanz.
MfG. Evaki
-
ach Evaki
Punkt 1 - es ist völlig ausreichend, wenn du weißt, warum du das machst - ich muß es nicht verstehen
Punkt 2 - auch, wenn ich dir privat auf Grund unserer diversen früheren Dispute eher aus dem Wege gehen würde, es wurden in vernünftiger Art diverse Fragen gestellt und ich habe versucht, diese zu beantworten, zu erklären und mein Wissen zu teilen - nicht nur für dich, sondern für alle, die irgendwo am Code schrauben. Mein heutiges Wissen kommt ja überwiegend auch aus Foren wie stackoverflow usw
Punkt 3 - im Normalfall sollte sich doch jeder über eine neu aufgesetzte Version freuen. Ich habe vor ein paar Tagen mitgeteilt, das die neue Version fertig ist und bei ein paar Leuten zum Test ist. Es wurden Fehler gemeldet, es wurde korrigiert und wieder getestet. Es wurden kleine Installationen upgedated und auch komplexe auf Testseiten und in Public-Projekten. Bisher waren es nur kleine Sachen, die entdeckt wurden, eine falsche CSS-Klasse, ein versehentlich auskommentierter Link und heute, nach dem 4.Tag mal ein "echtes" Problem - eine erste angelegte Galerie wurde nicht automatisch zur Default_Gallery, na gut, gibt es eine neue Version - kein Beinbruch
Da gibt es also Aussichten auf eine neue Modulversion, eine, die auf absehbare Zeit funktionssicher ist, eine, die auch den heutigen Sicherheitsanforder ungen entspricht. Wie angekündigt, wird das Modul in der Frontenddarstellung nicht vom alten in den Nuller-Versionen abweichen, alte Einstellungen werden übernommen. Ein Besucher sieht keinen Unterschied in der Ausgabe. Dazu kommt, das ich mit den neueren WB-Versionen ein für openSouce-CMS sehr sicheres System habe, warum sollte ich mit diversen Alt-Modulen nun wieder Tür und Tor öffnen, wenn da etwas Neueres, Sicheres in Aussicht steht? Wie gesagt, ich würde es schon gern verstehen, warum man dann auf etwas Altes setzt, dem man schon ansieht, aus welcher Zeitepoche es kommt. Von tatsächlichem Aufwand, der nötig ist, um das Modul von Ausgangsversion 0.6 auf den innerhalb des CMS mittlerweile üblichen sicherheits-technischen und auch Code-technischen Standard zu heben, wären mit vers 0.7.2 (ich sag mal) vielleicht 30% geschafft. Es ist ja nicht nur die view.php, die nach außen abgesichert werden muß. Die meisten Angriffe kommen ja durch Backend-User, dort ist so gut wie keine Absicherung vorhanden, war es nie und ist in vielen Modulen aus dieser Zeit zumindest ähnlich.
Das eigentlich Gefährliche ist dann, das Forumsbesucher den neuesten Thread sehen - oh - ein secureFix für die swiftgallery, installier ich sofort und hab wieder Ruhe für 10 Jahre. Sicherlich sind es im Vergleich zu Vers 0.6 schon ein paar Schritte vorwärts, aber wir kennen doch die Updatemüdigkeit. Ein paar Beiträge weiter oben in der Forumsliste wundert sich jemand, das eine WB 2.8.3 1611 nun nicht mehr läuft und selbst das Update auf 2.8.3 SP4 brachte keine Verbesserung. Ich weiß, er hat über 10.000 Seiten in diesem Projekt und ich verstehe die Ängste, aber ist es nicht schlimmer, wenn gerade solch Projekt dann auf Schlag nicht mehr benutzbar ist? Grundsätzlich kann ich da nur den Kopf schütteln, schließlich haben viele der User, die sich heute wegen Problemen in ihrer alten WB-Version gemeldet haben, bewußt oder unbewußt mit ihren Postings am neuen, sicheren und modernerem WB mitgearbeitet.
Du hast dich hier (wie auch bei diversen anderen Modulen) sehr engagiert und ich weiß ja auch aus deinen Schilderungen in der Vergangenheit, das in eurem Anwenderkreis Bedenken bestehen zu Upgrades, aber wenn du mal einen Schritt zurück trittst und die Arbeiten an den Versionen 0.6 und 0.7 nicht als Autor, sondern als potentieller User betrachtest, wäre dann nicht eine neu aufgesetzte Version, in der auch die Sicherheit passt, die bessere Lösung?
Gerade bei eurem Anwenderkreis gibt es doch ein, wie ich annehme, großes Potential für Upgrades von Modulen oder System und wenn da Bedarf ist oder jemand Angst hat, solch Upgrade durchzuführen, darfst du meine EMailadresse gern weiter geben.
P.S.: früher gab es einen geschlossenen Bereich für solche Diskussionen, nicht-öffentlich. Mir ist schon bewußt, das auch meine Beanstandungen Ängste hervorrufen, wenn man Angriffsmöglichkeit en aufzeigt
Natürlich trotzdem einen großen Dank für die Erläuterungen
gern geschehen und auch gerne wieder
-
wäre dann nicht eine neu aufgesetzte Version, in der auch die Sicherheit passt, die bessere Lösung?
Das ist sie, unbenommen!
Hier gehts aber um etwas anderes, nämlich einen pädagogischen Nebeneffekt.
Auch wenn nicht nur aus IT'ler-Sicht diese Bastelei vollkommen ineffizient ist, hier geht's um Annäherung.
In der Beschäftigung mit auftretenden Problemen (Ergeignisse), wenn diese z.B. - wohlgemerkt - in kleinen bearbeitbaren Blöcken und in der Gesamtlogik zuortenbar daherkommen, ist die Merkfähigkeit für eine vorausschaubare bzw. kalkulierbare Zeit erhöht. Über die Zeit läppert's sich... Falls jemand sich dann für weitergehendes interessiert, ist er bestens gerüstet, auch wenn's keine berufliche Entscheidung mit sich bringen mag.
Unsere Laien haben daher schon öfter Fragen aufgeworfen, auf die sie ohne diese Erfahrungen nie gekommen wären. Die sind eigentlich nur Nutzer/Schreiber/Fotografen usw., haben aber öfter die Erfahrung machen müssen, daß nicht nur jeder Schei.. golden glänzt, sondern es nützlich sein kann genauer hinzuschauen. Das sollte ihnen nicht genommen werden. Könnte ja auch sein, daß sich jemand für WB-Entwicklung interessiert. Das brauchste nicht, gibt bald neu, ist da nicht so der richtige Ansatz in diesem Zusammenhang :?
MfG. Evaki
-
Das ist die Erklärung und nun verstehe ich es auch
Dankeschön! (Y)
-
Ein schöner Heise-Artikel (http://) zum Thema unterschiedlicher Kulturen und Herangehensweise in der Arbeitswelt, wenn auch auf berufliche Ebene und Firmenstruktur bezogen.
Das gleiche Thema existiert auch in der Arbeitskultur (Projekte) an Hochschulen, speziell dort wo sich Teams bilden. Kann man wahrscheinlich überall dort fortführen, wo Spezialisten nicht nur beruflich miteinander kooperieren müssen. - So zum Mars fliegen un so z.B.
MfG. Evaki