ログイン認証 - ログイン検証 - セッションテクノロジー

会話テクノロジー

セッション追跡ソリューションの比較

解決策 1: Cookie

ソリューション 3: トークンテクノロジー (主流のソリューション)

実装のアイデア

アドバンテージ

欠点がある

会話テクノロジー

セッション: ユーザーがブラウザを開いて Web サービスのリソースにアクセスすると、一方が切断するまでセッションが確立され、セッションが終了します。1 つのセッションに複数のリクエストとレスポンスが含まれます。
セッショントラッキング: ブラウザの状態を維持する方法。ブラウザは、同じセッション内の複数のリクエスト間でデータを共有するために、複数のリクエストが同じブラウザから発信されているかどうかを識別する必要があります。
セッション追跡スキーム
- クライアントセッション追跡テクノロジー: Cookie
- サーバー側のセッション追跡テクノロジー: セッション
- トークンテクノロジー

セッション追跡ソリューションの比較

解決策 1: Cookie
- 実装のアイデア
  - ブラウザが初めてリクエストを送信してサーバーをリクエストするときに、Cookie を設定し、関連情報を Cookie に保存できます。その後、サーバーは自動的に Cookie に応答します (Set-Cookie: name= valie , Cookie のデータを設定するために使用されます) をブラウザーに設定すると、ブラウザーが Cookie を受信すると、Cookie の値 ( name=value ) がブラウザーのローカルに自動的に保存され、後続のリクエストではローカルに保存されているデータが自動的に保存されます。 Cookie ( Cookie: name=value、Cookie を保持するデータに使用) がサーバーに送信され、サーバー上で Cookie の値が取得され、Cookie 内の値が存在するかどうかを判断できます。
- 特定のコード
- ```
package com.example.tlias.controller;

import com.example.tlias.pojo.Result;
import jakarta.servlet.http.Cookie;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@Slf4j
public class SessionController {
    @GetMapping("/c1")
    // todo 设置Cookie
    public Result cookie1(HttpServletResponse response) {
        response.addCookie(new Cookie("login_name", "hkm"));
        return Result.success();
    }

    @GetMapping("/c2")
    // todo 获取Cookie
    public Result cookie2(HttpServletRequest request) {
        Cookie[] cookies = request.getCookies();
        for (Cookie cookie : cookies) {
            if (cookie.getName().equals("login_name")) {
                System.out.println("login_name:" + cookie.getValue());
            }
        }
        return Result.success();
    }
}
```
- c1にアクセスした結果は以下の通り
- c2にアクセスした結果は以下の通り
  - アドバンテージ
    - Httpプロトコルでサポートされるテクノロジー
  - 欠点がある
    - モバイルアプリではCookieを使用できません
    - 安全ではありません。ユーザーは自分で Cookie を無効にすることができます
    - Cookie をクロスドメインにすることはできません (クロスドメインの区別の 3 つの側面: プロトコル、IP/ドメイン名、ポート)
解決策 2: セッション
- 実装のアイデア
  - セッションはサーバー側のセッション追跡テクノロジーです。セッションはサーバー側に保存され、その最下層は Cookie に基づいて実装されます。ブラウザがサーバーにリクエストを送信すると、サーバー側は自動的に Session セッションオブジェクトを作成します。各 Session セッションオブジェクトには ID があり、これを SessionID と呼びます。サーバーがブラウザに応答するとき、Cookie ( Set-Cookie: JSESSIONID=1 )を通じてセッションオブジェクトの ID を使用してブラウザに応答します。ブラウザは受信した Cookie オブジェクトを自動的にローカルに保存し、その後、リクエストによって Cookie の値がサーバーに送信され、サーバーは Cookie の値を取得した後、現在のリクエストのセッションオブジェクト Session を見つけます (つまり、セッションのID)。
- 特定のコード
  - ```
  package com.example.tlias.controller;
  
  import com.example.tlias.pojo.Result;
  import jakarta.servlet.http.Cookie;
  import jakarta.servlet.http.HttpServletRequest;
  import jakarta.servlet.http.HttpServletResponse;
  import jakarta.servlet.http.HttpSession;
  import lombok.extern.slf4j.Slf4j;
  import org.springframework.web.bind.annotation.GetMapping;
  import org.springframework.web.bind.annotation.RestController;
  
  @RestController
  @Slf4j
  public class SessionController {
  
      // todo 在HttpSession中设置session对象的值
      @GetMapping("/s1")
      public Result Session1(HttpSession session) {
          log.info("HttpSession:{}", session.hashCode());
          session.setAttribute("loginUser-s1","hkm");// 往Session对象中存储
          return Result.success();
      }
  
      @GetMapping("/s2")
      // todo 获取=session对象的值
      public Result Session2(HttpServletRequest request) {
          HttpSession httpSession = request.getSession();
          log.info("HttpSession-s2:{}", httpSession.hashCode());
          Object loginUser = httpSession.getAttribute("loginUser");
          log.info("loginUser:{}", loginUser);
          return Result.success(loginUser);
      }
  
  }
```
- s1 にアクセスした結果は次のようになります。
- s2にアクセスした結果は以下の通り
- アドバンテージ
  - データはサーバー側に保存されるので安全
- 欠点がある
  - サーバークラスター環境ではセッションを直接使用することはできません
  - Cookie の欠点 (セッションの最下層は Cookie に基づいて実装されます)
ソリューション 3: トークンテクノロジー (主流のソリューション)
- 実装のアイデア
  - トークンはユーザーの ID を識別するものです。本質的には文字列です。ブラウザはリクエストを開始します。ログインインターフェイスをリクエストするときに、ログインが成功すると、サーバーはユーザーの法的 ID 証明書であるトークンを生成できます。次へデータに応答するとき、トークンをフロントエンドに直接応答することができ、フロントエンドはトークンを保存し (Cookie または他の記憶領域に保存できます)、後続の各リクエストでトークンが送信されます。サーバーはトークンの有効性を検証します。
- アドバンテージ
  - PCとモバイルをサポート
  - クラスター環境での認証問題を解決する
  - サーバーのストレージ負荷を軽減します
- 欠点がある
  - 自分で実装する必要がある