Repository GitHub
Visualizza il codice sorgente e gli esempi su GitHub
Pacchetto pub.dev
didit_sdk
SDK nativo: È l’approccio consigliato per le app Flutter. L’SDK incapsula gli SDK nativi per iOS e Android tramite i canali della piattaforma, per offrire la migliore esperienza utente, una gestione ottimizzata della fotocamera e il pieno supporto NFC.
Requisiti
Requisiti della piattaforma
Il consenso biometrico richiede la versione nativa 4.10.0 o successiva. Per le persone soggette alle leggi dell’Illinois, del Texas o del Colorado, Didit può chiedere un consenso biometrico esplicito prima della prima acquisizione del volto. Una release dell’SDK Flutter che fissa gli SDK nativi iOS e Android alla versione 4.10.0 o successiva mostra questo passaggio. Le versioni precedenti non possono mostrarlo: le loro sessioni proseguono come prima, e la decisione riporta il consenso come non raccolto (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Esegui l’aggiornamento se verifichi persone in questi stati.Installazione
pubspec.yaml:
Varianti dell’SDK nativo
didit_sdk include l’SDK nativo completo.
Per ottenere un binario più leggero, dipendi invece da un pacchetto alternativo: espone esattamente la stessa API Dart e fissa l’SDK nativo corrispondente su entrambe le piattaforme:
package:didit_sdk_core/sdk_flutter.dart.
Configurazione iOS
Il plugin supporta entrambi i gestori di dipendenze iOS di Flutter: Swift Package Manager e CocoaPods.Swift Package Manager
Se la tua versione di Flutter ha il supporto a Swift Package Manager abilitato (attivalo esplicitamente conflutter config --enable-swift-package-manager su Flutter 3.24+), il plugin viene utilizzato automaticamente come pacchetto Swift.
Non serve alcuna configurazione del Podfile: la dipendenza nativa DiditSDK viene risolta autonomamente da GitHub.
Imposta il deployment target iOS della tua app in Xcode (target Runner e progetto) al minimo previsto per il pacchetto scelto: 15.0 per didit_sdk e didit_sdk_nfc, 13.0 per didit_sdk_core e didit_sdk_autodetection.
CocoaPods
Condidit_sdk, il plugin seleziona la variante dell’SDK nativo iOS da $DiditSdkIosVariant, una variabile globale Ruby che imposti nel file ios/Podfile della tua app (il pod DiditSDK non è disponibile su CocoaPods trunk):
didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), esso fissa direttamente il proprio subspec nativo e ignora $DiditSdkIosVariant: mantieni la riga pod del tuo Podfile e il deployment target allineati a quella variante (ad esempio pod 'DiditSDK/Core', :podspec => ... con platform :ios, '13.0').
Le varianti
all e nfc richiedono un deployment target iOS 15.0+; core e autodetection possono avere come target iOS 13.0. Quando cambi variante, pulisci prima CocoaPods (rm -rf Pods Podfile.lock) in modo che la variante SDK precedente non venga riutilizzata.Configurazione Android
Per impostazione predefinita il plugin dipende dall’SDK Android completo, NFC incluso. Per compilare senza NFC, aggiungi questa riga aandroid/gradle.properties:
me.didit:didit-sdk con me.didit:didit-sdk-core, rimuovendo il modulo di lettura NFC e le sue dipendenze JMRTD/SCUBA/BouncyCastle.
Quando l’NFC è abilitato (impostazione predefinita), aggiungi questa regola di packaging a android/app/build.gradle.kts per risolvere un file di metadati duplicato di BouncyCastle:
mergeDebugJavaResource. La regola non serve quando diditSdkAndroidNfcEnabled=false.
L’SDK nativo Android viene risolto da un repository Maven remoto su GitHub (dalla versione 3.4.0 del plugin): nella tua app non serve alcuna configurazione Maven manuale.
Permessi
iOS
Aggiungi le seguenti chiavi al fileInfo.plist della tua app:
Configurazione NFC
Per abilitare la lettura NFC di passaporti e carte d’identità dotati di chip:-
Aggiungi la funzionalità NFC in Xcode:
- Seleziona il tuo target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
-
Aggiungi gli identificatori ISO7816 a
Info.plist:
D392F000260100000001 consente all’SDK di leggere la Japan My Number Card tramite JPKI: senza questo identificatore, iOS non segnala la carta all’SDK. La lettura della My Number Card non è ancora abilitata in produzione e l’identificatore non modifica nulla per gli altri documenti, quindi puoi aggiungerlo fin da ora.
- Aggiungi un file di entitlements con la lettura dei tag NFC abilitata:
com.apple.developer.nfc.readersession.formats mancante.
Questa configurazione NFC non è necessaria per le varianti core o autodetection ($DiditSdkIosVariant), né per i pacchetti didit_sdk_core / didit_sdk_autodetection: nessuno di questi legge i chip.
Android
L’SDK dichiara i seguenti permessi nel proprioAndroidManifest.xml e vengono uniti automaticamente:
Le funzionalità hardware di fotocamera e NFC sono dichiarate come facoltative (
android:required="false"), quindi la tua app può essere installata anche su dispositivi privi di queste funzionalità. Quando diditSdkAndroidNfcEnabled=false, l’SDK non aggiunge l’autorizzazione e la funzionalità NFC di Android.
Autorizzazioni di runtime
L’SDK gestisce automaticamente le richieste di autorizzazione di runtime di Android. Quando l’utente arriva a un passaggio che richiede l’accesso alla fotocamera:- L’SDK chiede l’autorizzazione ad accedere alla fotocamera se non è già stata concessa
- Se l’utente nega il permesso, viene mostrato un messaggio di errore con un pulsante Try Again
- Se l’utente concede il permesso, il flusso di verifica prosegue
startVerification(): l’SDK se ne occupa internamente.
Avvio rapido
Metodi di integrazione
L’SDK supporta due metodi di integrazione:Metodo 1: Session Token (consigliato per la produzione)
Crea una sessione sul tuo backend con l’API Create Verification Session, poi passa il token all’SDK:- Associazione delle sessioni ai tuoi utenti (
vendor_data) - Impostazione di metadati personalizzati
- Configurazione dei callback per ogni sessione
Metodo 2: Workflow ID (integrazione più semplice)
Per integrazioni più semplici, l’SDK può creare le sessioni direttamente con il tuo workflow ID, senza bisogno di un backend:I parametri avanzati della sessione (
contact_details, expected_details, metadata) sono supportati solo con il metodo Session Token, in cui il tuo backend chiama l’API Create Session con il supporto completo dei parametri. Passa il session_token restituito a DiditSdk.startVerification().Configurazione
Personalizza il comportamento dell’SDK passando un oggettoDiditConfig:
startVerificationWithWorkflow, passa config come parametro denominato:
Opzioni di configurazione
Opzioni della fotocamera
Le opzioni della fotocamera corrispondono alle opzioni della fotocamera del Web SDK. Ogni obiettivo èCameraLens.front o CameraLens.back.
Se il dispositivo non dispone dell’obiettivo richiesto, l’SDK usa la prima fotocamera disponibile.
Il selettore della fotocamera è inoltre nascosto sui dispositivi che hanno una sola fotocamera.
Imposta un’opzione del selettore su false per bloccare l’utente sull’obiettivo predefinito di quel passaggio.
Tema e colori: i colori, gli sfondi e le impostazioni della schermata introduttiva si configurano tramite le tue impostazioni White label nella Didit Console, non nella configurazione dell’SDK. Così l’identità del marchio resta coerente su tutte le piattaforme.
Supporto linguistico
L’SDK supporta 54 lingue. Se non viene specificata alcuna lingua, l’SDK usa la lingua del dispositivo, con l’inglese come lingua di ripiego.Parametri avanzati della sessione
I parametri comecontact_details, expected_details e metadata sono supportati solo tramite il metodo con session token. Il tuo backend chiama POST /v3/session/ con il supporto completo dei parametri, poi passa il session_token restituito all’SDK.
Il metodo Dart
startVerificationWithWorkflow accetta solo workflowId, vendorData e config. Le versioni precedenti alla 3.4.0 esponevano i parametri contactDetails, expectedDetails e metadata, ma sono stati rimossi perché l’endpoint Unilink non li rispetta.Gestione dei risultati
SiastartVerification sia startVerificationWithWorkflow restituiscono un Future<VerificationResult>. Il risultato è una classe sealed: usa il pattern matching per determinare l’esito.
Casi del risultato
Proprietà di SessionData
Tipi di errore
L’enumVerificationErrorType espone i seguenti casi:
Connessione persa
Se il dispositivo perde la connessione durante la verifica, l’SDK mostra una schermata “Nessuna connessione a Internet” al posto del flusso, invece di lasciare un passaggio in caricamento. Continua a controllare in background e chiude automaticamente la schermata appena Didit torna raggiungibile, e l’utente prosegue dal passaggio in cui si trovava. La schermata offre Riprova e, se il pulsante di chiusura non è disattivato, Esci dalla verifica. Uscire termina la verifica con un risultatoVerificationFailed il cui tipo di errore è networkError, così la tua app sa che l’utente è uscito a causa della connessione.
Esempio completo di gestione dei risultati
Esempio end-to-end (sessione backend → Flutter SDK → webhook)
Questa è l’integrazione pronta per la produzione: il tuo backend crea la sessione, la tua app Flutter riceve ilsession_token e l’SDK esegue il flusso. La decisione finale viene inviata al tuo backend tramite webhook: non fidarti mai del solo risultato lato client.