Flask-Login认证原理与实战：从无状态HTTP到安全会话管理

1. 为什么 Flask 默认不带登录功能？从“无状态”本质讲清楚认证的底层逻辑

Flask 本身被设计成一个极简的 Web 框架——它只负责把 HTTP 请求接进来，再把响应送出去。它不预设你用数据库还是文件存用户，不规定密码该哈希几次，也不管你是用邮箱、手机号还是微信扫码登录。这种“无状态”的哲学，是它轻量、灵活、可插拔的根本原因，但也是新手最容易栽跟头的地方：你写完@app.route('/login')，发现用户一刷新页面，又变回未登录状态了。

这不是 Bug，是设计。HTTP 协议本身是无状态的，每次请求都是独立事件。浏览器不会主动告诉服务器“我刚才已经输过密码了”，服务器也不会记住“张三在 10:03 登录成功”。要让系统“记住”用户身份，必须靠额外的机制来建立和维持这个“会话状态”。而 Flask-Login 正是为解决这个核心矛盾而生的中间件：它不碰密码存储、不处理表单验证、不决定登录页长什么样，而是专注做一件事——在 Flask 的 request-response 生命周期里，可靠地绑定、识别、传递并管理当前用户的会话标识。

这就像给一辆没有导航系统的车加装 GPS 模块：车（Flask）本身的功能没变，但它现在能持续知道“我在哪”（current_user）、“我有没有权限”（is_authenticated）、“我是不是管理员”（is_active）。而这个 GPS 模块（Flask-Login）的安装、校准、信号接收，全都有明确的接口和约定。

所以，当你看到标题里“Menambah Autentikasi”（添加认证）时，首先要理解，这不是在给 Flask “打补丁”，而是在它的骨架上，精准嵌入一个专司身份管理的神经中枢。它不替代你的用户模型，不接管你的密码逻辑，只负责把“已登录的用户对象”稳稳地托付给每一个视图函数。这也是为什么几乎所有成熟的 Flask 项目，哪怕只是内部工具，都会在第二步就集成 Flask-Login——因为绕开它去手写 session 管理，99% 的情况都会在“记住我”、“登出清空”、“多标签页冲突”这些细节上翻车。

提示：很多初学者误以为“只要用了 Flask-Login，登录就自动安全了”。这是巨大误区。Flask-Login 只管“你是谁”，不管“你怎么证明你是谁”。密码校验、防暴力破解、CSRF 防护、HTTPS 强制，这些都得由你自己的登录视图和配置来完成。它是个“身份快递员”，不是“安全守门员”。

2. Flask-Login 的四大核心组件：UserMixin、LoginManager、current_user 与 login_user 的协同关系

Flask-Login 的精妙之处，在于它用极少的几个核心类，就构建出一套完整、解耦的身份管理流水线。理解这四个组件如何咬合工作，比死记硬背 API 更重要。它们不是孤立的工具，而是一条环环相扣的传送带：

2.1 UserMixin：给你的用户模型“注入”登录能力的轻量混入

你肯定有自己的User类，可能继承自 SQLAlchemy 的db.Model，里面存着id,username,password_hash。但 Flask-Login 要求这个类必须提供几个特定方法，比如is_authenticated()、get_id()。你当然可以一个个手动写，但更聪明的做法是直接混入UserMixin。

from flask_login import UserMixin from flask_sqlalchemy import SQLAlchemy db = SQLAlchemy() class User(UserMixin, db.Model): id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(80), unique=True, nullable=False) password_hash = db.Column(db.String(120), nullable=False)

UserMixin已经为你实现了所有必需的默认方法：

• is_authenticated: 总是返回True（已登录用户才调用此方法）
• is_active: 默认True，可用于封禁账号
• is_anonymous: 默认False，区分游客
• get_id(): 返回str(self.id)，这是 Flask-Login 查找用户的唯一钥匙

