Swift-Gallery

[evaki]

Ein schöner Heise-Artikel 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

[Gast]

Das ist die Erklärung und nun verstehe ich es auch

Dankeschön! 

[evaki]

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

[Gast]

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 Sicherheitsanforderungen 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öglichkeiten aufzeigt

Natürlich trotzdem einen großen Dank für die Erläuterungen

gern geschehen und auch gerne wieder

[evaki]

Ganz vergessen. "Natürlich trotzdem einen großen Dank für die Erläuterungen" 
Soweit ich erinnere, war

Code Select Expand

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

[evaki]

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

[Gast]

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

Code Select Expand

$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

Code Select Expand

if (!empty($gallery)) {
echo '';
}
else {
$gallery = ' ';
}

ein paar Zeilen tiefer

Code Select Expand

$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

Code Select Expand

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  )

Code Select Expand

$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

Code Select Expand

$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

[evaki]

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

[dbs]

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.ä..

[evaki]

drei div entfernen und dafür jacobis admin print footer nehmen.

Habe soeben mal reingeschaut v.0.7.xxx, ist so auch drin 

Am "alten Aussehen" soll bei der "alten" Version auch nix mehr geändert werden.
Jacobi überarbeitet auch das ja mit seiner neuen.

[dbs]

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.

[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 

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.

[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

[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

[evaki]

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 Fehlinterpretationen 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

[Gast]

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

Code Select Expand

<?php
if ($print_info_banner) { ?>
<?php
}

// Print admin footer
$admin->print_footer();

ein Tipfehler war noch in Zeile 96 - Leerzeichen vor styles

Code Select Expand

<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

[dbs]

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.

[dbs]

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.

[evaki]

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   
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.

[evaki]

war nix. dumm gelaufen

[Gast]

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  , 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

[evaki]

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  , 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

[Gast]

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

[evaki]

War das nicht gut geschrieben zum Verstehen?

Das ist alles so in Ordnung. 
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   
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

[Gast]

War das nicht gut geschrieben zum Verstehen?   

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