Projekt-Memory

Zweck

Multi-Hoster-Upload ist eine Electron-Desktopanwendung für Windows, die große Dateimengen aus einer gemeinsamen Queue gleichzeitig zu Doodstream, VOE, Vidmoly, Byse und Clouddrop hochlädt.

Aktueller Zustand

Nach 2.1.49, noch nicht veröffentlicht: Backup-Untermenü erhält eine durchgängige Hover-Fläche über den sichtbaren Abstand und 250 ms abbrechbare Schließverzögerung. Hover plus Klick bleibt offen, erneutes Betreten startet keine neue Öffnungsanimation; Tastaturfokus hält das Untermenü offen. Pfeil und Pfeiltasten folgen der linken Öffnungsrichtung, Escape schließt nur die aktuelle Untermenüebene. Fremde animationend-Ereignisse schließen kein übergeordnetes Panel mehr. Electron-Regression prüft DOM-Treffertests im Abstand, verzögerte Ein-/Austritte, Klick, Fokus und Escape bei 850 und 600 Pixel Fensterbreite. Kein Release beauftragt.
Release 2.1.49 auf beiden Plattformen veröffentlicht und geprüft: Vidmoly-Sitzungsprüfung, getrennte Upload-Sperrmeldungen, Checkbox-Fokusfix und GB-Dateigrößenlimit. Live-Diagnose am 22.09.2026 bestätigt zuerst gültige Anmeldung mit UPLOAD_DISABLED (Upload-Konfiguration HTTP 403), danach erfolgreiche Anmeldung und vollständige Upload-Konfiguration (HTTP 200). Nutzer bestätigt funktionierende Anmeldung und gibt Release frei. Ein tatsächlicher Dateitransfer wurde dadurch nicht nachgewiesen. Ältere Angaben zu unveröffentlichten Änderungen darunter dokumentieren die Vorbereitung; diese Änderungen sind jetzt in 2.1.49 enthalten.
Vidmoly nach 2.1.48, noch nicht veröffentlicht: Anmeldung wird über /api/auth/me statt anhand der Upload-Konfiguration verifiziert. Öffentliches Website-JavaScript am 22.09.2026 bestätigt unveränderte Upload-Felder sowie DISK_FULL, UPLOAD_IP_BLACKLIST und UPLOAD_DISABLED; diese Antworten werden jetzt getrennt und ohne Antwortdaten angezeigt. Upload übernimmt zusätzlich das aktuelle Webfeld tos=1, weiterhin ohne API-Key. HTTP-Fehler, fehlende Benutzer, OTP-Anforderung und ungültige Serveradressen werden geprüft. Die konkrete Serverantwort des gemeldeten Accounts war in den lokalen Logs nicht vorhanden; erfolgreicher Live-Login/Upload ist noch nicht bestätigt.
Nach 2.1.48 lokal geändert, noch nicht veröffentlicht: Checkboxen in den Hoster-Einstellungen übernehmen beim Mausklick nicht mehr den Fokus-Schatten von Textfeldern. Tastatur-Fokusmarkierung bleibt erhalten; echter isolierter Electron-Test prüft An-/Abhaken, Tabulator, Leertaste und unveränderten Zahlenfeld-Fokus.
Hoster-Dateigrößenlimit wird direkt in GB eingegeben (0 unbegrenzt, 1 GB = 1024 MB). Beide Speicherwege rechnen verlustfrei in das bestehende maxSizeMb-Format um; bestehende Einstellungen und Backups bleiben kompatibel. Import-Vorprüfung und Upload-Manager überspringen zu große Dateien pro Hoster, lassen die exakte Grenze und andere Hoster zu. Regressionen prüfen 5 GB, einen Byte darüber sowie Dezimalwerte. Vorab übersprungene Jobs melden korrekt 0 Versuche statt der konfigurierten Höchstzahl.
IP-Erweiterung am 22.09.2026 nach gesondertem Go aktiviert: Backup-API 2.0.6 produktiv; App 2.1.48 auf beiden Plattformen veröffentlicht. Vorheriger Live-Iststand: Dienst 2.0.5, 13 Datensätze. Sicherung /var/backups/mhu-backup-api/20260922-pre-ip.tar.gz enthält Daten, Konfiguration, öffentlichen Wiederherstellungsschlüssel, Dienstdefinition und bisherigen Dienststand. Archivtest erfolgreich; SHA-256 7be0a9f4497cae20d89606e4872d41eb555fd66bf4613503e6f84e4aa5300e7f entspricht der geschützten lokalen Kopie server-backup-pre-ip-20260922.tar.gz im Wiederherstellungsordner.
Staging staging-ip: Alle 13 Bestandsdatensätze unverändert lesbar; Erstellen eines Version-4-Testbackups mit Herkunfts-IP, private Wiederherstellung, normaler Import und gezieltes Löschen erfolgreich. Anschließend sämtliche 13 Live-Dateien per SHA-256 mit der getesteten Kopie abgeglichen. Keine Live-Datensätze verändert.
Lokaler Build 2.1.48: Installer 98.032.605 Bytes, Portable 97.807.985 Bytes, Produktversion jeweils 2.1.48. Verpackte Quellmodule und Update-Manifest geprüft; keine Schlüssel oder Nutzerdaten enthalten. Englische/deutsche Release-Texte veröffentlicht. Dienstpfad /opt/mhu-backup-api/releases/20260922-v2.0.6 aktiviert und Dienst neu gestartet. Live-Smoke bestätigt serverseitige öffentliche Herkunfts-IP, privaten Wiederherstellungsweg und normalen Import. Ausschließlich eigenen Testdatensatz danach gelöscht; alle 13 Bestandsdatensätze per SHA-256 unverändert bestätigt. Kein pauschaler Rollback auf 2.0.5, sobald neue Version-4-Datensätze vorhanden sind; Daten müssen erhalten bleiben.
IP-Erweiterung seit 2.1.48 veröffentlicht und aktiviert: Der Dienst speichert die serverseitig ermittelte Herkunfts-IP neuer Sicherungen und gibt sie ausschließlich in der Erstellungsantwort zurück. Client-Schlüsselbund und Oberfläche behalten die IP neben Datum/Uhrzeit; alte Einträge zeigen IP unbekannt. Offline-Wiederherstellung unterstützt --details für Datum - Uhrzeit | IP: Adresse | MHU2-… (Zeitzone Europe/Berlin), ohne Flag weiterhin nur den Schlüssel. Private Schlüssel werden nicht übertragen und vollständige Online-Schlüssel nicht in der Übersicht angezeigt.
IP-Datensätze verwenden Version 4; neuer Dienst liest weiterhin Versionen 1–3. Ein Rückwechsel auf die alte Serverversion nach ersten Version-4-Datensätzen erfordert einen datenerhaltenden Kompatibilitätsplan. Live-Aktivierung nach Backup, Staging und ausdrücklichem Go erfolgt; keine Migration oder Änderung bestehender Datensätze. Bestehende IPs nicht nachträglich raten.
Read-only geprüft: Der produktive Proxy für den Backup-Endpunkt überschreibt X-Forwarded-For mit der beobachteten Verbindungsadresse; der Dienst vertraut ausschließlich den konfigurierten Loopback-Proxyadressen. Die IP kann die öffentliche Adresse eines VPN/NAT darstellen und ist keine eindeutige Gerätekennung. Sie unterliegt derselben Aufbewahrung wie der Backupdatensatz und wird nicht vom öffentlichen Restore-Endpunkt ausgegeben.
Version 2.1.47 veröffentlicht: Standardgültigkeit neuer Online-Schlüssel ist Unbegrenzt. Bestehende Ablaufdaten bleiben unverändert; Backup-API bleibt 2.0.5. Release-Commit afdad99, annotierter Tag auf beiden Plattformen identisch. 823 Haupttests, 17 Servertests, Lint und Audit erfolgreich. Installer 98.032.502 Bytes, Portable 97.807.793 Bytes. Alle acht veröffentlichten Dateien erneut heruntergeladen und per SHA-512 geprüft. Titel, Sprachen, Assets und Update-Manifeste auf beiden Plattformen verifiziert. Der eingebaute Updater erkennt 2.1.47 ausgehend von 2.1.46.
Lokale Erweiterung: Online-Backups erhalten einen RSA-3072/OAEP-SHA256-verschlüsselten Wiederherstellungsumschlag, der an die Datensatzkennung gebunden ist. Der private Wiederherstellungsschlüssel bleibt außerhalb des Servers. Verwaltungswerkzeug: scripts/backup-recovery.cjs; Einrichtung und Offline-Wiederherstellung stehen in der README.
Anwendung 2.1.46 auf GitHub und Forgejo veröffentlicht; Backup-API 2.0.5 nach gesondertem Go produktiv aktiviert. Schlüsselpaar lokal außerhalb des Projekts in einem auf Benutzerkonto und SYSTEM beschränkten Ordner eingerichtet; privater Schlüssel nie auf den Server übertragen. Eine unabhängige Sicherung im Passwortmanager/Offline-Speicher bleibt erforderlich. Der neue Client verweigert neue Exporte ohne verfügbaren öffentlichen Schlüssel. Alte Clients und bisherige Importe bleiben kompatibel.
Am 22.09.2026: Live-Dienst 2.0.4 aktiv, 12 Datensätze. Sicherung /var/backups/mhu-backup-api/20260922-pre-recovery.tar.gz enthält Daten, Konfiguration, Dienstdefinition und bisherigen Programmstand. Gzip-Test erfolgreich; SHA-256 4adeaae898317b1bbb179df019782065852a84647daa95da2d6147b61fe28838 entspricht der lokalen geschützten Kopie. Staging auf entpackter Kopie: alle 12 bestehenden Datensätze unverändert lesbar; Erstellen, private Wiederherstellung, Import und Löschen eines neuen Testbackups erfolgreich. Keine produktiven Datensätze verändert.
Release 2.1.46: Installer 98.032.406 Bytes, Portable 97.807.695 Bytes, beide Produktversion 2.1.46. Verpackte Wiederherstellungsmodule stimmen mit dem Quellcode überein; keine privaten Schlüssel oder Nutzerdaten enthalten. Installer-SHA-512 und Größe passen zum Update-Manifest. Erneut 822 Haupttests, 17 Servertests und Lint erfolgreich. Beide Releases enthalten vier geprüfte Assets und inhaltlich gleichwertige englische/deutsche Changelogs.
Aktivierung am 22.09.2026: ausschließlich öffentlichen Schlüssel als /etc/mhu-backup-recovery-public.pem installiert, Backup-API 2.0.5 in /opt/mhu-backup-api/releases/20260922-v2.0.5 bereitgestellt, RECOVERY_PUBLIC_KEY_FILE in /etc/mhu-backup-api.env ergänzt, current umgestellt und Dienst neu gestartet. HTTPS-Smoke bestätigt Schlüsselabfrage, Speicherung, private Wiederherstellung und normalen Import. Ausschließlich den eigenen Testdatensatz anschließend gelöscht. Alle 12 ursprünglichen Datensätze danach mit identischen SHA-256-Prüfsummen bestätigt. Rückfallziel: bisheriger Dienstpfad 20260901T140230Z-v2.0.4 und gesicherte Konfiguration /var/backups/mhu-backup-api/20260922-pre-recovery.env.
Aktive Arbeitslinie: master aus Sucukdeluxe/Multi-Hoster-Upload.
Zuletzt veröffentlichter Funktionsstand: Version 2.1.49, Release-Commit e9ea91a, annotierter Tag 1d52286 auf beiden Plattformen identisch.
Version 2.1.46 ist auf GitHub und Forgejo veröffentlicht. Beide Release-Changelogs benennen die weiterhin fehlgeschlagene DoodStream-Web-Serverermittlung ausdrücklich als bekanntes Problem; ein erfolgreicher Dateiupload wird nicht behauptet.
Einstiegspunkt des Electron-Hauptprozesses: main.js.
Oberfläche: renderer/; gekapselte Fachlogik: lib/; Online-Backup-Dienst: services/backup-api/.
Die Abhängigkeiten sind lokal mit Node.js 24 installiert.