关键点在于：UserMixin不强制你用 SQLAlchemy，也不要求你必须有password_hash字段。它只关心“你能返回一个稳定、唯一的 ID 字符串”。如果你用的是 MongoDB 或纯内存字典，只要你的User类有get_id()方法，一样能用。

2.2 LoginManager：整个认证系统的“调度中心”

LoginManager是 Flask-Login 的大脑。它不处理具体数据，但掌控全局策略：

• 登录视图名：当未登录用户访问需要认证的页面时，重定向到哪个路由？login_manager.login_view = 'auth.login'
• 登录消息：重定向时附带的提示信息，如login_manager.login_message = 'Silakan masuk untuk mengakses halaman ini.'
• 会话保护级别：login_manager.session_protection = 'strong'会检测用户 IP 和 User-Agent 的剧烈变化，自动登出，防会话劫持
• 匿名用户类：定义未登录时current_user是什么对象，默认是AnonymousUserMixin

初始化它必须在 Flask 应用创建之后、注册蓝图之前：

from flask import Flask from flask_login import LoginManager app = Flask(__name__) app.config['SECRET_KEY'] = 'kunci-rahasia-yang-panjang-dan-acak' login_manager = LoginManager() login_manager.init_app(app) # 关键：必须调用 init_app login_manager.login_view = 'auth.login'

注意：init_app(app)这一步绝不能省略。很多新手把LoginManager()实例化放在app = Flask()之前，或者忘了调用init_app，结果current_user始终是None，查半天才发现是初始化顺序错了。

2.3 current_user：每个请求中“活”的用户代理

这是 Flask-Login 最神奇也最易被误解的变量。它不是一个全局变量，也不是一个函数调用，而是一个LocalProxy对象——一种 Flask 特有的上下文代理。它的值在每个请求开始时被动态计算，在请求结束时自动销毁。

这意味着：

• 在@app.route视图函数里，你可以直接写if current_user.is_authenticated: ...
• 在 Jinja2 模板里，你可以直接写{% if current_user.is_authenticated %}Halo, {{ current_user.username }}{% endif %}
• 但它不能在模块顶层、或app.run()之前使用，因为那时还没有请求上下文

它的底层逻辑是：Flask-Login 在每次请求的before_request钩子中，检查 session 里的_user_id，然后调用你注册的user_loader回调函数，从数据库里把对应的User对象捞出来，赋值给current_user。所以，current_user的“活性”，完全依赖于你是否正确实现了user_loader。

2.4 login_user() 与 logout_user()：会话生命周期的开关

这两个函数是用户登录/登出动作的唯一直接操作接口：

• login_user(user, remember=False, duration=None): 将user对象标记为已登录，并将其get_id()存入 session。remember=True会设置一个长期有效的 cookie（通常 30 天），即使浏览器关闭也不失效。
• logout_user(): 清空 session 中的所有用户相关数据，包括_user_id和remember_token。

它们不负责验证密码，不跳转页面，只做一件事：修改当前请求上下文中的会话状态。因此，一个典型的登录视图是这样的：

from flask import request, redirect, url_for, flash from werkzeug.security import check_password_hash from flask_login import login_user, logout_user @app.route('/login', methods=['GET', 'POST']) def login(): if request.method == 'POST': username = request.form['username'] password = request.form['password'] user = User.query.filter_by(username=username).first() # 关键：密码校验必须由你自己完成！ if user and check_password_hash(user.password_hash, password): login_user(user, remember=request.form.get('remember')) return redirect(url_for('dashboard')) else: flash('Username atau password salah.') return render_template('login.html')

这里check_password_hash是 Werkzeug 提供的安全哈希校验，它和generate_password_hash是一对，必须配套使用。Flask-Login 从不接触明文密码，这是你作为开发者不可推卸的责任。

3. 从零搭建一个可运行的登录系统：包含用户注册、登录、登出与权限保护的完整闭环

光讲原理不够，我们来动手搭一个最小但完整的闭环。这个例子将覆盖生产环境 90% 的基础需求，所有代码均可直接复制运行（需安装flask,flask-sqlalchemy,flask-login,werkzeug）。

