Anmeldung

Modi

Bei Apps mit Anmeldung prüft connic die Session, bevor es eine Datei ausliefert oder eine Connector- oder Datenanfrage weiterleitet. Eine neue App ohne Anmeldeeinstellungen im Code oder im Dashboard nutzt connic-Konten und lässt jedes Projektmitglied hinein.

Code oder Dashboard

Lege die Anmeldung im Block auth von apps/<key>.yaml fest, oder lass auth weg und stelle sie im Dashboard auf dem Tab Settings der App unter Sign-in ein. Deklariert die Datei auth, hat die Datei Vorrang: Das Dashboard zeigt die Einstellungen mit dem Badge In code und lässt sie nicht ändern. Für update_app in connic MCP gilt dieselbe Regel.

Hört ein Deployment auf, auth zu deklarieren, behält die App ihre letzten Anmeldeeinstellungen samt OIDC Client Secret, und ab dann verwaltet das Dashboard sie. Ein Deployment ändert nur dann, wer eine App öffnen darf, wenn die Datei es so festlegt.

Jede Änderung an den geltenden Anmeldeeinstellungen, ob im Code oder im Dashboard, meldet alle Besucher von der App ab.

connic-Konten

auth:
  mode: connic
  groups: [Support, Admin]     # optional; ohne groups jedes Projektmitglied

Besucher melden sich mit ihrem connic-Konto an und müssen Mitglied des Projekts sein. Mit groups brauchen sie zusätzlich eine dieser Berechtigungsgruppen; der Owner des Projekts kann die App immer öffnen. Jede Gruppe muss im Projekt existieren, sonst scheitert das Deployment. In Zugriffsregeln und im Run-Kontext ist user.id die connic-Nutzer-ID des Besuchers, und user.groups listet seine Berechtigungsgruppen im Projekt auf.

connic-Konten eignen sich für interne Tools und Staging-Environments. Für Mitarbeitende deiner Kunden oder Partner nimmst du deren Identity Provider.

Dein Identity Provider

Mit oidc melden sich Besucher bei einem beliebigen OpenID-Connect-Provider an. connic nutzt den Authorization Code Flow mit PKCE und schickt das Client Secret per HTTP Basic Authentication (client_secret_basic).

auth:
  mode: oidc
  issuer: https://login.microsoftonline.com/${ENTRA_TENANT_ID}/v2.0
  client_id: ${PORTAL_CLIENT_ID}
  client_secret: ${PORTAL_CLIENT_SECRET}
  allowed_domains: [example.com]
  allowed_groups: [support]
  groups_claim: groups

Felder eines anderen Modus werden abgelehnt, eine connic-App kann also kein issuer setzen.

Sessions

Nach der Anmeldung hält der Browser ein Session-Cookie für den Host der App. connic erneuert es alle 10 Minuten und prüft dabei jedes Mal den Zugriff: bei connic-Konten Projektmitgliedschaft und Berechtigungsgruppen, bei Identity Providern die erlaubten E-Mail-Domains und Gruppen. Stellt der Provider Refresh Tokens aus, fragt connic ihn bei jeder Erneuerung, und wer dort entfernt wird, verliert den Zugang innerhalb von Minuten. Ohne Refresh Tokens wirkt das erst, wenn die Session endet.

Eine Session endet nach 12 Stunden, beim Abmelden oder wenn sich die Anmeldeeinstellungen der App ändern. Die Standard-URL und eine Custom Domain haben jeweils eigene Sessions.

Ohne gültige Session leiten Seitenaufrufe auf /_connic/login um und kehren nach der Anmeldung zum selben Pfad zurück. Alle anderen Anfragen, auch Connector-Aufrufe und die Data API, bekommen 401 mit {"error": "Sign-in required"}. Bekommt die App ein 401, schick den Besucher zu /_connic/login?return=<path>. Der Rückkehrpfad muss auf dem eigenen Host der App bleiben; alles andere, auch Pfade mit Steuerzeichen oder Backslashes, führt zurück zu /.

if (response.status === 401) {
  location.assign(`/_connic/login?return=${encodeURIComponent(location.pathname + location.search)}`);
}

Abmelden

Verlinke auf /_connic/logout. Der Pfad beendet die Session und zeigt eine Seite mit einem Link zur erneuten Anmeldung. Beim Identity Provider bleibt der Besucher angemeldet.

Öffentliche Apps

Öffentliche Apps haben keine Anmeldung, und /_connic/login leitet auf / um. Mit der ersten Anfrage der App an die Data API oder einen Connector legt connic ein zufälliges Secret in einem Cookie ab, das ein Jahr hält, und leitet daraus für jede App eine eigene Besucher-ID ab. Diese ID wird zu user.id in Zugriffsregeln und zu end_user.id in Runs. Wer die ID eines Besuchers kennt, kann nicht in dessen Namen handeln. Löscht jemand die Cookies, bekommt der Browser eine neue ID; sie steht also für einen Browser, nicht für eine Person. Solange das Cookie fehlt, bekommt jede Anfrage eine neue ID. Lass beim ersten Laden deshalb eine Anfrage wie GET /_connic/me abschließen, bevor die App weitere parallel schickt. Regeln für öffentliche Apps beschreibt Öffentliche Besucher.

Cookies

connic setzt diese Cookies auf dem Host der App. Jedes gilt nur für diesen Host und ist Secure, HttpOnly und SameSite=Lax.

Wenn die Anmeldung scheitert

Eine gescheiterte Anmeldung zeigt eine Seite Sign-in didn't work mit einer dieser Meldungen und zählt in den Statistiken der App als fehlgeschlagene Anmeldung.