Работа с правами
Движение, Final Cut Pro и Компрессор находятся в процессе перемещения в поигравшую в песочнице модель. Эта глава обеспечивает краткий обзор игры в песочнице приложения. Вы также изучите, как указать права для поигравшего в песочнице приложения и понять, как загружаются плагины.
Приложение, играющее в песочнице обзор
Игра в песочнице приложения ограничивает доступ приложения к только системным ресурсам, включая файловую систему, для которой это - явно заданный доступ. Поигравшему в песочнице приложению дают подпись кода для предотвращения вмешательства и списка системных ресурсов, к которым позволяется получить доступ. Этот список системных ресурсов вызывают, его права — видят Указание Прав.

До игры в песочнице приложения, загружая произвольный сторонний код имел полный системный доступ, представляя потенциальную проблему безопасности. Существует три способа сражаться с этим:
Ограничьте права хост-приложения на предметы первой необходимости.
Вызовите загруженный код, такой как плагин, для работы без большего количества прав, чем узел (наследование полномочия).
Разработайте хост-приложение для использования в своих интересах установленной OS XPC Services, типа межпроцессного взаимодействия (IPC), обрабатывающийся надежно на системном уровне.
Служба XPC является легким “процессом” инструмента помощника, который может быть порожден с его собственными правами для выполнения работы от имени приложения. Наличие его собственных прав вызывают разделением полномочия и существенно сокращает возможный вред от вредоносной атаки в случае инжекции кода и т.п.
Плагины FxPlug удобно связывают необходимые компоненты для традиционной Службы XPC, упрощающей для разработчиков принять. Для большинства сменных разработчиков, которым не нужны права вне того, что предоставлено Движением и Final Cut Pro, миграция существующих плагинов является простым процессом, состоящим главным образом из добавления целей XCode и plist объектов. Для разработчиков, хотящих использовать дополнительные права, такие как доступ к сети, доступ адресной книги или встроенная камера, перемещая код в Службу XPC может помочь.
Когда плагин FxPlug должен связаться с его Службой XPC из процесса, разработчики могут использовать новое FxPrincipalAPI, который возвращает объект прокси.

Этот объект прокси принимает вызовы метода, передает их через процессы и возвращает результаты. Это является быстрым, асинхронным, и менее сложным, чем установка Вашей собственной Службы XPC. Объект прокси знает, какие методы могут использоваться посредством установленного разработчиками протокола, соединяющегося с обоими компонент в узле (Встроенный Принципал), и Служба XPC из процесса (Принципал Службы — посмотрите Встроенную Коммуникацию Принципала Принципала и Службы).
Все три компонента (Встроенный Принципал, Принципал Службы и Протокол) объединены в единственный пакет, комплект приложений. Этот комплект приложений является новой структурой плагина FxPlug 3.0 — посмотрите Создание Нового Комплекта приложений FxPlug и Преобразование Старых Плагинов FxPlug к Новым Плагинам FxPlug. Многократные фильтры могут быть связаны в отдельное приложение и использовать тот же Принципал Службы. Разработчики могут использовать в своих интересах эту новую структуру и записать приложение, которое видят пользователи, когда они дважды щелкают по плагину, и плагины больше не должны жить в специальной папке в системе.
Указание прав
Обратитесь к Дающей право Ключевой Ссылке для получения информации о том, как указать права для Ваших плагинов FxPlug.
Сменное открытие
Сменное открытие выясняется через PlugInKit, новый OS X v10.9 системный компонент. Когда пользователь копирует файл в их систему в первый раз, Launch Services автоматически регистрирует Ваш плагин в PlugInKit. Когда Движение или выполнения Final Cut Pro, это запрашивает PlugInKit для всех плагинов FxPlug и загружает любого, которого это находит. Ваш плагин должен иметь дополнительную запись в своем plist файле для PlugInKit-специфичных данных.
Загрузка плагинов FxPlug
С Launch Services, теперь обрабатывающей открытие плагинов FxPlug, несколько новых проблем возникли для разработчиков. При разработке плагина весьма распространено иметь несколько папок проекта с каталогами сборки, содержащими различные версии того же плагина. Однако хост-приложения могут только загрузить один плагин определенным идентификатором, и загружающийся плагин может не быть тем, который Вы хотите.
Хост-приложения детерминировано загружают плагины идентичными идентификаторами с помощью следующего ряда правил:
Для конечных пользователей, плагинов в
/Applicationsпапка (и ее подпапки) имеют высший приоритет.Дополнительные плагины обнаружили на диске, которые не являются копией одной в
/Applicationsпапка сначала оценивается версией (последняя версия имеет приоритет), и, если их версии соответствуют, то согласно лексикографическому порядку (первый плагин списка порядка по убыванию выбран).
Например, скажите разработку плагина FxBrightness.app FxPlug, и конечный пользователь помещает его в /Applications. Плагин в /Applications тот, загружающийся, когда запускается хост-приложение. Если они перемещают его из /Applications, это все еще загружается, если другая копия FxBrightness.app не помещается в /Applications, когда загружается тот.
Если конечный пользователь имеет две копии плагина FxBrightness.app FxPlug на диске, и ни один не находится в /Applications, второй набор критериев применяется. Сначала версия проверяется, и если они - то же, тогда путь привык к, выбрал плагин для загрузки.
Для сторонних разработчиков те же правила применяются, но со средствами управления с более прекрасными зернами, чтобы помочь упростить процесс. Используя запись значений по умолчанию из командной строки, разработчики могут указать, игнорируют и приоритетные пути.
Проигнорируйте пути — Никакие плагины по указанным путям (и подпапки) не загружаются.
Приоритетные пути — Плагины по указанным путям берут приоритет над всеми другими плагинами с тем же идентификатором. Приоритетные пути применяются в порядке, они указаны с первым путем, имеющим самый высокий приоритет.
defaults write команда:
defaults write <host-application> <path-type> -array <paths> |
Где:
host-application— Хост-приложение, для которого должны быть применены значения по умолчанию пути:com.apple.motionapp(для Движения) илиcom.apple.FinalCut(для Final Cut Pro).path-type— Тип тракта:FxPlugPriorityPaths(для Приоритета) илиFxPlugIgnorePaths(для Игнорируют).paths— Список каталогов, разделенных пространством. Оставьте это незаполненное для очистки путей.
По умолчанию приоритетный путь хост-приложения /Applications. Если новый приоритетный путь указан, /Applications больше не считаются приоритетом, если явно не установлено как таковым.
В любых коллизиях между приоритетом и игнорируют пути, проигнорировать пути применяются сначала, для отбора плагинов.
Встроенная коммуникация принципала принципала и службы
Встроенный Принципал может получить прокси XPC для Принципала Службы через +[FxPrincipalAPI servicePrincipal] метод. Аналогично, Принципал Службы может получить прокси XPC для встроенного принципала через +[FxPrincipalAPI embeddedPrincipal] метод. Эти два принципала должны согласиться с протоколом для своей коммуникации, и необходимо включать имя протокола в запись PlugInKit файла плагина Info.plist. Когда соединение установлено, можно асинхронно вызвать любые методы, перечисленные в согласованном протоколы каждого принципала.
Если плагин не использует XPC и не требует никаких специальных полномочий, он может работать полностью встроенным кодом. Необходимо все еще указать Основной класс XPC и назвать его в XPC-Info.plist, но можно опустить определять протокол. Если Вы делаете, несомненно, перечислят значение для Протокола как NSObject.