Certificats et organisation de profil pour plusieurs produits

Sur mon lieu de travail, nous avons terminé le développement d'une application iOS et sums sur le point d'en lancer une seconde.

Avant cela, je voulais clarifier quelques points concernant les certificates et les profils et les environnements de construction:

Q1: Ai-je raison de penser qu'un count Apple ne peut avoir qu'un seul certificate de dissortingbution, et que par conséquent, il sera utilisé dans les deux applications? (en étant présent dans les profils d'approvisionnement, je vais créer un nouvel set de profils contenant un nouvel identifiant d'application pour la nouvelle application).

Q2: Comme ce sont les certificates et non les profils qui sont installés dans le trousseau, je suppose que la nouvelle application devrait juste build sur la machine de construction qui est actuellement configurée pour l'application actuelle.

Q3: En lien avec Q2, je me request s'il est nécessaire, ou une bonne idée, de séparer les builds de l'application actuelle et de la nouvelle application en les plaçant sur des machines physiques différentes (ou en partitionnant la machine en machines virtuelles) . Si les deux applications utilisaient des certificates différents, je pense que c'est nécessaire (ou au less partitionner le trousseau). Je suis inquiet de problèmes de certificate et de trousseau. Cependant, si la réponse à Q1 est qu'il n'y a qu'un seul certificate de dissortingbution, il ne devrait théoriquement pas être nécessaire d'avoir des machines de construction séparées pour chaque application.

Q4: Les deux applications utilisent des notifications push, est-ce correct d'utiliser le même certificate push pour les deux (dans un profil différent bien sûr)?

TIA

Les certificates et l'approvisionnement peuvent être un sujet délicat, alors c'est certainement une bonne idée de requestr d'abord avant de vous causer de la douleur par inadvertance!

Q1: Un seul certificate de dissortingbution par count?

Oui, les counts individuels et d'entreprise sont limités à un seul certificate de dissortingbution actif par année d'adhésion. Toutefois, ce certificate peut être révoqué et réémis à tout moment si la personne ou la société le juge nécessaire (key publique / privée compromise, cessation d'emploi avec access à la key privée, etc.). J'ai récemment répondu à une question "Quelles sont les identités de signature de code?" Cela peut être utile pour fournir un context supplémentaire sur les informations qui sont codées dans un profil de provisioning et comment Xcode search ces informations lors de l'exécution des builds de périphériques. Gardez à l'esprit que, selon le type de profil de provisionnement utilisé (développement ou dissortingbution), le nombre et le type de certificates et de périphériques de test encodés dans un profil de provisionnement seront modifiés.

Vous avez également tout à fait raison de réutiliser le certificate de dissortingbution existant avec un tout nouvel set de profils de provisionnement qui sont codés avec l'identifiant de l'application / l'ID de l'set de la deuxième application que vous êtes en train d'écrire.

Q2: Les certificates et non les profils d'approvisionnement sont ce que l'installation dans Keychain est-elle correcte? Comment une machine de construction serait-elle affectée?

Oui, c'est correct. Votre certificate de développement et votre certificate de dissortingbution sont tous deux installés dans le trousseau alors que les profils de provisionnement sont installés dans un directory spécial de Xcode pour être utilisés avec les opérations de code.

En supposant que vous avez configuré votre machine de build et que vous travaillez pour votre première application, vous avez beaucoup de travail. Une list de haut niveau de choses que vous aurez encore besoin de faire:

  • Générer un set de profils de provisionnement pour le nouvel AppId en utilisant les certificates existants
  • Installez le ou les profils de provisionnement dans l'environnement de construction
  • Assurez-vous que le paramètre de génération 'Identité de signature de code' du projet Xcode est configuré pour utiliser les profils de provisionnement nouvellement créés ou, idéalement, utilisez le 'Sélecteur automatique de profil' si la configuration de votre projet le permet.
  • Configurez votre système de construction pour créer la nouvelle application.

Les HOWTO spécifiques à ces tâches de haut niveau dépendent en quelque sorte de la manière dont vous avez configuré votre projet et votre système de construction, mais doivent généralement suivre le même stream de travail que lors de la construction de la première application.

Q3: Est-il nécessaire / bonne idée de partitionner l'environnement de construction sur des machines séparées?

En ce qui concerne la partie 'nécessaire' de cette question, Non, il n'est pas nécessaire que vous sépariez physiquement ou virtuellement les environnements de construction pour pouvoir build ces applications côte à côte, mais vous pourriez choisir de le faire si votre entreprise les besoins sont tels que vous avez besoin d'environnements de construction dédiés par application.

D'un sharepoint vue technique, les profils d'approvisionnement fournissent 99% du partitionnement nécessaire pour pouvoir build côte à côte. Le seul moment où vous rencontrerez une situation où un partitionnement physique ou virtuel peut être requirejs serait si vous étiez membre de deux ou plusieurs programmes de développement iOS et que les «noms communs» sur les certificates émis par chacune de ces équipes correspondaient (ex. "iPhone Dissortingbution: MyCompany" était le nom commun du certificate de Team1 et était absolument identique à un certificate émis par Team2). Si c'était le cas, vous verriez des avertissements et des erreurs dans Xcode comme suit:

Erreur de code: L'identité du certificate «iPhone Dissortingbution: MyName» apparaît plusieurs fois dans le trousseau. L'outil codesign nécessite seulement un.

Dans tous les autres cas, en supposant que vos certificates et profils d'approvisionnement soient installés et que la valeur de l'identité de signature de code soit définie correctement, le signe de code peut prendre soin de lui-même.

Q4: Est-il acceptable de réutiliser le même certificate push pour les deux applications?

Celui-ci est un "Non" solide. Chaque identifiant d'application possède son propre set de profils de provisionnement qui sont accompagnés d'un set de droits, dont un est celui des notifications push. Lors de la création d'un nouveau profil d'approvisionnement avec le droit de notification push, vous êtes invité à générer de nouveaux certificates Push – Il n'est pas possible de fournir vos certificates existants à Apple. Ceci est fait pour s'assurer qu'un fournisseur de notifications push (votre server qui crée les charges utiles de notification push envoyées à Push Gateway d'Apple) est en sandbox d'une manière similaire à celle trouvée dans l'écosystème iOS – un fournisseur par AppId … un sandbox par AppId.

Du sharepoint vue de la security, cela empêche un attaquant d'envoyer des notifications push spam à votre user simplement en fournissant un jeton Push valide et une charge utile sur la Push Gateway d'Apple. Configurez une seconde instance de votre code fournisseur et utilisez les certificates Push générés lors de la création du nouveau profil Provisioning ou mettez à jour votre fournisseur existant pour conserver les jetons Push Notification au niveau de chaque application et utiliser le bon certificate lors de l'envoi d'une charge Push à Apple. Malheureusement, vous seul (ou vos collègues) pouvez prendre cette décision car cette décision dépendra des capacités techniques de votre fournisseur existant et du degré de risque que vous / votre entreprise êtes prêt à prendre des Notifications Push unifiées sur la même instance fournisseur.

D'autres peuvent redirect ici et fournir des informations supplémentaires sur la façon dont ils configurent leurs propres fournisseurs, mais je suis allé avec des instances entièrement distinctes pour éviter un scénario où les mises à jour pour notifications push d'une application pourraient casser les notifications push pour une application entièrement différente.