faviconicoアイコンによる重大な事故
3175 ワード
一つのケースを共有し、著者が問題を分析し、解決する構想の流れは学ぶ価値があるので、markの下に記録します.
信じられないかもしれないfaviconicoアイコンは重大な事故を引き起こすが、私は本当に自分で経験した.最近オンラインになったプロジェクトで不思議なことが起こった.かばんをつかんで分析しなければ、本当に玄学と言えるだろう.
このプロジェクトはAPIバックエンドとAndroidクライアント、WebViewに埋め込まれたページに分かれています.クライアントは、ログインといくつかの基本的なAPIがオリジナルの操作であることを除いて、他のコアビジネスはWebViewがロードしたWebページ上でインタラクティブです.プロジェクトの発表生産環境がオンラインになった後、一部の機種のユーザーはコア機能が使用できないと反応し、ある程度深刻な問題をもたらした.最終的に問題にナビゲートするにはicoアイコンで、以下で詳細な分析を行います.AppクライアントにWebViewを埋め込み,オリジナルと非オリジナルの混合開発を行うことは,現在もコスト反復の産物である.多くの場合、API間の要求はSessionの代わりにTokenメカニズムを採用することが増えているが、Sessionにも独自の改善案があり、APIの安全を保証している.ここではTokenとSessionの対比はしない.
プロジェクトの特殊性のため、クライアントとサービス側のAPIインタフェースはSessionメカニズムを採用する
テストの主な問題は次のとおりです.
1.APPクライアントのテスト環境に対するすべての要求は完全に正常であるが、生産環境において、後続ページのAjax要求の核心業務異常2.PCブラウザで対応するページを開くと、テスト環境も本番環境もすべて正常
この問題に対して、符号化の観点から発見することはできないので、パケットをキャプチャして区別しなければならない.パケットのデータ分析に基づいて問題点を見つけたので、キャプチャしたパケットを以下のテスト環境と生産環境の要求タイミングチャートを簡単に羅列した.
一、テスト環境の要求
ハイブリッド開発では、クライアントとサービス側の正常なリクエスト応答を下図に示します.
Androidクライアントには、オリジナルのAPIリクエストとWebViewリクエストの2つの部分があり、ログインリクエストはAndroidオリジナルのリクエストで実現され、ログイン後に得られたSessionIDはCookie同期によりWebViewに設定される.これにより、WebViewは、後続のリクエスト時に自動的に緑色のライフライン部分がクライアントのWebViewを表すようになります(ここではシーケンス図を簡略化します).
二、生産環境の要求
シーケンス図から分かるように、生産環境下には多くのプロジェクトが配置されており、そのうちWEBサービスのドメイン名はwww.pro-webである.com、私たちのバックエンドAPIサービスはこのドメイン名のサブディレクトリの下に配置されています:www.pro-web.com/api/
低バージョンのAndroidのWebViewは、リクエストを開始すると、デフォルトではドメイン名に対応するfaviconをリクエストします.icoリソース.このドメイン名は、WEBサービスAにブロックされ、WebViewにSESSIONIDが再割り当てされ、応答ヘッダのSet-Cookieによって古いCookieのSESSIONIDが上書きされます.このSESSIONIDはWEBサービスAが割り当てられているため、後続のAjaxがAPIサービス側を要求した場合、APIサービスはSESSIONIDに基づいて対応するSESSIONを見つけることができず、当該ユーザがログインしていないと判断して正常な業務要求を行うことができない.
二、結論
Androidのバージョン番号によってWebViewのリクエスト方式が異なるため、リクエストインタフェースアドレスwww.pro-web.com/api/のリソースの場合、www.pro-webが自動的に要求されます.comドメイン名の下のfavicon.icoアイコン.
しかもちょうどwww.pro-web.comというドメイン名の下で他のWebサービスがico要求をブロックし、このWebサービスの他の業務にリダイレクトしたため、変更Webサービスに対応するSESSIONIDが再割り当てされ、ヘッダのSet-Cookieに戻ることでクライアントの元のSESSIONIDが自動的に上書きされる.後続のサービスが利用できなくなりました.
ソリューション
1.androidのWebViewはサイトを要求しないfaviconを設定する.icoリソース2.xxx.htmlにicoリソースを追加する優先度が最も高く、icoリソース3を要求しない.同じドメイン名の下に複数のプロジェクトがある場合、各プロジェクトにそれぞれのコンテキストを構成する必要があり、コンテキストがネストされていない場合4.Tokenメカニズムを使用してAPIインタフェースの検証を行い、サービス側がリソースをブロックした後にSet-Cookieがクライアントをログインする時に正常なSESSIONIDを上書きすることを回避する.
シナリオ1:androidの開発が忙しいことを考慮して、コミュニケーションのコストが比較的大きいシナリオ3:古いプロジェクトの生産環境のアドレスはすでに長い間使って、コンテキストを修正して他のサービス呼び出しの問題をもたらす可能性があります.シナリオ4:SessionからTokenへの移行には大きな作業量が必要であり、特にすでにオンラインになっているサービスが多い場合は、一発で全身を動かす.
そこで最終的に案2を採用し、APIサービス側でxxxを修正する.htmlのheadには次のように追加されます.
提案:各プロジェクトを異なる2級ドメイン名で使用する注意:2級ドメイン名を設定しても、カーネルバージョンのブラウザによってはfaviconが要求されます.icoピクチャは、2級ドメイン名が見つからない場合は、トップドメイン名を検索します.トップドメイン名の下で対応するプロジェクトにリソースブロックのある業務がicoをブロックした場合、依然として問題が発生する可能性があるため、サービス側は必ず規範化しなければならない.妥協は鍋を振るためや鍋を受け取るためではなく、プロジェクト全体が正常に行われるために、試行錯誤を続け、大局を考えなければならない場合がある.
信じられないかもしれないfaviconicoアイコンは重大な事故を引き起こすが、私は本当に自分で経験した.最近オンラインになったプロジェクトで不思議なことが起こった.かばんをつかんで分析しなければ、本当に玄学と言えるだろう.
このプロジェクトはAPIバックエンドとAndroidクライアント、WebViewに埋め込まれたページに分かれています.クライアントは、ログインといくつかの基本的なAPIがオリジナルの操作であることを除いて、他のコアビジネスはWebViewがロードしたWebページ上でインタラクティブです.プロジェクトの発表生産環境がオンラインになった後、一部の機種のユーザーはコア機能が使用できないと反応し、ある程度深刻な問題をもたらした.最終的に問題にナビゲートするにはicoアイコンで、以下で詳細な分析を行います.AppクライアントにWebViewを埋め込み,オリジナルと非オリジナルの混合開発を行うことは,現在もコスト反復の産物である.多くの場合、API間の要求はSessionの代わりにTokenメカニズムを採用することが増えているが、Sessionにも独自の改善案があり、APIの安全を保証している.ここではTokenとSessionの対比はしない.
プロジェクトの特殊性のため、クライアントとサービス側のAPIインタフェースはSessionメカニズムを採用する
テストの主な問題は次のとおりです.
1.APPクライアントのテスト環境に対するすべての要求は完全に正常であるが、生産環境において、後続ページのAjax要求の核心業務異常2.PCブラウザで対応するページを開くと、テスト環境も本番環境もすべて正常
この問題に対して、符号化の観点から発見することはできないので、パケットをキャプチャして区別しなければならない.パケットのデータ分析に基づいて問題点を見つけたので、キャプチャしたパケットを以下のテスト環境と生産環境の要求タイミングチャートを簡単に羅列した.
一、テスト環境の要求
ハイブリッド開発では、クライアントとサービス側の正常なリクエスト応答を下図に示します.
Androidクライアントには、オリジナルのAPIリクエストとWebViewリクエストの2つの部分があり、ログインリクエストはAndroidオリジナルのリクエストで実現され、ログイン後に得られたSessionIDはCookie同期によりWebViewに設定される.これにより、WebViewは、後続のリクエスト時に自動的に緑色のライフライン部分がクライアントのWebViewを表すようになります(ここではシーケンス図を簡略化します).
二、生産環境の要求
シーケンス図から分かるように、生産環境下には多くのプロジェクトが配置されており、そのうちWEBサービスのドメイン名はwww.pro-webである.com、私たちのバックエンドAPIサービスはこのドメイン名のサブディレクトリの下に配置されています:www.pro-web.com/api/
低バージョンのAndroidのWebViewは、リクエストを開始すると、デフォルトではドメイン名に対応するfaviconをリクエストします.icoリソース.このドメイン名は、WEBサービスAにブロックされ、WebViewにSESSIONIDが再割り当てされ、応答ヘッダのSet-Cookieによって古いCookieのSESSIONIDが上書きされます.このSESSIONIDはWEBサービスAが割り当てられているため、後続のAjaxがAPIサービス側を要求した場合、APIサービスはSESSIONIDに基づいて対応するSESSIONを見つけることができず、当該ユーザがログインしていないと判断して正常な業務要求を行うことができない.
二、結論
Androidのバージョン番号によってWebViewのリクエスト方式が異なるため、リクエストインタフェースアドレスwww.pro-web.com/api/のリソースの場合、www.pro-webが自動的に要求されます.comドメイン名の下のfavicon.icoアイコン.
しかもちょうどwww.pro-web.comというドメイン名の下で他のWebサービスがico要求をブロックし、このWebサービスの他の業務にリダイレクトしたため、変更Webサービスに対応するSESSIONIDが再割り当てされ、ヘッダのSet-Cookieに戻ることでクライアントの元のSESSIONIDが自動的に上書きされる.後続のサービスが利用できなくなりました.
ソリューション
1.androidのWebViewはサイトを要求しないfaviconを設定する.icoリソース2.xxx.htmlにicoリソースを追加する優先度が最も高く、icoリソース3を要求しない.同じドメイン名の下に複数のプロジェクトがある場合、各プロジェクトにそれぞれのコンテキストを構成する必要があり、コンテキストがネストされていない場合4.Tokenメカニズムを使用してAPIインタフェースの検証を行い、サービス側がリソースをブロックした後にSet-Cookieがクライアントをログインする時に正常なSESSIONIDを上書きすることを回避する.
シナリオ1:androidの開発が忙しいことを考慮して、コミュニケーションのコストが比較的大きいシナリオ3:古いプロジェクトの生産環境のアドレスはすでに長い間使って、コンテキストを修正して他のサービス呼び出しの問題をもたらす可能性があります.シナリオ4:SessionからTokenへの移行には大きな作業量が必要であり、特にすでにオンラインになっているサービスが多い場合は、一発で全身を動かす.
そこで最終的に案2を採用し、APIサービス側でxxxを修正する.htmlのheadには次のように追加されます.
1
"icon" href="data:image/ico;base64,aWNv">
提案:各プロジェクトを異なる2級ドメイン名で使用する注意:2級ドメイン名を設定しても、カーネルバージョンのブラウザによってはfaviconが要求されます.icoピクチャは、2級ドメイン名が見つからない場合は、トップドメイン名を検索します.トップドメイン名の下で対応するプロジェクトにリソースブロックのある業務がicoをブロックした場合、依然として問題が発生する可能性があるため、サービス側は必ず規範化しなければならない.妥協は鍋を振るためや鍋を受け取るためではなく、プロジェクト全体が正常に行われるために、試行錯誤を続け、大局を考えなければならない場合がある.