🥞 🔇 🚶🏿 Est-il sûr d'utiliser des packages R pour travailler avec l'API des systèmes publicitaires 🚄 👨🏾‍🎨 👩🏾‍⚖️

Récemment, ils ont souvent commencé à me poser une question sur la sécurité de l'utilisation de diverses extensions prêtes à l'emploi, c'est-à-dire packages écrits pour la langue R, est-il possible que le compte publicitaire tombe entre de mauvaises mains

Dans cet article, je parlerai en détail du fonctionnement du mécanisme d'autorisation à l'intérieur de la plupart des packages et des API des services de publicité et de la manière la plus sûre possible d'utiliser les packages décrits dans l'article.

Les informations contenues dans cet article ne sont pas techniquement les plus faciles, donc, pour que le texte ne soit pas aussi sec et technique que l'aide habituelle, j'ose essayer le rôle d'un guide et je vais vous guider à travers les matériaux de cet article pour sa perception la plus simple.

Notre bus touristique est déjà arrivé, prenez vos places et consultez notre itinéraire actuel.

Table des matières

Fonctionnement du processus d'autorisation dans la plupart des services publicitaires modernes

Le lieu de rencontre de notre groupe d'excursion est le protocole OAuth.

Presque tous les services avec lesquels l'API j'ai dû travailler effectuent des autorisations en utilisant le protocole OAuth 2.0, ils ont déjà écrit plus en détail à ce sujet sur le hub, qui sont intéressés à se promener dans ses déserts, s'il vous plaît, vous avez une telle opportunité, vous pouvez le faire ici et ici .

Si vous expliquez sa signification en un mot, OAuth permet à l'application (dans notre cas, le package R sera une telle application), à laquelle vous avez accordé la permission, d'effectuer certaines actions en votre nom, sans avoir besoin de transférer votre nom d'utilisateur et votre mot de passe du compte publicitaire vers cette application, à nouveau pour des raisons de sécurité.

Au lieu d'un nom d'utilisateur et d'un mot de passe, le protocole OAuth utilise un jeton, il s'agit d'une chaîne générée composée d'un ensemble de lettres et de chiffres, qui stocke les informations sous forme cryptée:

Au nom de quel utilisateur l'application exécute la demande
L'utilisateur a-t-il vraiment autorisé cette application à accéder à ses données
L'utilisateur dispose-t-il des autorisations nécessaires pour travailler avec les supports publicitaires auxquels il se réfère?

Pour le processus d'autorisation et l'utilisation de l'API, vous devez généralement enregistrer l'application dans l'API. En outre, cette application devrait recevoir la confirmation de l'équipe de support API d'un système publicitaire particulier, c'est-à-dire l'auteur décrit initialement en détail comment et pourquoi il utilisera l'API, tout cela est vérifié, modéré, et seulement si le support du côté de la plateforme publicitaire n'a pas de questions de sécurité, l'auteur du package aura accès à l'API, et avec l'aide de son application enregistrée, vous package, vous pouvez vous authentifier à l'aide de l'ID et du secret émis pour cette application.

D'où vient la question de sécurité

Nous allons de l'avant, essayons de comprendre où la question de sécurité s'est posée lors de l'utilisation des packages?

En général, la question de la sécurité d'accès aux panneaux publicitaires est plus que justifiée, car les agences de publicité ont de l'argent, et souvent pas assez petit, de sorte que la sécurité des comptes publicitaires est un problème beaucoup plus grave que la sécurité d'accès, par exemple, à un profil d'utilisateur régulier sur les réseaux sociaux.

Le fait est que dans la plupart des cas, lors de l'autorisation, R redirige les utilisateurs des packages vers le navigateur, initialement pour confirmer l'accès au compte, à ce stade, vous êtes sur la page de service avec l'API avec laquelle vous allez travailler. Après confirmation, l'utilisateur est redirigé vers la page où le jeton sera généré, ou le code de confirmation d'autorisation, qui doit ensuite être entré dans le R.

Ainsi, la plupart des utilisateurs sont inquiets car les sites où le jeton lui-même ou le code de confirmation d'autorisation sont générés sont tiers et n'ont rien à voir avec le service de publicité lui-même, bien sûr, ils ont soit un compteur Google Analytics soit un compteur Yandex.Metrica, et le propriétaire du site, qui, dans la plupart des cas, est également l'auteur du package, selon beaucoup, à travers ce site, il peut prendre possession de ses jetons et accéder à la gestion de son matériel publicitaire à travers eux.

Qu'est-ce qui vous menace avec une interception symbolique

Parlons de ce qui vous permet généralement de créer un jeton s'il tombe entre les mains d'un attaquant.

