01 · PORTAL
Portal Service
Registrierung, Login, Profile und Abos. Hier entscheidet sich, wer Zugang zur Plattform bekommt.
FLASK · PORT 8000
v1.0 / SAFE
LESEN STATT AUSFÜHREN
4RD[
in einfachen Worten.
Ein mehrteiliges Python-System, das Benutzer, Kleinanzeigen-Konten, Anzeigen und Chats über Aufgaben verbindet. Diese Seite macht den Code nachvollziehbar — und hält riskante Produktivfunktionen bewusst außerhalb.
Leseschutz: Beispiele sind synthetisch. Originale Secrets, Proxies, Datenbankinhalte und operative Endpunkte wurden nicht übernommen.
03Hauptdienste
01Aufgaben-Worker
10+Funktionscluster
SAFEDemo-Modus
01 / SYSTEM
Was steckt dahinter?
Stell dir 4RD wie eine kleine Leitstelle vor: Vorne gibt es ein Benutzerportal, daneben die eigentliche Arbeitsoberfläche, und im Hintergrund arbeitet ein Bot, der Aufgaben aus der Datenbank abholt.
SYSTEM MAP → interne Grenzen
session / access
02 · WORKSPACE
KLZ Plattform
Die geschützte Oberfläche für Konten, Anzeigen, Chats, Uploads und Auswertungen.
FLASK · PORT 8001
task queue
03 · BACKGROUND
Client Loop
Fragt offene Aufgaben ab, markiert sie als gelesen und startet den passenden Handler.
PYTHON · THREADS
read / write
04 · STATE
Datenbank
Speichert Benutzer, Konten, Anzeigen, Chats, Aufgaben und Statuswerte.
MYSQL / SQLITE
UI / EingangVerarbeitungPersistenter Zustand
02 / DATENFLUSS
Eine Aufgabe, vier Stationen
Der wichtigste Gedanke im Code: Die Weboberfläche führt die Arbeit nicht direkt aus. Sie legt eine Aufgabe ab. Der Client-Worker holt sie später und schreibt das Ergebnis zurück.
⌁
Benutzeraktion
Ein Nutzer klickt etwa auf „Chats laden“ oder „Anzeige aktualisieren“.
POST / action→
⊞
Task-Tabelle
Die Plattform schreibt einen Datensatz mit task_read = 0.
→
◌
Client-Loop
Der Worker fragt offene Aufgaben ab und startet den passenden Handler.
POLL → START→
✓
Status zurück
Erfolg oder Fehler wird gespeichert und im Dashboard angezeigt.
UPDATE statusKurz gesagt: Die Datenbank ist hier nicht nur Ablage, sondern eine Warteschlange. Der Worker ist der Teil, der die eigentliche Arbeit übernimmt.
03 / KOMPONENTEN
Was kann welcher Teil?
Die Namen im Repository sind breit gefächert. Hier sind sie auf drei verständliche Bereiche reduziert.
01
Portal — Zugang und Abrechnung
Das Portal ist die Eingangstür. Es verwaltet Nutzer, Sessions, Abos, Profile und den Marketplace-Bereich.
AUTH
Login & Registrierung
Legt Nutzer an, prüft Sessions und schützt geschlossene Seiten.
PLAN
Subscription
Ordnet einem Nutzer einen Zeitraum und ein Kontingent zu.
PROFILE
Profil & Referral
Zeigt Profilinfos und optionale Empfehlungs-Codes.
02
KLZ — die Arbeitsoberfläche
Hier werden Konten, Anzeigen und Chats gesammelt. Aktionen werden als Tasks an den Worker weitergereicht.
ACCOUNTS
Kontenübersicht
Zeigt bereinigte Kontenmetadaten, Ads-Anzahl und Chat-Zähler.
CONTENT
Anzeigen & Uploads
Verwaltet Inhalte, Bilder und Status – im Original mit externen Plattformen verbunden.
CHAT
Chat-Aktionen
Listet Chats und legt Antworten als Aufgaben ab.
03
Client — die Hintergrundschicht
Der Client Loop ist ein Dispatcher: Er erkennt den Aufgabentyp und startet das passende Python-Modul.
POLLING
Aufgaben abholen
Fragt mehrere Task-Tabellen in kurzen Abständen ab.
HANDLERS
Handler starten
Verbindet Tasks mit Modulen für Login, Chats, Anzeigen und Uploads.
STATE
Ergebnis speichern
Schreibt erledigt, fehlgeschlagen und Zusatzinformationen zurück.
04 / SICHERHEIT
Was sollte vor einem echten Betrieb passieren?
Die Analyse zeigt mehrere Stellen, die vor einer produktiven Nutzung zwingend überarbeitet werden müssten. Die Befunde sind bewusst ohne geheime Werte dokumentiert.
5priorisierte Befunde
HOCHhöchste Stufe
0Secrets in dieser Demo
HOCHSEC-01
Geheimnisse und feste Schlüssel im Quellcode
In der Ausgangsbasis finden sich fest eingetragene Schlüssel beziehungsweise sensible Konfigurationswerte.
SchutzmaßnahmeAlle Secrets rotieren, aus dem Repository entfernen und ausschließlich über einen Secret-Store zur Laufzeit laden.
HOCHSEC-02
Externe Zahlungs- und API-Ziele per HTTP
Das Portal spricht ein externes Zahlungsziel über unverschlüsseltes HTTP an und nutzt einen fest eingetragenen API-Key.
SchutzmaßnahmeHTTPS erzwingen, Anbieter-Client kapseln, Schlüssel aus Secrets lesen und Ausgänge allowlisten.
MITTELSEC-03
Passwort- und Session-Prüfungen prüfen
Die Login- und Session-Logik sollte mit standardisierten Framework-Flows, sicheren Cookie-Attributen und Tests abgesichert werden.
SchutzmaßnahmeWerkzeug für Passwort-Hashing korrekt einsetzen, Session-Cookies härten, CSRF konsistent aktivieren und Rate Limits zentralisieren.
MITTELSEC-04
Externe Plattformregeln und Datenschutz
Automatisierte Logins, Anzeigen- und Chat-Aktionen sowie Fingerprint-/Proxy-Logik erzeugen besondere Compliance- und Missbrauchsrisiken.
SchutzmaßnahmeNur offizielle APIs und erlaubte Workflows nutzen, Einwilligungen dokumentieren, Daten minimieren und Abuse-Controls einbauen.
NIEDRIGSEC-05
Architektur und Wartbarkeit
Mehrere Services teilen sich ähnliche Datenbanklogik, und viele Task-Abfragen duplizieren sich.
SchutzmaßnahmeGemeinsame Datenzugriffsschicht, Migrationen, Tests und strukturierte Logs einführen.
05 / SIMULATION
Demo-Dashboard
Ein Blick auf die Idee hinter der Oberfläche. Alle Namen, Zähler und Statuswerte sind erfunden. Aktionen sind in dieser Dokumentation absichtlich nicht ausführbar.
WED · 09:42:16
Good morning, Demo User.
ACCOUNTS08+2 this week
ACTIVE ADS142+8.4% vs last week
OPEN CHATS273 need attention
TASK QUEUE ● LIVE
Chat history syncdone
Ad status refreshrunning
Category suggestionqueued
RECENT ACCOUNTS VIEW ALL →
AKaccount_01@demo.invalidconnected · proxy abstracted
MSaccount_02@demo.invalidconnected · proxy abstracted
TRaccount_03@demo.invalidneeds review