iOS 7ウェブアプリのHTTP認証が応答しない

Question

私の組織はiOS 6で完全に機能するウェブアプリケーションを持っていました。ウェブサイトにアクセスすると、ウェブサイトにホームページが追加され、すばらしいHTML5 Webアプリケーションがホーム画面に追加されました。

私たちは機密データを処理しているため、WebアプリケーションはHTTP認証（ネイティブのWebKit認証ダイアログを使用）を使用してユーザー/パスを認証しました。 iOS 7までは問題なく動作しました。誰かがHTTP認証ダイアログを呼び出そうとすると、何も起こりません。明らかにステータスバーのスピナーが表示されますが、ダイアログが表示されないので、何かを読み込もうとしています。

誰かがこれに遭遇しましたか？これはあなたがAppleの終わりにバグであると考えるだろうか？回避策はありますか？

Answer 1

私は全く同じ問題があります。基本認証は以前のiOSバージョンでは機能しましたが、iOS 7ではホーム画面に追加されたWebアプリケーションとの組み合わせでは機能しませんでした。私はこれがhereと記述されたダイアログの問題に関連していると思います。

アラート、確認、またはプロンプトなど、標準のダイアログがまったく機能していません。

ユーザーはおそらくブロックされている（動作していないか、表示されることはありません）とWebアプリが認証フェーズを通過しない理由があるの認証に示されているログインプロンプト。

私はAppleがこのバグを将来のリリースで修正する必要があると思います。

編集：iOS 7.0.3の基本認証にアップグレードした後、基本認証が突然ホーム画面のWebアプリモードでも再び開始されました。ログインプロンプトが表示され、すべてが正常に動作します。

Answer 2

私の会社はこの昨秋、iOS 6から始めました。私たちが確認できたのは、セキュリティ強化機能の一環としてApple Safariのバグです。理論的根拠から実際の説明はありませんが、ここではデバッグとパケットスニッファで見ています。

通常の操作では、SafariブラウザはサーバーからGETでページ（またはページ内のオブジェクト）を要求します。そのアセットがApache Basic Authのアクセス制御リストで保護されており、そのアセットがそのセッションの最初のリクエストである場合、サーバーは401 HTTP応答ヘッダーで応答し、クライアント（ブラウザ）に今回は再度要求する必要があります。今回は、認証資格情報を持つ基本認証ヘッダーを追加します。次に、ブラウザにログインダイアログが表示され、ユーザーにログインして資格情報を渡し、リクエストを送信またはキャンセルすることができます。送信時に、クライアントはauthヘッダー内のこれらの資格情報を使用して再要求します。

2番目のGETリクエストで資格情報が受け入れられると仮定すると、適切なアセットが応答に返され、ブラウザのドキュメントはページの残りの部分をロードするように進みます（リクエストしたページであると仮定します）。異なるホストにある資産を組み込み、ホストがその資産の認証を必要とする場合は、ページがロードされるとプロセスが繰り返されます。

ここでそれは壊れています。基本認証を必要とする同じページに2つ以上のホストのオブジェクトへの呼び出しを埋め込むと、そのページの3回目の認証プロンプトが表示されないため、ブラウザは表示されないプロンプト。そのSafariブラウザは、このストールされた認証プロンプト、これと他のタブ（リロード時でさえ）でハングアップします。ブラウザを閉じたり、デバイスを再起動したりするまで、別のプロンプトが表示されません。

これはChrome、Safariだけに影響はなく、iOS 6以降のiPhoneとiPadの両方に適用されます。私はこの記事（7.0.6）の時点で最新のiOS版を持っていますが、問題はまだあります。

昨年回避策がありました。埋め込みホストのそれぞれの配列を持つ内部ページを作成し、そのホストの場所にfavicon.icoの呼び出しを埋め込んだiframeでループします。それは最近まで働いていました。おそらく、iOS 7の背景タブのフリーズ機能のために、認証プロンプトが再び凍結されます。 document.writeを第二のセットは、それらのファビコンは、現在表示されるホストは、認証されているの視覚的表示を与える

hosts=["store","profile","www","secure-store","images","m","modules"]; 
devhost=location.hostname; 
var i=0; 
while (hosts[i]) 
{ 
newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain'); 
document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>"); 
document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>"); 
i++; 
} 

：ここ

は、JavaScriptのサンプルでした。また、アイコンが表示されないため、停止している可能性のあるホストを知ることができます。

iOS 7ではこの回避策が機能しなくなったため、唯一の厄介な解決策は、各favicon（URLに直接）ごとに別々のタブを開き、authを入力して戻って次のページに進みます1つはリストにあり、ページで使用されているすべてのホストのすべての認証資格情報がキャッシュされるまで繰り返されます。その時点で、あなたの信用がキャッシュされているので、元のページを読み込むことができます。 Cruddyであり、最終消費者には完全に不合理ですが、ACLを使用してその開発サイトの資産を保護する必要があるため、公開CDNの背後にあるサイトをテストするために必要なものです。

現在のところ、私たちはまだ、より良い回避策を考えています。 Android、Windows、その他のiOSでは問題ありません。

ジョブズが生きていたときにはうまくいきました。

これはいくつか役立ちます。