Academic Suite 身份验证与授权

I’m happy to help translate the article, but I need the text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article text, I’ll translate it into Simplified Chinese while preserving all formatting, code blocks, URLs, and technical terms.

3.1 Academic Suite 的认证方式

Academic Suite 使用 无状态认证 方法，基于 JSON Web Token (JWT)。

不同于 基于会话的认证（将登录状态存储在服务器内存或 Redis 中），JWT 将用户信息直接存放在令牌里，客户端在每个请求中携带该令牌。

之所以选择这种方式，是因为它适用于具有以下特征的在线考试系统：

• 请求量大
• 同时活跃用户众多
• 需要水平扩展

3.2 为什么使用 JWT（JSON Web Token）？

JWT 为在线考试系统提供了若干重要优势：

可伸缩性 – 令牌验证不需要在每个请求上进行数据库查询。服务器只需校验令牌签名，即使成千上万的学生同时在线，也能保持数据库负载受控。

无状态 – 服务器无需存储会话状态，使得应用更容易水平扩展。

移动端友好 – JWT 同样适用于 Web 和移动客户端，为未来的客户端开发提供了更多可能。

这种做法也与 Academic Suite 所采用的前后端分离架构保持一致。

3.3 身份验证流程

登录过程在后端实现，具体位于文件 backend/handlers/auth.go 中。

大致流程如下：

1. 请求 – 客户端以 JSON 格式发送凭证：{ "email": "...", "password": "..." }。
2. 用户查找 – 服务器在数据库中根据邮箱搜索用户。
3. 密码验证 – 将提供的密码与存储的哈希值进行比对。
4. 令牌生成 – 若凭证有效，服务器生成包含用户信息（claims）的 JWT，并将其返回给客户端。

随后，客户端在每个后续请求的 Authorization: Bearer <token> 头部中携带该令牌。

使用 Bcrypt 的密码安全

Academic Suite 从不以明文形式存储密码。在密码哈希方面，bcrypt 使用相对较高的成本。

// During registration or data seeding
hashed, _ := bcrypt.GenerateFromPassword([]byte("password123"), 14)

// During login
err := bcrypt.CompareHashAndPassword(
    []byte(user.Password),
    []byte(inputPassword),
)

使用 bcrypt 可以确保即使数据库泄露，原始密码仍然难以被还原。

3.4 JWT 的结构与 Claims

系统生成的 JWT 在 claims 部分包含重要数据。

claims := jwt.MapClaims{
    "userId": user.ID,
    "role":   user.Role, // admin, teacher, student
    "exp":    time.Now().Add(time.Hour * 1).Unix(),
}

令牌中存储的信息包括

• userId – 用户标识
• role – 授权需求
• exp – 令牌有效时间限制

通过在令牌中嵌入 role，系统可以在不每次查询 users 表的情况下检查访问权限。

3.5 认证中间件

为了保护 API 端点，Academic Suite 使用 认证中间件。该中间件：

1. 获取 Authorization: Bearer <token> 头部。
2. 使用密钥验证 JWT 签名。
3. 从声明中提取 userId 和 role。
4. 将这些数据存入请求上下文，以供下游处理程序使用。

示例代码片段

c.Locals("userId", claims["userId"])
c.Locals("role", claims["role"])

return c.Next()

链中后续的处理程序可以直接访问 userId 和 role，无需重新实现认证逻辑。

3.6 基于角色的访问控制 (RBAC)

身份验证告诉我们用户是谁；授权决定用户可以做什么。

Academic Suite 实现了 RBAC，包含三种主要角色：

• admin
• teacher
• student

例如，只有 teacher 和 admin 被允许创建或管理测验。

处理器中的角色检查模式

func CreateQuiz(c *fiber.Ctx) error {
    role := c.Locals("role").(string)

    if role != "teacher" && role != "admin" {
        return c.Status(403).JSON(fiber.Map{
            "error": "Forbidden",
        })
    }

    // Quiz creation logic …
}

这种简单的模式对于角色数量有限且定义明确的系统非常有效。

3.7 生产环境安全注意事项

在部署到生产环境之前，请考虑以下事项：

• jwtSecret 不得在源代码中硬编码。
• 将密钥存放在环境变量中（例如 JWT_SECRET）。
• 根据安全需求设置令牌有效期（exp）。
• 如需更长会话时间，请实现 令牌刷新 机制。

这些步骤对于防止令牌滥用和维护整体系统安全至关重要。

章节概述

在本章节中，我们通过以下方式构建了 Academic Suite 安全的基础：

• 基于 JWT 的 身份验证 系统（无状态、可扩展、移动端友好）。
• 基于 角色的授权 机制（RBAC），利用存储在令牌中的声明。

有了稳固的身份验证和授权，系统能够安全地支持前几章中描述的考试功能。

Nature can only be accessed by authorized users.

In **Chapter 4**, we will begin to enter the functional core of the LMS: **quiz management and question bank**, which serves as the basis for the entire online exam process.