Content Provider的權限

Content Provider的權限的管理很複雜，因此須要慢慢的說。

 

一個Provider裏面可能有私有數據，也有公有數據。也就是說，有可能有些數據能夠公開，有些不能公開。而且，有些數據可讓別人修改，有些不能讓別人修改。

 

圍繞上訴的可能狀況，Provider就須要設置讀權限（android:readPermission），和寫權限（android:writePermission），或者乾脆都設置（android:permission）。由於一個Provider可能被多個程序共同調用，那麼這個Provider的數據，就須要作同步處理，所以須要設置android:multiprocess="true"

 

那麼怎麼控制哪些數據是能夠操做的，哪些又是不能操做的呢？Provider是經過URI來識別須要操做的數據是什麼，所以數據的限制就須要體如今對URI的控制上。

 

path-permission，控制訪問在這個路徑下的數據的權限，如：

<path-permission android:pathPrefix="/users"            
    android:permission="lichie.provider.permission"/>    

意思就是，訪問「/users」這個路徑下的數據，必需要有"lichie.provider.permission"的權限。

值得注意的是：若是provider沒有設置權限，只設置了path-permission的權限，那麼在android 2.3.3版本中，path-permission設置的權限，是不會生效的。

 

<provider
    android:name=".PackageProvider"
    android:authorities="com.ygomi.packageprovider"
    android:multiprocess="true"
    android:readPermission="com.ygomi.packageprovider.permission.read">
    <path-permission
        android:pathPattern="/apks/.*"
        android:permission="com.ygomi.packageprovider.permission.application.read"/>
</provider>

這段代碼的path-permission是有效的，可是下面這段代碼是無效的。

<provider
    android:name=".PackageProvider"
    android:authorities="com.ygomi.packageprovider"
    android:multiprocess="true">
    <path-permission
        android:pathPattern="/apks/.*"
        android:permission="com.ygomi.packageprovider.permission.application.read"/>
</provider>

android:grantUriPermissions，管理哪一個範圍的數據權限須要處理。這個屬性其實不用顯示的設置，由於若是設置了android:readPermission, android:writePermission ,android:permission中的任意一個android:grantUriPermissions就默認是true了；若是設置了grant-uri-permission，那麼android:grantUriPermissions默認就是false；若是都設置了，那麼android:grantUriPermissions也是false。

 

grant-uri-permission這個東西是很是難理解了。文檔上雖說是在沒有權限的程序，須要訪問Provider的時候，用於繞過權限控制的。可是這個東西第一次使用，仍是很是的難。下面來細說一下。

 

首先，要創建一個觀念，沒有權限，就必定不能訪問，不然就有安全隱患。咱們來舉個例子：

應用程序（Application）A有一個Provider來提供一些數據給其餘程序訪問，可是他須要設置一個權限控制，因此在應用程序A的配置文件中，就有了下面一段代碼：

<provider
    android:name=".MyProvider"
    android:authorities="mytest.testProvider"
    android:multiprocess="true"
    android:readPermission="lichie.provider.permission">
    <grant-uri-permission android:pathPrefix="/user/"/>
</provider>

意思就是，除了應用程序A外，其餘全部的程序，都必須具備"lichie.provider.permission"的權限，才能訪問Provider的數據。可是容許你們在沒有權限的時候，經過"/user/"訪問。等等，等等，沒有權限也能夠用「/user/」訪問，那麼要權限來有啥子用啦？

 

精彩的地方來了，其實grant-uri-permission的做用是使，調用Provider的程序（咱們這裏叫應用程序B）能夠沒有權限，可是調用應用程序B的程序（咱們這裏叫應用程序C），必需要有權限。

 

因此，在應用程序C的配置文件中，須要有如下代碼：

<uses-permission android:name="lichie.provider.permission" />

 

一個content provider可能想保護它的讀寫權限，而同時與它對應的直屬客戶端也須要將特定的URI傳遞給其它應用程序，以便其它應用程序對該URI進行操做。一個典型的例子就是郵件程序處理帶有附件的郵件。進入郵件須要使用permission來保護，由於這些是敏感的用戶數據。然而，若是有一個指向圖片附件的URI須要傳遞給圖片瀏覽器，那個圖片瀏覽器是不會有訪問附件的權利的，由於他不可能擁有全部的郵件的訪問權限。
針對這個問題的解決方案就是per-URI permission：當啓動一個activity或者給一個activity返回結果的時候，呼叫方能夠設置Intent.FLAG_GRANT_READ_URI_PERMISSION和/或 Intent.FLAG_GRANT_WRITE_URI_PERMISSION . 這會使接收該intent的activity獲取到進入該Intent指定的URI的權限，而不論它是否有權限進入該intent對應的content provider。

這種機制容許一個一般的capability-style模型，這種模型是以用戶交互（如打開一個附件， 從列表中選擇一個聯繫人）爲驅動，特別獲取fine-grained permissions（更細粒化的權限）。這是一種減小沒必要要權限的重要方式，這種方式主要針對的就是那些和程序的行爲直接相關的權限。
這些URI permission的獲取須要content provider（包含那些URI）的配合。強烈推薦在content provider中提供這種能力，並經過android:grantUriPermissions或者<grant-uri-permissions>標籤來聲明支持。

<grant-uri-permission android:path="string"
                      android:pathPattern="string"
                      android:pathPrefix="string" />