Annonce de notre nouveau SDK iOS et macOS : TransloaditKit

Mark Masterson

Développeur iOS et macOS · Los Angeles, Californie, États-Unis · Afficher la bio

Un nouveau SDK a fait son apparition en novembre 2017 : notre SDK iOS et macOS, TransloaditKit ! Écrite en Objective-C et utilisable depuis Objective-C comme depuis Swift, la version 1.0.0 apportait aux applications Apple les fonctionnalités de base de Transloadit et la reprise des téléversements grâce à tus⁠. Nous prévoyions d’autres mises à jour pour étendre sa couverture de l’API Transloadit.

Mise à jour de sécurité, septembre 2026 : ceci est l’annonce de publication d’origine, dont la configuration non sécurisée des informations d’identification et les exemples exécutables obsolètes ont été remplacés. Ne placez jamais votre Auth Secret dans Info.plist, dans le binaire d’une application ni dans une configuration téléchargée par l’application. Conservez-le sur un serveur de confiance. Le serveur doit authentifier l’utilisateur et autoriser le téléversement demandé avant d’approuver toute signature. Notre guide Signature Authentication explique cette frontière et comment exiger des signatures dans votre Workspace.

Au lancement, le paquet CocoaPods s’appelait Transloadit. L’intégration Swift nécessitait aussi la dépendance Arcane pour contourner les en-têtes d’origine. Ces détails de configuration concernent la version Objective-C ; ils ne constituent pas des instructions pour l’implémentation Swift ultérieure. La version 1.0.0 signait les requêtes au sein du SDK à l’aide de son secret et n’exposait aucun callback de signature externe. Déplacer ce secret vers un autre fichier de configuration de l’application ne réglerait pas le problème de frontière de sécurité.

La version 3.5.0 de TransloaditKit⁠, publiée ultérieurement, a ajouté un initialiseur signatureGenerator qui permet à l’Auth Secret de rester sur votre serveur. Pour cette version, la déclaration CocoaPods est la suivante :

pod 'Transloadit', '3.5.0'

Les utilisateurs de Swift Package Manager peuvent sélectionner exactement la même version depuis le dépôt TransloaditKit⁠. La fonction utilitaire Swift suivante utilise l’API publique de cette version. Elle accepte l’intégration de signature existante du backend de l’application ; elle n’implémente pas de service de signature :

import Foundation
import TransloaditKit

func makeUploadClient(
    authKey: String,
    configuration: URLSessionConfiguration = .default,
    signatureGenerator: @escaping SignatureGenerator
) -> Transloadit {
    Transloadit(
        apiKey: authKey,
        sessionConfiguration: configuration,
        signatureGenerator: signatureGenerator
    )
}

func makeResizeStep() -> Step {
    Step(
        name: "encode",
        robot: "/image/resize",
        options: ["width": 400, "result": true]
    )
}

L’intégration de signature reçoit exactement les paramètres sérialisés. Votre backend ne doit autoriser que les instructions de traitement, les destinations, les limites de fichiers et l’expiration permises pour cet utilisateur ; rejetez les instructions arbitraires choisies par le client. Signez les octets approuvés sans les resérialiser. Ne renvoyez que la signature, et terminez le callback du SDK par un succès ou un échec sur chaque chemin d’exécution, y compris en cas de délai d’attente réseau dépassé.

Il existe une limitation importante dans 3.5.0 : la création d’une Assembly fixe auth.expires à 24 heures dans le futur, et le callback de signature public ne peut pas remplacer ces paramètres. Si votre politique exige une validité plus courte, ce chemin de création ne peut pas la satisfaire. Créez plutôt l’Assembly sur votre backend ou utilisez l’API de création d’Assembly avec des paramètres contrôlés par le serveur. N’acceptez pas silencieusement une expiration plus longue pour faire réussir le callback.

Un exemple rapide de création d’une Assembly

L’exemple d’origine montrait une Assembly de redimensionnement d’images. Son flux de travail comportait plusieurs phases distinctes :

1. Créez un Assembly Step nommé encode à l’aide du Robot /image/resize. La fonction utilitaire Swift ci-dessus exprime cette opération avec l’initialiseur Step plus récent, en ajoutant une largeur de 400 pixels et en demandant un résultat.
2. Dans l’API Objective-C d’origine, créez une Assembly avec les Steps et le nombre de fichiers attendu, puis joignez l’URL du fichier local. Les extraits Swift d’origine utilisaient cette même API Objective-C via son pont Swift.
3. Enregistrez les callbacks de fin et de statut avant de lancer la requête. L’ancien assemblyCompletionBlock recevait la réponse de création de l’Assembly, y compris assembly_ssl_url. L’exemple affectait cette URL avant d’appeler invokeAssembly pour lancer le téléversement et checkAssembly pour vérifier l’état du traitement.
4. Gérez séparément la progression du téléversement, la fin du traitement et les échecs. Recevoir une URL d’Assembly ne signifie pas que ses fichiers ont fini d’être téléversés ou traités.

Le SDK Swift ultérieur utilise createAssembly et un TransloaditPoller renvoyé pour le flux combiné de téléversement et de traitement. Son callback de création n’est pas une notification de résultat final. Les fonctions utilitaires makeUploadClient et makeResizeStep ci-dessus illustrent uniquement la configuration du client et la construction des Steps ; une application a toujours besoin de son intégration backend autorisée, de la sélection des fichiers, du cycle de vie du téléversement et de la gestion des résultats.

Cette séparation est importante pour la reprise des téléversements : tus peut reprendre un transfert après une interruption, tandis que l’Assembly représente le flux de traitement qui l’entoure. Comme pour la version d’origine, nous accueillons volontiers les contributions qui améliorent les deux parties de l’intégration. Consultez la source et la documentation du SDK⁠ pour connaître les API de la version que vous utilisez.