3.1 初始化应用与数据库模型

首先，创建app.py：

from flask import Flask, render_template, request, redirect, url_for, flash, abort from flask_sqlalchemy import SQLAlchemy from flask_login import LoginManager, UserMixin, login_user, logout_user, login_required, current_user from werkzeug.security import generate_password_hash, check_password_hash import os # 创建应用 app = Flask(__name__) app.config['SECRET_KEY'] = os.environ.get('SECRET_KEY', 'dev-key-untuk-pengembangan') # SQLite 数据库路径 app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///site.db' app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False # 初始化扩展 db = SQLAlchemy(app) # 初始化 LoginManager login_manager = LoginManager() login_manager.init_app(app) login_manager.login_view = 'login' # 未登录时重定向的目标视图 login_manager.login_message = 'Silakan masuk untuk mengakses halaman ini.' # 定义 User 模型 class User(UserMixin, db.Model): id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(80), unique=True, nullable=False) email = db.Column(db.String(120), unique=True, nullable=False) password_hash = db.Column(db.String(120), nullable=False) def set_password(self, password): """安全地设置密码哈希""" self.password_hash = generate_password_hash(password) def check_password(self, password): """校验密码""" return check_password_hash(self.password_hash, password) # 必须注册的 user_loader 回调 @login_manager.user_loader def load_user(user_id): """根据 user_id 从数据库加载用户对象""" return User.query.get(int(user_id))

这段代码的关键点：

• set_password和check_password是封装好的便捷方法，避免在视图里重复写generate_password_hash。
• @login_manager.user_loader是 Flask-Login 的“钩子”，它告诉框架：“当你要找用户时，请调用这个函数”。这个函数必须存在，且参数名必须是user_id，返回值必须是User对象或None。
• os.environ.get('SECRET_KEY', 'dev-key...')是最佳实践：开发时用固定密钥，生产时从环境变量读取，避免密钥硬编码。

3.2 实现注册、登录、登出视图

继续在app.py中添加：

@app.route('/') def index(): return render_template('index.html') @app.route('/register', methods=['GET', 'POST']) def register(): if current_user.is_authenticated: return redirect(url_for('dashboard')) if request.method == 'POST': username = request.form['username'] email = request.form['email'] password = request.form['password'] # 简单检查 if User.query.filter_by(username=username).first(): flash('Username sudah digunakan.') return redirect(url_for('register')) if User.query.filter_by(email=email).first(): flash('Email sudah terdaftar.') return redirect(url_for('register')) # 创建新用户 user = User(username=username, email=email) user.set_password(password) db.session.add(user) db.session.commit() flash('Pendaftaran berhasil! Silakan masuk.') return redirect(url_for('login')) return render_template('register.html') @app.route('/login', methods=['GET', 'POST']) def login(): if current_user.is_authenticated: return redirect(url_for('dashboard')) if request.method == 'POST': username = request.form['username'] password = request.form['password'] user = User.query.filter_by(username=username).first() if user and user.check_password(password): login_user(user, remember=request.form.get('remember')) next_page = request.args.get('next') return redirect(next_page) if next_page else redirect(url_for('dashboard')) else: flash('Username atau password salah.') return render_template('login.html') @app.route('/logout') def logout(): logout_user() flash('Anda telah keluar.') return redirect(url_for('index')) @app.route('/dashboard') @login_required # 这个装饰器是关键！ def dashboard(): return render_template('dashboard.html', username=current_user.username)

这里有几个实战中极易忽略的细节：

• 注册页的登录态拦截：if current_user.is_authenticated:防止已登录用户重复注册，提升体验。
• request.args.get('next')：这是 Flask-Login 的“回跳”机制。当未登录用户访问/dashboard时，会被重定向到/login?next=%2Fdashboard，登录成功后，next_page就能捕获这个参数，实现“登录后回到刚才想看的页面”，而不是千篇一律跳回首页。
• @login_required装饰器：这是保护路由的最简单方式。它会在视图函数执行前检查current_user.is_authenticated，为False则触发重定向。你也可以在函数内部手动检查，但装饰器更清晰、更不易遗漏。

