企业官网建设流程全解析

小百姓这个网站谁做的,天津的网站建设公司哪家好,公司网络推广网站就选火13星仁德,付费阅读wordpress你想知道为什么会出现「退出系统」的日志#xff08;用户名: 管理员,退出成功#xff01;#xff09;#xff0c;对吧#xff1f;结合日志内容和 JeecgBoot 项目的特性#xff0c;这不是手动点击退出按钮导致的#xff0c;而是系统自动触发的登出逻辑#xff0c;核心原…你想知道为什么会出现「退出系统」的日志用户名: 管理员,退出成功对吧结合日志内容和 JeecgBoot 项目的特性这不是手动点击退出按钮导致的而是系统自动触发的登出逻辑核心原因和之前的token认证失败直接相关。一、先看日志中的关键线索从你提供的日志能提取两个核心信息串联起整个自动登出的流程先出现了token相关记录获取子系统菜单,eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...这个 JWT token 就是前端携带的X_ACCESS_TOKEN紧接着执行了sys_log表的插入操作记录「退出成功」最后打印登出日志结合之前的token非法无效!异常整个流程的逻辑是token 认证失败 → 系统触发自动登出 → 清除无效 token 并记录登出日志。二、自动登出的 3 种核心原因按优先级排序1. 最可能token非法/过期/无效触发 Shiro/JWT 过滤器的自动登出这是 JeecgBoot 项目的默认特性也是和你之前的异常直接关联的原因后端的JwtFilter或ShiroFilter会拦截所有需要认证的请求校验X_ACCESS_TOKEN的有效性包括是否过期、签名是否合法、是否被篡改、是否能解析出有效clientId/userId当校验失败就是之前的clientId null属于 token 无效过滤器会直接触发「强制登出」逻辑清除后端缓存中该token对应的用户登录信息向前端返回「token 无效/过期」的响应同时告知前端清除本地存储的token自动插入登出日志到sys_log表就是你看到的「退出成功」记录这种场景下前端可能还没收到明显的退出提示就已经被系统自动登出了本质是「无效登录状态的自动清理」。2. 其次token对应的用户已在其他终端登录账号互踢JeecgBoot 支持「单终端登录」默认配置或已开启该功能当出现以下情况时会触发旧终端自动登出同一个账号stc_sinosoft在另一台电脑、另一个浏览器标签页重新登录后端会生成新的token后端会失效旧的token当旧终端用无效的旧token发起请求比如获取子系统菜单时会触发自动登出同时记录登出日志从日志中的ip能辅助判断登出日志的ip是0:0:0:0:0:0:0:1本地回环地址 IPv6 格式之前登录的ip是127.0.0.1IPv4 格式大概率是同一台机器的不同环境/标签页导致的账号互踢。3. 其他场景系统缓存清理/会话超时会话超时后端对用户登录会话设置了超时时间比如 30 分钟无操作超时后会话失效token对应的缓存被清理此时发起请求会触发自动登出缓存刷新后端重启、Redis 缓存若使用清理导致token对应的用户信息丢失无法完成认证触发自动登出并记录日志。三、补充和「手动退出」的区别你可能会疑惑为什么是「退出成功」而不是「认证失败」这里要说明 JeecgBoot 的日志设计手动退出用户点击页面上的「退出登录」按钮发起/logout接口请求后端清除token、缓存记录「退出成功」流程更完整前端会主动跳转到登录页自动登出系统通过过滤器强制清理无效登录状态本质也是「登出操作」所以日志统一记录为「退出成功」而非「认证失败」这是为了简化日志类型方便统计用户登出行为。四、如何验证具体原因如果想确认是哪种情况可以通过以下方式排查查看token过期时间复制日志中的 JWT tokeneyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...打开 JWT 在线解析工具粘贴后查看exp字段过期时间戳转换为本地时间看是否已经过期检查账号登录状态确认是否在其他终端/标签页登录了同一个stc_sinosoft账号查看后端配置打开 JeecgBoot 的application.yml查看 JWT 过期时间配置确认是否设置过短jeecg:jwt:expire:7200# token 过期时间单位秒默认 2 小时secret:jeecg-boot# JWT 签名密钥总结该「退出成功」日志是系统自动触发的登出逻辑并非手动操作核心和token有效性相关。最可能的原因是token非法/过期之前clientId null导致JeecgBoot 的 Shiro/JWT 过滤器自动清理无效登录状态并记录日志。日志中的「退出成功」是统一的登出操作记录包含「手动退出」和「自动强制登出」两种场景和认证失败不冲突。你想解决的是「同一台机器因 IPv4/IPv6 差异导致的账号互踢」问题本质是要让 JeecgBoot 项目忽略 IP 格式差异识别出127.0.0.1IPv4和0:0:0:0:0:0:0:1IPv6是同一台客户端避免因 IP 不同触发账号互踢逻辑。一、先明确核心原因JeecgBoot 的「单终端登录账号互踢」功能默认会关联用户账号和客户端 IP部分配置还会关联设备信息用于标识「一个登录会话」。当你在同一台机器上有时请求的 IP 是127.0.0.1IPv4有时是0:0:0:0:0:0:0:1IPv6后端会认为是「两个不同的客户端」第一次用127.0.0.1登录生成 token A记录登录 IP 为127.0.0.1后续请求触发了 IPv6IP 变为0:0:0:0:0:0:0:1后端认为是「新客户端登录同一账号」触发单终端登录逻辑失效旧 token A生成新 token B同时记录旧会话的「退出成功」日志也就是你看到的现象。二、针对性解决方案按推荐度排序方案 1统一客户端 IP 格式最简单优先推荐让前端请求统一使用IPv4 格式127.0.0.1避免出现 IPv6 格式的0:0:0:0:0:0:0:1从根源上消除 IP 差异。具体操作前端请求地址修改把前端.env文件中的接口地址从localhost改为127.0.0.1localhost可能被解析为 IPv6127.0.0.1强制 IPv4# .env.developmentVUE_APP_BASE_API http://127.0.0.1:8089/api# 原先是 http://localhost:8089/apiVUE_APP_CAS_BASE_URL http://127.0.0.1:8089/placedangerous/sys/thirdLogin/render/SINOSOFT重启前端项目npm run serve后续请求的客户端 IP 会统一为127.0.0.1。后端服务绑定 IPv4可选防止后端监听 IPv6若后端 Tomcat 优先监听 IPv6可在application.yml中指定绑定 IPv4server:address:127.0.0.1# 强制绑定 IPv4 地址拒绝 IPv6 连接port:8089重启后端服务确保仅接收 IPv4 格式的客户端请求。方案 2修改后端 IP 处理逻辑统一归一化 IP如果无法统一客户端 IP 格式比如需要支持 IPv6可修改后端获取/存储 IP 的逻辑将0:0:0:0:0:0:0:1转换为127.0.0.1视为同一个 IP。具体操作JeecgBoot 项目找到 IP 工具类JeecgBoot 中通常有IpUtils.java路径一般是org.jeecg.common.util.IpUtils核心方法是getIpAddr(HttpServletRequest request)用于获取客户端 IP。修改该方法添加 IPv6 本地地址转换逻辑packageorg.jeecg.common.util;importorg.springframework.web.context.request.RequestContextHolder;importorg.springframework.web.context.request.ServletRequestAttributes;importjavax.servlet.http.HttpServletRequest;importjava.net.InetAddress;importjava.net.UnknownHostException;publicclassIpUtils{// 原有方法不变添加 IPv6 本地地址转换publicstaticStringgetIpAddr(HttpServletRequestrequest){if(requestnull){returnunknown;}Stringiprequest.getHeader(x-forwarded-for);if(ipnull||ip.length()0||unknown.equalsIgnoreCase(ip)){iprequest.getHeader(Proxy-Client-IP);}if(ipnull||ip.length()0||unknown.equalsIgnoreCase(ip)){iprequest.getHeader(WL-Proxy-Client-IP);}if(ipnull||ip.length()0||unknown.equalsIgnoreCase(ip)){iprequest.getRemoteAddr();}// 核心修改将 IPv6 本地回环地址转换为 IPv4 本地地址if(0:0:0:0:0:0:0:1.equals(ip)){ip127.0.0.1;}// 多IP处理原有逻辑保留if(ip!nullip.contains(,)){ipip.split(,)[0].trim();}returnip;}// 其他原有方法...}验证修改重启后端服务再次登录并操作项目查看sys_log表中的ip字段会发现无论是 IPv4 还是 IPv6 请求最终都被记录为127.0.0.1后端识别为同一客户端不会再触发账号互踢。方案 3关闭/调整「单终端登录」功能终极方案按需使用如果不需要「同一账号只能在一个终端登录」的功能可直接关闭该特性从根本上避免账号互踢。具体操作JeecgBoot 3.x 为例找到 Shiro 配置文件路径一般是org.jeecg.config.shiro.ShiroConfig.java。修改登录缓存逻辑关闭单终端限制找到shiroRealm相关配置或找到「登录成功后存储 token 与用户信息」的逻辑注释/删除「失效旧 token」的代码JeecgBoot 中通常是RedisUtil.delKey()或CacheManager.remove()相关操作或通过配置文件关闭部分版本支持# application.ymljeecg:security:single-login:false# 关闭单终端登录默认 true 开启注意该方案会允许同一账号在多个终端同时登录可能存在安全风险仅在开发/测试环境或业务允许的场景下使用。三、验证是否解决成功前后端项目均重启后用同一账号登录多次操作触发不同 IP 格式127.0.0.1/0:0:0:0:0:0:0:1查看后端日志不再出现无意义的「退出成功」记录查看sys_log表ip字段统一为127.0.0.1且不会出现频繁的登录/退出日志交替前端不会被强制登出能正常访问子系统菜单等接口无token非法无效异常。总结问题核心是127.0.0.1IPv4和0:0:0:0:0:0:0:1IPv6被后端识别为不同客户端触发单终端登录的账号互踢。优先选择方案 1统一客户端 IP 为127.0.0.1操作最简单无代码侵入适合大部分场景。若需要支持 IPv6选择方案 2修改IpUtils归一化 IP从后端逻辑上解决 IP 差异问题。方案 3关闭单终端登录仅作为兜底需权衡安全风险谨慎使用。这是百度地图 API 的Referer 域名白名单校验失败错误意味着你的前端页面当前访问 IP 是192.168.31.101:3011不在该 AKAPI 密钥允许的域名白名单中。核心原因百度地图 API 为了防止密钥被滥用会校验请求来源的Referer头信息。如果请求的域名没有在百度地图开放平台的后台配置为“白名单”就会触发这个报错。解决方案你需要登录百度地图开放平台修改该 AK 的白名单设置进入百度地图开放平台控制台访问http://lbsyun.baidu.com/apiconsole/key#用你的账号登录。找到对应的应用和 AK在「应用管理」→「我的应用」里找到你当前使用的应用和 AK。修改 Referer 白名单进入该 AK 的「设置」页面找到「Referer 白名单」选项。开发调试场景直接输入*表示允许所有域名访问简单快捷但不建议线上使用。正式上线场景添加你的具体域名比如http://192.168.31.101:3011 http://localhost:3011 https://yourdomain.com保存并验证保存设置后刷新你的前端页面地图应该就能正常加载了。如果需要的话我可以帮你整理一份白名单配置模板包含开发、测试、生产环境的完整配置示例这样你直接复制就能用。需要吗