Entscheidungen

Weiterarbeit erfolgt im aktiven Repository Multi-Hoster-Upload, nicht im archivierten Multi-Hoster-Upload-Private-Archive und nicht im älteren Tauri-Versuch Multi-Hoster-Upload-2.
Die jüngste Automatik schützt erfolgreiche Uploads mit einem atomar gespeicherten Abschlussnachweis aus vollständigem Pfad, Hoster, Dateigröße und Änderungszeit.
Schlägt dieser Nachweis fehl, bleibt die Queue erhalten und der Fehler wird als lokale Persistenzstörung behandelt, damit kein stiller Doppel-Upload entsteht.
DoodStream-OTP-Prüfungen verwenden dieselbe Cookie-Sitzung weiter, fassen identische oder parallele Checks zusammen und fordern einen neuen Code nur nach einer ausdrücklichen Aktion mit mindestens 60 Sekunden Abstand an.
DoodStream respektiert die ausdrückliche Auswahl authType=login: Weblogin und Webupload werden nicht durch einen zusätzlich gespeicherten API-Key übersteuert. API-Accounts und ältere Accounts ohne ausdrückliche Login-Auswahl behalten den API-Weg.
Sammelchecks melden jedes Account-Ergebnis einzeln an den Renderer, sodass fertige Karten sofort grün, rot oder als OTP-pflichtig erscheinen, während die übrigen Accounts weiter geprüft werden.
Neue Online-Backups unterstützen 24 Stunden, 3 Tage, 7 Tage, 31 Tage und Unbegrenzt (Standard seit 2.1.47). Bestehende Schlüssel behalten ihre Laufzeit. Endliche Schlüssel werden lokal aus dem verschlüsselten Schlüsselbund entfernt und serverseitig ab Ablauf nicht mehr wiederhergestellt; der Dienst räumt abgelaufene Datensätze bei Zugriff oder der nächsten Speicherung auf.
Vorhandene Online-Backups und alte Upload-Payloads ohne Ablaufangabe bleiben zur Abwärtskompatibilität unbegrenzt gültig.
Backup-Importe wenden Sprache und automatischen Account-Check sofort an. Alle Konfigurationsfelder werden übertragen; Warteschlange, Upload-Wiederherstellungsstatus, letzter Dateiauswahlordner, Automatik-Telemetrie und Pausenzustand bleiben bewusst geräte- beziehungsweise laufzeitgebunden.
Ein nicht vorhandener Ordnerüberwachungspfad bleibt nach dem Import sichtbar gespeichert, die Überwachung wird aber deaktiviert und der Nutzer erhält eine Warnung. Ein nicht vorhandener Log-Ordner wird ebenfalls gemeldet, ohne den konfigurierten Pfad still zu löschen.
Upload-Status-Badges und ihre Textlabels sind nicht markierbar; kopierbare Fehlerdetails, Logs und Eingabefelder behalten ihre Textauswahl.
VOE-Fehler mit der Meldung Maximum storage space of the account used up. gelten als temporärer Accountfehler. Die Retry-Schleife bricht auch nach einem bereits erfolgten Account-Wechsel sofort ab und setzt die Fallback-Kette Account für Account fort, bis ein Upload gelingt oder kein weiterer Account verfügbar ist.
Der DoodStream-Weblogin folgt dem aktuellen Browservertrag über GET /?op=login_ajax, behandelt otp_sent und redirect ausdrücklich und übernimmt sess_id auch aus den aktuellen Vue-Daten mit URL-sicheren Sonderzeichen. Die Upload-Server-Ermittlung verwendet /?op=upload_get_srv und versteht dessen server.srv_url-/server.disk_id-Antwort.
Eine bestätigte DoodStream-Dashboard-Sitzung benötigt beim Account-Check kein Upload-Sessionfeld. Uploads übernehmen unabhängige Kopien der bestätigten Cookie-Sitzung aus dem OTP-Koordinator. Ein fehlender Upload-Server ist vom Login getrennt; bei Web-Accounts findet keine automatische API-Key-Ableitung für Uploads statt.
Version 2.1.45 ist als GitHub- und Forgejo-Release veröffentlicht; Backup-API 2.0.4 blieb bei dieser reinen Veröffentlichung der Desktopanwendung unverändert aktiv.
Der eingebaute Updater liest Releases und Binärdateien von Forgejo; GitHub liefert ergänzend die öffentlichen Release Notes. Ein Release ist deshalb erst vollständig, wenn die vier Assets auch im Forgejo-Release vorhanden sind.
Forgejo bewahrt Leerzeichen in Asset-Namen, GitHub normalisiert sie zu Punkten. Das Forgejo-latest.yml und der Release-Plan verwenden Namen wie Multi-Hoster-Upload Setup 2.1.44.exe; das GitHub-Manifest muss auf den dort tatsächlich veröffentlichten Punktnamen zeigen.
forgejo/master besitzt eine getrennte ältere Historie. Die aktuelle GitHub-Arbeitslinie wird deshalb zerstörungsfrei unter forgejo/sync/github-master gespiegelt.

