我正在寻找一些示例、技巧、建议以及一些用于实现（或查找其实现）面向方面的 HTTP 身份验证库的一般方向感。
作为一些基础工作，我们构建了一个 iOS 库，该库为 HTTP 服务建立各种形式的身份验证，通过 Web 表单或本机模式窗口请求用户凭据，具体取决于所使用的机制。但是，一旦凭证经过验证，图书馆就会将其移交，并且基本上免除了其确保会话新鲜度、超时等的任何责任。
我有兴趣寻找示例或一些在我们的应用程序和后端服务之间实现更多连续网络身份验证网关的指南。从某种意义上说，应用程序对此身份验证库进行了一些初始配置，从那时起，任何 NSURLConnections 或 UIWebView 请求都将被透明地拦截并通过此身份验证库......该库接收这些请求，确定是否存在且有效auth 会话满足要求，或者是否通过 Web 表单或本机模式为这些待处理请求中的一个或多个请求提供登录信息……然后，一旦满足，它会将生成的响应传送回初始请求者。
重要的是，后续的网络请求都不想或不需要知道有关正在使用的身份验证机制的任何特殊详细信息，无论是 cookie、基本身份验证标头、O-Auth 令牌等……所有这些详细信息都由auth 库会改变出站请求并监听入站响应。
我很确定，如果我们实现了 NSURLProtocol，我们就可以通过这个库重定向连接，但是我是否正确理解这需要 URL 具有自定义方案？ （即 myauthlib-https://）...这似乎打破了后续连接不需要了解任何 auth 实现的任何特殊信息的要求。理想情况下，任何针对 http:// 和 https:// 的 GET、POST、PUT、DELETE、PATCH 请求都会自动且透明地通过此出站/入站身份验证...
我们可以尝试在 NSURLConnection 上尝试一些方法来通过我们的身份验证库重定向它，但这似乎相当脆弱。我也在考虑实施一些基于Objective-C 的 AOP https://github.com/ndcube/AOP-for-Objective-C
尝试以编程方式实现 HTTP 代理会更明智吗？
None
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
