Entitlements (受權機制) 延伸

受權機制 (Entitlements) 

到目前爲止，咱們都假設全部的證書起到的做用都是同樣的，而且假設若是咱們有了一個有效的證書代碼簽名也就相應的有效。然而這固然不是惟一的規則。操做系統有許多標準來檢測你的代碼是否容許運行。

這些標準並非一成不變的。舉例來講，在 OS X 上一個應用是否容許被開啓是由 Gatekeeper 的選項決定的，你能夠在系統設置的安全選項中改變選項。在 Gatekeeper 選項中選擇 「受信任的開發者或者來自 Mac App Store」 會要求被打開的應用必須被證書籤名，能夠是 Mac App Store 開發者的應用發佈證書也能夠是開發者 ID 證書。這些選項是由一個系統工具 spctl 來管理的，它管理着系統的全部安全評估策略。

在 iOS 上規則是不同的，不管是用戶仍是開發者都不能改變應用開啓策略，你必須有一個開發者賬號或者應用發佈證書才能讓應用運行在 iOS 系統上。

即便你可讓應用運行起來，在 iOS 上你的應用能作什麼依然是受限制的。這些限制是沙盒管理的。沙盒和代碼簽名機制是不一樣的，這很重要。代碼簽名保證了這個應用裏所包含的內容正如它所說的那樣很少很多，而沙盒則是限制了應用訪問系統的資源。這兩種技術是相互合做來發揮做用的，它們都能阻止你的應用運行，也都能在 Xcode 中引發奇怪的問題。可是在平常開發過程當中，沙盒可能會更常常引發問題。沙盒機制在何時會引發問題呢，大多數狀況下都是因爲一個叫作受權的機制決定的。

受權機制

受權機制決定了哪些系統資源在什麼狀況下容許被一個應用使用。簡單的說它就是一個沙盒的配置列表，上面列出了哪些行爲被容許，哪些會被拒絕。

極可能你已經猜到受權機制也是按照 plist 文件格式來列出的。Xcode 會將這個文件做爲 --entitlements 參數的內容傳給 codesign ，這個文件內部格式以下：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>application-identifier</key> <string>7TPNXN7G6K.ch.kollba.example</string> <key>aps-environment</key> <string>development</string> <key>com.apple.developer.team-identifier</key> <string>7TPNXN7G6K</string> <key>com.apple.developer.ubiquity-container-identifiers</key> <array> <string>7TPNXN7G6K.ch.kollba.example</string> </array> <key>com.apple.developer.ubiquity-kvstore-identifier</key> <string>7TPNXN7G6K.ch.kollba.example</string> <key>com.apple.security.application-groups</key> <array> <string>group.ch.kollba.example</string> </array> <key>get-task-allow</key> <true/> </dict> </plist> 

在 Xcode 的 Capabilities 選項卡下選擇一些選項以後，Xcode 就會生成這樣一段 XML。 Xcode 會自動生成一個 .entitlements 文件，而後在須要的時候往裏面添加條目。當構建整個應用時，這個文件也會提交給 codesign 做爲應用所須要擁有哪些受權的參考。這些受權信息必須都在開發者中心的 App ID 中啓用，而且包含在配置文件中，稍後咱們會詳細討論這一點。在構建應用時須要使用的受權文件能夠在 Xcode build setting 中的 code signing entitlements 中設置。

在這個應用中我啓用了 iCloud 鍵值對存儲 (key-value storage) (com.apple.developer.ubiquity-kvstore-identifier) ，以及 iCloud 文檔存儲 (com.apple.developer.ubiquity-container-identifiers)。另外我還將應用添加進了一個 App Group (好比說爲了與擴展 (extensions) 共享數據，com.apple.security.application-groups)， 最後開啓了推送功能 (aps-environment)。這是一個開發版本，我會有將它鏈接到調試器的需求，這就須要將 get-task-allow 設爲 true。另外，app id，也就是 bundle id 加上開發者 id，也被單獨列出來了。

固然你並不能爲所欲爲的取得受權，你的應用可否獲得某一項受權是有特定的規定的。舉例來講，當 get-task-allow 被設定爲 ture 時，應用只能在用於開發的證書籤名下運行。你被容許使用的推送環境 (aps-environment) 也存在相似的限制。

根據操做系統版本的不一樣咱們可選的受權項目是不同的，因此很難有一份列表能夠詳盡地列出全部條目。至少在文檔 Adding Capabilities 中提到的全部功能都是須要通過受權的。

受權信息會被包含在應用的簽名信息中。若是你在這方面遇到了問題，能夠嘗試查看簽名信息中具體包含了什麼受權信息：$ codesign -d --entitlements - Example.app 會列出一個和前面的很像的 XML 格式的屬性列表。你能夠將這個文件的內容添加進一個腳本，每次構建應用時用腳本檢查是否包含了推送服務的受權信息，以此確保推送服務工做正常。在這裏推送服務只是一個例子，你使用的服務越多，這樣的時候都添加推送通知的受權，以保證能夠註冊推送通知。在新版本的 Xcode 6 以後，受權信息列表會以 Example.app.xcent這樣的名字的文件形式包含在應用包中。在我看來，這麼作是爲了在出現配置錯誤時提供更加有用的錯誤信息。

 

參考連接：

1.http://foggry.com/blog/2014/10/16/ios-code-signing-xue-xi-bi-ji/

2.https://objccn.io/issue-17-2/