3.3 创建基础模板

创建templates/base.html（所有页面的父模板）：

<!DOCTYPE html> <html> <head> <title>Flask-Login Demo</title> <meta charset="utf-8"> </head> <body> <nav> <a href="{{ url_for('index') }}">Beranda</a> {% if current_user.is_authenticated %} <a href="{{ url_for('dashboard') }}">Dashboard</a> <a href="{{ url_for('logout') }}">Keluar</a> {% else %} <a href="{{ url_for('login') }}">Masuk</a> <a href="{{ url_for('register') }}">Daftar</a> {% endif %} </nav> <main> {% with messages = get_flashed_messages() %} {% if messages %} {% for message in messages %} <div class="flash">{{ message }}</div> {% endfor %} {% endif %} {% endwith %} {% block content %}{% endblock %} </main> </body> </html>

templates/login.html：

{% extends "base.html" %} {% block content %} <h2>Masuk ke Akun Anda</h2> <form method="POST"> <p><input type="text" name="username" placeholder="Username" required></p> <p><input type="password" name="password" placeholder="Password" required></p> <p><label><input type="checkbox" name="remember"> Ingat saya</label></p> <p><input type="submit" value="Masuk"></p> </form> {% endblock %}

templates/register.html：

{% extends "base.html" %} {% block content %} <h2>Daftar Akun Baru</h2> <form method="POST"> <p><input type="text" name="username" placeholder="Username" required></p> <p><input type="email" name="email" placeholder="Email" required></p> <p><input type="password" name="password" placeholder="Password" required></p> <p><input type="submit" value="Daftar"></p> </form> {% endblock %}

templates/dashboard.html：

{% extends "base.html" %} {% block content %} <h2>Selamat datang, {{ username }}!</h2> <p>Ini adalah halaman dashboard pribadi Anda.</p> <a href="{{ url_for('logout') }}">Keluar dari akun ini</a> {% endblock %}

3.4 初始化数据库并运行

最后，在app.py底部添加：

# 创建数据库表（仅首次运行） @app.before_first_request def create_tables(): db.create_all() if __name__ == '__main__': app.run(debug=True)

运行python app.py，访问http://127.0.0.1:5000/register，注册一个用户，然后登录。你会发现：

• 导航栏自动切换为“Dashboard”和“Keluar”；
• 访问/dashboard时，如果未登录，会自动跳转到/login?next=%2Fdashboard；
• 勾选“Ingat saya”后关闭浏览器再打开，依然保持登录状态；
• current_user.username在模板和视图中都能正确显示。

这个闭环之所以“可运行”，是因为它严格遵循了 Flask-Login 的契约：UserMixin提供了标准接口，user_loader提供了数据源，login_user启动了会话，@login_required施加了保护。任何一个环节缺失，整个链条就会断裂。

4. 生产环境必做的五项加固：从 Cookie 安全到会话过期的深度配置

一个能跑通的 demo 和一个能上线的系统，中间隔着五道防火墙。Flask-Login 提供了丰富的配置项，但默认值往往只为开发便利，而非生产安全。以下是我在多个项目中踩坑后总结的五项强制加固措施，每一条都对应一个真实的风险场景。

4.1 强制 HTTPS 与 Secure Cookie：防止会话 ID 在传输中被窃听

在开发环境，HTTP 是常态。但在生产环境，任何未加密的登录请求，都等于把用户名密码明文广播给网络上的所有人。Flask-Login 通过SESSION_COOKIE_SECURE配置项，确保其生成的 session cookie 只能通过 HTTPS 传输。

# 生产配置 app.config['SESSION_COOKIE_SECURE'] = True # 仅 HTTPS 有效 app.config['SESSION_COOKIE_HTTPONLY'] = True # 禁止 JavaScript 访问，防 XSS 窃取 app.config['SESSION_COOKIE_SAMESITE'] = 'Lax' # 防 CSRF，限制跨站请求携带 cookie

