Berechtigungen & Zustimmung

Eine Methacore App handelt im Namen eines Mitglieds. Was sie darf, bestimmen Scopes – und das Mitglied stimmt ihnen zu, bevor die App auch nur startet. Diese Seite beschreibt die Scopes der API „Methacore Apps“, den Ablauf der Zustimmung und was passiert, wenn eine App später mehr braucht.

Scopes

Die Spalte Beim Mitglied zeigt den Text, den Mitglieder in der Zustimmung und bei „Zugriff erweitern“ lesen. Neben diesen Scopes kann eine App die Scopes anderer Methacore-APIs verlangen (etwa mc.members:read), wenn sie im Projekt freigeschaltet sind – siehe die Datenquelle request. Auch dann gilt: Ein Token kann nie mehr als das Mitglied selbst.

Drei Stellen, eine Liste

Das Studio bietet unter Einstellungen nur Scopes an, die der Client trägt. Verlangt eine App zur Laufzeit einen Scope, den ihr Client nicht hat, lehnt der DevHub ab – dann hilft nur, den Client zu erweitern.

Die Zustimmung

Beim ersten Öffnen startet eine App nicht sofort. Der Host zeigt stattdessen „Noch nicht freigegeben“ mit Icon und Name der App, dem Anbieter (Name des DevHub-Teams), den verlangten Berechtigungen in Klartext und den Knöpfen „Zugriff erlauben“ und „Zurück“. Bei externen Apps kommt vorher die Warnung zum Anbieter.

„Zugriff erlauben“ öffnet die Zustimmungsseite des DevHub – im Dashboard als Pop-up, auf dem Handy im In-App-Browser:

1. Der Host holt bei Methacore ein einmaliges Anmelde-Ticket für das Mitglied und hängt es an die Autorisierung. Der DevHub reicht es an die Methacore-Anmeldung weiter – das Mitglied ist schon angemeldet und muss sich nicht ein zweites Mal anmelden. Klappt das nicht, erscheint wie gewohnt das Anmeldeformular.
2. Die Zustimmungsseite zeigt Logo, Anbieter, Datenschutzerklärung und Nutzungsbedingungen aus dem DevHub-Projekt und die Berechtigungen.
3. Gehört das Mitglied mehreren Vereinen an, wählt es den Verein, für den die App gelten soll. Zur Wahl stehen nur Vereine, deren Richtlinie die App zulässt.
4. Nach der Zustimmung geht der Code an https://apps-run.methacore.de/oauth/callback, der Host tauscht ihn per PKCE gegen ein Token und startet die App.

Das Token bewahrt der Host je App und Verein auf – im Dashboard im Browser, auf dem Handy im sicheren Speicher des Geräts – und erneuert es selbst. Beim nächsten Öffnen startet die App ohne Rückfrage. Die App selbst sieht nur das Access-Token, nie ein Refresh-Token.

Mitglied            Host (Dashboard/Handy)          DevHub                    Methacore
   │ Zugriff erlauben ─▶│                              │                          │
   │                    │── Anmelde-Ticket holen ─────────────────────────────────▶│
   │                    │── /v1/oauth/authorize?…&session=<ticket> ─▶│            │
   │                    │                              │── Anmeldung (Ticket) ───▶│
   │◀── Zustimmungsseite ───────────────────────────── │                          │
   │ zustimmen ────────────────────────────────────────▶│                          │
   │                    │◀── code an apps-run…/oauth/callback                     │
   │                    │── /v1/oauth/token (PKCE) ───▶│                          │
   │                    │── startet die App, Token über die Bridge                │

Wenn eine App mehr braucht

Kommt eine neue Version mit zusätzlichen Scopes, oder verlangt die App zur Laufzeit einen Scope, den ihr Token nicht trägt, fragt der Host erneut – aber nur nach dem Unterschied:

• Neue Scopes in auth.scopes: Beim nächsten Öffnen merkt der Host, dass dem gespeicherten Token etwas fehlt, und zeigt „Zugriff erweitern“ mit genau den fehlenden Berechtigungen.
• Zur Laufzeit: Antwortet die API mit 403 und This token does not carry the <scope> scope., bittet die App über die Bridge um auth.token mit { scopes: ["<scope>"], reauthorize: true }. Der Host zeigt „Zugriff erweitern“; nach der Zustimmung wiederholt die App den Aufruf einmal.

Im Browser öffnet der Host die Zustimmung nur nach einem Klick des Mitglieds – Pop-ups ohne Klick blockiert jeder Browser. Verweigert das Mitglied, bekommt die App einen Fehler und das alte Token bleibt, wie es war.

Gehostete Apps erledigen das alles über die Runtime, externe über das SDK. Du musst nichts davon selbst bauen.

Vereinsrichtlinie

Administratoren eines Vereins legen im Dashboard unter Organisation → Apps fest, welche Apps ihre Mitglieder nutzen dürfen – getrennt für Dashboard und Mitglieder-App:

Eine App, die die Richtlinie nicht zulässt, erscheint nicht im Store dieses Vereins, und in der Zustimmung lässt sich der Verein nicht wählen.

Was Mitglieder sehen

• im App Store und in der Detailansicht: die verlangten Berechtigungen, den Anbieter und den Link zur Datenschutzerklärung
• bei gehosteten Apps mit freigegebener Live-Version das Siegel „Von Methacore geprüft“, bei externen Apps „Extern – nicht von Methacore geprüft“
• vor dem ersten Start „Noch nicht freigegeben“, bei neuen Berechtigungen „Zugriff erweitern“