我成功验证了从苹果商店进行的应用内购买，然后我的应用程序从我的服务器下载内容。问题是，如果用户嗅探传出的 url 请求，他们将可以访问我的所有内容。我搜索了互联网，发现安全性不是一个简单的解决问题，如果你真的很认真，你应该采用多层。我只是一名开发人员，正在权衡风险/努力，我真的想让窃取我的内容比简单地查看传出的 URL 请求更加困难。
有什么我可以做的吗？仅仅验证收据是不够的，我想让我的服务器只允许 iPhone/iPad 从某些文件夹下载，或者提供隐藏文件夹的自定义 URL。
编辑：
与此同时，我发现了这个 问题是相关的，但它并没有直接回答我的问题。事实上，提供的唯一解决方案并不是适合我的解决方案，因为我希望我的内容在同一用户拥有的所有设备上可用。我只是不希望有人能够在浏览器中输入他们找到的 URL 并下载我的所有内容。
I successfully verify in-app purchases from the apple store, and then my app downloads the content from my server. The problem is if a user sniffs the outgoing url request, they will have access to all my content. I've scoured the internet and I've gathered that security is not a simple problem to solve, and if you are really serious you should employ multiple layers. I'm just one developer and weighing the risks/effort, I'd really just like to make it more difficult to steal my content than simply looking at outgoing url requests.
Is there anything I can do? Just verifying the receipt isn't enough, I'd like to have my server allow only iPhones/iPads to download from certain folders, or provide custom urls to folders hidden otherwise.
EDIT:
in the meantime, I've found this question to be relevant, but it doesn't directly answer my question. In fact, the only solution offered isn't a solution for me, since I want my content to be available on all devices owned by the same user. I just don't want somebody to be able to type the URL they found into a browser and download all my content.
发布评论
评论（2）
您可以切换到 TLS 或 SSL HTTP 会话吗？这会减少嗅探 URL 的机会。
如果您生成极其复杂的每用户 URL，那么您可能会在一定程度上相信客户无法简单地猜测他们未购买的内容的 URL。
例如，不是通过以下方式提供新内容：
在不同的 URL 上提供它：
我生成了那些荒谬的 URL：
每个用户都可以得到自己的一堆可怕的 URL，并且需要比平均更多的努力来逆转它。 （当然，对于这个简单的例子，如果我刚刚购买了“西班牙语动词包”，我可能很有可能猜测 URL 格式。你能做的不多这样做，因为无论你让它变得多么复杂，具有调试器访问权限或有大量空闲时间的人可能会弄清楚 URL 混淆机制。）
这就是为什么我选择简单机制：TLS 和哈希开发速度应该足够快，这样您就不会浪费太多时间来保护您的内容，而不是编写新功能或修复最后几个烦人的错误。
Can you switch to TLS or SSL HTTP sessions? That'd reduce the chances of sniffing the URLs.
If you generate extremely complicated per-user URLs then you could have some level of faith that clients cannot simply guess URLs for content they have not purchased.
For example, instead of offering your new content via:
offer it on a different URL:
I generated those ridiculous URLs with:
Each user could get their own piles of horrible URLs, and it'd take more than the average amount of effort to reverse it. (Of course, for this simple example, if I just bought the "spanish verbs pack", I might stand a good chance of guessing the URL format. Not much you can do about that, as no matter how complicated you make it, someone with debugger access or plenty of free time could probably figure out the URL obfuscation mechanism.)
Which is why I picked simple mechanisms: TLS and hashing ought to be fast enough to develop that you don't waste too much of your time working on protecting your content rather than writing new features or fixing those last few annoying bugs.
您不仅可以验证收据，还可以使用收据中购买者特有的某些部分（但不是 URL 的一部分）来混淆或加密下载。
Not only could you verify the receipt, but you could obfuscate or encrypt the download using some portion of the receipt unique to the purchaser but that isn't a part of the URL.