Plattformkonfiguration
Die Authentifizierung erfolgt im externen Browser. Nach Abschluss der Authentifizierung öffnet der Browser eine URL mit dem benutzerdefinierten Schema der App, und das Betriebssystem übergibt diese URL an die App. Das Schema muss in der App registriert werden. Die Bibliothek nimmt keine Änderungen am Manifest oder an Info.plist vor.
Registrieren Sie unter iOS (CFBundleURLSchemes) und Android (<data android:scheme="...">) denselben Schemanamen. Die Namen müssen exakt übereinstimmen.
iOS
Fügen Sie das Schema in ios/Runner/Info.plist hinzu.
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>com.yourcompany.yourapp</string>
<key>CFBundleURLSchemes</key>
<array>
<string>yourscheme</string>
</array>
</dict>
</array>
Android
Fügen Sie in android/app/src/main/AndroidManifest.xml die CallbackActivity von flutter_web_auth_2 hinzu.
<activity
android:name="com.linusu.flutter_web_auth_2.CallbackActivity"
android:exported="true"
android:taskAffinity="">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<!-- Minimalkonfiguration: nur das Schema -->
<data android:scheme="yourscheme" />
<!-- Optional (nur OAuth): host/path auf die benutzerdefinierte URL einschränken, die der Browser letztlich öffnet.
MiAuth kehrt ohne host/path zu `yourscheme://` zurück; wenn Sie auch MiAuth verwenden, behalten Sie den Eintrag nur mit Schema bei. -->
<!-- <data android:scheme="yourscheme" android:host="oauth" android:path="/callback" /> -->
</intent-filter>
</activity>
Die vollständige Konfiguration finden Sie unter example/android/app/src/main/AndroidManifest.xml. Verwenden Sie diese Datei als Grundlage für die Android-Konfiguration.
Hinweise:
- Das Attribut
android:labelvon<intent-filter>kann weggelassen werden. - Ab Android 12 (API 31 oder höher) muss für Activities mit einem
intent-filterandroid:exported="true"angegeben werden. - Wenn Ihre App Netzwerkkommunikation durchführt, deklarieren Sie
<uses-permission android:name="android.permission.INTERNET" />direkt unter<manifest>inandroid/app/src/main/AndroidManifest.xml. Eine Deklaration nur im Manifest fürdebugoderprofilegilt nicht für Release-Builds. - Wenn Sie den intent-filter durch host oder path einschränken, muss er zur benutzerdefinierten URL passen, die der Browser letztlich öffnet (entweder zur
redirect_uriselbst oder zur Weiterleitungsziel-URL der Zwischenseite). Wenn Sie auch MiAuth verwenden, schränken Sie ihn nicht ein, da MiAuth zuyourscheme://zurückkehrt.
Wenn der Browser-Tab geöffnet bleibt
Im Beispielmanifest ist gemäß der Empfehlung von flutter_web_auth_2 für die exportierte MainActivity und CallbackActivity jeweils android:taskAffinity="" festgelegt.
Mit dieser Einstellung kann der Browser-Tab nach der Authentifizierung geöffnet bleiben, wenn der Standardbrowser Auth Tab nicht unterstützt (zum Beispiel Chrome vor 137). Die Authentifizierung selbst ist erfolgreich, aber der Benutzer muss den Tab schließen. flutter_web_auth_2 verwendet Auth Tab, wenn der Browser dies unterstützt, andernfalls wechselt es auf Custom Tab. Beim mit Chrome 109 geprüften Fallback-Ablauf startet Chrome die CallbackActivity in einem neuen Task. Daher kann der Tab, der im Task der App verbleibt, nicht geschlossen werden.
- Um den Tab auch beim Fallback zu schließen, entfernen Sie
android:taskAffinity=""sowohl ausMainActivityals auch ausCallbackActivity. Das Entfernen nur bei einer der beiden Activities hilft nicht. Für Auth Tab ist diese Änderung nicht erforderlich. Unter Android 13 mit Chrome 154 wurde der Tab mit beiden Einstellungen geschlossen. taskAffinity=""kann als teilweise Maßnahme gegen Task-Hijacking (StrandHogg) auf Geräten vor Android 11 (API 30) verwendet werden. Android empfiehlt als Schutz vor dieser Sicherheitslücke,minSdkVersionauf mindestens 30 festzulegen. Weitere Informationen finden Sie unter Issue #158 von flutter_web_auth_2.
PlatformException(CANCELED, User canceled login, ...)
Die Bibliothek meldet diesen Fehler als UserCancelledException. Tritt er auf, obwohl der Benutzer nicht abgebrochen hat, sind folgende Ursachen häufig.
- Der Callback hat die App nicht erreicht. Prüfen Sie, ob ein passender
<intent-filter>fürCallbackActivityvorhanden ist. - Eine PWA oder eine andere App hat den Link abgefangen.
- Die
redirect_uristimmt nicht exakt mit dem<link rel="redirect_uri">auf der client_id-Seite überein, sodass Misskey nicht weitergeleitet hat.