Files

T

Sascha WolfandClaude Opus 5 0a2cf52e8a feat(kontakte): Zustaendigkeit, LinkedIn-Foto, Netzwerkauswahl

Drei Verbesserungen an den Kontakten:

* Beim Anlegen ist der angemeldete Benutzer voreingestellt zustaendig.
  Bisher stand dort der erste Benutzer der Liste - fast immer falsch.
* Wird eine LinkedIn-Adresse hinterlegt, holt das CRM das oeffentliche
  Profilfoto und setzt es als Kontaktfoto: beim Verlassen des Feldes
  einmal je Adresse, solange kein Foto gesetzt ist, und auf Klick ueber
  den Knopf daneben. Der Abruf laeuft ueber das Backend
  (server/src/linkedinPhoto.js, POST /api/leads/linkedin-photo), weil
  ihn die Same-Origin-Policy im Browser verhindert. Gelesen wird die
  Open-Graph-Vorschau der Profilseite; Herkunft, Groesse und Antwortzeit
  des Bildes werden geprueft, Platzhalter-Silhouetten abgewiesen.
  Schlaegt der Abruf fehl, steht der Grund unter dem Feld.
* In der Netzwerkansicht hebt ein Klick auf freie Flaeche die Auswahl
  auf - das Diagramm sieht danach aus wie beim Wechsel in die Ansicht.
  Ein Ziehen des Hintergrunds (ab 4 px) laesst die Auswahl stehen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-09 23:25:37 +02:00

4.5 KiB

Raw Blame History

01 Architektur

Bausteine

Drei Teile, keiner davon spricht direkt mit einem anderen ausser über HTTP bzw. SQL:

Teil	Technik	Wo
Frontend	React 19, TypeScript, Tailwind 4, Vite	statisches Build in `/var/www/perinco_CRM/dist`
Backend	Express 4, mysql2 (CRM), Sequelize (Scanner)	`/var/www/perinco_CRM/server`, `127.0.0.1:5006`
Datenbank	MariaDB 10.11	`perinco_CRM` und `perinco_scanner`

Der Browser spricht nie direkt mit MariaDB - deshalb überhaupt ein Backend. Das Backend bindet ausschließlich auf 127.0.0.1 und ist von außen nur über den Apache-Reverse-Proxy erreichbar.

Topologie

flowchart LR
    U(("Browser")) -->|"HTTPS"| A["Apache :443<br/>pcrm.perinco.de"]
    A -->|"/"| D["dist/<br/>SPA, FallbackResource"]
    A -->|"/api"| E["Express :5006"]
    E --> C[("perinco_CRM")]
    E --> S[("perinco_scanner")]

Der Scanner im CRM hängt unter /api/scanner und braucht damit keine eigene Apache-Regel: alles läuft über den bestehenden /api-Proxy. Dasselbe gilt für die Postfachanbindung unter /api/mail (siehe 11 Postfachanbindung).

Ausgehende Verbindungen

Das Backend spricht von sich aus mit vier fremden Diensten. Alle sind optional - fehlen die Zugangsdaten oder ist das Ziel nicht erreichbar, läuft die Anwendung ohne den jeweiligen Teil weiter.

Ziel	Wofür	Ausgelöst von
Projektbörsen	Scraping der Projektangebote	Scanner-Scheduler
`api.openai.com`	Bewertung Lebenslauf gegen Projekt	Scanner-Pipeline
`login.microsoftonline.com`, `graph.microsoft.com`	Postfach `crm@perinco.de` lesen	Mail-Scheduler
`linkedin.com`, `media.licdn.com`	Profilfoto zu einem Kontakt holen	Benutzer im Kontaktformular

Der LinkedIn-Abruf ist der einzige, den ein Benutzer direkt auslöst: Er liest die öffentliche Vorschau (og:image) einer Profilseite und lädt das Bild vom LinkedIn-CDN. Keine Anmeldung, kein Zugriff auf geschützte Inhalte - schlägt der Abruf fehl, bleibt es beim Hochladen von Hand.

Die Postfachanbindung schickt keine Mailinhalte an Dritte: Kontaktdaten werden auf dem Server aus Graph-Feldern und Signaturen gelesen, ohne Sprachmodell.

Anfrageweg mit Anmeldung

sequenceDiagram
    actor B as Browser
    participant A as Apache
    participant E as Express
    participant M as MariaDB

    B->>A: POST /api/auth/login
    A->>E: weiterleiten
    E->>M: SELECT crm_users WHERE username
    M-->>E: Zeile mit bcrypt-Hash
    E->>E: bcrypt.compare
    E-->>B: { token (JWT, 12 h), user }
    Note over B: Token im localStorage

    B->>A: GET /api/scanner/matches<br/>Authorization: Bearer ...
    A->>E: weiterleiten
    E->>E: requireAuth: JWT pruefen
    E->>M: SELECT crm_users WHERE id (ist der noch aktiv?)
    E->>M: SELECT matches JOIN agents, projects
    M-->>E: Treffer
    E-->>B: JSON

Bei 401 löscht das Frontend das Token und springt zurück auf den Anmeldeschirm (setUnauthorizedHandler in src/lib/api.ts). Das Token wird bei jeder Anfrage neu gegen die Datenbank geprüft - ein deaktivierter Benutzer ist sofort draußen, ohne auf den Ablauf des Tokens zu warten.

Rollen

flowchart TD
    L["Anmeldung"] --> R{"Rolle"}
    R -->|admin| A["Dashboard, Akquise, Opportunities, Interviews, Kontakte, Mails, Scanner<br/>Einstellungen: Nutzerverwaltung, Mein Konto, Akquise, Postfach, Scanner, Whisper"]
    R -->|user| U["Dashboard, Akquise, Opportunities, Interviews, Kontakte, Mails, Scanner<br/>Einstellungen: Mein Konto, Akquise, Whisper"]

Bei den Mails darf jede Rolle lesen und zuordnen - crm@perinco.de ist ein gemeinsames Vertriebspostfach. Einrichten, Verbindungstest und manueller Abgleich sind Administratoren vorbehalten.

Die Rollenprüfung sitzt doppelt: das Menü blendet aus, was nicht erlaubt ist, und das Backend weist Zugriffe zusätzlich mit 403 ab (requireAdmin). Ausnahme ist GET /api/users/directory - die Benutzerliste brauchen alle Rollen für Netzwerkdiagramm, Zuständigkeiten, @-Mentions, Teilnehmerauswahl und Terminfarben. Passwort-Hashes liefert der Endpunkt nie.

Ein Sicherheitsnetz im Backend verhindert, dass der letzte aktive Administrator degradiert, deaktiviert oder gelöscht wird.

Belegte Ports auf dem Server

Der Rechner hostet weitere Dienste (n8n, Docker, ~15 Apache-Vhosts). Vor jeder Portbelegung ss -tlnp prüfen. Relevant hier:

Port	Dienst
5006	perinco CRM Backend (nur `127.0.0.1`)
3000	weitere Vite-App
5678	n8n

4.5 KiB Raw Blame History