SESSION_COOKIE_HTTPONLY = True是关键。它让浏览器禁止 JavaScript 通过document.cookie读取这个 cookie。即使你的网站有 XSS 漏洞，攻击者也无法用<script>fetch('/steal?cookie='+document.cookie)</script>直接盗走会话 ID。会话 ID 只能由浏览器在发请求时自动附加，这是纵深防御的第一道屏障。

4.2 自定义user_loader的健壮性：处理用户被删除或禁用的边界情况

@login_manager.user_loader回调函数看似简单，但它是整个认证链的“信任锚点”。如果它返回None，current_user就是AnonymousUserMixin，用户被当作未登录处理。但如果它抛出异常（比如数据库连接失败），整个请求就会 500 错误。

一个健壮的user_loader必须：

• 使用try...except包裹数据库查询；
• 明确返回None而非让异常冒泡；
• （可选）加入缓存层，避免高频查询。

from functools import wraps from flask_login import current_user @login_manager.user_loader def load_user(user_id): try: # 这里可以加 Redis 缓存：cache.get(f"user:{user_id}") user = User.query.get(int(user_id)) # 额外检查：用户是否被禁用？ if user and not user.is_active: return None return user except (ValueError, TypeError): # user_id 不是合法整数 return None except Exception as e: # 记录日志，但绝不让异常传播 app.logger.error(f"Failed to load user {user_id}: {e}") return None

4.3 精确控制会话有效期：REMEMBER_COOKIE_DURATION与PERMANENT_SESSION_LIFETIME

Flask 有两个层面的会话时效控制，新手常混淆：

• REMEMBER_COOKIE_DURATION: 控制“记住我”功能的 cookie 有效期（单位：秒）。默认是 31 天（timedelta(days=31)）。
• PERMANENT_SESSION_LIFETIME: 控制普通 session 的有效期（单位：秒）。默认是 31 天，但如果你调用session.permanent = True，它才会生效。

在生产环境，你应该显式设置它们：

from datetime import timedelta # “记住我” cookie 有效期设为 7 天，更安全 app.config['REMEMBER_COOKIE_DURATION'] = timedelta(days=7) # 普通 session（不勾选“记住我”）有效期设为 30 分钟 app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(minutes=30)

这样，用户不勾选“Ingat saya”时，关闭浏览器或 30 分钟无操作后，会话自动过期；勾选后，cookie 有效期为 7 天，但用户仍需在 7 天内至少活跃一次，否则服务端 session 也会因PERMANENT_SESSION_LIFETIME过期而失效。这是一种“双保险”策略。

4.4 防暴力破解：在登录视图中集成flask-limiter

Flask-Login 本身不提供限流。但一个开放的/login接口，是暴力破解的黄金靶子。你需要在登录视图上加一层速率限制。

pip install flask-limiter

from flask_limiter import Limiter from flask_limiter.util import get_remote_address limiter = Limiter( app, key_func=get_remote_address, default_limits=["200 per day", "50 per hour"] ) @app.route('/login', methods=['GET', 'POST']) @limiter.limit("5 per minute") # 对登录接口单独限流：每分钟最多 5 次 def login(): # ... 原有逻辑

这个配置意味着，同一个 IP 地址，每分钟最多尝试 5 次登录。超过后，flask-limiter会直接返回429 Too Many Requests，根本不会进入你的密码校验逻辑，极大减轻数据库压力，并让暴力破解变得不现实。

4.5 登出时的彻底清理：logout_user()的隐含行为与手动清理

logout_user()函数会做三件事：

1. 从 session 中移除_user_id；
2. 如果存在remember_token，将其从 session 中移除；
3. （如果启用了session_protection）重置 session ID。

但有一个常见陷阱：它不会删除你应用中自己写入 session 的其他数据。比如，你可能在登录后把用户角色存进session['role']，或者把临时 token 存进session['temp_token']。logout_user()不会碰这些。

