★ FEATURED ARTICLE 简介一套在Dash应用中集成Flask-Login的示例工程面向需要为Plotly Dash仪表盘添加用户认证能力的Python开发者解决Dash默认不提供登录与会话管理的问题。工程以SQLite3作为默认认证数据库同时允许在配置文件中修改数据库连接串以对接自有数据库登录、登出、成功后跳转等页面逻辑均已分层实现结构清晰且易于复用。资源压缩包共23个文件整体约16KB包含9个Python脚本、3个CSS样式文件、配置文件、依赖清单、用户管理脚本以及一个用于辅助增删用户的Jupyter笔记本。Python脚本覆盖登录认证、登出处理、应用入口与服务部署入口CSS与静态资源可快速套用到仪表盘界面配置文件则方便调整数据库及初始化参数。截至目前已有929人学习或下载。该示例内置测试账号可先登录验证完整流程再依据笔记本或用户管理模块扩展真实用户同时将应用初始化、视图逻辑与静态文件分离能帮助开发者更快理解Flask-Login在Dash应用中的挂载方式减少自行摸索的排错成本适合作为生产项目二次开发的基础模板。1. Dash 上做登录为什么优先选 Flask-login 而不是自己造轮子某公司的内部运营看板用 Dash 写了两个月上线时才发现一个尴尬问题谁拿到 URL 谁就能看数据连登录页都没有。这不是少数人的处境Dash 官方默认不带账号体系做内部工具的人迟早要亲手补上「登录」这一环。我推荐的做法不是去写一套 Session 工具也不是把页面拆出来单独做前端鉴权而是直接在 Dash 之上接 Flask-login。因为 Dash 应用本质上就是一个 Flask 应用Flask 生态里成熟的登录会话方案可以直接落在它的 server 上。这篇文章按「最小跑通 → 架构选择 → 多页面流转 → 避坑 → 进阶」的顺序把这条路完整走一遍适合正在用 Dash 做内部系统、又不想为登录额外引入重框架的开发者。2. 最小登录闭环server 绑定、user_loader 与回调内的 login_user2.1 从 server 属性拿到 Flask 实例LoginManager 才能绑对地方很多人第一次接触 Dash 会以为它是一个独立 Web 框架实际上 Dash 只是在 Flask 之上包了一层Flask 负责路由和请求Dash 负责把组件树序列化成 JSON 交给前端 React 渲染。所以dash_app.server就是一个标准的 Flask 实例Flask-login 需要app才能初始化这个app必须是dash_app.server不能自己 new 一个Flask(__name__)。如果绑错了实例会出现非常隐蔽的翻车现场登录回调执行了login_user()也调用了但 session 写到了另一个 Flask 应用的上下文里浏览器拿不到正确的 Cookie页面永远停在登录态。这也是我在第 5 章避坑部分会展开的第一个高频问题。绑定正确之后还要实现user_loader。Flask-login 不关心你的用户存在数据库还是内存里它只在你每次请求进来时调用user_loader(user_id)根据 session 里存的用户 ID 加载用户对象。这个回调返回的对象必须实现几个属性is_authenticated、is_active、is_anonymous、get_id()。最简单的方式是继承UserMixin它已经把这些都实现了。2.2 单文件跑通登录闭环login_user 在 Dash 回调里是合法的下面这个最小 demo 不需要多页面不需要额外数据库复制到一个app.py就能跑。它把登录表单直接做成 Dash 布局在回调里调用login_user()登录成功后通过dcc.Location跳转到受保护的路径。# app.py from dash import Dash, html, dcc, Input, Output, State, callback, no_update from flask import Flask from flask_login import LoginManager, UserMixin, login_user, logout_user, current_user from werkzeug.security import generate_password_hash, check_password_hash server Flask(__name__) # 生产环境务必从环境变量读不要写死在代码里 server.config.update(SECRET_KEYdev-secret-change-me) dash_app Dash(__name__, serverserver) login_manager LoginManager(server) # 示例用户表生产环境换成数据库查询即可 FAKE_USERS { alice: { id: 1, name: Alice, role: admin, password_hash: generate_password_hash(alice123), } } class User(UserMixin): def __init__(self, data): self.id data[id] self.name data[name] self.role data[role] login_manager.user_loader def load_user(user_id): for data in FAKE_USERS.values(): if data[id] user_id: return User(data) return None dash_app.layout html.Div([ dcc.Location(idloc), html.Div(idpage-content), ]) def login_form(): return html.Div([ html.H2(登录), dcc.Input(idusername, typetext, placeholder用户名), dcc.Input(idpassword, typepassword, placeholder密码), html.Button(登录, idlogin-btn), html.Div(idlogin-msg), ]) callback(Output(page-content, children), Input(loc, pathname)) def render_page(pathname): if not current_user.is_authenticated: return login_form() if pathname /dashboard: return html.Div([ html.H2(f欢迎{current_user.name}), html.Button(退出, idlogout-btn), ]) return html.Div([ html.H2(首页), html.A(进入看板, href/dashboard), ]) callback( Output(loc, pathname, allow_duplicateTrue), Output(login-msg, children), Input(login-btn, n_clicks), State(username, value), State(password, value), prevent_initial_callTrue, ) def do_login(n_clicks, username, password): user_data FAKE_USERS.get(username) if user_data and check_password_hash(user_data[password_hash], password): login_user(User(user_data)) return /dashboard, return no_update, 用户名或密码错误 callback( Output(loc, pathname, allow_duplicateTrue), Input(logout-btn, n_clicks), prevent_initial_callTrue, ) def do_logout(n_clicks): logout_user() return / if __name__ __main__: dash_app.run(debugTrue)这段代码的核心逻辑有三步。第一步render_page回调每次路径变化都会执行它先检查current_user.is_authenticated未登录就渲染登录表单已登录才渲染业务页面。第二步点击登录按钮后do_login在回调里校验密码并调用login_user这一步会把用户 ID 写进 Flask 的 session响应返回时浏览器自动种下 Cookie。第三步登录成功后把loc.pathname改成/dashboard路径变化触发render_page重新执行此时current_user已经认证页面自然切到看板。有两个参数需要说明。allow_duplicateTrue是因为登录和退出两个回调都输出同一个loc.pathnameDash 默认禁止同一个 Output 被多个回调声明这个参数显式声明允许重复输出。prevent_initial_callTrue是为了防止页面刚加载时按钮回调被自动触发一次否则n_clicks从None变成0也会进入回调。还有一个容易误判的点本地开发开着debugTrue每次改代码热重载都会重启进程session 存在内存里也会丢失表现为「改一行代码就要重新登录」。这不是代码问题是调试模式的正常现象别在这一步浪费排查时间。3. 全站拦截还是回调内判断两种登录保护架构与取舍3.1 全站守护before_request 白名单如果整个应用不允许匿名访问最常见做法是给 Flask 实例挂一个before_request钩子。这个钩子会在每个请求进入视图函数之前执行未登录直接重定向到登录页。from urllib.parse import quote PUBLIC_PATHS {/login} server.before_request def require_login(): # Dash 内部端点必须放行否则页面根本加载不出来 if request.path.startswith(/_dash) or request.path.startswith(/assets): return None if request.path in PUBLIC_PATHS: return None if not current_user.is_authenticated: return redirect(/login?next quote(request.path)) return None这段代码里最关键的是第一行判断。Dash 页面能正常渲染依赖/_dash-layout、/_dash-dependencies、/_dash-update-component这些内部端点如果 before_request 一视同仁全部拦截登录页也会跟着白屏。常见的做法是放行所有以/_dash开头的路径和静态资源路径再单独维护一个公开页面的白名单。登录页用 Flask 自己的路由渲染也没问题此时login_view可以直接指向这个路由server.route(/login, methods[GET, POST]) def login_page(): if request.method POST: # 校验用户名密码成功后 login_user() return redirect(/) return form methodpost input nameusername / input namepassword typepassword / button typesubmit登录/button /form 这种方案的优点是逻辑集中登录校验、session 管理全部收敛在 Flask 层Dash 页面不需要关心自己是怎么被保护起来的。缺点是粒度粗只要路径不在白名单里一律不让看无法表达「首页所有人可见、看板页必须登录」这类混合需求。3.2 细粒度守护在 Dash 回调内检查 current_user有些应用只有少数页面需要登录或者某个回调返回的数据敏感此时更适合在回调内部判断。做法是写一个装饰器包装 Dash 回调函数from functools import wraps from flask_login import current_user def login_required_callback(fn): wraps(fn) def wrapper(*args, **kwargs): if not current_user.is_authenticated: return html.Div(请先登录后查看) return fn(*args, **kwargs) return wrapper callback( Output(data-content, children), Input(load-btn, n_clicks), prevent_initial_callTrue, ) login_required_callback def load_sensitive_data(n_clicks): # 这里可以安全地查数据库、读内网接口 return html.Pre(敏感数据)装饰器放在callback下面执行顺序是 Dash 触发回调后先进入wrapper检查未登录就直接返回提示组件不再执行真正的业务逻辑。注意包装函数用*args, **kwargs接收参数这样不管回调声明了几个 Input 和 State 都能透传。这种方式的优势是精准匿名用户可以访问公开页面也可以触发公开回调但碰敏感数据时会被挡在门外。缺点是每个敏感回调都要手动加装饰器很容易漏。我的习惯是「全站拦截保底 回调内判断做精细化」。3.3 两种方案怎么选用一张表总结两者的适用场景维度before_request 全站拦截回调内判断适用场景整站不允许匿名访问混合权限部分页面公开拦截时机请求进入 Flask 路由层Dash 回调执行时静态资源需要白名单放行不受影响维护成本低一处配置每个敏感回调都要处理误放行风险白名单写错会漏装饰器漏加会漏我的建议是二选一而不是叠加使用。两个都上会带来调试困扰before_request 把未登录用户挡在页面外回调内检查通常永远等不到执行你很难判断到底是哪一层在起作用。先想清楚需求边界再决定用哪一套。4. 多页面 Dash 应用的登录态流转next 回跳与角色页4.1 多页面布局怎么接 before_request真实项目很少是单页应用一般会用use_pagesTrue把页面拆到pages/目录里。目录结构通常是app.py pages/ __init__.py index.py login.py report.py admin.pyapp.py 里初始化 Dash 时开启多页面模式server Flask(__name__) server.config.update(SECRET_KEYenv-secret-key) dash_app Dash(__name__, serverserver, use_pagesTrue) login_manager LoginManager(server) server.before_request def protect_all_pages(): if request.path.startswith(/_dash) or request.path.startswith(/assets): return None if request.path /login: # 已登录用户访问登录页直接送回首页 if current_user.is_authenticated: return redirect(/) return None if not current_user.is_authenticated: return redirect(/login?next quote(request.path)) return None这里有个细节use_pagesTrue之后每个页面文件里的layout可以是变量也可以是函数。如果是函数Dash 会在每次请求时重新执行如果是变量只在模块导入时执行一次。登录态判断必须写在函数里否则current_user的值在进程启动时就被固定住了。4.2 登录后回到原页next 参数与二次重定向用户访问/report被重定向到/login?next/report登录成功后最好能回到/report而不是固定跳首页。实现方式是登录页布局里放一个dcc.Location读取地址栏的search参数登录成功后再跳转。# pages/login.py from urllib.parse import urlparse, parse_qs import dash from dash import html, dcc, Input, Output, State, callback, no_update from flask_login import login_user, current_user from werkzeug.security import check_password_hash dash.register_page(__name__, path/login) def layout(): return html.Div([ dcc.Location(idlogin-loc), html.H2(登录), dcc.Input(idusername, typetext, placeholder用户名), dcc.Input(idpassword, typepassword, placeholder密码), html.Button(登录, idlogin-btn), html.Div(idlogin-msg), ]) def parse_next(search): # search 形如 ?next/report query parse_qs(urlparse(search).query) next_path query.get(next, [/])[0] # 防止开放重定向只允许站内路径 if not next_path.startswith(/) or next_path.startswith(//): return / return next_path callback( Output(login-loc, pathname, allow_duplicateTrue), Output(login-msg, children), Input(login-btn, n_clicks), State(username, value), State(password, value), State(login-loc, search), prevent_initial_callTrue, ) def do_login(n_clicks, username, password, search): user_data query_user(username) if user_data and check_password_hash(user_data[password_hash], password): login_user(User(user_data)) return parse_next(search), return no_update, 用户名或密码错误这里有一个隐蔽的坑不要在布局函数里用request.args.get(next)拿参数。Dash 的布局函数是在/_dash-layout这个内部端点被请求时执行的查询串不是/login?next/report里的那一段拿到的永远是None。正确的做法是用dcc.Location的search属性从浏览器端读取。parse_next里的startswith(//)判断是为了防止next//evil.com这种伪协议跳转属于开放重定向的常规防护。4.3 页面级角色判断不止登录还要看权限before_request 只能回答「是不是登录用户」回答不了「有没有权限看这个页面」。页面级角色判断要放在 layout 函数里# pages/report.py import dash from dash import html from flask_login import current_user dash.register_page(__name__, path/report) def layout(): if not current_user.is_authenticated: return html.Div(请先登录) if current_user.role not in (admin, viewer): return html.Div(当前账号无权查看报表) return html.Div([ html.H2(运营报表), html.P(本月出货量、退货率等敏感指标), ])# pages/admin.py import dash from dash import html from flask_login import current_user dash.register_page(__name__, path/admin) def layout(): if not current_user.is_authenticated: return html.Div(请先登录) if current_user.role ! admin: return html.Div(仅管理员可访问) return html.Div([ html.H2(用户管理), html.P(重置密码、调整角色等操作), ])角色权限的映射关系建议集中维护避免散落在各个页面文件里角色可访问页面不可访问页面admin/、/report、/admin无viewer/、/report/admin未登录/login除 /login 外全部这种设计把「是否登录」和「是否有权限」拆成了两层Flask-login 解决前者页面 layout 函数解决后者。数据回调用同一种思路回调内先判断current_user.role是否满足条件再决定返回真实数据还是无权限提示。5. Dash Flask-login 高频坑现象、原因与修复5.1 登录成功却没写进 Cookie现象点击登录后页面没有任何变化打开浏览器开发者工具Network 里能看到/_dash-update-component的请求但响应头里没有Set-Cookie或者刷新后依然回到登录页。原因最常见的是出现了两个 Flask 实例。比如先dash_app Dash(__name__)让 Dash 自动创建了实例然后又server Flask(__name__)新建了一个LoginManager绑定到了后面这个新实例上。Dash 处理请求用的是dash_app.server两个实例的 session 互相不认。解决初始化顺序固定为「先创建 server再创建 dash_app再绑定 LoginManager」server Flask(__name__) dash_app Dash(__name__, serverserver) login_manager LoginManager(server)另外检查SECRET_KEY是否每次进程启动都在变化。session 的签名依赖这个 key如果随机生成重启后所有旧 Cookie 都会失效用户表现为「每次重启都要重新登录」。5.2 匿名用户依然能触发受保护回调现象用户未登录也能触发某个回调回调返回了敏感数据或者执行了写操作。原因第 3 章里为了让登录流程能跑通before_request 放行了所有/_dash开头的路径。而 Dash 回调走的就是/_dash-update-component相当于所有回调都对匿名用户开放了。before_request 只保护了页面路由保护不了回调接口。解决敏感回调必须自己加判断。用第 3.2 节的login_required_callback装饰器或者在回调开头手动检查callback(Output(sensitive, children), Input(btn, n_clicks), prevent_initial_callTrue) def safe_callback(n_clicks): if not current_user.is_authenticated: return 未登录无法操作 return load_secret_data()记住一个原则页面显示可以靠布局挡数据泄露必须靠回调挡。回调是服务端接口不能假设页面没渲染就安全。5.3 布局里的 current_user.is_authenticated 判断不生效现象布局函数里写了if not current_user.is_authenticated: return 登录页但未登录用户访问时仍然看到了登录后的内容。原因layout被写成了模块级变量# 错误写法 layout html.Div([ html.H2(欢迎{current_user.name} if current_user.is_authenticated else 请登录), ])模块导入时这段代码就执行完了current_user在导入阶段没有请求上下文被解析成匿名用户。之后不管谁访问看到的都是导入时算好的静态内容。解决把 layout 改成函数# 正确写法 def layout(): if current_user.is_authenticated: return html.Div([html.H2(f欢迎{current_user.name})]) return html.Div([html.H2(请登录)])函数布局在每次请求时执行current_user才能拿到当前会话的真实状态。Dash Pages 的register_page(layout...)参数同样支持传函数。5.4 重定向循环/login 跳完又跳回 /login现象浏览器地址栏在/login?next/login和/login之间反复跳转页面最终报「重定向次数过多」。原因user_loader返回了None。Flask-login 在每次请求时用 session 里的用户 ID 调user_loader拿不到有效用户就把current_user当成匿名对象。最常见的引发点是类型不一致用户在get_id()里返回整数1但load_user里写的是if int(user_id) ...类型转换失败返回了None。解决get_id()统一返回字符串load_user的参数也按字符串处理class User(UserMixin): def get_id(self): # 必须返回 strFlask-login 内部会序列化到 session return str(self.id) login_manager.user_loader def load_user(user_id): # user_id 永远是字符串不要在这里做 int() 转换 user find_user_by_id(user_id) return user # 找不到返回 None如果 load_user 里确实需要 int用try/except包住异常时返回None而不是让异常冒出去。5.5 退出登录后浏览器后退还能看到旧页面现象用户点击退出页面正常跳回登录页但按浏览器后退键上一页的敏感内容又出现了。原因这是浏览器 bfcache 的典型表现。后退时浏览器直接从内存恢复了之前的 DOM 快照没有重新发请求Flask-login 的退出逻辑管不到这一层。此外如果页面用了dcc.Store缓存数据恢复出来的页面仍然持有那些数据。解决处理分两层。第一层在退出回调里清理前端状态callback( Output(loc, pathname, allow_duplicateTrue), Output(store, data), Input(logout-btn, n_clicks), prevent_initial_callTrue, ) def do_logout(n_clicks): logout_user() return /login, None # 清空 dcc.Store第二层如果敏感度要求高采用第 6 章的 token 版本号方案。用户退出时刷新 token旧页面上任何残留回调再次触发时服务端会因为 token 不匹配拒绝执行。这样即使浏览器恢复了旧 DOM里面的交互也全部失效。6. 进阶技巧可配置白名单与主动踢人6.1 把公开路径收敛到一个配置里before_request 里的路径判断时间长了会越堆越多。我的习惯是把公开路径放进一个集合统一管理PUBLIC_PATHS { /login, /healthz, # 健康检查 /favicon.ico, } server.before_request def require_login(): if request.path.startswith(/_dash) or request.path.startswith(/assets): return None if request.path in PUBLIC_PATHS: return None if not current_user.is_authenticated: return redirect(/login?next quote(request.path)) return None新增公开页面时只需改这一个集合不用在钩子里加 if。配置项建议放到单独的config.py或环境变量里和业务逻辑解耦。6.2 主动踢人给用户 ID 加一个 token 版本号Flask-login 的 session 里存的是get_id()的返回值。如果让get_id()返回「用户 ID 当前 token」那只要把用户表里的 token 换掉旧 session 里的 ID 解析出来就匹配不上user_loader返回None该用户的所有会话全部失效。这比logout_user()只能踢当前会话要强得多。class User(UserMixin): def __init__(self, data): self.id data[id] self.token data[token] # 每次登录随机生成或者管理员主动刷新 def get_id(self): # 返回 用户ID:token 的组合 return f{self.id}:{self.token} login_manager.user_loader def load_user(user_id): if : not in user_id: return None uid, token user_id.split(:, 1) user find_user_by_id(uid) if user and user.token token: return user return None管理员踢人时只需把对应用户的 token 重新生成一次。旧 session 里的42:old_token在 load_user 里解析出来 token 对不上current_user变回匿名用户下一次访问任何受保护页面都会被重定向到登录页。这两个技巧配合起来就是一套完整的内网工具登录方案Flask-login 管会话before_request 管页面入口回调装饰器管数据接口token 版本号管主动失效。以前我偷懒把 SECRET_KEY 写死在代码里线上部署时改了配置结果所有用户一夜之间全部掉线被同事追着问了一周。后来我把 SECRET_KEY 放进环境变量又把 token 版本号做成用户表的常态字段才觉得这套方案真正收尾了。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
![[SAP ABAP] SAP设置定时执行任务Job](http://pic.xiahunao.cn/yaotu/[SAP ABAP] SAP设置定时执行任务Job)
