Was sollte ein Paidmail-Script können?

440ci

Well-known member
12 Januar 2014
129
0
Ich bin schon seit ca. 1 Jahr dabei, ein eigenes Paidmail-Script zu schreiben, weil es entweder kein vernünftiges Script auf dem Markt gibt, oder immer irgendwelche wichtigen Features fehlen, die auch (aufgrund des schlechten Codes) nur sehr schwer implementiert werden können.
Alle mir bekannten Scripte sind hoffnungslos veraltet und voll mit Sicherheitslöcher oder Bugs, welche einfach nicht gefixt werden. Kein Script, welches mir bekannt ist, hat eine saubere Trennung vom HTML/JS und PHP-Code, will man zb. beim "Paidmailer" etwas ändern, muß die Änderung in zig PHP-Dateien eingetragen werden.
Neuere Scripte basieren zum größten Teil auf den alten und Fehlerbehafteten Scripten und bieten nur sehr wenig neue Funktionen, welche zum größten Teil auch noch Laienhaft umgesetzt wurden.

Mein Script (welches noch nicht fertig geschrieben ist), beinhaltet folgende Features:
  • PHP5 OOP
  • Abstrakter Datenbank-Layer (verschiedene Engines wie MySQL, MySQL-I, PDO usw. können als "Driver" geladen werden.)
  • Komplette Trennung vom HTML, PHP und JS, HTML befindet sich in PHP-Klassen, JS wird über eine spezielle Klasse geladen
  • HTML-Form-Elemente (Input, Select, Kalender, Fieldset, Submit usw.) über eine Dokumenten-Klasse
  • Vernünftige Session-Klasse inkl. Sicherheitstoken beim Aufrufen/Abschicken von Formularen und Webseiten läuft unsichtbar im Script (für Gäste, Mitglieder und Admins), dadurch Session-Hijacking unmöglich
  • Ganzes Design läuft über 1 HTML-Seite, welche über die Theme-Engine geladen und über eine Caching-Klasse gecacht werden kann
  • Unzählige Benutzergruppen und Admin mit jeweils unterschiedlichen Systemrechten möglich
  • Alle im System gespeicherten Passwörter liegen als SHA512-Hash vor (oder SHA-256, falls das SHA-512 am Server nicht verfügbar sein sollte) => MD5 ist Geschichte und läßt sich zu schnell knacken
  • Kompletter Globaler Scope (Server-Variablen, POST, GET und sogar COOKIE) wird bei jedem Seitenaufruf auf plausiblen Wert geprüft, ungültige Variablen werden sofort wieder gekillt (zb. bei versuchten Injection). Dateiupload ist nicht möglich und Arrays wie POST oder GET lassen sich nur noch über diese Klasse holen, verändern oder setzen (zb. $_POST['foo'] = 'bar'; funktioniert nicht mehr).
  • Alle Variablen, welche in einem Formular abgeschickt werden, werden automatisch auf Plausibilität (Validate-Klasse) geprüft (zb. Normale Vornamen enthalten keine Sonderzeichen, PLZ sind 5 Stellig usw. Gibt es einen Fehler, wird das Formular abgefangen und mit den bereits ausgefüllten Feldern erneut angezeigt.
  • Mail-Adressen werden auf Syntax (Schreibweise) und Echtheit (MX-Host mit Anfrage beim Server) geprüft, Mail-Anbieter oder Adressen, welche in der Blackliste (im Admin einstellbar) sind, werden nicht angenommen
  • Filterung der Mitglieder nach Geo-Location
  • File-Management (FOpen, Write, Read, cURL usw. läuft über PHP-Klassen.
  • Konfigurierbares und abschaltbares Anti-Cheater (Klick-Bots).
  • Unbegrenzte Anzahl von Netzwerken (lassen sich im Admin eintragen). Geplant ist noch eine zentrale Verwaltung, bzw. Netzwerk-Abgleich aller Installationen, so würde jeder auf dem aktuellsten Stand bleiben, ohne die Mühe zu haben, neue Netzwerke einzutragen (das ganze natürlich abschaltbar)
  • Multi-Language-Fähig über geparste INI-Files
  • Währungen wie "Klammlose", "Primera", "Euro" usw. liegen als Treiber für eine abstrakte Klasse bei
  • Mehrere Währungen zur Vergütung der Mitglieder möglich
  • Migration von allen bekannten alten Scripten (in Planung)
  • Plug`n Play für neue Komponenten (braucht nur im Admin aktiviert zu werden)
  • Konfigurierbare Cronjobs (Gebürtstagsgrüße, Neuer Ref, alte Mails löschen usw.)

Die Liste könnte noch unzählige Punkte länger sein, aber sie soll nur einen kleinen Einblick in mein Script bieten und einen ersten Eindruck verschaffen, was bereits umgesetzt wurde.

Jetzt die Frage an euch...was würdet ihr noch da einbauen, was würdet ihr weg lassen?
 
Das wichtigste habe ich natürlich vergessen :D
Das Script läßt sich von Paidmailer (Multi-Währung) auf Mailtauscher (Punkte) oder Loseseite (Lose) umschalten.
Auszahlungen können beim Paidmailer auch in allen Währungen durchgeführt werden.
Referals können in Auktionen erworben werden (der meistbietende Gewinnt die Auktion)
 
Kommt die Tage evtl. noch eine kleine Demo- bzw. eher eine Info Seite wo man den Fortschritt etc. einsehen kann?
 
  • Alle Variablen, welche in einem Formular abgeschickt werden, werden automatisch auf Plausibilität (Validate-Klasse) geprüft (zb. Normale Vornamen enthalten keine Sonderzeichen, PLZ sind 5 Stellig usw. Gibt es einen Fehler, wird das Formular abgefangen und mit den bereits ausgefüllten Feldern erneut angezeigt.

Damit sind schon einmal alle Österreicher ausgeschlossen. :-(
Achte bitte darauf, dass die Validierung nicht nur für Deutschland funktioniert.
Eventuell ermöglichst du es dem Admin der Seite, einzelne Prüfungen ein-/aus- zu schalten.
 

Das Script ist leider noch nicht so weit, das es eine (für den Webserver im Internet) geeignete Version ist ;)

Kommt die Tage evtl. noch eine kleine Demo- bzw. eher eine Info Seite wo man den Fortschritt etc. einsehen kann?

Ich beeile mich :D

Damit sind schon einmal alle Österreicher ausgeschlossen. :-(
Achte bitte darauf, dass die Validierung nicht nur für Deutschland funktioniert.
Eventuell ermöglichst du es dem Admin der Seite, einzelne Prüfungen ein-/aus- zu schalten.

Hey, das ganze ist natürlich am Geo-IP gekoppelt, wenn da Österreich freigeschaltet ist, wird es auch über die Geo-Codes und der IP geprüft, aber trotzdem kann dann niemand aus AT eine PLZ angeben, welches nicht AT-Typisch ist ;)


Als kleinen Vorgeschmack ein kleiner Auszug aus dem (bereits stabil laufenden) Core des Scriptes.

PHP:
// start the output-handler
\ob_start ();

// define the root-dir
\define ('orwPATH_ABSOLUTE', \dirname (__FILE__));

// get the defined paths
require \orwPATH_ABSOLUTE . '/includes/defined.php';

// include the loader
include \orwPATH_LIBS . 'loader.php';

// register the loader
\loader::register ();

// load core-classes for the environment, security, language etc. and clean up the global scope
\orwImport ('factory');
\orwImport ('environment.request');

\orwRequest::clean ();

\orwImport ('utilities.helper');
\orwImport ('environment.validate');
\orwImport ('environment.path');
\orwImport ('document.scripts');
\orwImport ('document.views.system');

// load frontend and backend-language-files
$language = \Factory::getLanguage ();
$language->getLangFiles ();

/* check, if user, sponsor or admin is banned */
\Factory::checkIfBanned ();

// compare the php-version (min. v5.2.0)
(\version_compare (\PHP_VERSION, '5.2.0', '>=')) || die (\sprintf (\text::_ ('SYSTEM_HINT_PHP_TO_OLD'), \PHP_VERSION));

(Sollte ich jemals und irgendwie Namespace ans laufen kriegen, wird das ganze natürlich noch umgebaut, aber im Moment läuft es mehr als nur dürftig (selbst mit Doctrine) und nicht im Script vorhanden)
 
Zuletzt bearbeitet:
Das Script ist leider noch nicht so weit, das es eine (für den Webserver im Internet) geeignete Version ist ;)
Ich bin sicher nicht dran interessiert, die 100.000ste Paidmail-Seite zu sehen :LOL: Pack den Code und zeig ihn... und nicht nur n nutzlosen Schnippsel, wo ein paar Zeilen Includes stehen :p
 
Mit dem winzigen, wahllosen Codeschnipsel kann man natürlich wirklich nicht viel bewerten/einschätzen.

Aber zwei Sachen fallen immerhin schon mal auf:
  1. Kommentare, die 1:1 die Codezeile in englische Sprache wiedergeben, sind sinnlos bzw. machen den Code sogar unübersichtlicher. Lieber selbsterklärende Bezeichner verwenden und Kommentare nur im Ausnahmefall (vgl. CleanCode).
  2. da kommt wieder zum Tragen, dass man den Rest des Codes nicht kennt – aber ich finde es erstmal verwunderlich, wieso eine Factory prüft, ob "user, sponsor or admin is banned"
 
Pack den Code und zeig ihn

Dazu ist es noch viel zu früh, fast das komplette Frontend läuft ja noch nicht, weil ich erst mal das Backend inkl. der Settings, Admin-Klamotte und den Core aufgebaut habe. Frontend ist dann aber leichter und sollte schneller gehen, als das Backend, weil man da auf (fast) nichts mehr achten muß

aber ich finde es erstmal verwunderlich, wieso eine Factory prüft, ob "user, sponsor or admin is banned"

Niemand ist perfekt, ich habe das Script vor ca. 3 Jahren mal angefangen und vieles noch nicht beachtet, später wurde dann "preg_match_all" im gesamten Script geändert, weil dort ein Limiter geändert wurde, dann die komplette SQL-Klamotte...bei genauer Betrachtung muß ich dir natürlich recht geben, eine Funktion, welche die Mitglieder betrifft, sollte nicht in der Factory, sondern in der Member-Klasse laufen :D

Ich denke, ich könnte ca. mitte Januar eine Live-Demo online stellen und das Backend + Frontend nur für einen ausgewählten Kreis zugänglich machen (unterschiedliche Test-User/Admins) zum gucken :D
 
dann warten wir auf mitte januar (was genau genommen gerade vorüber ist :D)

Verdammt, habe ich tatsächlich Mitte Januar geschrieben? :D

Hm, ich versuche es zumindest für Mitte April, dann sollte es alles so weit Stabil laufen, das man es auch (für eine Demo-Installation) nutzen kann, ohne ständig über irgendwas zu stolpern...es soll ja auch einen guten Eindruck hinterlassen, denn der 1. Eindruck zählt ja bekanntlich am meisten :)
 
[...]Hm, ich versuche es zumindest für Mitte April, dann sollte es alles so weit Stabil laufen, das man es auch (für eine Demo-Installation) nutzen kann, [...]

Mitte April... welchen Jahres? ;-) Spaß zur Seite - Es ist ja schon mittlerweile recht ruhig geworden, sind die arbeiten an dem Script noch aktuell?
 
Die Arbeiten sind noch aktuell, verzögern sich aber wegen eines anderen Projektes (Kundenverwaltung mit Ticket, Lizenz und Shop-Anbindung über abstrakte Klasse) ein wenig ;)