in dem patch geht es nur um schönheits fehler
Falsch. Es wurden u.a. auch "PHP Fatal Errors" behoben. die zu einem Abbruch der Ausführung führen. Einfach mal das Errata lesen bevor man soetwas behauptet.
in dem patch geht es nur um schönheits fehler
Falsch. Es wurden u.a. auch "PHP Fatal Errors" behoben. die zu einem Abbruch der Ausführung führen. Einfach mal das Errata lesen bevor man soetwas behauptet.
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:
In der ersten Mitteilung wird die Anwendung des Patchs beschrieben.
Korrekturen:
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
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.
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.
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:
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:
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:
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:
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:
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
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:
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:
Damit werden auch jetzt schon Gruppen angezeigt.
Dann nutzt Du entweder ein altes Apache-System, einen anderen Webserver, oder das Modul access_compat, das die Kompatibilität mit der alten Syntax herstellt.
Daher ist alles Ok.
Wenn ich den ADMIN-Bereich aufrufe, dann erscheint die folgende Fehlermeldung im error log:
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:
Gottseidank ist es nicht so schlimm, da man trotzdem das Admin-Interface erreicht. Muss wohl etwas eingebettetes sein.
Muss ich was machen wenn bei mir alles funktioniert?
Greif auf https://DOMAIN/backup zu und schaue dir das Ergebnis an. Fehler 500 zeugt von einem Syntax-Error.
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:
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:
Backup-Problem gefunden und gelöst: Cronjob DB Backup hängt
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:
Korrektur (2 Backticks ergänzt):
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