另一个应用程序,比如ApplicationCreator,通过intent在提供程序上创建一个元素. ApplicationProvider获取intent并相应地创建元素.
现在我希望ApplicationCreator成为唯一拥有访问该元素的权限的人.因此,如果另一个应用程序试图访问该元素,则会产生某种错误.
这样做的最佳方法是什么？我提出了两种可能的解决方案,但我不喜欢它们中的任何一种.
1)ApplicationProvider拒绝任何对提供者的直接访问,而是使用接收者获取通过intentForResult发送的意图,因此接收者可以检查调用者,验证是创建该元素的原始调用者并授予访问权限.其他应用程序将被拒绝,因为他们持有不同的uid.由于没有简单的方法来伪造uid,因此该系统可行.
2)任何应用程序都可以向提供程序发送意图,但在清单中,我指定了创建的单个uris的所有路径级权限.每次有人想要创建新元素时,我都会手动向应用程序发出更新.
=========================================
附加信息：
如果不同的应用程序可以放置不同的元素并且能够保留修改它们创建的元素的权限,并且还授予那些请求所述权限的元素的权限,那将是理想的.
A---> +--------+ A creates content
| pro | <---B B asks permission
A<----| vid | the provider forward permission
A---->| er | A grant permission
| | --->B B is given permission and can access A's stuff
+--------+
以下是我对这个主题的看法.没有提供代码,因为我没有实现任何内容.此外,我不完全确定这个解决方案是完全安全的.
一,认证.
每个想要使用您的内容提供商的客户都需要一个密钥.每个客户端从您的应用程序中获取一个密钥(可能为此实现内容提供程序).随机的字母/数字序列应该没问题.此密钥存储在您的应用程序和客户端应用程序中,这是其他任何人都无法访问的地方,即私有数据库/首选项属性.
此密钥用于向您的内容提供商验证客户端应用程序.在每个请求中,此密钥(可能是密钥的哈希值)都包含在请求uri中(与使用REST Web服务时的API密钥非常相似).您的应用程序检查以前是否生成了提供的密钥.如果是这种情况,则验证成功.
接下来,授权.
数据库中的每个元素都有一个字段ownerKey.创建新元素时,此字段将填充请求提供的密钥.访问/修改/删除元素时,内容提供商应检查存储的密钥是否与提交的密钥匹配.仅在键匹配时执行操作.
额外的想法.
>重点是应用程序生成的随机密钥保持私密.我不确定第三方是否有可能拦截客户端应用程序和内容提供商之间的交互.在编写任何代码之前,您可能需要对此进行调查.
>在每个请求上指定密钥可以是可选的.在元素创建期间省略键时,这些元素没有ownerKey,因此任何没有身份验证/授权的人都可以访问和修改它们.
我希望这有点帮助.