一个客户端应用，比如说微博的第三方客户端，应该把 api_secret_key 这种重要的常量放到项目的哪个位置？如果被逆向了是不是这个 api_secret_key 也会泄漏？
This topic created in 4016 days ago, the information mentioned may be changed or developed.
11 replies • 2015-11-09 13:13:42 +08:00
 |
XcodeUserNov 7, 2015
1
keychain
|
 |
pheyerNov 7, 2015
2
@XcodeUser 越狱后 keychain 一样不安全， http://bobao.360.cn/learning/detail/324.html
|
 |
WildCatNov 7, 2015
3
|
 |
GPUNov 7, 2015
4
keychain 可以保存 app 的登录密码的吗原来 。
怎么用的？ |
 |
squid157Nov 7, 2015
5
API Key 放在客户端 这个我觉得不合适 应该放在你们的服务器吧 客户端不直接调用上面的 API 而是调用你们服务器的 API
然后再考虑你们内部的 api_key 怎么处理 这样有 key 泄露了也好处理 |
 |
zts1993Nov 7, 2015 via iPhone
6
我来看头像
|
 |
7
@squid157 我觉得这样其实没有从本质上解决问题，不过还是感谢你
|
 |
so898Nov 8, 2015
9
以前针对微博（算是 OAuth 2.0 ）这种验证研究过
具体来说就是你的 Secret 应该存在你的服务器上，通过那个回掉的 URL 获取用户的 Access Token 以前有些 SDK 会在用户登录的时候拦截 URI 跳转，然后通过应用拿回用户的 Access Token ，这样确实省了一个服务器成本，但是 Secret 就得保存在本地，而且傻逼微博获取 Access Token 的接口是 get 的， ssl 也无法防止用户拦截获取你的 Secret |
|
10
找到一篇可供参考的解决方案： http://stackoverflow.com/questions/14778429/secure-keys-in-ios-app-scenario-is-it-safe 我想这就是上面各位说的把 secret key 放到服务器端来保护。看来服务器这一层目前是免不了了，那我干脆在服务器这层把翻墙代理一起弄了，这样就可以做出在国内可用的 Twitter 客户端了 XD ，一个思路，不一定对。
|
|
11
|
Select Language