4 Commits (e031d4c20af9f67f77a5d3c00a6e81975c6755f8)

Author	SHA1	Message	Date
nexxo	f40b762413	Zwei Empfaengerkreise, und eine Wegwahl, die auch das Konto verschiebt ... Fix-Welle nach dem Gesamt-Review, Punkte 4 und 5. Beide sitzen in denselben Dateien, deshalb ein Commit. DIE HOST-MELDUNG WAR WORTWOERTLICH DIE KUNDENMAIL (Punkt 4). notifyHostManagers() verschickte dieselbe SecurityBlockMail. Deren Text ist fuer den Kunden geschrieben ("bei Ihrer Cloud", "…koennen Sie die Sperre auf der Sicherheitsuebersicht aufheben"), der Knopf zeigte auf portal.security — wo ein Betreiber kein Konto hat und Host-Sperren nie erscheinen —, welcher Host betroffen ist stand nirgends, und die Anrede blieb leer, weil $block->instance null ist. Die Mail kann jetzt beide Faelle. Unterscheidungsmerkmal in der Ansicht ist $hostName: gesetzt heisst Host-Sperre, null heisst Instanz-Sperre. Ein zweites Flag daneben waere eine zweite Wahrheit. - Betreff nennt den Host. - Eigener Textblock (mail_heading_host, mail_preheader_host, mail_intro_host mit "fehlgeschlagene SSH-Anmeldungen am Host :host"), eigene Tabellenzeile field_host, eigener Hinweis mail_note_host. - Der Knopf zeigt auf admin.hosts.show, also auf die Host-Detailseite der Konsole, wo die Host-Sperren mit ihrem Aufheben-Knopf stehen. - Keine Anrede im Host-Fall — sie war vorher leer, und der Empfaengerkreis ist ohnehin mehrere Personen. - Der Fehlalarm-Satz ist ein anderer und sagt, was ein Betreiber wissen will: bestehende Verbindungen bleiben unberuehrt, die Regel steht unter "established,related accept". R19: die zwei Kommentare, die fuer Host-Sperren Unwahres behaupteten, sind richtiggestellt — der Kopfkommentar von SecurityBlockMail und der MailCatalogue-Eintrag. Beide beschreiben jetzt zwei Empfaengerkreise. Ein Kommentar mit falscher Begruendung haelt den Naechsten vom Nachsehen ab. DIE WEGWAHL VERSCHOB DEN ABSENDER, NICHT DAS KONTO (Punkt 5). SecurityBlockMail nagelte mailer('cp_system') fest und holte das Postfach ueber die Wegwahl. MailboxTransport loeste weiter ueber den ZWECK auf und authentifizierte mit dessen Zugangsdaten. Legte der Betreiber security-block auf info@ — der ausdrueckliche Anlass fuer Abschnitt 3a der Spec —, ging die Mail mit From: info@ durch die SMTP-Sitzung von no-reply@. Viele Server weisen das ab ("553 5.7.1 Sender address rejected: not owned by user"), und dann verschwindet ausgerechnet die Mail, die er gerade umgelegt hat. Betraf ALLE Mailarten. Die Wegwahl bestimmt jetzt auch den Mailer. Die zweitbeste Loesung — die Auswahl in der Konsole auf Postfaecher zu begrenzen, deren Konto benutzt wird — war nicht noetig. - config/mail.php erzeugt AUS MailCatalogue::all() je Mailart einen Mailer cp_mail_<mailart> mit transport, purpose und mail_key. Erzeugt statt aufgelistet, weil der Katalog ausdruecklich die EINE Liste ist; eine zweite hier waere die, die beim siebzehnten Mail vergessen wird. Genauso statisch wie die fuenf Zweck-Mailer: ein reines Array, keine Datenbank, auch unter config:cache unveraendert. - MailboxTransport nimmt den mail_key entgegen und loest damit ueber DIESELBE MailRoute::purposeOrMailbox() auf, die auch der Umschlag fragt. Ohne Schluessel entscheidet wie bisher allein der Zweck — jeder Mailer, der keinen hat, verhaelt sich unveraendert. - Jede Mailart mit Schluessel benennt ihren Mailer ueber MailCatalogue::mailer(). Dessen Rueckfall auf cp_<zweck> fuer einen unbekannten Schluessel ist nicht Zierde: DunningNoticeMail baut seinen Schluessel aus der Mahnstufe, und ohne den Rueckfall waere eine Stufe ausserhalb 0-3 ein "Mailer [...] is not defined" und damit ein Totalausfall statt eines falschen Absenders. - Betrifft alle Mailarten: 13 Mailables, die CloudReady-Notification und die cloud-ready-Vorschau. ContactRequestMail bleibt auf cp_support — es hat keinen Schluessel im Katalog, weil es keine eigene Mailart ist. MailSenderOwnershipTest ist mitgezogen und dabei STRENGER geworden. Die alte Fassung verglich "From-Zweck == Mailer-Zweck"; jetzt prueft sie, dass der Katalog dem Zweck zustimmt, den der Umschlag verlangt. Katalog-Drift war bis hierher nur als Warnung im Docblock von MailCatalogue festgehalten und durch nichts erzwungen. Ein Literal, das selbst kein Schluessel ist, wird als PRAEFIX behandelt (der Mahnlauf) — dann muessen alle Schluessel dahinter zustimmen, und es muss mindestens einen geben. MailPreviewTest fragte den Zweck bisher, indem es 'cp_' vom Mailer-Namen abschnitt. Das war eine Zusicherung ueber das Namensschema, nicht ueber die Zusage; sie liest den Zweck jetzt aus der Konfiguration des Mailers selbst. tests/Feature/Mail/SenderAddressTest.php gehoert inhaltlich zur parallel laufenden Sitzung. Vier Zusicherungen darin pruefen genau den Mailer-Namen, den dieser Commit aendert, also sind sie mitgezogen — die Datei war dabei sauber, es steckt keine fremde unfertige Arbeit in diesem Commit. Committet mit ausdruecklicher Dateiangabe am Zeilenende, weil eine parallele Sitzung an derselben Ablage arbeitet und der Index fremde Arbeit enthalten kann. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 17:00:20 +02:00
nexxo	51a97019a8	Sperren sehen und aufheben: Portalseite fuer den Inhaber, Abschnitte in der Konsole ... Aufgabe 6 des Fruehwarnsystems. Der Inhaber sieht im Portal die Sperren SEINER Instanzen und hebt sie dort auf; der Betreiber sieht in der Konsole alle, an der Kunden- und an der Host-Detailseite, und auf der Uebersicht steht ein Hinweis, solange irgendwo eine Sperre aktiv ist. Aufgehoben wird ueber ein Bestaetigungs-Modal (R23), und das Modal mutiert nichts: es wirft ein Ereignis, das die Seite auffaengt und an ihre eigene Methode weiterreicht. Die Berechtigungspruefung bleibt damit an der einen Stelle, an der sie schon stand — noetig, weil ein Modal ohne die Middleware der Seite erreichbar ist (R20). Dazu die Berechtigung `instances.manage`, nach dem Muster der bestehenden `instances.restart`-Migration; Abrechnung und Read-only bleiben unberuehrt. ACHTUNG, was hier sonst noch drinsteckt und NICHT zu dieser Aufgabe gehoert: rund 150 Zeilen zum Versandtakt — das Merkmal `RidesALane`, vierzehn Mailables und `MailLaneRoutingTest`. Die stammen aus einer PARALLEL laufenden Sitzung an einem anderen Feature. Wie das hineingeriet: der Implementierer dieser Aufgabe brach vor dem Commit ab und liess seine fertige Arbeit ungespeichert im Baum. Ich habe sie dateigenau mit `git add <dateien>` vorgemerkt, um nichts Fremdes mitzunehmen — und dabei uebersehen, dass `git add` nur HINZUFUEGT: die andere Sitzung hatte ihre Arbeit bereits vorgemerkt, und `git commit` schreibt den ganzen Index, nicht nur das zuletzt Hinzugefuegte. Richtig waere `git commit -- <dateien>` gewesen. Nichts ist verloren, und die volle Suite ist auf diesem Stand gruen (2571). Aber diese Botschaft soll nicht behaupten, sie beschreibe alles, was hier steht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 15:53:24 +02:00
nexxo	2d979052d0	Benachrichtigung ueber eine gesperrte Adresse, hoechstens eine je Stunde ... SecurityBlockMail geht bei einer Instanz-Sperre an die Kontoadresse des Inhabers, aus dem SYSTEM-Postfach wie NewDeviceSignInMail. Die Drossel sitzt in BlockAddress::notifyInstanceOwner() ueber Settings (kein neues Feld fuer etwas, das nach einer Stunde niemanden mehr interessiert) und wird VOR dem Versandversuch gesetzt. Ein Throwable beim Verschicken wird gemeldet und verschluckt: die Sperre steht schon, bevor ueberhaupt versucht wird zu verschicken, und ein kaputtes Postfach darf sie nicht rueckgaengig machen. Host-Sperren verschicken bewusst noch keine Mail: kein Muster im Repo, wie eine Betreiber-Meldung ihren Empfaenger findet (siehe Bericht). Route 'portal.security' minimal angelegt (Aufgabe 6 baut die echte Seite) - auf einem eigenen Pfad, weil sie sich mit der oeffentlichen /security-Seite sonst lautlos gegenseitig ueberschreiben, sobald Portal und Website ohne eigene Domain laufen (RouteCollection indiziert ueber Methode+Domain+URI, nicht ueber den Namen). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 14:39:35 +02:00
nexxo	f8874f32ea	Put customer instances on their own domain, and say which domains are ours ... ── The zone ──────────────────────────────────────────────────────────────── A fresh install now addresses customer instances under clupilot.cloud rather than clupilot.com. Not branding: a Nextcloud is third-party software that strangers sign in to, and on the same registrable domain as the portal it shares cookie scope, document.domain and CAA with it. The same reason googleusercontent.com and vercel.app exist. Existing installations keep whatever the console says — the zone has been a setting all along. `clupilot:check-zone <zone>` reports what a change would touch before anything is touched: the DNS records, the monitoring targets, the certificates and Nextcloud's trusted_domains all carry the old name and the setting reaches none of them. With no instances in service it says so and stops. Changing it later is a migration with an outage, and the command says that too. ── Which addresses are ours ──────────────────────────────────────────────── A new public page at /sicherheit: the domains that belong to us, the rule for reading an address bar, what we never do, and — the part that matters — what to do if you have already typed your password into a copy of our sign-in form. Change it, end every other session, change it wherever else you use it, tell us. In that order. Reachable without an account, deliberately: somebody who has just given their password away is signed in nowhere, and the page they need cannot be behind the thing they lost. Linked from the three places a person is when the question comes up: every mail footer (the mail is the vector), the sign-in form (this is the page a phishing kit copies, so the real one says which host you are on), and the site footer. The domain list is DERIVED from configuration and keyed by what each domain is for. A list typed into a page would eventually tell a customer that a phishing domain is one of ours, or that one of ours is not — the same two-sources-of-truth failure that had the price sheet promising an address on a domain the company does not own. The operator console is deliberately absent from it: naming it on a public page tells an attacker where to aim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:03:13 +02:00