Start- und Testbefehle

npm ci
npm start
npm run verify

Im aktuellen übergeordneten Windows-Pfad enthält der Ordnername ein &. Dadurch können von npm erzeugte .cmd-Shims zerlegt werden. Die verifizierten direkten Aufrufe sind:

node node_modules/eslint/bin/eslint.js .
$testFiles = @((Get-ChildItem tests -Filter '*.test.js').FullName) + (Resolve-Path tests/ui-smoke.js).Path
node --test @testFiles
node --test services/backup-api/test/server.test.mjs
npm audit --omit=dev

Bekannte Probleme

npm run verify bricht in diesem konkreten Arbeitsverzeichnis bereits beim npm-Shim ab, obwohl Linter und Tests bei direktem Aufruf erfolgreich sind.
Der Forgejo-Standardzweig ist nicht mit dem aktuellen GitHub-master verwandt und darf nicht ohne gesonderte Prüfung oder ausdrückliche Freigabe überschrieben werden.
Der optionale, nur mit RUN_UI_SMOKE=1 aktivierte Langzeit-UI-Test meldet reproduzierbar 16 bestehende Timing-/Fixture-Abweichungen außerhalb des Accounts-/OTP-Pfads; die reguläre CI aktiviert diesen Test nicht.

Offene nächste Schritte

