Сертификаты и организация профилей для нескольких продуктов

Question

На моем рабочем месте мы завершили разработку в одном приложении iOS и собираемся встать на второй.

Перед этим я хотел бы уточнить несколько моментов, касающихся сертификаты и профили и создание условий:

Q1: Я правильно думать, что учетная запись Apple, может иметь только один сертификат распределения, и что, следовательно, это будет используется в обоих приложениях? (через него, присутствуя в профилях подготовки, я создам новый набор профилей, содержащий новый идентификатор приложения для нового приложения).

Q2: Поскольку это сертификаты, а не профили, установленные в брелок, я предполагаю, что новое приложение должно просто построить на машине сборки, которая в настоящее время настроена для текущего приложения.

Q3: Что касается Q2, мне интересно, нужно ли это, или хорошая идея, иметь сборки для текущего приложения и нового приложения, разделенные, помещая их на разные физические машины сборки (или разбивая машину сборки в виртуальные машины). Если бы два приложения использовали разные сертификаты, я бы подумал, что это необходимо (или, по крайней мере, разделить цепочку ключей). Я беспокоюсь о возникающих проблемах с сертификатом и связью ключей. Однако, если ответ на вопрос Q1 заключается в том, что существует только один сертификат распространения, теоретически нет необходимости иметь отдельные машины сборки для каждого приложения?

Q4: Оба приложения используют push-уведомления, можно ли использовать тот же сертификат push для обоих (в другом профиле, конечно)?

ТИА

Answer 1

Сертификаты и Provisioning может быть непростой темой, так что это, безусловно, хорошая идея, чтобы спросить, прежде чем невольно вызывает себе некоторую боль!

Q1: Только 1 сертификат распространения на одну учетную запись?

Да, индивидуальные и корпоративные учетные записи ограничены одним активным сертификатом распространения за каждый год участия, однако этот сертификат может быть отозван и переиздан в любое время, если Индивидуум или Компания сочтут это необходимым (скомпрометировано Public/Private ключ, прекращение работы сотрудников с доступом к закрытому ключу и т. д.). Недавно я ответил на вопрос "What are Code Signing Identities?", который может быть полезен в предоставлении дополнительного контекста информации, которая закодирована в профиле Provisioning Profile и как Xcode просматривает эту информацию при выполнении сборки устройства. Имейте в виду, что в зависимости от типа используемого профиля Provisioning Profile (Development vs. Distribution) будет изменяться количество и тип сертификатов и тестовых устройств, закодированных в профиле Provisioning Profile.

Вы также абсолютно правы в том, что вы повторно используете существующий сертификат распространения с совершенно новым набором профилей Provisioning Profiles, которые кодируются идентификатором Id/Bundle приложения второго приложения, которое вы готовите/пишете.

Q2: Сертификаты, а не Профили Профили - это то, что нужно установить в брелок справа? Как повлиять на машину сборки?

Да, это правильно. Оба сертификата разработки и сертификат распространения - это то, что устанавливается в Keychain, в то время как Provisioning Profiles устанавливаются в специальный каталог в Xcode для использования с операциями Code Sign.

Предполагая, что у вас есть установка сборки и работа для вашего первого приложения, у вас есть много тяжелой работы. Список высокий уровень вещей, которые вы все еще нужно сделать:

• Сформировать набор Provisioning Профили для нового AppId с использованием существующих сертификатов
• Установите Provisioning Profile (ы) на окружающую среду сборки
• Убедитесь, что в настройке сборки кода «Код подписи кода Xcode» настроено использование вновь созданных профилей Provisioning Profiles или, в идеале, использование «Automatic Profile Selector», если это позволяет ваша конфигурация проекта.
• Настройте свою систему сборки, чтобы создать новое приложение.

Специфические HOWTO для этих задач высокого уровня будут в некоторой степени зависеть от того, как вы настроили проект и систему сборки, но обычно должны следовать тем же рабочим процессам, что и при создании первого приложения.

Q3: Необходимо ли/целесообразно разделить среду сборки на отдельные машины?

Что касается «необходимой» части этого вопроса, нет, это не требуется, чтобы вы физически или виртуально отделить среду сборки, чтобы иметь возможность строить эти приложения бок о бок, однако вы могли выбирайте это, если ваши потребности в бизнесе таковы, что вам необходимы специализированные среды сборки для каждого приложения.

С технической точки зрения профили Provisioning Profiles обеспечивают 99% разделов, необходимых для сборки бок о бок. Единственный раз, когда вы столкнетесь с ситуацией, когда физическое или виртуальное разбиение может потребоваться, было бы, если бы вы были членом двух или более программ развития iOS и «Common Names» в сертификатах, выпущенных каждой из этих команд, сопоставленных (например, «Распространение iPhone: MyCompany» было общим именем сертификата Team1 и было абсолютно идентично сертификату, выпущенному Team2). Если бы это было когда-либо случай, если вы хотите видеть предупреждения и ошибки в Xcode, как следующее:

Code Sign error: Certificate identity 'iPhone Distribution: MyName' appears more than once in the keychain. The codesign tool requires there only be one.

Во всех остальных случаях, если у вас есть как свои сертификаты и Provisioning профилей, установленных и подписывание кода значение Identity Set правильно, то Code Sign может позаботиться о себе.

Q4: Можно ли повторно использовать один и тот же сертификат для обоих приложений?

Это сплошной «Нет». Каждый идентификатор приложения имеет собственный набор профилей Provisioning Profiles, которые сопровождаются набором разрешений, одним из которых является Push Notifications. При создании нового профиля Provisioning Profile с полномочиями Push Notification вам предлагается создать новые Push-сертификаты - нет возможности предоставить ваши существующие сертификаты Apple. Это делается для обеспечения того, чтобы поставщик «Push Notifications» (ваш сервер, который создает полезную нагрузку Push Notification, отправленную на Push-шлюз Apple) изолирован песочницей, подобной той, что была найдена в iOS-экосистеме - один поставщик на AppId ... один песочница на AppId.

С точки зрения безопасности это предотвращает отправку нежелательных push-уведомлений злоумышленнику пользователю, просто предоставляя действительный токен Push и полезную нагрузку на Push Gateway от Apple.Либо настройте второй экземпляр кода вашего провайдера, либо используйте созданные сертификаты Push, создав при этом новый профиль Provisioning Profile или обновив существующий провайдер, чтобы отслеживать токены Push Notification на уровне каждого приложения и использовать правильный сертификат при отправке полезной нагрузки Push Notification к Apple. К сожалению, только вы (или ваши коллеги) можете сделать это определение, поскольку это решение будет определяться техническими возможностями вашего существующего провайдера и степенью риска, который вы/ваша компания готовы принять унифицированные Push-уведомления в одном экземпляре поставщика.

Другие могут подключиться сюда и дать дополнительную информацию о том, как они настраивают своих собственных поставщиков, но я пошел с совершенно отдельными экземплярами, чтобы предотвратить сценарий, когда обновления для Push Push уведомлений могут прерывать Push Notifications для совершенно другого приложение.