Tous les produits
Search
Centre de documentation

Object Storage Service:Configurer des rappels de téléchargement pour les applications mobiles

Dernière mise à jour :Sep 25, 2026

Cette rubrique explique comment mettre en place un service de transfert direct de données pour les applications mobiles à l'aide d'Object Storage Service (OSS) et comment configurer les rappels de téléchargement.

Informations générales

La rubrique Configurer le transfert direct de données pour les applications mobiles décrit la procédure de configuration d'un service de transfert direct de données pour les applications mobiles via OSS. Toutefois, cette solution présente un inconvénient. Pour les applications mobiles Android et iOS, vous pouvez demander un jeton Security Token Service (STS) une seule fois et l'utiliser pour télécharger des données vers OSS à plusieurs reprises. Par conséquent, le serveur d'application ne peut pas déterminer quelles données l'utilisateur a téléchargées, ce qui complique la gestion des données pour le développeur de l'application. Pour résoudre ce problème, OSS propose la fonctionnalité de rappel de téléchargement.

Procédure

Le flux de développement d'un rappel de téléchargement est le suivant :

image

Après qu'OSS a reçu les données d'une application Android ou iOS (étape 5 du schéma) et avant de renvoyer le résultat du téléchargement à l'utilisateur (étape 7), OSS déclenche une tâche de rappel de téléchargement (étape 6). Lors du rappel, OSS envoie une requête à votre serveur d'application, attend une réponse, puis transmet cette réponse à l'application Android ou iOS. Pour plus d'informations, reportez-vous à la rubrique Rappel.

Objectif des rappels de téléchargement

  • Les rappels de téléchargement informent le serveur d'application des informations de base concernant un fichier téléchargé.

    Ces informations peuvent inclure une ou plusieurs variables figurant dans le tableau ci-dessous. Le format du contenu renvoyé est spécifié par l'application Android ou iOS lors du téléchargement.

    Variable système

    Description

    bucket

    Bucket vers lequel l'application mobile télécharge le fichier.

    object

    Nom du fichier après son téléchargement vers OSS par l'application mobile.

    etag

    ETag du fichier téléchargé. Il s'agit du champ etag renvoyé à l'utilisateur.

    size

    Taille du fichier téléchargé.

    mimeType

    Type de ressource.

    imageInfo.height

    Hauteur de l'image.

    imageInfo.width

    Largeur de l'image.

    imageInfo.format

    Format de l'image, par exemple JPG ou PNG.

  • Les rappels de téléchargement permettent de définir des paramètres personnalisés pour transmettre des informations.

    En tant que développeur, vous souhaitez peut-être connaître la version de l'application de l'utilisateur, la version du système d'exploitation, les informations GPS et le modèle du téléphone. Vous pouvez spécifier les paramètres personnalisés suivants lorsqu'un appareil Android ou iOS télécharge un fichier :

    • x:version : spécifie la version de l'application.

    • x:system : spécifie la version du système d'exploitation.

    • x:gps : spécifie les informations GPS.

    • x:phone : spécifie le modèle du téléphone.

    L'application Android ou iOS inclut ces paramètres lors du téléchargement d'un fichier vers OSS. OSS ajoute ensuite ces paramètres au CallbackBody et les envoie au serveur d'application. Ce processus permet au serveur d'application de recevoir les informations.

Prérequis pour le serveur d'application

  • Déployez un service capable de recevoir des requêtes POST. Ce service doit disposer d'une adresse réseau publique, telle que http://example.com/callback.php.

  • Le service doit renvoyer une réponse valide à OSS. La réponse doit être au format JSON et peut contenir du contenu personnalisé. OSS transfère cette réponse du serveur d'application à l'application Android ou iOS. Pour plus d'informations, reportez-vous à la rubrique Rappel.

Configurer un rappel de téléchargement sur l'application mobile

Pour déclencher un rappel de téléchargement lorsque OSS reçoit une requête de téléchargement, incluez le contenu suivant lors de la construction de la requête de téléchargement dans l'application mobile :

  • L'URL de rappel (callbackUrl). Il s'agit de l'URL du serveur vers lequel la requête de rappel est envoyée, par exemple http://example.com/callback.php. Cette adresse doit être accessible depuis Internet.

  • Le corps de la requête de rappel (callbackBody) envoyé au serveur d'application. Le corps peut inclure une ou plusieurs des variables système fournies par OSS.

Supposons que l'URL de rappel de téléchargement de votre serveur d'application soit http://example.com/callback.php. Vous souhaitez obtenir le nom et la taille du fichier téléchargé, et vous avez défini la variable x:phone pour le modèle du téléphone et la variable x:system pour la version du système d'exploitation.

