この動作の理由については、この記事で説明します。 私はこれをvk.comやOS Xのバグとは考えていませんが、両方ともこの状況を修正できるとすぐに言いたいです。
点滅ウィンドウ
まず、ビデオでどのようなウィンドウが点滅しているのかを説明します。 これを行うために、API VKの操作についていくつか説明します。 そのため、api.vk.comサーバーへのリクエストには、トークンが必要です。トークンは、oauth.vk.comのWebインターフェイスよりも承認によって取得する必要があります。 アルゴリズムは次のとおりです。
- 最後の既知のトークンを渡して、vk.comのメソッドを使用します
- 応答で認証エラーを受け取った場合は、認証に進みます
- Webフォームがロードされたウィンドウを表示し、トークンを取得します
- ステップ1からすべてを繰り返します
検閲画面で認証ウィンドウが点滅することがすぐに明らかになりました。 唯一の問題は、ウィンドウが自動的に消えたことです。 これは、Cookieが保存され、ログイン/パスワードが不要なため、Webフォームはすぐに新しいトークンにリダイレクトされます。 プログラムの認証システムは、最初のバージョンから変更されておらず、同様の問題に対処したユーザーは一人もいません。 さまざまなタイプのエラーを生成することで、このような状況をシミュレートしようとして、すぐにコードに取り組みました。 私は検索に多くの時間を費やしましたが、これはどのリクエストでも認証の問題であるという事実に留まりましたが、なぜそれが起こったのかは謎のままです。
ヒント
理由はわかりませんが、リクエストの送信元を確認することにしました。驚いたことに、IPv6アドレスがリストされました。 さて、次のタスクはIPv6チャネルを取得することでした。 Q＆A Habrセクションが役に立ちました。 私はすぐにトンネルを持ち上げ、debazhitsyaを始めました。 残念なことに、すべてが正常に機能しました。
理由
トンネルを構成するとき、すべてのトラフィックがIPv6を通過するわけではなく、さらにそのスタックのほんの一部がIPv6を通過することに気付きました。 それから私は、とにかくIPv6を優先する方法についてグーグルに行きました。 それは不可能であることが判明しました。 IPv4を完全に無効にすると、IPv6のみが残ります。 インターネット上の多くの情報を中断して、サーバー側とクライアント側の両方で両方のスタックにアクセスできる場合、使用するスタックを選択し、過去のリクエストとキャッシュの速度に基づいて決定するという情報を見つけました。 ここが問題の原因です！ 数回再起動し、DNSをリセットし、トンネルを切断/接続した後、バグが繰り返されることを確認しました。 これがどのように進んだかです：
- oauth.vk.comに連絡すると、システムはIPv6を選択します
- oauth.vk.comサーバーは、IPv6ユーザーアドレスに関連付けられたトークンを生成します
- api.vk.comを呼び出すと、システムはIPv4を選択します
- トークンが無効であり、ユーザーアドレスが変更されたため、api.vk.comサーバーはリクエストを拒否します
可能な解決策：
1. vk.comから
トークンは、IPv4とIPv6の両方の両方のアドレスにバインドする必要があります。 執筆時点で、彼らはvkから、これは不可能だと答えました。「スタックを犠牲にして。 相互に接続されていないため、2つのIPにトークンを確実に添付することはできません。
2.直接認証
VK APIには直接認証のためのメソッドがありますが、vkコマンドにアクセスした1週間で、アクセスできませんでした。
3. OS X側
スタックの1つにトラフィックを強制するための便利なソフトウェアメカニズムを作成します。
4.クライアント側。
WebViewコンポーネントはWebフォームの表示に使用され、NSURLConnectionはリクエストに使用されます。 すべてのトラフィックを1つのスタックに強制的に通すことができれば、すべてが機能するはずです。 NSURLProtocolを記述することでこれを行うことができますが、これは非常に大量の作業です。HTTPプロトコルとHTTPS +キャッシング全体を自分で記述する必要があります。
5.クライアント側。
ログイン時に、権利範囲=オフラインを要求します。これにより、IPを削除できますが、このようなアクセスを要求するプログラムは非常に疑わしいです。
この情報が他の開発者に役立つことを願っています。