Vidmoly-Livediagnose abgeschlossen: separate lokale Testinstanz mit temporärem Profil und kopierten Vidmoly-Accounts; keine automatischen Accountchecks, Ordnerüberwachung oder Remote-Steuerung. Lokaler Launcher .artifacts/vidmoly-dev.cjs erfasst nur HTTP-Status, feste Fehlercodes und Strukturmerkmale in .artifacts/vidmoly-live-diagnostic.jsonl; keine Passwörter, OTP-, Cookie- oder Sessionwerte. Erfolgreiche manuelle Anmeldung und Upload-Konfiguration bestätigt; installierte Anwendung nicht automatisch aktualisiert. Dateitransfer bleibt separat zu prüfen.
DoodStream: Am 12.09.2026 wurde das authentifizierte Dashboard ohne sess_id live bestätigt. Der alte Upload-Aufruf lieferte eine andere Seite ohne Upload-Felder. Ein zwischenzeitlich getesteter API-Ausweichweg bestätigte zwar den Account, wurde auf Nutzerwunsch wieder entfernt; dessen Uploadversuch scheiterte serverseitig mit No servers available for uploads. Der aktuelle Web-Upload muss noch live auf Serververfügbarkeit und erfolgreichen Dateitransfer geprüft werden. Die lokale Seitendiagnose protokolliert ausschließlich Strukturmerkmale ohne Formularwerte, OTP oder Cookie-Werte.
Keine offenen Veröffentlichungsschritte für Release v2.1.49; ein Server-Rollback muss Version-4-Datensätze erhalten und lesen können. Das oben dokumentierte DoodStream-Uploadproblem bleibt offen. Privaten Wiederherstellungsschlüssel zusätzlich unabhängig vom lokalen PC sichern.
Bei Bedarf einen Arbeitsweg ohne & im absoluten Pfad verwenden oder die npm-Aufrufe weiterhin direkt ausführen.

Zuletzt verifiziert

Backup-Untermenü nach 2.1.49: 838 Haupttests, 18 Servertests und Lint erfolgreich. Gezielter Electron-Test nach abschließender Fokuskorrektur erneut erfolgreich; ein Mausklick auf den Trigger hält das Menü beim Verlassen nicht unbeabsichtigt offen. Änderungen noch nicht veröffentlicht.
Release 2.1.49: Titel, Tags, englischer GitHub- und deutscher Forgejo-Changelog, jeweils vier Assets und Update-Metadaten geprüft. Alle acht veröffentlichten Dateien erneut heruntergeladen und Größe sowie SHA-512 mit lokalen Dateien verglichen. Echter Updater erkennt 2.1.49 ausgehend von 2.1.48 und akzeptiert englische Hinweise sowie Forgejo-Manifest. Öffentlicher Quellcheck einschließlich Screenshots erfolgreich (164 Dateien). Keine produktive Serveränderung erforderlich.
Releasevorbereitung 2.1.49: 837 Haupttests und 18 Backup-API-Tests erfolgreich, Lint erfolgreich, Produktionsaudit ohne Schwachstellen. Installer 98.033.241 Bytes, Portable 97.808.535 Bytes, beide Produktversion 2.1.49. Gepackte Vidmoly-, Upload-, UI- und Backupmodule entsprechen dem Quellstand; keine Nutzerdaten enthalten. Installer-SHA-512 und Größe stimmen mit dem Update-Manifest überein.
Vidmoly-Änderung vom 22.09.2026: alle sieben neuen Regressionen und Lint erfolgreich. Hauptlauf: 836 von 837 Tests erfolgreich; bestehender Electron-Checkbox-Fokustest einmal mit Timingfehler, separater Wiederholungslauf der gesamten Datei mit 23 von 23 erfolgreich. Backup-API weiterhin 18 von 18 erfolgreich. Öffentlicher Quellcheck umfasst 164 Dateien. Keine Live-Anmeldung und kein Release durchgeführt.
Checkbox-/GB-Limit-Änderung nach 2.1.48: 830 Haupttests und 18 Servertests erfolgreich; Lint ohne Fehler. Echter Electron-Fokustest sowie GB-Speicher-, Import- und Upload-Grenztests erfolgreich. Änderungen noch nicht als Update veröffentlicht.
Release 2.1.48: Titel, Sprachen, Veröffentlichung, jeweils vier Assets und Update-Metadaten beider Plattformen verifiziert. Alle acht Assets erneut heruntergeladen und per Größe/SHA-512 mit lokalen Dateien verglichen. Eingebauter Updater mit Version 2.1.47 erkennt 2.1.48, übernimmt englische Release Notes und akzeptiert das Forgejo-Manifest. Release-Commit 7a49a19, annotierter Tag b8df102 auf beiden Remotes identisch. Anleitung auf dem Desktop aktualisiert.

Stand: 22.09.2026 (Produktivaktivierung und Release 2.1.46; ältere Versionsprüfungen darunter sind historische Nachweise)

Eingebauter Updater mit isoliertem Testprofil und installierter Version 2.1.45 erkennt 2.1.46, übernimmt den englischen GitHub-Changelog und akzeptiert das Forgejo-Update-Manifest. Alle acht veröffentlichten Dateien wurden erneut heruntergeladen und anhand Größe und SHA-512 gegen die lokalen Dateien geprüft. Titel, Tag, Sprache, Veröffentlichungsstatus und beide anbieterspezifischen Manifeste stimmen. Vollständiger öffentlicher Quellcheck: 163 erlaubte Dateien, Screenshots gültig. Anleitung auf dem Desktop mit abgeschlossenem Live- und Release-Stand aktualisiert.
Lint: erfolgreich, 0 Warnungen und 0 Fehler.
Haupttests: 826 erfolgreich, 0 fehlgeschlagen; Backup-API: 18 erfolgreich; Lint ohne Fehler. Neue IP-Regressionen prüfen IPv4/IPv6, gefälschte Clientangaben, vertrauenswürdige und fremde Proxys, Persistenz im Schlüsselbund, alte Datensatzformate, unbekannte IPs und Offline-Detailausgabe. Öffentliche Quellmanifest-Prüfung umfasst weiterhin 163 Dateien. Die Änderung der Standardgültigkeit ist mit 2.1.47 veröffentlicht; IP-Erweiterung ist mit 2.1.48 veröffentlicht.
Wiederherstellung lokal Ende-zu-Ende geprüft: öffentliche Schlüsselabfrage, verschlüsselter Serverdatensatz, normaler Import, private Offline-Wiederherstellung und Löschen. Falsche Schlüssel, beschädigte Daten, Kennungstausch, Ablauf, fehlende Serverkonfiguration und Überschreiben bestehender Schlüssel/Ausgabedateien werden geprüft. Anleitung auf dem lokalen Desktop mit eingerichteten Schlüsselpfaden und Sicherungsnachweis aktualisiert.
Backup-API-Tests: 17 erfolgreich, 0 fehlgeschlagen.
Der Regressionstest für die VOE-Fallback-Kette bestätigt bei deaktivierter normaler Rotation genau einen Versuch auf jedem vollen Account und anschließend den erfolgreichen Wechsel auf den vierten Account.
Der öffentliche DoodStream-Webablauf wurde am 12.09.2026 direkt gegen die Startseite und deren aktuelle Browser-Skripte geprüft. Regressionstests bilden den neuen GET-Login, otp_sent, redirect, Vue-Sessiontokens mit _/- und die aktuelle upload_get_srv-Antwort nach.
Der lokale Web-Account-Check um 14:35:27 bestätigte das authentifizierte Dashboard ohne Upload-Sessionfeld. Regressionen prüfen zusätzlich explizite Web-Auswahl trotz gespeichertem API-Key, Wiederverwendung der OTP-Sitzung, getrennte Cookie-Kopien für parallele Uploads und Web-Serverausfälle. Der Upload-Aufruf verwendet nachweislich weder API-Ableitung noch einen zweiten Login.
Das Support-Bundle vom 07.09.2026 bestätigt als Ursache der gemeldeten Datei: Wechsel vom Primäraccount auf Fallback #1, dort vier unnötige Versuche, anschließend skip-account-pause und Abbruch mit override-same-as-current statt Weiterschaltung.
Der vollständige opt-in UI-Smoke bestätigte zusätzlich, dass Upload-Status-Badges und deren Labels nicht markierbar sind; die 16 bekannten themenfremden Abweichungen blieben unverändert.
Produktionsabhängigkeiten: npm audit --omit=dev meldet 0 Schwachstellen.
Release v2.1.45: Commit 05769cd und annotierter Tag sind auf beiden Remotes identisch. Die englischen GitHub- und deutschen Forgejo-Changelogs, Titel, Versionsangaben und jeweils vier Assets wurden nach der Veröffentlichung geprüft.
Der echte Updater mit installierter Version 2.1.44 erkennt 2.1.45 und akzeptiert den englischen GitHub-Changelog sowie das Forgejo-Manifest. Alle acht veröffentlichten Assets wurden heruntergeladen und per Größe sowie SHA-512 gegen die lokalen Dateien geprüft. Beide Manifeste zeigen auf den tatsächlichen Installer-Namen des jeweiligen Anbieters.
Der Installer 2.1.45 ist 98.031.439 Bytes groß, Portable 97.806.832 Bytes. Datei- und Produktversion stimmen mit 2.1.45 überein; die verpackten Kernmodule stimmen mit dem geprüften Quellcode überein, Nutzereinstellungen sind nicht enthalten. Der vollständige öffentliche Quellcheck einschließlich Screenshots war erfolgreich.
Release-Commit e191ea8 und der annotierte Tag v2.1.44 wurden auf GitHub und Forgejo mit identischen Commit-Hashes verifiziert.
GitHub- und Forgejo-Release v2.1.44 enthalten jeweils Installer, Portable-Build, Blockmap und ein zum Anbieter passendes Update-Manifest; GitHub führt den englischen und Forgejo den inhaltlich gleichwertigen deutschen Changelog.
Der echte Updater mit installierter Version 2.1.43 erkennt Forgejo-Release v2.1.44, lädt den englischen GitHub-Changelog und akzeptiert Version, Installername, Größe und SHA-512 des veröffentlichten Manifests.
Der öffentliche Release-Quellcheck bestätigte 160 erlaubte Dateien, korrekte Versionsmetadaten und gültige Screenshots. Der über den Forgejo-Updatepfad erneut geladene Installer ist 98.029.932 Bytes groß, stimmt mit der Manifest-SHA-512 überein und trägt Datei- sowie Produktversion 2.1.44.
Backup-API 2.0.4 läuft produktiv aus /opt/mhu-backup-api/releases/20260901T140230Z-v2.0.4; der vorherige Dienststand und alle 10 bestehenden Datensätze wurden davor in /var/backups/mhu-backup-api/20260901T140230Z-pre-v2.0.4.tar.gz gesichert und per Gzip-Test sowie SHA-256 geprüft.
Der produktive HTTPS-Smoke für einen endlichen Testschlüssel bestätigte Erstellen 201, Wiederherstellen 200, Löschen 204 und anschließendes Nichtfinden 404; danach waren weiterhin exakt 10 bestehende Datensätze vorhanden.

24 KiB Raw Blame History Unescape Escape