Beiträge von Wiimm

Ich habe einen Blog Artikel verfasst - Wie benutze ich die Suche richtig - Bitte diesen beachten und auch umsetzen bevor Ihr ein Neues Thema eröffnet!

    Jetzt nur zu sagen“ muss man nicht“ passt irgendwie nicht, zumindest für mich…

    Passt schon, wenn man es historisch sieht. Schon vor Jahren war er erbost darüber, dass ich ich Sichherheitslücken festgestellt und dazu einen Fix bereit gestellt hatte. Seitdem ist für ihn alles, was ich mache, einfach nur "Bäh",

    Es gibt 2 Patch-Dateien:

    • Datei patch.2.txt ist für alle, die bereits meinen ersten Patch (siehe erste Mitteilung) eingespielt haben.
    • Datei patch.1-2.txt enthälte den ersten und den neuen (zweiten) Patch in einer Datei.

    In der ersten Mitteilung wird die Anwendung des Patchs beschrieben.



    Korrekturen:

    • Wichtiger Patch übernommen.
    • Ranglisten-Update (Datei rangliste.dep.php). Ich finde im Moment nicht das Thema. Das Update habe ich auch für Mobil angepasst.
    • Mehrere "PHP Fatal Error" gelöst.
    • Kleine Optimierung bei der Abfrage des Team-Namens: Weniger Datenbankabfragen und damit schneller.
    • Einen Ajax-Bug behoben.
    • 2 Typos in .htaccess korrigiert.


    Betroffene Dateien:

    * backup/.htaccess

    * content/admin.spiele.php

    * content/rangliste.dep.php

    * content/statistik.spiel.php

    * content/tippen.gruppen.php

    * include/inc.functions.php

    * m/backup/.htaccess

    * m/content/rangliste.dep.php

    * m/content/statistik.spiel.php

    * m/content/tippen.gruppen.php

    * xajax/xajax_core/xajaxResponse.inc.php

    Dateien

    • patch.1-2.txt

      (28,29 kB, 11 Mal heruntergeladen, zuletzt: )
    • patch.2.txt

      (18,68 kB, 3 Mal heruntergeladen, zuletzt: )

    Die Art und Weise der Korrekturen hier verlangt eine strikte Übereinstimmung der Ausgangsdateien von WIIMM und euren eigenen Dateien.

    Wegen der Art als Patch ist dieses gerade eben die Übereinstimmung nicht nötig. Eigene Änderungen bleiben so erhalten. Um diese Patches zu liefern habe ich ich mehrere Version des Tippspiels.

    1. Das Original von xcript.de
    2. Meine Version mit privaten und öffentlichen Anpassungen
    3. Eine Zwischenversion mit nur privaten Anpassungen

    Nur so kann ich dann einen Patch ziehen, der nur öffentlichen Anpassungen enthält. (diff -ru version3 version2).


    Bei einer vollständigen Datei würden alle privaten Änderungen von Dritten überschrieben werden.


    Der Nachteil des Patches ist allerdings, dass man auf Kommandozeile arbeiten muss und es für viele merkwürdig aussieht. Zur Beruhigung sollte man aber wissen, das z.B. SVN oder GIT mit genau dieser Art von Patches im Hintergrund arbeiten. Es ist halt ein sehr ausgereiftes Verfahren mir Jahrzehnte langer Erprobung.

    @Kassi

    Das war mir auch aufgefallen. Wieso $RUNTIME['PATH'][4] == 0 ist kann ich nicht sagen. Ich tippe immer mal wieder wild durch die Oberfläche um Auffälligkeiten im Log zu finden.


    Meine Lösung: Anstatt $begin verwende ich nun max(0,$begin), und das an 4 Stellen.

    Für alle interessierten wird heute ein Patch von mir erscheinen. In den letzten Tagen hatte ich zu viel mit anderen Projekten zu tun,

    Du zitierst diesen Satz von mir ...

    Ich bin ja jemand, der auch Fehlerkorrekturen bereitstellt.

    ... und forderst mich dann auf Fehlerkorrekturen bereitzustellen:

    Dann wäre es besser gewesen statt Oberlehrerhaft mit dem Finger auf die zu zeigen die in ihrer Freizeit versucht haben hier für die User auch dieses Jahr ein Tippspiel bereitzustellen, diese ach so schlimmen Fehler zu beheben und diese dann für alle

    bereitzustellen.

    Es sieht so aus, als b Du noch nicht einmal das von die zitierte gelesen und verstanden hast. Vielleicht verwendest Du mal die Suche, um ein jüngstes Thema von mir zu finden, indem ich 15 Patches für 13 Dateien zu Verfügung stelle, sowohl für Standard als auch für Mobil. Dann merkst Du vielleicht, dass Du dich mit der Antwort vertan hast.


    Weitere Klarstellungen:

    • Ich habe nicht mit dem Finger auf jemanden gezeigt.
    • Seit Jahren liefere Ich Updates und Korrekturen, die meist auch sofort oder im Nachgang in die Software aufgenommen wurden. Dabei waren auch sicherheitskritische Korrekturen.
    • Schau die doch mal Updates/Korrekturen diverser Nutzer (auch Hauptentwickler) an, Da gibt es nicht wenige, die nur den Standardzweig behandeln, aber den Mobil-Zweig ignorieren. Vor Jahren wurden meine Sicherheitskorrekturen (anfangs?) auch nur im Standardbereich korrigiert.
    • Immer wieder gibt es Themen, die sagen: Standard funzt, aber Mobil nicht.
    • Wenn ich Korrekturen vom Standardzweig (in dem ich teste) in den Mobilzweig übernehme, dann stelle ich immer wieder fest, dass sich beide Zweige semantisch unterscheiden -- in manchen Jahren mehr, dieses Jahr ist mir weniger aufgefallen. Und dann kann ich die Korrekturen nicht übernehmen.

    Zusammenfassung:

    Ich tue genau das, was Du forderst: Updates bereitstellen.

    Aber das, was Du mir unterstellst, tue ich gerade nicht.


    Wenn Du meinen Beitrag richtig gelesen hättest, wäre es dir aufgefallen.

    Ich bin ja jemand, der auch Fehlerkorrekturen bereitstellt. Ich versuche immer die Fehler in der Standard-Version und in der mobilen Version zu beheben. Dabei treffe ich immer wieder auf Codestellen, die eine unterschiedliche Semantik haben. Häufig sieht es so aus, als ob wichtige Updates und Korrekturen nur in den Hauptzweig eingeflossen sind, nicht aber in die mobile Version. Das habe ich schon vor Jahren bemerkt. Bestätigt wird dieses auch durch diverse Updates, die nur den Hauptzweig ändern, und durch Beschwerden das dies und jenes nicht Mobil funktioniert.


    Daher deaktiviere ich seit Jahren die Mobile Version.

    Dieses ist auch meine Empfehlung für alle!


    Wie deaktiviert man möglichst einfach die Mobile Version?

    Dazu muss man nur die Erkennung eines Mobil-Gerätes unterbinden. Dafür habe ich 2 Edits in der Datei clsMobileDetection.php vorgenommen:

    Code
    1. # Zeile 107:
    2. private function detectMobileAgent() {
    3. return; // deactivate mobile variant, by Wiimm
    4. # Zeile 150
    5. public function IsMobile() {
    6. return false; // deactivate mobile variant, by Wiimm

    Es wird in den nächsten Tagen (wenn ich es schaffe: heute Abend) noch ein weiteres Update (als Patch) von mir kommen. Neben ein paar Kleinigkeiten, die ich bereits korrigiert habe, ist mit gerade eben der nächste "Fatal error" nach einem DB-Abfrage.Fehler ausgefallen.


    Nach dem Update auf v1.0.3 habe ich in meinem System diverse Änderungen vorgenommen. Einige sind bereits in anderen Themen publiziert worden. Und hiermit stelle ich meine Korrekturen seit Update auf v1.0.3 zur Verfügung.

    Errata:

    • Probleme mit FATAL-ERROR aufgrund von Fehlerhaften DB-Abfragen gelöst (if (...) eingefügt).
    • Tabellenname "lastSearch" in "lastsearch" umbenannt, um Großschreibungs-Probleme zu umgehen. Dieses ist nur für diejenigen relevant, bei denen lower_case_table_names auf 0 steht. Test mit mysql -e 'show global variables like "lower_case_tab%"'.
    • 1x $wmtippstyle durch $emtippstyle ersetzt.
    • Mehrfach $row77[date] durch $row77['date'] ersetzt.
    • Die Gruppenanzeige aktiviert.
    • Dateien .htaccess geändert, so dass sie auch auf modernen Apache-Systemen ohne Kompatibilitäts-Modus funktionieren.


    Nach den Änderungen habe ich in meinem Error-Log nur noch "PHP Notices" gesehen, meist "Undefined offset" oder "Undefined index".


    Hier findet ihr den Patch dazu. Genaugenomen richtet er sich an das Entwicklerteam. Aber für Leute, die ihre eigenen Modifikationen haben, ist die Verwendung der Patch-Datei einfacher/sinnvoller. Hierzu ist die Kommandozeile (Anmeldung mit ssh) nötig. Alternativ geht auch: Mittels FTP alle Dateien auf eigene System kopieren, den Patch ausführen und dann alle Dateien zurück kopieren. In beiden Varianten muss das Patch-Kommando verfügbar sein.


    Zur Ausführung die Datei patch.txt ins Basisverzeichnis kopieren und dort das folgende Kommando ausführen:

    Code
    1. patch --dry-run -p1 < patch.txt

    Wegen der Option --dry-run findet nur ein Test-Lauf statt, ohne dass eine Datei geändert wird. Der Lauf ist perfekt, wenn nur "checking" Zeilen ausgegeben werden. Alle Rückfragen mit RETURN (also dem Standardwert) beantworten. Zu diesen Rückfragen kommt es u.a., wenn ihr bereits Teile angepasst habt.

    Danach kann man den folgenden Befehl zum tatsächlichen Patchen nutzen:

    Code
    1. patch -p1 < patch.txt



    Zum Abschluss folgt eine Liste der veränderten Dateien:
    * backup/.htaccess
    * content/admin.info.php
    * content/admin.spiele.php
    * content/gruppen.content.php
    * content/rangliste.custom.php
    * content/rangliste.dep.php
    * content/tippen.bonuswetten.php
    * include/inc.backup.mysql.php
    * m/backup/.htaccess
    * m/content/admin.spiele.php
    * m/content/rangliste.custom.php
    * m/content/rangliste.dep.php
    * m/content/tippen.bonuswetten.php

    Dateien

    • patch.txt

      (11,54 kB, 24 Mal heruntergeladen, zuletzt: )

    Ich habe noch ein wenig gespielt. Ist das Modul mod_authz_core.c geladen, dann sind die modernen Kommandos wie Require ... möglich. Ist zusätzlich das Modul mod_access_compat.c geladen, dann ist zusätzlich das alte Order ... möglich; man kann aber auch weiterhin Require ... verwenden. Damit vereinfacht sich ein überall gültiges .htaccess wir folgt:

    Code
    1. # If module mod_authz_core.c is avaialble, then use new authorization command.
    2. # Compare https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html
    3. <IfModule mod_authz_core.c>
    4. Require all denied
    5. </IfModule>
    6. <IfModule !mod_authz_core.c>
    7. Order allow,deny
    8. </IfModule>

    Ich habe mir mal das folgende bash Script set-password.sh geschrieben:

    Man muss ganz oben den DB-Namen anpassen.

    Der Aufruf ist dann: ./set-password.sh BENUTZERNAME KENNWORT

    Bugfix als Patch, Datei content/rangliste.dep.php Zeile 61:

    Diff
    1. @@ -58,7 +58,7 @@
    2. " WHERE u.department <> 'privat' AND u.department <> 'ohne Gruppe' AND isUnlocked = '1' AND t.active = '1'".
    3. " GROUP BY u.department");
    4. $i = 0;
    5. -$deprl = "";
    6. +$deprl = array();
    7. while ($ar_dep = $sql_dep->fetch_array())
    8. {
    9. if ($ar_dep['ctdep'] > 1) {

    Damit werden auch jetzt schon Gruppen angezeigt.

    Die einzige Änderung in css/style-EM2020.php seit v1.0.1 bis v1.0.3:

    Diff
    1. /*** Position des EM-Counters ***/
    2. .counterposition {
    3. - margin: -87px 0px 0px 830px;
    4. + margin: -87px 0px 0px 790px;
    5. position: absolute;
    6. }

    Wenn ich den ADMIN-Bereich aufrufe, dann erscheint die folgende Fehlermeldung im error log:

    Code
    1. 07 08:58:21 --------------------------------
    2. 07 08:58:21 01: SELECT s.id,s.date,s.heim,s.gast FROM emtipp_spiele as s WHERE ORDER BY date ASC
    3. 07 08:58:21 error #1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'ORDER BY date ASC' at line 1
    4. 07 08:58:21 --------------------------------
    5. 07 08:58:21 > GLOBAL @.../index.php #1214
    6. 07 08:58:21 >> createSiteContent() @.../include/inc.content.php #167
    7. 07 08:58:21 >> include() @.../content/admin.spiele.php #243
    8. 07 08:58:21 --------------------------------

    Diese Art Fehlermeldung kommt nur, weil ich die Klasse mysqli erweitert habe. Offensichtlich ist die WHERE-Anweisung leer. Der untere Teil zeigt die Aufrufliste.


    Da das Ergebnis nicht überprüft wird, kommt es zu einem FATAL-ERROR:

    Code
    1. 07 08:58:21 PHP Fatal error: Uncaught Error: Call to a member function fetch_array() on boolean in .../content/admin.spiele.php:245\nStack trace:\n#0 .../include/inc.content.php(167): include()\n#1 .../index.php(1214): createSiteContent()\n#2 {main}\n thrown in .../content/admin.spiele.php on line 245

    Gottseidank ist es nicht so schlimm, da man trotzdem das Admin-Interface erreicht. Muss wohl etwas eingebettetes sein.

    Unter backup/ und m/backup/ gibt es jeweils eine .htaccess. Gestern beim Suchen nach dem Backup-Fehler war mir aufgefallen, dass die Dateien die folgende Zeile enthalten, um den Zugriff zu verbieten:

    Code
    1. Order allow,deny


    Leider ist es die alte Syntax, die schon seit Jahren zu einem "Invalid command" in Apache führt, wenn das Apache-Modul access_compat nicht verwendet wird.. Daher habe ich eine Alternative erstellt. Sie untersucht die geladenen Module und sollte daher bei alten und neuen Apache-Servern funktionieren. "Sollte", weil ich es nur minimal getestet habe:


    Der Fehler tritt auf, wenn man mit Sonderzeichen (z.B. Minuszeichen) im Datenbanknamen arbeitet.


    Bugfix:

    Datei: include/inc.backup.mysql.php

    Funktion: backup_database() Zelle 85


    Vorher:

    Code
    1. $result = $CONFIG['MYSQL']['CONNECT']->query("SHOW TABLES IN " . $CONFIG['MYSQL']['DATENBANK'].);


    Korrektur (2 Backticks ergänzt):

    Code
    1. $result = $CONFIG['MYSQL']['CONNECT']->query("SHOW TABLES IN `" . $CONFIG['MYSQL']['DATENBANK']."`");

    gzip ist ein einfaches und damit schnelles Komprimier-Verfahren, mit dem sich auch Streams komprimieren lassen. Signalisiert der Browser seine GZIP-Fähigkeit, dann darf der Server Dateien entsprechend komprimieren. Normalerweise aktiviert man die Kompression bei Textdateien. Hier kann die Datei auf 10% verkleinert werden (90%) Ersparnis. Das schont die Datenbelastung und Übertragungszeit insbesondere bei mobilen Tarifen.


    Bei Apache sieht es z.B. so aus:

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript