登录认证：登录功能与会话技术

登录功能

登录成功的条件是用户名和密码都正确。后端实现上，登录本质仍然是一次数据库查询：

select * from emp where username = ? and password = ?;

登录接口：

POST /login
Content-Type: application/json

请求体：

{
  "username": "jinyong",
  "password": "123456"
}

登录成功后，服务端返回员工信息以及后续认证需要使用的令牌。

{
  "code": 1,
  "msg": "success",
  "data": {
    "id": 2,
    "username": "songjiang",
    "name": "宋江",
    "token": "..."
  }
}

三层架构中的登录流程

浏览器
  ↓ POST /login
Controller
  ↓
Service
  ↓
Mapper
  ↓
MySQL

• Controller：接收用户名和密码，调用 Service，响应登录结果。
• Service：根据用户名和密码查询员工，判断是否登录成功并组装返回数据。
• Mapper：执行 SQL 查询员工信息。

为什么只做登录接口还不够

如果没有统一登录校验，用户即使没有登录，也可以直接请求：

/depts
/emps
/report

完整认证需要两个步骤：

登录成功
   ↓
生成登录标记
   ↓
后续请求携带登录标记
   ↓
服务端统一拦截并校验

会话与会话跟踪

用户打开浏览器访问 Web 服务器时，会话开始建立。一次会话中可以包含多次请求和响应。

HTTP 本身是无状态的，因此服务器需要一种机制识别多次请求是否来自同一个客户端，这就是会话跟踪。

课程介绍了三种方案：

Cookie
Session
令牌

Cookie

Cookie 属于客户端会话跟踪技术。

服务器通过响应头：

Set-Cookie: name=value

让浏览器保存数据。后续浏览器通过请求头：

Cookie: name=value

重新把 Cookie 发给服务器。

优点：HTTP 协议原生支持。

课程中列出的主要缺点：

• 移动端 APP 无法直接使用浏览器 Cookie 机制。
• 用户可以禁用 Cookie。
• Cookie 数据保存在客户端。
• Cookie 存在跨域限制。

跨域通常从协议、IP/域名、端口三个维度判断。

Session

Session 属于服务端会话跟踪技术，状态数据保存在服务器。

浏览器通常通过 JSESSIONID 与服务器中的 Session 建立关联：

服务器创建 Session(1)
      ↓
Set-Cookie: JSESSIONID=1
      ↓
浏览器保存
      ↓
Cookie: JSESSIONID=1
      ↓
服务器找到 Session(1)

因此 Session 的底层仍然依赖 Cookie 来传递 Session ID。

优点：数据主要存储在服务端。

课程中强调的问题：

• 仍然受 Cookie 限制。
• 服务器集群环境下，Session 无法天然共享。

令牌

令牌方案的基本流程：

登录成功
   ↓
服务器生成Token
   ↓
返回给客户端
   ↓
客户端保存Token
   ↓
后续请求携带Token
   ↓
服务器校验Token

课程给出的优势：

• 支持 PC 端和移动端。
• 能解决集群环境中的认证问题。
• 减轻服务端保存会话状态的压力。

缺点是令牌的生成、携带和校验需要应用自己实现。

三种方案对比

Tlias 后续采用 JWT 作为具体的令牌技术。