Le jeton doit être stocké de la même manière que toutes les autres données nécessaires pour accéder au compte, c'est-à-dire si le jeton tombe dans l'une ou l'autre des mains, celui qui en a pris possession pourra gérer vos supports publicitaires: supprimez-les, modifiez par exemple, il sera possible de modifier le texte de l'annonce et le lien vers lequel elle mène.

La bonne nouvelle est que, comme je l'ai écrit ci-dessus, le protocole OAuth vous permet de gérer vos supports publicitaires sans fournir de nom d'utilisateur et de mot de passe depuis votre compte, c'est-à-dire même si quelqu'un a pris possession de votre jeton, il ne pourra pas voler votre compte avec son aide. Pas une seule API ne vous permet de demander, et plus encore, de changer votre mot de passe, donc vous ne serez pas retiré de votre compte, mais la publicité de votre site via votre compte est facile.

Que faire si quelqu'un a pris possession de votre jeton

S'il se trouve que vous avez accidentellement transféré votre jeton, ne paniquez pas. En fait, ce n'est pas la fin du monde, dans la plupart des cas, il existe un certain nombre d'actions qui réinitialisent les jetons précédemment émis, par exemple, dans cette section de la référence API Yandex.Direct, le processus de rappel des jetons précédemment émis est décrit en détail.

Dans la plupart des cas, quel que soit l'API du système publicitaire avec lequel vous travaillez, il suffira de changer le mot de passe de votre compte.

Comment utiliser en toute sécurité les packages R pour travailler avec les systèmes de publicité API

Et maintenant que nous sommes arrivés à la partie la plus intéressante de notre tournée, je vais parler de la façon la plus sûre d'utiliser les packages que j'ai développés, car je connais bien les API des systèmes avec lesquels ils fonctionnent.

Je tiens à noter que tous les jetons émis sont stockés sur le côté de la plate-forme publicitaire, pas l'application via laquelle le package R fonctionne, donc même l'utilisateur de l'application enregistrée pour travailler avec l'API de la plate-forme publicitaire n'a pas accès au jeton lui-même.

ryandexdirect et rym - Packages pour travailler avec les API Yandex.Direct et Yandex.Metrica

Les deux packages utilisent le service Yandex OAuth; pour plus de détails, consultez ce lien .

Il y a 2 fonctions dans le package ryandexdirect pour l'autorisation:

yadirAuth - autorisation en deux étapes
yadirGetToken - demande de jeton d'autorisation

Lorsque vous utilisez la fonction yadirAuth, à savoir, je recommande de l'utiliser lorsque vous travaillez avec ryandexdirect, le processus d'autorisation se déroule selon le schéma décrit ici , la seule vulnérabilité dans ce cas est la période entre le moment où le code de confirmation est généré et son entrée dans la console R.

Je vais vous expliquer pourquoi, voici comment Google Analytics affiche les données relatives aux visites sur la page de génération de code de vérification .

C'est-à-dire le code vient après le signe ``? '' et est considéré comme un paramètre GET qui capture le compteur Google Analytics, mais la durée de vie d'un tel code de confirmation se termine immédiatement après son utilisation, c'est-à-dire juste après l'avoir entré dans la console R. La durée de vie maximale d'un tel code est de 10 minutes.

La deuxième fonction, yadirGetToken , effectue l'autorisation selon l'autre schéma décrit ici . Et lors de son utilisation, aucun code de confirmation n'est généré, c'est-à-dire après avoir donné au package l'autorisation d'accéder aux données, vous accédez à la page de génération de jetons. Le jeton dans l'URL elle-même est retourné après le signe '#', ce n'est pas un paramètre get, mais une ancre, ou comme cette partie de l'URL est également appelée hachage. Le navigateur ne transmet pas ces données; en conséquence, elles ne sont pas transférées ultérieurement dans les rapports Google Analytics, c'est-à-dire les visites de cette page dans les rapports sont affichées comme suit:

Dans ce deuxième cas, il n'y a pas de risques, mais l'inconvénient d'utiliser la fonction yadirGetToken est qu'elle n'enregistre pas les informations d'identification dans un fichier sur votre PC et ne peut donc pas utiliser ces données entre différentes sessions R, ce qui n'est pas très pratique. Vous stockerez le jeton reçu avec son aide et utiliserez dans les scripts une chaîne de texte, la durée de vie d'un tel jeton est de 1 an, après quoi le package ne pourra pas le remplacer automatiquement, comme cela se produit lors de l'utilisation de la fonction yadirGetAuth.

Il y a une fonction rym_auth dans le paquet rym pour autorisation, qui est un analogue complet de la fonction yadirAuth, dont j'ai déjà décrit en détail le schéma de fonctionnement.

rfacebookstat - Packages pour travailler avec le compte publicitaire Facebook

Le processus d'authentification dans l'API Facebook Marketing est décrit en détail ici .

