セッションIDとセッション、およびjwt
プロセスを書きます.
ユーザーがブラウザを開き、サーバにアクセス
TomcatはセッションIDを作成し、クッキーに入れ、有効期限をブラウザに設定して閉じ、SessionManager実装クラスManagerBaseのConcurrentHashMapに入れてkeyとして、このときのvalueはnullです.ブラウザはクッキーアクセスシステムを持ち,セッションはセッションの根拠とし,開発者はセッションにユーザの基本や権限情報などを格納し,セッションを認証することができる.
サーバプログラムがrequestを呼び出す.getSession(true)(注意:request.getSession()=request.getSession(true))、requestはクッキーとURIからsessionIDを探し、sessionIDに基づいてmapからentityを取り、自動的にsessionインスタンスを作成します.このときvalueはnullではありません.もちろんセッションIDが見つからない場合はnullを返します
だからsessionidとsessionは別々で、ブラウザを閉じて、sessionidはなくなりましたが、sessionはまだメモリの中にあります.
サーバーを閉じてセッションはなくなりましたが、セッションはまだブラウザにあります.通常、sessionを持つのはrequestのことで、プログラマーは気にしないでくださいが、その分布式では、2回のリクエストを処理するサーバは1台のサーバではないかもしれません.sessionは別のサーバのメモリの中にあり、sessionは取れません.セキュリティの安定性に特に要求されているシステムでは、サーバが突然停止し、sessionはなくなります.お客様の重要な情報はいくつかありません.これらの問題を解決するためにredisキャッシュセッションが発生しました!redisのhashハッシュテーブルを使用してkey:sessionIDとvalue:sessionを格納します.セッションを取るにはrequestに頼ってはいけない.getSession()です.私たちは自分でクッキーに行ってセッションIDを手に入れ、redisからセッションを取る必要があります.自分でHttpServletRequestは実現できませんよ.Tomcatは自己実現クラスを用い,不要なリクエストメッセージに応じて異なるrequestでクラスを実現する.
では、いつセッションを保存するのか、ログインリクエストやホームページリクエストのプログラムで、クッキーからセッションIDをもらうことができます.そして自分でStandardSessionインスタンス(Standard付きクラスの概算率はTomcatが自分で実現したもの)を作成し、redisに保存します.自分でsessionを実現することはできますが、お勧めしません.もちろんrequest.getSession(true)でsessionを作成することができます.これは最も妥当です!この方法でセッションを取ることはできません
この中で私たちがしなければならないのは保存です.一つは取ります.保存は簡単ですが、取りにはThreadLocalが必要です.ThreadLocalは何の役に立ちますか.メンバー変数は同時で共有されています.彼に共有されないように、局所変数に書くことができます.synchronizedで制限することもできますが、局所変数は頻繁に初期化されます.synchronizedは遅すぎます.だからThreadLocalはメンバー変数を非共有のデータにするために使用されます.redisはデータベースで、データベースはキャッシュを必要として、キャッシュの最も簡単なのはThreadLocalを使って、ここで彼を使ってsessionをキャッシュします!redisに対するクエリーの頻度を減らします.
sessionidはセッションの唯一の証明書として、サーバはそれを通じてsessionが有効かどうかを判断し、上がったらrestfulインタフェースにアクセスし、クッキーにsessionidがないため、tomcatはsessionが失効したと判断し、ログインページにジャンプするとurlを書き換え、後に追加します.jsessionid=xxxなど、これは安全ではありませんのでurlの書き換えを禁止する必要があります.簡単に@bean注入sessionmanager、カスタム設定でいいです.
セッションで権限を作るには問題があります.セッションがクッキーに格納されているため、xss攻撃が漏れることがあります.
JWT(json web token)についてお話しします
セッションに対して、これは現在非常に一般的なサービス授権方式であり、有状態と無状態の2種類に分けられ、有状態tokenと上のセッションのようなもの、cookie存key、メモリまたはカスタム永続化ツール(redis)key-session/tokenのハッシュリストを格納するのでtokenの意味を失い、無状態のtokenの転送はheaderまたはpost body内に書き込まれてサーバに与えられ、ドメイン間の問題を解決し、サーバ内に格納されないため、天然にはマルチサーバ共有であり、永続化する必要はなく、フロントエンドがLocalStorageまたはindexDBに格納する責任を負うログインも簡単で、異なるビジネスサーバではtokenを検証するだけです.また、サーバに情報が格納されていないため、ユーザが管理者によってログアウトされたり、ユーザがアクティブにログアウトされたりすると、当然、このユーザはシステムにアクセスできなくなります.すなわち、tokenはすぐに失効するはずですが、フロントエンドはtokenを持っています.1つのシナリオは、サービス側がユーザがログアウトしたときに、ログアウトしたtokenをサーバ内に保存することであり、tokenをもう一度受信すると、このtokenが有効かどうかを知ることができる.しかし、サーバはtokenを格納しなければならないので、ログアウト時にフロントエンドがtokenを捨てるという案もあります.また、ステータスなしtokenはサーバに保存されないため、tokenが期限切れになる前にtokenの検証情報を変更することができず、権限を変更することができません.tokenはsessionidとは異なり、それ自体にユーザー情報が含まれているため、漏洩される可能性があります.以上の2点を合わせるとtokenの期限切れ時間が長すぎず、盗用を減らすことはできません.またtokenを使用するにはhttpsプロトコルで伝送し,盗用を減らすべきである.以下に、いくつかの特性を示します.
バックエンドは、JWT文字列をログイン成功の返信結果としてフロントエンドに返します.フロントエンドは、返された結果をlocalStorageまたはsessionStorageに保存し、ログインを終了するとフロントエンドは保存したJWTを削除すればよい.簡潔(Compact):URL、POSTパラメータ、またはHTTPヘッダで送信できます.データ量が小さいため、転送速度が速いセルフ・インクルード(Self-contained):負荷にはすべてのユーザーに必要な情報が含まれており、データベースのフロントエンドが要求されるたびにJWTをHTTPヘッダのAuthorizationビットに複数回クエリーすることを回避します.(XSSとXSRFの問題解決)
バックエンド取得要求ヘッダから対応するtokenを取得し、tokenから期限切れを取得してtokenが期限切れであるか否かを判断し、期限切れでない場合は通過し、期限切れである場合は直接固定の値をフロントエンドに返し、フロントエンドは戻り値でtokenが期限切れであることを知ってからtokenを再要求し、再要求する.
間違いがあれば、指摘してください.
ユーザーがブラウザを開き、サーバにアクセス
TomcatはセッションIDを作成し、クッキーに入れ、有効期限をブラウザに設定して閉じ、SessionManager実装クラスManagerBaseのConcurrentHashMapに入れてkeyとして、このときのvalueはnullです.ブラウザはクッキーアクセスシステムを持ち,セッションはセッションの根拠とし,開発者はセッションにユーザの基本や権限情報などを格納し,セッションを認証することができる.
サーバプログラムがrequestを呼び出す.getSession(true)(注意:request.getSession()=request.getSession(true))、requestはクッキーとURIからsessionIDを探し、sessionIDに基づいてmapからentityを取り、自動的にsessionインスタンスを作成します.このときvalueはnullではありません.もちろんセッションIDが見つからない場合はnullを返します
だからsessionidとsessionは別々で、ブラウザを閉じて、sessionidはなくなりましたが、sessionはまだメモリの中にあります.
サーバーを閉じてセッションはなくなりましたが、セッションはまだブラウザにあります.通常、sessionを持つのはrequestのことで、プログラマーは気にしないでくださいが、その分布式では、2回のリクエストを処理するサーバは1台のサーバではないかもしれません.sessionは別のサーバのメモリの中にあり、sessionは取れません.セキュリティの安定性に特に要求されているシステムでは、サーバが突然停止し、sessionはなくなります.お客様の重要な情報はいくつかありません.これらの問題を解決するためにredisキャッシュセッションが発生しました!redisのhashハッシュテーブルを使用してkey:sessionIDとvalue:sessionを格納します.セッションを取るにはrequestに頼ってはいけない.getSession()です.私たちは自分でクッキーに行ってセッションIDを手に入れ、redisからセッションを取る必要があります.自分でHttpServletRequestは実現できませんよ.Tomcatは自己実現クラスを用い,不要なリクエストメッセージに応じて異なるrequestでクラスを実現する.
では、いつセッションを保存するのか、ログインリクエストやホームページリクエストのプログラムで、クッキーからセッションIDをもらうことができます.そして自分でStandardSessionインスタンス(Standard付きクラスの概算率はTomcatが自分で実現したもの)を作成し、redisに保存します.自分でsessionを実現することはできますが、お勧めしません.もちろんrequest.getSession(true)でsessionを作成することができます.これは最も妥当です!この方法でセッションを取ることはできません
この中で私たちがしなければならないのは保存です.一つは取ります.保存は簡単ですが、取りにはThreadLocalが必要です.ThreadLocalは何の役に立ちますか.メンバー変数は同時で共有されています.彼に共有されないように、局所変数に書くことができます.synchronizedで制限することもできますが、局所変数は頻繁に初期化されます.synchronizedは遅すぎます.だからThreadLocalはメンバー変数を非共有のデータにするために使用されます.redisはデータベースで、データベースはキャッシュを必要として、キャッシュの最も簡単なのはThreadLocalを使って、ここで彼を使ってsessionをキャッシュします!redisに対するクエリーの頻度を減らします.
sessionidはセッションの唯一の証明書として、サーバはそれを通じてsessionが有効かどうかを判断し、上がったらrestfulインタフェースにアクセスし、クッキーにsessionidがないため、tomcatはsessionが失効したと判断し、ログインページにジャンプするとurlを書き換え、後に追加します.jsessionid=xxxなど、これは安全ではありませんのでurlの書き換えを禁止する必要があります.簡単に@bean注入sessionmanager、カスタム設定でいいです.
mySessionManager.setSessionIdUrlRewritingEnabled(false);セッションで権限を作るには問題があります.セッションがクッキーに格納されているため、xss攻撃が漏れることがあります.
JWT(json web token)についてお話しします
セッションに対して、これは現在非常に一般的なサービス授権方式であり、有状態と無状態の2種類に分けられ、有状態tokenと上のセッションのようなもの、cookie存key、メモリまたはカスタム永続化ツール(redis)key-session/tokenのハッシュリストを格納するのでtokenの意味を失い、無状態のtokenの転送はheaderまたはpost body内に書き込まれてサーバに与えられ、ドメイン間の問題を解決し、サーバ内に格納されないため、天然にはマルチサーバ共有であり、永続化する必要はなく、フロントエンドがLocalStorageまたはindexDBに格納する責任を負うログインも簡単で、異なるビジネスサーバではtokenを検証するだけです.また、サーバに情報が格納されていないため、ユーザが管理者によってログアウトされたり、ユーザがアクティブにログアウトされたりすると、当然、このユーザはシステムにアクセスできなくなります.すなわち、tokenはすぐに失効するはずですが、フロントエンドはtokenを持っています.1つのシナリオは、サービス側がユーザがログアウトしたときに、ログアウトしたtokenをサーバ内に保存することであり、tokenをもう一度受信すると、このtokenが有効かどうかを知ることができる.しかし、サーバはtokenを格納しなければならないので、ログアウト時にフロントエンドがtokenを捨てるという案もあります.また、ステータスなしtokenはサーバに保存されないため、tokenが期限切れになる前にtokenの検証情報を変更することができず、権限を変更することができません.tokenはsessionidとは異なり、それ自体にユーザー情報が含まれているため、漏洩される可能性があります.以上の2点を合わせるとtokenの期限切れ時間が長すぎず、盗用を減らすことはできません.またtokenを使用するにはhttpsプロトコルで伝送し,盗用を減らすべきである.以下に、いくつかの特性を示します.
バックエンドは、JWT文字列をログイン成功の返信結果としてフロントエンドに返します.フロントエンドは、返された結果をlocalStorageまたはsessionStorageに保存し、ログインを終了するとフロントエンドは保存したJWTを削除すればよい.簡潔(Compact):URL、POSTパラメータ、またはHTTPヘッダで送信できます.データ量が小さいため、転送速度が速いセルフ・インクルード(Self-contained):負荷にはすべてのユーザーに必要な情報が含まれており、データベースのフロントエンドが要求されるたびにJWTをHTTPヘッダのAuthorizationビットに複数回クエリーすることを回避します.(XSSとXSRFの問題解決)
バックエンド取得要求ヘッダから対応するtokenを取得し、tokenから期限切れを取得してtokenが期限切れであるか否かを判断し、期限切れでない場合は通過し、期限切れである場合は直接固定の値をフロントエンドに返し、フロントエンドは戻り値でtokenが期限切れであることを知ってからtokenを再要求し、再要求する.
間違いがあれば、指摘してください.