Voici deux exemples de rappels de téléchargement :

  • Exemple de spécification d'un rappel de téléchargement sur iOS :

    OSSPutObjectRequest * request = [OSSPutObjectRequest new];
    request.bucketName = @"<bucketName>";
    request.objectKey = @"<objectKey>";
    request.uploadingFileURL = [NSURL fileURLWithPath:@"<filepath>"];
    // Set callback parameters.
    request.callbackParam = @{
                              @"callbackUrl": @"http://example.com/callback.php",
                              @"callbackBody": @"filename=${object}&size=${size}&phone=${x:phone}&system=${x:system}"
                              };
    // Set custom variables.
    request.callbackVar = @{
                            @"x:phone": @"iphone6s",
                            @"x:system": @"ios9.1"
                            };
  • Exemple de spécification d'un rappel de téléchargement sur Android :

    PutObjectRequest put = new PutObjectRequest(testBucket, testObject, uploadFilePath);
    ObjectMetadata metadata = new ObjectMetadata();
    metadata.setContentType("application/octet-stream");
    put.setMetadata(metadata);
    put.setCallbackParam(new HashMap<String, String>() {
        {
            put("callbackUrl", "http://example.com/callback.php");
            put("callbackBody", "filename=${object}&size=${size}&phone=${x:phone}&system=${x:system}");
        }
    });
    put.setCallbackVars(new HashMap<String, String>() {
         {
             put("x:phone", "iPhone 6s");
             put("x:system", "YunOS5.0");
         }
    });

Requête de rappel reçue par le serveur d'application

La requête de rappel reçue par le serveur d'application varie selon l'URL de rappel et le corps configurés. L'exemple de code suivant illustre cette structure :

POST /index.html HTTP/1.0
Host: 203.0.113.0
Connection: close
Content-Length: 81
Content-Type: application/x-www-form-urlencoded
User-Agent: ehttp-client/0.0.1
authorization: kKQe**************/kdD1ktNVgbWE**************
x-oss-pub-key-url: aHR0**************
filename=test.txt&size=5&phone=iphone6s&system=ios9.1

Pour plus d'informations, consultez la référence de l'API Rappel.

Vérifier que la requête de rappel provient d'OSS

Si votre serveur de rappel est la cible d'une attaque malveillante, telle que la réception de requêtes de rappel falsifiées qui perturbent les opérations normales, vous devez vérifier que chaque requête de rappel provient bien d'OSS.

Pour ce faire, effectuez une validation RSA sur les paramètres x-oss-pub-key-url et authorization présents dans l'en-tête qu'OSS envoie au serveur d'application. Une requête est considérée comme provenant d'OSS uniquement si elle passe la validation RSA. Les exemples de programmes fournis dans cette rubrique illustrent cette implémentation à titre de référence.

Traiter la requête de rappel

Le serveur d'application vérifie que la requête provient d'OSS et spécifie le format du contenu pour le rappel, par exemple :

filename=test.txt&size=5&phone=iphone6s&system=ios9.1

Le serveur d'application peut analyser le contenu renvoyé par OSS pour obtenir les données requises. Après avoir récupéré les données, le serveur d'application peut les stocker pour une gestion ultérieure.

Traitement par OSS de la réponse du serveur d'application

Deux scénarios sont possibles :

  • OSS envoie la requête de rappel au serveur d'application, mais celui-ci ne la reçoit pas ou est inaccessible. Dans ce cas, OSS renvoie le code d'état 203 à l'application Android ou iOS. Les données sont déjà stockées dans OSS.

  • Le serveur d'application reçoit la requête de rappel d'OSS et renvoie une réponse valide. Dans ce cas, OSS renvoie le code d'état 200 à l'application Android ou iOS et transmet la réponse du serveur d'application à l'application.

Télécharger les exemples de programmes

Les exemples de programmes montrent uniquement comment vérifier la signature reçue par le serveur d'application. Vous devez ajouter votre propre code pour analyser le contenu du corps du rappel.

  • Java

    • URL de téléchargement.

    • Mode d'exécution : après avoir décompressé le package, exécutez java -jar oss-callback-server-demo.jar 9000. Dans cet exemple, 9000 est le numéro de port, que vous pouvez modifier.

      Remarque

      Cet exemple JAR a été testé sur Java 1.7. Si vous rencontrez des problèmes, vous devrez peut-être modifier le code. Il s'agit d'un projet Maven.

  • PHP

    • URL de téléchargement.

    • Mode d'exécution : déployez le package décompressé dans un environnement Apache. En raison de la nature de PHP, la méthode de récupération de certains en-têtes dépend de l'environnement. Vous devrez peut-être vous référer à l'exemple et l'adapter à votre environnement spécifique.

  • Python

    • URL de téléchargement.

    • Mode d'exécution : après avoir décompressé le package, exécutez python callback_app_server.py. Le programme implémente un serveur HTTP simple. Vous devrez peut-être installer la dépendance RSA pour exécuter ce programme.

  • Version Ruby

FAQ

Puis-je modifier l'URL de rappel pour qu'un autre serveur reçoive le rappel et confirme l'état du téléchargement ?

Non, cela n'est pas possible. Les paramètres sont signés et vérifiés côté serveur par OSS. Tout contenu modifié échouera à la validation.