Pour passer l'autorisation, le package rfacebookstat a la fonction fbGetToken , il fonctionne de la même manière que la fonction yadirGetToken du package ryandexdirect décrit précédemment, c'est-à-dire tout est implémenté via une authentification en une étape. Il n'y a aucun danger que votre token soit intercepté via les rapports Google Analytics, il y a un écran à quoi ressemble une visite sur la page de génération de token dans Google Analytics.

rvkstat - Packages pour travailler avec le compte VK

Le processus d'authentification Vkontakte est décrit dans l' aide de l' API .
Dans rvkstat, vous pouvez utiliser l'une des deux fonctions d'autorisation:

vkAuth - Schéma d' autorisation Flux de code d'autorisation , c.-à-d. autorisation en deux étapes.
vkGetToken - Autorisation selon le schéma de flux implicite , autorisation en une étape, avec le jeton lié à l'appareil.

vkAuth fournit une authentification en deux étapes, essentiellement un analogue de la fonction yadirAuth décrite au début de ce bloc, mais uniquement pour l'autorisation dans l'API Vkontakte, et non Yandex.

La particularité de travailler avec l'API Vkontakte dans ce cas est que l'enregistrement de votre application et l'accès à l'API y sont assez simples, vous n'avez pas besoin de remplir des formulaires dans lesquels vous devez décrire en détail comment et pourquoi vous utiliserez l'API. Donc, puisque vous utilisez votre application lorsque vous travaillez avec rvkstat, même l'interception du code de confirmation ne fonctionne pas, car il est lié à votre application, et pour intercepter un jeton avec lui, vous devez connaître l' identifiant et le secret de votre application, le code lui-même ne vous permettra pas d'obtenir un jeton pour vous.

La fonction vkGetToken vous permet d'obtenir le jeton de la manière la plus vkGetToken outre, le jeton reçu est lié à l'appareil à partir duquel il a été demandé, c'est-à-dire même si quelqu'un l'obtient, il ne peut l'utiliser que depuis le même PC à partir duquel il a été sollicité. Dans le même temps, le jeton dans l'URL lors de la génération se trouve après le signe `` # '', et comme je l'ai dit plus tôt, il n'entre pas dans les rapports Google Analytics.

rmytarget - Packages de tableau de bord MyTarget

À l'heure actuelle, il existe 3 schémas d'autorisation dans l'API MyTarget, pour plus de détails sur chacun, voir la documentation .

La fonction myTarAuth est destinée à être autorisée dans l'API MyTarget dans rmytarget.Par défaut, elle utilise le schéma d'autorisation Granting Code Authorization , qui vous permet de travailler avec l'API MyTarget sans avoir à y accéder personnellement. C'est-à-dire J'ai déjà enregistré l'application, elle a été approuvée par le support de l'API MyTarget, et vous lui donnez accès à travailler avec le compte en votre nom.

L'autorisation du code d'autorisation est un schéma d'autorisation en deux étapes, ce qui signifie similaire à celui implémenté par la fonction yadirAuth dans le package ryandexdirect.

Cela fonctionne comme suit:

Vous démarrez la fonction, après quoi le navigateur s'ouvre.
Sur la page du service MyTarget, vous autorisez l'accès à votre compte.
Vous serez redirigé vers la page du package où le code de confirmation est généré. La durée de vie maximale de ce code est de 1 heure, mais il se termine immédiatement après avoir reçu un jeton avec lui.
Vous entrez le code de confirmation copié dans la console R et obtenez un jeton pour travailler avec l'API.

Dans ce cas, le code de confirmation est un paramètre get et est enregistré dans les rapports Google Analytics.

Mais, si vous regardez attentivement, en plus du code (obtenir le code du paramètre) , l'URL contient un autre paramètre - l' état . Il s'agit d'une chaîne, également un jeton généré par le package rmytarget lui-même et envoyé au navigateur immédiatement après le démarrage de la fonction, ce paramètre est unique et le code de confirmation d'autorisation lui est attaché. Même si vous interceptez à la fois le code de confirmation et le jeton d'état, vous ne pouvez toujours pas utiliser cette combinaison car Premièrement, il n'y a nulle part où entrer le jeton d'état, et comme je l'ai déjà écrit, il est unique, et même s'il y avait un endroit pour y entrer, il ne peut pas être renvoyé. Par conséquent, ce régime d'autorisation est totalement sûr.

Mais si tout de même, cette option vous semble encore suspecte, alors rmytarget et la fonction myTarAuth vous permettent d'utiliser les deux schémas d'autorisation restants:

Client Credentials Grant , utilisé pour travailler avec des données de compte personnel via l'API
Subvention des pouvoirs des clients d'agence , utilisée pour travailler avec les données de leurs propres clients d'agences / gestionnaires.