因此，一个负责任的登出流程应该是：

@app.route('/logout') def logout(): # 1. 手动清理所有自定义 session 数据 session.pop('role', None) session.pop('temp_token', None) session.pop('preferences', None) # 2. 调用 Flask-Login 的登出 logout_user() # 3. （可选）强制销毁整个 session # session.clear() flash('Anda telah keluar.') return redirect(url_for('index'))

session.clear()是终极手段，它会删除 session 中的所有键值对，包括 Flask-Login 内部使用的_fresh和_id。在绝大多数情况下，logout_user()已足够，但如果你的应用对 session 数据的洁净度要求极高（比如金融类系统），session.clear()是更稳妥的选择。

5. 常见故障排查链路：从current_user为None到login_user不生效的完整诊断手册

在实际开发中，current_user始终是None，或者login_user()调用后页面刷新又变回未登录，是最让人抓狂的问题。它不像语法错误那样有明确报错，而是一种“静默失败”。下面是我整理的一套标准化排查链路，按顺序执行，99% 的问题都能定位。

5.1 第一步：确认LoginManager是否已正确初始化

这是最基础也最容易被忽略的一步。打开 Python shell，导入你的app和login_manager：

>>> from app import app, login_manager >>> app.config.get('SECRET_KEY') 'dev-key-untuk-pengembangan' >>> login_manager._login_disabled False >>> login_manager.login_view 'login'

如果login_manager._login_disabled是True，说明init_app(app)没有被调用。检查你的初始化代码顺序，确保login_manager.init_app(app)在app = Flask(...)之后，且在任何视图注册之前。

5.2 第二步：检查user_loader回调是否被触发及返回值

在user_loader函数里加一行日志：

@login_manager.user_loader def load_user(user_id): app.logger.info(f"[DEBUG] user_loader called with user_id: {user_id}") user = User.query.get(int(user_id)) app.logger.info(f"[DEBUG] user_loader returned: {user}") return user

然后启动应用，访问一个需要登录的页面（如/dashboard），查看终端日志。你应该看到两行[DEBUG]日志。如果没有第一行，说明user_loader根本没被调用，问题出在LoginManager初始化或current_user的使用时机上。如果没有第二行，说明user_loader抛出了异常，被静默吞掉了，需要检查数据库查询逻辑。

5.3 第三步：验证 session 中是否真的存入了_user_id

login_user(user)的核心动作，就是把user.get_id()的字符串值，存入session['_user_id']。我们可以直接在视图里打印 session 来验证：

@app.route('/debug-session') def debug_session(): return str(dict(session))

在登录后访问/debug-session，你应该看到类似{'_user_id': '1', '_fresh': True}的输出。如果_user_id缺失，说明login_user()没有成功执行。检查你的登录视图，确认login_user()调用前没有return或abort，并且user对象是有效的（user.id不为None）。

5.4 第四步：检查current_user的上下文与使用位置

current_user只能在请求上下文中使用。以下代码是错误的：

# ❌ 错误：在模块顶层使用 print(current_user.username) # RuntimeError: Working outside of application context. # ❌ 错误：在后台线程中使用 def background_task(): print(current_user.username) # 同样会报错

正确的做法是，确保它只在@app.route视图函数、@bp.route蓝图视图、或 Jinja2 模板中使用。如果你需要在后台任务中获取用户信息，应该在任务启动时，把user.id作为参数传进去，然后在任务内部重新查询数据库。

5.5 第五步：分析@login_required的重定向行为

当@login_required生效时，它会重定向到login_manager.login_view。如果重定向后，你发现 URL 是/login?next=%2Fdashboard，但登录表单提交后，却跳转到了首页，而不是/dashboard，问题很可能出在登录视图的next_page处理上。

检查你的登录视图，确认是否有：

next_page = request.args.get('next') if not next_page or url_parse(next_page).netloc != '': next_page = url_for('index') return redirect(next_page)

