アスペクト指向の HTTP 認証ライブラリを実装する (または実装を見つける) ための例、ヒント、アドバイス、一般的な方向性を探しています。
ちょっとした基礎として、使用しているメカニズムに応じて、Web フォームまたはネイティブ モーダル ウィンドウを介してユーザー資格情報を要求する、HTTP サービスのさまざまな形式の認証を確立する iOS ライブラリを構築しました。ただし、資格情報が検証されると、ライブラリはそれらを引き渡し、基本的に、セッションの鮮度、タイムアウトなどを保証する責任をすべて取り除きます。
アプリとバックエンド サービスの間に継続的なネットワーク認証ゲートウェイをさらに実装するための例やガイダンスを見つけることに興味があります。ある意味では、アプリはこの認証ライブラリの初期構成を行い、その時点から、NSURLConnections または UIWebView リクエストは透過的に傍受され、この認証ライブラリを通過します...ライブラリはこれらのリクエストを受け取り、既存の有効な認証セッションは要件を満たしているか、これらの保留中のリクエストの 1 つ以上に対して Web フォームまたはネイティブ モーダルを介してログインを提示するかどうかを満たしています...そして、満たされると、結果のレスポンスを最初のリクエスタに送り返します。
重要なことは、後続のネットワーク リクエストのいずれも、使用中の認証メカニズムに関する特別な詳細を必要としない、または知る必要がないということです。アウトバウンド リクエストを変更し、インバウンド レスポンスをスヌープする認証ライブラリ。
NSURLProtocol を実装した場合、このライブラリを介して接続をリダイレクトできると確信していますが、これには URL にカスタム スキームが必要であるという理解で正しいでしょうか? (つまり、myauthlib-https://) ... これは、以降の接続で auth 実装について特別なことを知る必要がないという要件を破っているようです。理想的には、http:// および https:// に対する GET、POST、PUT、DELETE、PATCH リクエストは、この送信/受信認証を自動的かつ透過的に通過します ...
NSURLConnection でいくつかのメソッド スウィズリングを試して、認証ライブラリを介してリダイレクトすることもできますが、これはかなり壊れやすいようです。また、 AOP-for-Objective-C に基づいたものを実装することも検討していました
プログラムで HTTP プロキシを実装することをお勧めしますか?