Dans ce cas, vous devez accéder indépendamment à l'API MyTarget, au moment où elle ne peut être obtenue que par des entités juridiques, et elle est émise manuellement, pour demander l'accès, vous devez utiliser le formulaire de commentaires, vous pouvez trouver tous les détails ici .

Donc, si vous avez quand même réussi à enregistrer votre application pour travailler avec l'API MyTarget, vous pouvez assez facilement vous authentifier à l'aide de l'un des deux schémas répertoriés ci-dessus en utilisant la fonction myTarAuth , pour cela, passez la valeur FALSE à l'argument code_grant et utilisez les arguments suivants:

grant_type - Le type de votre compte, dans ce cas un compte client normal, prend les valeurs "client_credentials" ou "agency_client_credentials".
agency_client_name - Connexion client à partir du compte d'agent, utilisée uniquement si grant_type = "agency_client_credentials".
client_id - L'ID vous est délivré lors de la confirmation de l'accès à l'API MyTarget.
client_secret - Délivré lorsque vous confirmez l'accès à l'API MyTarget avec l'ID client.

Exemple de code d'autorisation de subvention des informations d'identification client

 myTargetAuth <- myTarAuth(code_grant = FALSE, grant_type = "client_credentials", client_id = "XXXXXXXXXX", client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")

Exemple de code pour le schéma d'autorisation Grant of Credentials Agency Agency

 myTargetAuth <- myTarAuth(code_grant = FALSE, grant_type = "agency_client_credentials", client_id = "XXXXXXXXXX", client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", agency_client_name = "xxxxxxxxx@agency_client")

Dans le cas de l'utilisation de cette approche, l'authentification passera sans aucune interaction avec le site du package rmytarget.

Conclusion

C'est là que notre tour se termine, car aujourd'hui plus de 10000 packages sont publiés dans les principaux référentiels - CRAN, et plus de 80000 sur GitHub, en conclusion, je voudrais dire quelques mots de plus sur la sécurité de leur utilisation.

Tout d'abord, faites attention à savoir s'il existe un package dont vous avez besoin sur CRAN, car il s'agit du référentiel officiel du langage R, les packages sont soumis à une modération assez stricte par une équipe de spécialistes de ce référentiel avant d'être publiés sur ce site. Et le package ne sera pas publié là-bas tant qu'il ne sera pas entièrement conforme à la politique CRAN . Par conséquent, si le package est présent sur CRAN, vous pouvez être sûr que son utilisation est sans danger pour vous.

De plus, je tiens à noter que le code de tous les packages pour le langage R est ouvert, vous pouvez toujours consulter le code de l'une de ses fonctions avant de le lancer.

Essayez également de trouver des articles sur l'application de ce package, les utilisateurs de R sont tout à fait disposés à partager des informations, et vous trouverez probablement des cas d'utilisation de packages plus ou moins populaires. S'ils écrivent sur un paquet, cela signifie qu'ils l'utilisent, et apparemment personne n'a eu de problème avec lui.

Regardez également qui est l'auteur du package, il y a deux façons de procéder:

Après avoir installé le package, exécutez la commande utils::packageDescription("_")$Author
Affichez le fichier DESCRIPTION dans la source du package.

Essayez de trouver des informations sur l'auteur sur un réseau mondial, si une personne est même la moins publique, il est peu probable qu'elle risque sa réputation afin d'obtenir un jeton d'accès à votre compte publicitaire et à votre matériel publicitaire. Souvent, une réputation coûte plus cher que l'argent reçu de manière douteuse.

Si vous installez un package à partir de GitHub, puis installez-le à partir du référentiel de l'auteur, et non à partir de n'importe quelle branche, en règle générale, il y a beaucoup de telles branches dans les référentiels populaires:

Succursales Ryandexdirect

Le fait est que les branches ne sont pas mises à jour par l'auteur du package, ce qui signifie que vous ne recevrez pas sa version la plus récente. De plus, l'utilisateur GitHub qui a créé la branche peut apporter des modifications à son code lui-même, que vous décidiez ou non de faire confiance à ces modifications.

Vous pouvez voir à partir de quel référentiel sa branche a été créée sur sa page sur GitHub.

Ne transférez vos jetons à personne en aucune circonstance, stockez-les de la même manière que vous stockez les mots de passe des comptes, même si vous devez montrer un exemple de code, faites-le sans spécifier de jetons.

N'oubliez pas que dans la grande majorité des cas, l'utilisation des packages R est totalement sûre pour vous, j'espère que cet article vous en convaincra et explique comment fonctionne le processus d'autorisation dans l'API des plateformes publicitaires les plus populaires.

Bonne chance, soyez prudent mais ne cédez pas à la paranoïa.

Est-il sûr d'utiliser des packages R pour travailler avec l'API des systèmes publicitaires