Bêta du SDK Flutter Transloadit : prise en charge multiplateforme

Joseph Grabski

Responsable du contenu · Rochester, Royaume-Uni · Afficher la bio

En septembre 2022, nous avons accueilli un SDK Transloadit pour Flutter, le framework de développement multiplateforme. La version 0.2.0 fournissait des surcouches pour les opérations de l’API Transloadit et le téléversement de fichiers avec reprise via le protocole tus. Nous l’avons présenté comme une bêta, avons invité les utilisateurs à le tester et à signaler les bugs, et ne le considérions pas comme prêt pour la production.

Le paquet est répertorié sur pub.dev⁠.

Mise à jour de sécurité, septembre 2026 : l’exemple d’origine plaçait un Auth Secret dans le client Flutter. Ne distribuez pas ce secret dans une application mobile, de bureau ou web, et ne le récupérez pas dans l’application depuis une configuration distante. La présentation exécutable a été remplacée par le processus historique et les limites spécifiques du paquet décrites ci-dessous. Conserver le secret sur un backend de confiance est obligatoire ; le dissimuler dans une application ne le rend pas privé.

Installation

La version présentée ici était 0.2.0. Le registre de paquets indique 0.2.1 comme dernière version publiée au moment de cette mise à jour ; il ne contient pas la version 1.0.0 présentée auparavant dans l’exemple de dépendance de cet article. Le paquet 0.2.1 publié déclare la contrainte de SDK Dart >=2.12.0 <3.0.0 et une dépendance au SDK Flutter. Il ne peut pas être ajouté tel quel à un projet utilisant Dart 3.

Le chemin d’import de la bibliothèque est package:transloadit/transloadit.dart. Ces détails identifient le paquet historique ; ils ne constituent pas une recommandation de rétrograder un projet Flutter actuel. Consultez les métadonnées du paquet publié⁠ lorsque vous examinez une intégration existante.

Utilisation du SDK

La classe cliente publiée est TransloaditClient, et non la classe Transloadit utilisée dans l’exemple d’origine. Le client regroupe des opérations telles que la création d’Assemblies, la récupération de leur statut et la gestion des Templates, afin que les appelants n’aient pas à construire chaque requête HTTP manuellement.

Cependant, le constructeur 0.2.1 exige un authSecret, et son implémentation des requêtes signe les paramètres localement. Il n’offre aucune fonction de rappel publique pour des signatures générées par le serveur. Le simple fait de retirer le secret du constructeur, de passer une chaîne vide ou d’ajouter une URL de backend ne transforme pas ce paquet en intégration de signature mobile sûre. Cette limite s’applique aussi au processus 0.2.0 décrit dans l’annonce.

Une intégration de production nécessite un autre chemin de requête : votre backend doit authentifier l’utilisateur, autoriser le téléversement et contrôler les instructions de traitement, les destinations, les limites et l’expiration. Il peut créer l’Assembly lui-même ou fournir des paramètres approuvés et de courte durée, ainsi qu’une signature, à un client capable de les soumettre sans modification. Pour ce protocole, consultez notre guide de Signature Authentication et l’API de création d’Assembly. Il s’agit d’une alternative architecturale, et non d’une fonctionnalité fournie par ce paquet Flutter.

Créer une Assembly

La présentation d’origine redimensionnait une image locale à 400 pixels de large. Son déroulement reste utile pour comprendre l’organisation du SDK :

1. Appelez la méthode newAssembly du client pour obtenir un TransloaditAssembly. Celui-ci rassemble les fichiers et les Steps avant l’envoi de la requête.
2. Joignez l’image d’exemple, cat.jpg, avec addFile. Le paquet publié accepte un File et encapsule son chemin dans un XFile pour le client tus.
3. Ajoutez un Step nommé resize, qui utilise le Robot /image/resize et le paramètre width réglé sur 400. Il s’agit de l’instruction de traitement de l’image, distincte du transfert de ses octets.
4. Soumettez avec createAssembly. Le paquet crée d’abord l’Assembly et utilise son URL de téléversement tus pour transférer les fichiers.
5. Utilisez onProgress pour la progression du transfert et onComplete pour un téléversement de fichier terminé. Dans ce processus, la fin du téléversement est distincte de la fin du traitement ; une fonction de rappel de téléversement ne suffit pas à elle seule à établir que l’image redimensionnée est prête.
6. Lisez le TransloaditResponse renvoyé via response.data['ok'], plutôt que d’indexer directement l’objet de réponse lui-même. ASSEMBLY_COMPLETED indique un traitement réussi. Le paquet peut aussi renvoyer une Assembly annulée ou interrompue, et les erreurs nécessitent leur propre gestion.

Ces détails d’API expliquent le processus de la bêta sans présenter la voie non sûre de signature côté client comme une recette de téléversement actuelle. Une solution de remplacement doit préserver la distinction entre la progression du transfert et les résultats du traitement, tout en conservant l’autorisation et les secrets sur le backend.

Et ensuite ?

L’annonce renvoyait à l’origine vers notre série sur une application de recettes Flutter, comme exemple plus complet. Cette présentation historique distribuait elle aussi des informations d’accès via une configuration distante ; elle ne doit donc pas être suivie comme guide d’implémentation sécurisée. Pour concevoir une nouvelle intégration, commencez par les références sur l’authentification et les Assemblies ci-dessus.

Pour l’historique d’implémentation et le suivi des tickets de la bêta, consultez le dépôt du SDK Flutter⁠. L’invitation à contribuer reste valable : une intégration client acceptant des paramètres autorisés générés par le serveur nécessiterait sa propre implémentation et sa propre vérification avant que nous puissions la recommander ici.