url_parse(next_page).netloc != ''这一行至关重要。它防止了开放重定向漏洞（Open Redirect），即攻击者构造?next=https://evil.com来诱导用户跳转到恶意网站。如果next_page是一个外部 URL，它会被安全地重置为首页。但这也意味着，如果你的next_page解析后netloc不为空（比如//example.com/dashboard），它也会被重置。确保你的next_page是一个绝对路径（以/开头）。

这张表格总结了上述排查步骤的典型现象与对应原因：

这套链路的价值在于，它不依赖于猜测，而是提供了一条可执行、可验证的路径。每一次检查，你都能得到一个明确的“是”或“否”的答案，从而将模糊的“不工作”问题，转化为具体的、可修复的技术点。

6. 进阶场景：如何将 Flask-Login 与 OAuth2（如 Google 登录）无缝集成

Flask-Login 的设计哲学是“专注核心，解耦外围”，这使得它与 OAuth2 这类第三方认证协议的集成变得异常优雅。你不需要抛弃 Flask-Login，也不需要重写整个认证流程，只需在“用户来源”这个环节做一点适配。核心思想是：OAuth2 负责“我是谁”，Flask-Login 负责“记住我”。

以 Google OAuth2 为例，整个流程分为三步：授权码获取、令牌交换、用户信息拉取。而 Flask-Login 的介入点，就在最后一步——当从 Google API 拿到用户邮箱和 ID 后，你需要决定：这是一个新用户，还是一个老用户？无论哪种，最终都要得到一个User对象，然后调用login_user(user)。

6.1 使用Authlib简化 OAuth2 流程

flask-login本身不处理 OAuth，所以我们引入Authlib，一个现代、安全的 OAuth 客户端库。

pip install authlib

from authlib.integrations.flask_client import OAuth from flask import session, request, redirect, url_for, jsonify oauth = OAuth(app) google = oauth.register( name='google', client_id=app.config['GOOGLE_CLIENT_ID'], client_secret=app.config['GOOGLE_CLIENT_SECRET'], access_token_url='https://accounts.google.com/o/oauth2/token', access_token_params=None, authorize_url='https://accounts.google.com/o/oauth2/auth', authorize_params=None, api_base_url='https://www.googleapis.com/oauth2/v1/', client_kwargs={'scope': 'openid email profile'}, )

6.2 实现 Google 登录回调：创建或查找用户

@app.route('/login/google') def login_google(): redirect_uri = url_for('authorize_google', _external=True) return google.authorize_redirect(redirect_uri) @app.route('/authorize/google') def authorize_google(): token = google.authorize_access_token() # 从 Google 获取用户信息 user_info = google.parse_id_token(token) # user_info 包含 'email', 'sub' (Google 用户唯一ID), 'name' 等 email = user_info['email'] google_id = user_info['sub'] # 尝试查找已有用户（按 email） user = User.query.filter_by(email=email).first() if not user: # 新用户：创建一个本地用户，用 Google ID 作为 username，email 作为 email user = User( username=f"google_{google_id}", email=email, # 密码字段留空，因为我们不管理其密码 password_hash='' ) db.session.add(user) db.session.commit() # 关键：无论新老用户，都用 login_user 登录 login_user(user, remember=True) return redirect(url_for('dashboard'))

这里的关键设计决策：

• 主键选择：我们用email作为查找依据，因为它是用户最稳定的标识。Google 的sub是全局唯一，但不同平台的sub不同，不适合作为主键。
• 密码字段：新用户创建时，password_hash设为空字符串。这没问题，因为UserMixin的check_password方法在密码为空时会返回False，而我们的登录流程根本不调用它。User模型的职责是“代表一个用户”，而不是“必须有密码”。
• remember=True：第三方登录的用户，通常希望长期保持登录状态，所以默认开启“记住我”。

6.3 统一的用户模型：支持多种登录方式

为了支持“邮箱密码登录”和“Google 登录”共存，你的User模型需要一点小改造：

class User(UserMixin, db.Model): id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(80), unique=True, nullable=False) email = db.Column(db.String(120), unique=True, nullable=False