Ce qui n'est pas écrit dans Qiita n'est rien d'autre qu'un échec technique, je dois donc me conduire ici [SoftLayer Advent Calendar 2015](http://qiita.com/ Je me suis inscrit avec advent-calendar / 2015 / softlayer). Si je ne faisais pas cela, j'aurais l'impression qu'il n'y avait pas de matériel technique, mais je ne pourrais pas du tout écrire à cause d'Iloilo. Je pense qu'il augmentera à partir de l'année prochaine (plus d'entraînement).

Maintenant. Récemment, lors d'une session d'étude Python en interne, il était prévu d'utiliser Python sur Bluemix pour accéder à l'API de SoftLayer! J'ai écrit du code Python avec une telle histoire, et j'avais honte d'écrire [github](https: //) Il est publié sur github.com/sho7650/python03). Cette fois, j'ai pensé que je devrais aborder le contexte de devoir écrire un tel code, pas le code lui-même, alors je l'ai écrit. Ce n'est pas que je sois fatigué d'expliquer ce que j'ai écrit. Par tous les moyens.

Connaissances préalables et objectif de lecture après cela

Vous pouvez faire quelque chose avec Bluemix
J'ai essayé de frapper l'API SoftLayer ou la commande slcli (anciennement sl)
Il n'est pas étonnant que vous entendiez cf push
Pourtant, je n'ai pas fait beaucoup de développement Web, en particulier les ingénieurs d'infrastructure

C'est très limité, mais ce n'est probablement utile que pour ceux qui semblent limités.

Points à considérer lors de l'utilisation de l'API SoftLayer, etc. avec une application Web

Le titre est devenu clair, mais ce n'est pas vraiment une histoire limitée comme Bluemix ou SoftLayer, c'est un concept général. Cette fois, il m'est arrivé d'écrire le code qui a frappé l'API de SoftLayer sur Bluemix, donc il est écrit de manière si limitée. Lorsque vous voulez mettre le code, ou quand vous voulez l'essayer, il vaut mieux que le code existe. Doit être bon.

Maintenant. Ingénieurs d'infrastructure qui ont essayé d'écrire des lots en appuyant sur l'API ou slcli de SoftLayer (ne le limitez pas), qu'est-il arrivé à votre ID utilisateur et à votre clé API?

Pas décevant à mes attentes, la plupart d'entre vous regardent fixement l'ID utilisateur et la clé API dans le shell. Si quelqu'un dit que ce n'est pas écrit dans le shell, vous n'aurez peut-être plus besoin de le lire.

N'écrivez pas la clé API telle qu'elle est dans le programme

Du coup j'ai montré les points à considérer dans le titre, mais ça y est. Ce n'est pas limité aux clés d'API, mais il est courant d'avoir des données qui peuvent être modifiées et des données qui sont utilisées en affichant plusieurs options, plutôt que d'être codées en dur dans le programme. "Bien sûr.

Pourquoi

Les données et les mots de passe peuvent changer, mais devoir changer de programme à ce moment-là est problématique. Il y a deux choses auxquelles vous pouvez penser.

Les problèmes de sécurité

Nous savons que si le programme lui-même est contrôlé par version ou si le programme lui-même est accessible, le contenu des données sera visible. Par conséquent, si vous écrivez une «clé» ou un «mot de passe» dans le programme que vous ne voulez pas voir, cela ressemblera à quelqu'un qui ne devrait pas le voir. Comme les mots de passe, les clés d'API SoftLayer sont des éléments de données importants qui ne doivent pas être divulgués, ne les écrivez donc pas directement dans votre programme.

Il est souhaitable pour la sécurité que le programme et les données puissent être gérés séparément.

Problèmes administratifs

L'autre est que chaque fois que je change le contenu des données et que je commets, la version augmente même si je n'ai pas du tout changé la logique du programme. Au fur et à mesure que la version augmente, il y aura une règle selon laquelle la logique elle-même, ainsi que le test de régression de l'application, doivent être effectués. CI peut exécuter le test automatiquement, même s'il n'y a pas de règles. C'est une perte de temps et de ressources. De plus, même s'il n'y a pas de changements dans le programme lui-même, seule la version monte, donc ce n'est rien d'autre que du gaspillage pour enregistrer les parties modifiées.

À cet égard, si vous stockez vos données dans un emplacement distinct de votre logique, vous n'aurez pas besoin de retester la logique de votre application en cas de changement (bien que beaucoup aimeraient le faire).

Par conséquent, la clé API SoftLayaer doit être séparée dans le programme sans code en dur et écrite ailleurs.

Alors, où? Il y a quatre modèles, et je vais vous expliquer chacun d'eux.

Faites entrer la clé API
Enregistrez la clé API dans un fichier séparé
Enregistrez la clé API dans la base de données
Enregistrez la clé API dans la variable d'environnement

1. Faites entrer la clé API

C'est une méthode de saisie en utilisant le champ de saisie un par un. Comme les données ne sont stockées nulle part, certaines personnes peuvent penser qu'elles sont ('∀`) b bonnes! Cependant, Bluemix est "http" lorsque vous l'utilisez sans rien faire. En outre, bien que cela puisse réduire la convivialité si vous saisissez cette longueur à chaque fois, il existe un risque que la clé API soit stockée ailleurs et fuitée à partir de là.

En premier lieu, si le site que vous souhaitez saisir est un site de phishing ... Il semble que cette méthode n'est pas recommandée car elle est infinie quand on y pense.

2. Enregistrez la clé API dans un fichier séparé

C'est une bonne manière de le faire. Cependant, il y a trois choses à garder à l'esprit. Il est essentiel qu'il ne soit pas accessible de l'extérieur et ne puisse être consulté que par les utilisateurs nécessaires. Cependant, dans de tels cas, le programme et le fichier de données sont souvent placés sur le même serveur, et si l'administrateur du programme fait la chose appropriée, les données peuvent être accessibles. Ensuite, un développeur peut facilement accéder au fichier de données, alors soyez prudent de ce point de vue.

Placez-le en tant que contenu statique dans un emplacement inaccessible de l'extérieur. Un répertoire supérieur à DocumentRoot dans Apache.
Assurez-vous que les privilèges utilisateur ne sont accessibles qu'aux développeurs qui doivent les utiliser, qui ne sont pas accessibles en tant que contenu statique.
Cryptez si possible. Cependant, la question de savoir quoi faire avec cette clé entre toujours en jeu.

En tant que fichier externe, il peut y avoir un moyen de le placer sur le serveur de fichiers derrière et de séparer l'administrateur du fichier de données, mais je pense que la méthode d'accès à ce fichier est gênante. En quelque sorte.

3. Enregistrez la clé API dans la base de données

La tendance actuelle est qu'il en sera ainsi. Toutes les données modifiables sont placées dans le DB comme les autres données. Ce qui est bien à ce sujet, c'est qu'il est facile de faire en sorte que la gestion des données soit complètement différente de celle de l'administrateur du programme. Cela dit, il y a certaines choses à surveiller.

Les utilisateurs qui peuvent accéder à la base de données à partir du programme ne doivent disposer que des droits d'accès minimum requis. Si l'utilisateur qui utilise l'application peut contrôler lui-même les données qui peuvent accéder à la base de données, le développeur peut également le laisser seul.
Séparez l'application et la base de données. Si vous le définissez sur un serveur logiquement différent afin que le serveur de base de données ne soit accessible que par programme, il existe moins de façons d'afficher librement les données dans la base de données. Ce sera un peu sûr.
Pourtant, chiffrons-le. Encore une fois, la question de savoir quoi faire avec la clé de cryptage se pose, mais pas tellement si l'accès aux données est finement contrôlé avant cela. Ceci est fait en termes de cryptage afin que l'administrateur de données ne puisse pas voir quand on accède à l'enregistrement.

4. Enregistrez la clé API dans la variable d'environnement

S'il s'agit d'un serveur d'applications démarré en tant que processus enfant depuis le shell, il est également possible de le spécifier dans la variable d'environnement.

Cependant, si l'exécuteur définit toujours la valeur dans la variable d'environnement, puis démarre l'application, la variable d'environnement ne peut pas être utilisée comme méthode sûre. C'est une très mauvaise méthode. Surtout quand vous voulez l'exécuter avec Bluemix, vous devez spécifier la méthode d'exécution et le script shell pour l'exécuter dans manifest.yml et le démarrer. Dans ce cas, après tout, vous allez mettre une instruction pour affecter des données à la variable d'environnement dans le script shell, donc la méthode de gestion sera la même que de la stocker dans un fichier séparé. Pour le moment, il serait possible de séparer la personne qui écrit le shell pour démarrer et la personne qui écrit la logique, mais les fichiers l'un de l'autre seront complètement visibles.

autre...?

Je viens de proposer une autre méthode mais je l'ai oubliée. Je l'écrirai si je me souviens (´ ・ ω ・ `)

Cette fois, la méthode réalisée

Pour la méthode que j'ai implémentée cette fois, j'ai choisi la méthode «d'enregistrement de la clé API dans la base de données».

Étant donné que Django a une fonction de gestion des utilisateurs en standard, il est possible de changer le site SoftLayer cible pour chaque utilisateur en associant cet utilisateur avec le "nom d'utilisateur" et la "clé API" enregistrés dans la base de données. D'une manière ou d'une autre, cela semblait plus pratique.

Cette fois, nous avons créé une partie qui affiche une liste de comptes enregistrés par l'utilisateur SoftLayer correspondant. Dans le code source, il se trouve dans ʻaccounts / views.py`.

`views.py`


def account_list(request):
    loginname = None
    if request.user.is_authenticated():
        loginname = request.user.username
    username = CustomUser.objects.get(username=loginname)
    user   = softlayer_api.objects.get(pk=username.softlayer_id)
    client = SoftLayer.create_client_from_env(username=user.username, api_key=user.api_key)
    acct   = client['Account'].getUsers()
    return render_to_response('account_list.html', {'accounts': acct}, context_instance=RequestContext(request))

Cette déclaration def est précédée de @ login_required afin que seuls les utilisateurs authentifiés connectés puissent y accéder. Même ainsi, je vérifie d'abord que je suis l'utilisateur qui s'est correctement authentifié et a accédé à loginname.

En utilisant le nom de connexion comme clé, j'ai lu les informations de SoftLayer enregistrées dans la base de données. C'est la partie de ʻusername = et ʻuser =. A ce moment, la variable ʻuser contient les informations ʻusername ʻapi_key` de SoftLayer enregistrées dans la base de données.

La partie suivante, client =, appelle en fait l'API SoftLayer avec l'utilisateur SoftLayer spécifié. Dans ʻacct = , toutes les informations utilisateur de SoftLayer enregistrées par .getUsers () sont acquises à partir des informations utilisateur. Enfin, vous faites render_to_response` pour afficher toutes ces informations.

De cette façon, il n'est pas possible de connaître des informations telles que «nom d'utilisateur» et «api_key» de SoftLayer à partir du programme. De plus, en fonction de l'utilisateur connecté, il est possible de basculer entre les utilisateurs de SoftLayer, donc je l'ai fait moi-même et suis devenu euphorique.

Résumé

Si vous souhaitez accéder à l'API SoftLayer à partir d'une application Web sur Bluemix, vous pouvez effectuer les opérations suivantes.

Stocker les informations d'API dans DB
Conservez la base de données dans un emplacement logiquement et physiquement séparé de l'application
Gestionnaires de programme et de données distincts

L'utilisation de l'exemple de programme créé cette fois-ci est correctement publiée sur github, veuillez donc l'essayer tel quel. Cela devrait marcher.

Cependant, sqlite ne crypte aucune donnée, essayez donc d'utiliser un autre serveur pour la base de données.

[PYTHON] Points à considérer lors de l'utilisation de l'API de SoftLayer à partir d'une application sur Bluemix