Legacy-API-Kunden mit Keys beider Altportale — vor allem connektar — senden
jede Meldung an presseecho.de UND businessportal24.de. Weil die Firma ihr
Portal vom User und die Meldung es von der Firma erbte, landeten beide Kopien
im selben Portal, die zweite mit Slug-Suffix "-2". Verifiziert wurde das über
die Token-Hashes gegen die Legacy-Datenbanken.
Das Portal wird jetzt in fester Reihenfolge aufgelöst: expliziter
portal-Parameter, sonst die aufgerufene Domain, sonst das Portal des
Firmenprofils, zuletzt Portal::Both — genau der Default, den beide Spalten
ohnehin tragen. Die Auflösung ist damit nicht-nullbar; vorher konnte sie null
liefern, was als SQL-Fehler und damit als 500er beim Alt-Client gelandet wäre.
Ein Update über die v1-API verschiebt eine bestehende Meldung ausschließlich
über den expliziten Parameter, nie über die aufgerufene Domain.
press-releases:fix-api-portal-duplicates repariert die Altdaten: Es findet
Paare (gleicher User, Titel, Sprache und Portal, beide per API eingereicht,
kurz nacheinander) und verschiebt die zweite Kopie samt ihrer exklusiven Firma
ins jeweils andere Portal, mit neu vergebenem Slug. Web-Doppel-Submits ohne
Status-Log source=api und Legacy-Sync-Daten mit gesetzter legacy_id werden
geschont. Auf Live ausgeführt und verifiziert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kunden, die in beiden Altportalen existierten, tragen nach dem Merge nur
das zuletzt importierte Portal in users.legacy_portal/legacy_id — der
Schlüssel des anderen Portals fand dadurch keinen Besitzer und wurde als
'Kein User-Mapping' übersprungen (Presseecho-Key → 410). Die Import-Map
kennt beide Zuordnungen und wird jetzt zuerst befragt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
updateOrCreate ersetzt durch eine Ownership-Prüfung: ein fremder,
gesetzter Eigentümer wird abgelehnt (409), bestätigte Abos werden nicht
still ent-bestätigt. Verwaiste Datensätze (user_id NULL nach Konto-
Löschung/Legacy-Import) dürfen neu gebunden werden, statt dauerhaft
gesperrt zu bleiben.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- trustHosts erlaubt nur die konfigurierten Domains (plus localhost/IP
für Health-Checks) und verwirft fremde Host-Header, sodass
X-Forwarded-Host keine URL-Generierung mehr vergiften kann (H5).
- Legacy-API-Keys nur noch per Header (Bearer/X-ApiKey); die alte
Query-/Body-Übergabe wird nicht mehr zur Auth akzeptiert, erhält aber
weiterhin den 410-Migrationshinweis statt eines opaken 401 (M11).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Neue PM-Bilder/Anhänge liegen auf der privaten local-Disk; Auslieferung
über kontrollierte Media-Routen mit gemeinsamer Zugriffslogik
(AuthorizesPressReleaseMediaAccess). Öffentliche Medien werden aus den
geladenen Modellen ermittelt (weniger Queries) und länger gecacht.
- Anonyme Token-Vorschau lädt Bilder über temporär signierte URLs (Fix#5).
- API-Resource baut Variant-URLs über die Media-Route statt /storage
(Fix#4). Storage-Schicht prüft zusätzlich den serverseitigen MIME-Type (M5).
- press-releases:privatize-media migriert Bestandsmedien.
Deployment: einmalig `php artisan press-releases:privatize-media` ausführen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Publish/Reject/Archive und changeStatus erzwingen konsistent
press-releases:publish; changeStatus schloss die Lücke, über die das
Status-Modal die Prüfung umging (Fix#1/H2).
- publish()/changeStatusFromAdmin sperren PM- und User-Zeile
transaktional; QuotaExceededException wird in Admin-Publish und im
Auto-Publish-Job abgefangen (Warnung statt 500 / bleibt in Review, Fix#3/M2).
- Slug-Erzeugung nur noch über HasUniqueSlug (generateUniqueSlug +
saveWithUniqueSlugRetry), redundanter Controller-Helper entfernt (M3).
- API-/Legacy-Text wird vor der Persistenz sanitisiert (M6);
Scheduler/Legacy-Tracking ignorieren soft-gelöschte PMs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ein vergessener Postman-Platzhalter (PM_ID) lief als String in die
int-typisierten Controller-Parameter. Numerische where-Constraints auf
den v1- und /service-Gruppen; Legacy faellt in den 410-Catch-all.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Befund: v1 hatte keine KI-Deklarationsfelder — Submit lief seit der
KI-Kennzeichnungspflicht (09.07.) immer auf 422 und haette alle
Legacy-API-Kunden blockiert (Suite uebersah es: Factory deklariert).
- v1-Submit verlangt ai_text_declaration; der Call gilt dokumentiert
als verbindliche Bestaetigung (Art. 50 KI-VO) und schliesst die
Archiv-Kenntnisnahme (AGB par. 13) ein
- Bild-Upload verlangt ai_declaration (original/ai_generated/ai_edited)
- Legacy-/service-Aliasse defaulten auf none/original — das
API-Kunden-Mailing (R6.4) weist auf die Erklaerungswirkung hin
- OpenAPI v1.yml + lang-Hinweis aktualisiert; Tests erweitert
(Submit/Image/LegacyCompatibility)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bestehende Kunden-Integrationen der Altportale laufen nach dem Relaunch
weiter, ohne dass Kunden etwas umstellen muessen:
1. legacy:import-api-keys uebernimmt die api_keys aus den Legacy-DBs
(sf_guard_user_profile) als Sanctum-Tokens mit identischem Secret
(Sanctum loest Tokens ohne id|-Praefix per sha256-Hash auf) — nur
fuer berechtigte Nutzer (aktiver Zahlungsstatus/Bestandsschutz,
ApiAccessEligibilityService); idempotent, mit Dry-Run. Probe gegen
die lokalen Snapshots: 406 Keys wuerden uebernommen.
2. Die Auth-Middleware uebersetzt die alten Uebergabeformen (X-ApiKey-
Header, api_key-Parameter) fuer gueltige Keys in Bearer; unbekannte
Keys erhalten weiterhin 410 mit Migrationshinweis.
3. Die dokumentierten /service/...-Pfade der Alt-API sind als Aliasse
auf die v1-Controller gelegt (pressreleases inkl. Bilder, companies
lesend); nicht uebernommene Alt-Endpoints (Pressemappen/Kontakte
anlegen) antworten 410 mit Hinweis auf Kundenkonto und neue Doku.
API-Seite + OpenAPI entsprechend aktualisiert; Go-Live-Checkliste um den
Import-Schritt (nach dem Grandfathering) ergaenzt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
9A — Gelb geht direkt live (Entscheidung 12.06.2026):
- routeByClassification(): Gelb durchlaeuft denselben Auto-Publish-Pfad
wie Gruen (autoPublishApproved); nur Rot wird abgelehnt
- Scheduler publiziert faellige gelbe + gruene PMs; unklassifizierte
bleiben als Fallback in der manuellen Queue
9B — Slot-Verbrauch bei Veroeffentlichung (Decision-Update 3.2):
- Increment aus submitForReview() entfernt; publish() und
changeStatusFromAdmin() zaehlen idempotent beim ersten
published-Uebergang (Pruefung ueber Status-Logs); Rot kostet nichts
- Submit-Guard: Einreichen erfordert freien Slot
(QuotaExceededException, API 422)
9C — Submit-Gate vorbereitet (Decision-Update 5.1):
- User::hasActiveBooking()-Stub hinter config/billing.php
(enforce_booking, Default aus); Tarif-Modul ersetzt nur den Rumpf
- Einreichungs-Modal zeigt ohne Buchung einen Buchungs-Hinweis;
Server-Guard (BookingRequiredException), API antwortet 402
- Fix: Customer-Create legte PMs bei "Zur Pruefung senden" direkt mit
Status review an (vorbei an Blacklist/Quota/KI/Status-Log) — laeuft
jetzt immer ueber submitForReview()
Suite: 451 passed, 4 skipped (9 neue Tests). Pint clean.
Plan: docs/PHASE-9-FLOW-UND-TARIFE-PLAN.md (Block 2 nach Review-Stopp).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
