vBulletin Hacking Verbrechen

[Andreas]

Das sind meine persönlichen Highlights, von denen ich jedem nur wärmstens ans Herz legen kann Sie zu unterlassen


HTML in PHP-Scripten
Total übel wenn man eigene Styles verwendet.
Ist auch total unübersichtlich wenn Code und Daten so vermischt sind
Hardcodierte Texte in Scripten oder Templates
Läuft auf das gleiche hinaus wie HTML
Erschwert die Internationalisierung unheimlich
Spaghetti-Code
Kein Mensch kann vernünftig Code lesen geschweige denn verstehen bei dem keine Blöcke erkennbar sind
Ein-/Ausschater für den Hack
Wozu? vBulletin bietet über das Produktsystem eine eingebaute, standardisierte Möglichkeit um Hacks zu deaktivieren. Das kann man auch in eigenen Scripten einfach abfragen:
PHP:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------
Für jeden Hack eine eigene Einstellungs-/Rechte-/Menügruppe
Das mag Geschmeckssache sein, aber ich finde es recht nervig/unübersichtlich wenn jeder Hack für 1-2 Einstellungen oder Rechte eine eigene Gruppe erstellt.
Wenn sich ein Hack z.B. mit dem Userprofil beschäftigt, warum bringt man die Einstellungen nicht da unter wo sie thematisch-logisch dazugehören - nämlich in der Gruppe Benutzer; Benutzerliste und Profilanzeige
Fehlerintolerante Installationscodes
De-/Installationscodes sollten möglichst fehlertolerant sein.
Warum muss ich alle hinzugefügten Tabellen/Felder erst einmal wieder löschen oder den Installationscode anpassen wenn eine Aktion schiefgegangen ist (Feld/Tabelle existiert schon z.B.)?


Wer Ergänzungen hat, als her damit :)

[Hoffi]

Mir fällt auch noch was ein.

Die allgemeinen Einstellungen dazu missbrauchen Daten vorzuhalten, die nur an einer einzigen Stelle benötigt werden. Das ist ganz großer Müll, denn die Einstellungen sind immer komplett im RAM. Wenn man Daten in nur einer oder zwei Seiten benötigt, sollte man eine eigene Tabelle benutzen.

Formulare um dort reinzuschreiben usw. sind mit vB recht schnell zusammengestrickt.

[ragtek]

Dann könnte man auch eigene Benutzergruppenrechte in die Tabelle packen, falls sie nur dort verwendet werden^^
Aber ja, an und für sich hast du recht:)

[AA_]

ich frage mich, ob man den programmierstil des vbulletin übernehmen muss.
aktiviert man zb. die ausgabe von warnmeldungen, wird der screen bei jedem aufruf mit meldungen derart gefloodet, dass man mühe hat mögliche fehlermeldungen, die durch eigene fehler entstanden sind, zu erkennen.

ein beispiel, welches leider zu oft in vbulletin vorkommt:

PHP:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

dieser aufruf erfolgt in vbulletin4 bei jedem zu parsenden template. die eigenschaft relpath existiert nicht und wird erst im verlauf der ersten abfrage gesetzt, so dass dieser code eine warnung ausgibt, weil hier auf eine nicht existierende eigenschaft zugegriffen wird.

das gleiche passiert im ganz grossen stil innerhalb von template-conditions, wenn zb abgefragt wird:

CODE:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

existiert der index 'foobar' nicht, hagelt es warnmeldungen.

so wird mein screen mit warnmeldungen gefloodet, weil es einen index 'vbcms' in der vbulletin4 classic version nicht gibt und im code ungeniert auf diesen index zugegriffen wird. beispiel:

PHP:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

gut - diese warnmeldungen werden per default unterdrückt, so dass man diese nicht zu gesicht bekommt. während der entwicklung sollte man diese unterdrückung aber tunlichst unterlassen, da man sonst keinerlei kontrolle über mögliche fehler hat. denn nicht immer verursacht ein mieser programmierstil eine warnung, sondern auch dinge, die einem durchaus mal passieren können.

so bleibt unentdeckt, dass in der init.php eine konstante gesetzt wird, die bereits in der global.php gesetzt wurde. das sind ziemlich grobe schnitzer, die bereinigt werden müssen. auch kann es mal passieren, dass man sich verschreibt und dadurch schlimme fehler in der folge entstehen:

PHP:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

im code oben wird eine variable $unit_found abgefragt, die nirgends existiert oder gesetzt wird. in wahrheit ist nämlich $units_found gemeint, was die konstruktion gleich mal in einem anderen licht erscheinen lässt, weil sie dann anders funktioniert. der code stammt ebenfalls aus vbulletin4.


nun meine frage: sollte man sich diesen vbulletin-schlampen-stil zu eigen machen und auch die teilweise denkwürdigen vorschriften des vbulletin coding standards befolgen, oder doch lieber sauberen code schreiben?

[Andreas]

Am besten wäre es wenn der vBulletin-Code von Haus aus komplett sauber wäre ... aber das wird wohl noch einige Zeit dauern (wenn es überhaut soweit kommt).

Deine Frage kann ich dir aber nicht wirklich beantworten - ich versuche meist einen Mittelweg zu fahren, denn das eine oder andere aus den Code-Standards hat IMHO durchaus seine Berechnigung (z.B. AND statt &&, Array-Keys in Anführungszeichen, etc.).

[Bachsau]

Das wird wahrscheinlich immer schlimmer werden, je größer und kommerzieller das Produkt wird. Die Erfahrung hat gezeigt, dass vor dem Hintergrund des Profits für Konformität zu Standards meist kein Platz mehr ist. Hauptsache es läuft - irgendwie. :(

Dass man durch solch einen Coding-Stil zudem Sicherheitsprobleme z.B. in Form von register_globals riskiert ist vielen nicht bewusst.