做JavaWeb开发这些年如果要我评一个“看起来简单、做起来全是雷”的模块用户登录认证绝对能排前三。很多刚接触企业级项目的同学第一个要动手实现的业务模块就是登录认证结果一上来就踩了一堆坑密码明文存数据库、Session失效找不到原因、登录成功后刷新页面又跳回登录页、同一个账号被并发登录挤下线……这些事情其实不是某一个技术点多难而是登录认证横跨了前端交互、后端业务、会话管理、安全控制一整条链路只要一个环节没想清楚后面就会连环踩坑。这篇内容我打算按照实际业务落地的顺序来讲从方案选型、数据库设计、密码加密、登录接口、会话管理到最后的统一拦截和部署发布把“登录认证”这个模块在企业级项目里到底该怎么搭、怎么防坑完整拆给你看。内容主要面向正在做JavaWeb课程设计、或者刚进入企业做传统Servlet Tomcat项目的同学如果你已经在用Spring Boot也可以透过这篇文章把底层机制重新理顺一遍。1. 登录认证要解决的根本问题与整体设计思路1.1 “用户登录认证”到底在认证什么很多人以为登录认证就是“做个表单查一下用户名密码对不对”这个理解太窄了。企业中说的登录认证实际上是三件事的组合第一确认“当前这个请求是谁发起的”这叫身份识别第二确认“这个用户有没有权限访问某个资源”这属于授权登录认证往往是授权的第一步第三解决HTTP协议“无状态”导致的会话问题让服务器在多个请求之间还能记住同一个用户。所以你会发现一个完整的登录认证模块必须包含注册、密码加密存储、登录验证、会话创建、登录状态检查、登出清理这六个基本环节。到了更复杂的多系统环境还要考虑单点登录、第三方授权、自动登录、分布式会话共享等问题。如果你只是做一个“表单比对”那只能叫“验证口令”不能叫“认证”。在动手写代码前我建议先回答一个问题你这个系统是传统服务端渲染页面还是前后端分离的接口服务这两种场景下登录状态的维护方式差别非常大。1.2 Session、JWT、OAuth2怎么选JavaWeb传统企业项目最经典的方案是服务端Session加Cookie这几乎是教科书里的标准答案。用户登录成功后服务端创建一份会话数据把会话ID通过Cookie交给浏览器浏览器后续每个请求都自动带上这个Cookie服务端根据会话ID找到对应的登录用户。这套方案的好处是状态在服务端主动可控想踢人下线就清Session想限制并发就维护会话列表。缺点也很明显当应用部署了多台机器用户第一次请求落在A机器、第二次落在B机器Session不共享用户就会被误判为未登录。正因如此企业里做集群时一般会用Redis统一托管Session或者用Spring Session来做透明同步。JWT这类无状态令牌方案更适合前后端分离的接口项目。服务端不保存状态登录成功后签发一个自带签名和过期时间的令牌客户端每次请求放在请求头里服务端验签即可。好处是不用考虑服务端会话存储和集群同步代价是令牌在过期前无法主动失效万一泄露只能等它自己过期或靠黑名单兜底。OAuth2、CAS这类统一认证解决的是“一个账号登录多个系统”的问题属于企业级门户场景。一般中小型JavaWeb项目用不上但如果你的项目未来要接入企业微信、钉钉或统一身份中心提前理解OAuth2授权码模式的流程会很有帮助。我的建议很直接如果是在做传统JavaWeb项目别犹豫直接用Session方案认真把会话生命周期和权限控制做好这套底子打扎实了以后理解框架里的SecurityContext本质上也是同一回事。1.3 模块怎么划分代码才不会写成一锅粥登录认证看似功能少但如果代码随便塞后面加个“记住我”、加个验证码、加个账号锁定就会越改越乱。我在设计这个模块时一般按下面的职责来分控制层负责接收请求参数、调用业务层、返回结果或跳转页面只做参数收集和视图控制。业务层负责校验用户名密码、判断账号状态、记录登录失败次数、更新登录时间等。数据访问层负责对用户表、登录日志表做数据库操作不掺业务逻辑。工具类负责密码加密、会话工具、Cookie操作等与业务无关的基础能力。过滤器负责拦截所有受保护的请求统一判断“当前线程是否已登录”。这样做最大的好处是登录逻辑可以被复用。比如以后做App端接口可以跳过页面转发只复用业务层和工具类不用重写一遍校验逻辑。后面我在第3节里写的代码也会严格按这个分层来展开你复制到项目里就能直接按照这个结构组织。2. 从零搭建开发环境与数据库2.1 用VS Code创建JavaWeb项目比你想象中简单很多同学习惯了用IDEA但如果是轻量级开发或者临时验证代码用VS Code其实也完全够用关键是要把扩展装对。这里我把流程拆一下安装Java Extension Pack它会把语言服务器、调试器、Maven支持一起装好。安装Tomcat for Java扩展这个扩展让你可以直接在VS Code里启动和调试Tomcat项目。通过命令行或者VS Code自带的Maven面板创建一个Maven Web项目groupId填自己公司或个人的域名倒写artifactId填项目名打包方式选war。项目创建完后手动检查目录结构是否包含src/main/java、src/main/resources、src/main/webapp三个目录如果没有就自己建出来。在pom.xml中引入javax.servlet-api注意scope用provided和mysql-connector-java。在webapp下创建login.html、register.html等页面。最后在VS Code左侧找到Tomcat Server窗口把项目war包拖进去启动或者添加本地Tomcat目录后直接Run on Tomcat。这中间最容易踩的坑是Maven创建出来的项目可能没有src/main/java目录因为war原型默认只建立webapp目录。解决办法是在src/main下新建java文件夹然后右键标记为Source Root。如果你没有用Maven而是手动建项目那还得自己管理lib依赖既麻烦又容易漏包我不太推荐。2.2 用户表结构设计这是一张能扛得住业务的表用户表设计看着简单实际需要认真考量。我见过不少项目在用户表里直接写一个password字段存登录密码明文或者无盐MD5这种表上线就是裸奔。下面这个表结构是我在项目里经过几次迭代后沉淀下来的版本CREATE TABLE t_user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, username VARCHAR(64) NOT NULL COMMENT 登录名, password_hash VARCHAR(128) NOT NULL COMMENT 密码哈希值, password_salt VARCHAR(64) NOT NULL COMMENT 随机盐, status TINYINT NOT NULL DEFAULT 1 COMMENT 账号状态1正常 0禁用, fail_count INT NOT NULL DEFAULT 0 COMMENT 连续登录失败次数, lock_until DATETIME DEFAULT NULL COMMENT 锁定截止时间, last_login_time DATETIME DEFAULT NULL COMMENT 最近一次登录时间, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户登录认证表;为什么username字段要加唯一索引因为用户名是登录标识用户注册和登录时都需要按用户名精确查询加了唯一索引既能防重复注册又能让查询走索引一举两得。status字段千万不能省企业后台经常需要对某个账号做禁用处理没有这个字段就只能删数据或改密码太粗暴了。fail_count和lock_until是为防暴力破解准备的后面会详细解释用法。还有一个容易忽略的细节username字段到底要不要区分大小写。MySQL的utf8mb4_general_ci排序规则默认不区分大小写也就是说Abc和abc在唯一索引里会被判定为重复。如果你不想让用户名出现这种歧义可以在程序里统一把小写转成小写后存储或者在建表时给username指定utf8mb4_bin排序规则。2.3 密码字段设计的深意为什么不能叫password这里专门说一下字段命名的问题。很多表设计习惯把密码字段叫password但实际上我们存到数据库里的并不是密码本身而是密码加盐后的哈希值。把字段名写成password很容易让人误以为可以直接存明文写成password_hash和password_salt后光看字段名就知道该往里面放什么内容。在企业级开发中密码安全这条线是需要画得很清楚的。用户提交的原始密码只允许在内存中存在一瞬间使用完后立刻丢弃不能进入日志不能进入数据库不能出现在任何查询字符串或响应体里。如果你在代码里看到有人在写日志时把用户密码打出来那不管项目多紧急都应该停下来先修这个问题。3. 核心实现从注册到登录认证的完整链路3.1 密码加密为什么绝对不能偷懒密码加密是整个登录模块里最不能省事的地方。很多人觉得MD5够用了觉得哈希之后别人看不到明文就行这个想法在今天是相当危险的。MD5这类算法的计算速度非常快GPU一秒能算几十亿次攻击者拿到你的哈希列表后跑字典破解弱密码几乎瞬间就被还原。另一个问题是彩虹表攻击者可以预先算好一大批常见密码的哈希拿到你的数据库后用彩虹表反查不需要逐个猜。正确做法是使用加盐慢哈希算法比如PBKDF2、bcrypt或scrypt。所谓“慢”指的是算法内部会多次迭代运算让单次哈希计算耗时尽量长这样攻击者想暴力破解时成本会呈指数级上升。下面是我在项目里常用的PBKDF2实现思路public class PasswordUtil { private static final int ITERATIONS 10000; private static final int KEY_LENGTH 256; // 生成随机盐 public static String generateSalt() { SecureRandom random new SecureRandom(); byte[] salt new byte[16]; random.nextBytes(salt); return HexFormat.of().formatHex(salt); } // 计算哈希 public static String hashPassword(String password, String salt) { try { char[] passwordChars password.toCharArray(); byte[] saltBytes hexToBytes(salt); PBEKeySpec spec new PBEKeySpec(passwordChars, saltBytes, ITERATIONS, KEY_LENGTH); SecretKeyFactory factory SecretKeyFactory.getInstance(PBKDF2WithHmacSHA256); byte[] hash factory.generateSecret(spec).getEncoded(); return HexFormat.of().formatHex(hash); } catch (Exception e) { throw new RuntimeException(密码加密失败, e); } } // 验证密码 public static boolean verifyPassword(String password, String salt, String expectedHash) { String actualHash hashPassword(password, salt); return MessageDigest.isEqual( actualHash.getBytes(StandardCharsets.UTF_8), expectedHash.getBytes(StandardCharsets.UTF_8) ); } }代码里最后一步用MessageDigest.isEqual做比较而不是直接用字符串equals是因为普通的字符串比较在遇到不同字符时会在更短的时间内返回结果理论上存在时序攻击风险。虽然这个风险在Web场景里很难被实际利用但作为企业级代码养成安全习惯总没有坏处。3.2 注册接口里的设计细节注册接口往往是登录模块里最容易被轻视的部分因为大多数人觉得“注册就是把数据插到数据库里”。但真正严谨的做法是在插入数据库之前做好三道防线第一道是参数合法性校验。用户名只能包含字母、数字、下划线长度在4到20之间密码最低长度至少8位并且建议要求同时包含字母和数字。密码强度要求不要搞得过于苛刻否则用户会绕开你的系统去用记事本记账反而制造更多安全隐患。第二道是业务重复校验。先按用户名查一次数据库如果记录已存在直接返回“用户名已被注册”。这里要注意你查数据库的username参数应该先规范化处理一下比如去掉首尾空格避免用户用带空格的用户名绕过唯一索引的重复限制。第三道是密码处理顺序。用户名查重通过之后再生成盐、计算哈希然后把username、password_hash、password_salt一起插入数据库。盐要每个用户独一份不能全局共用同一个固定盐否则就失去了“加盐”的意义。如果你打算以后支持“手机号或邮箱登录”建议在注册表中预留mobile和email字段并且分别加上唯一索引这样后续业务扩展时不用对表结构做伤筋动骨的调整。3.3 登录接口比“查表比对”多出来的那些事登录接口的核心逻辑虽然直白但每一步我都建议按下面这段流程来写WebServlet(/login) public class LoginServlet extends HttpServlet { private final UserService userService new UserService(); Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding(UTF-8); response.setContentType(text/html;charsetUTF-8); String username request.getParameter(username); String password request.getParameter(password); if (username null || password null || username.trim().isEmpty() || password.isEmpty()) { request.setAttribute(errorMsg, 用户名和密码不能为空); request.getRequestDispatcher(/login.html).forward(request, response); return; } // 这里会包含账号状态校验、失败次数锁定、密码校验等 User user userService.login(username, password); if (user null) { request.setAttribute(errorMsg, 用户名或密码错误); request.getRequestDispatcher(/login.html).forward(request, response); return; } // 登录成功更换Session ID防止会话固定攻击 HttpSession session request.getSession(true); session.changeSessionId(); session.setAttribute(LOGIN_USER, user); session.setMaxInactiveInterval(30 * 60); response.sendRedirect(request.getContextPath() /home.jsp); } }从这段代码可以看到Servlet层只做参数整理和页面跳转真正的登录判断被封装在UserService.login方法里。这里最重要的操作是session.changeSessionId()它解决的是会话固定攻击。攻击者可以先让用户用一个已知的Session ID访问系统等用户登录成功后再用这个ID冒用用户身份。登录成功后主动更换Session ID攻击者手里的旧ID立刻失效这是企业级系统非常基础但很容易被忽略的一个动作。3.4 登录失败次数与账号锁定防暴力破解的实用策略登录接口不能无限次尝试如果不加次数限制攻击者可以先抓包拿到接口地址然后写脚本对用户名密码做组合爆破一天能试几百万次。企业里的常用做法是同一账号连续失败N次后锁定该账号一定时间。N一般设置为5锁定时间设置为15分钟比较合理。我在UserService里的实现逻辑大致是先按用户名查出用户如果用户不存在为了不泄露“该用户名是否存在”可以统一返回“用户名或密码错误”。判断lock_until字段如果当前时间小于lock_until说明账号还在锁定期直接提示“账号已锁定请稍后再试”。如果账号未被锁定再比对密码哈希。如果密码错误fail_count加1当fail_count达到5时同时把lock_until设置成当前时间加15分钟并让fail_count归零避免锁定时间结束后立刻被再次尝试。如果密码校验通过将fail_count清零lock_until置为NULL记录last_login_time然后进入创建Session的流程。这里有一个比较需要把握的细节锁定时间要不要精确到分钟还是秒我建议用秒级别的DATETIME并且把比较操作放在数据库查询之后、用Java的Date对象统一计算不要依赖业务服务器和数据库服务器的时间一致性。两台机器时间不同步很容易出现“明明已经过了锁定时间账号还是提示锁定”的诡异问题。3.5 用Filter统一做登录状态拦截别再每个页面里重复判断登录模块最忌讳的做法是在每个Servlet里都写一遍“从Session取用户取不到就跳转登录页”。这种重复代码后期维护起来非常痛苦今天忘加一个Servlet明天就多出一个未授权接口漏洞。正确的做法是写一个AuthFilter把所有需要登录才能访问的资源全部拦下来只放行登录页、注册页、静态资源和少数公开接口。核心逻辑如下WebFilter(/*) public class AuthFilter implements Filter { Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) servletRequest; HttpServletResponse response (HttpServletResponse) servletResponse; request.setCharacterEncoding(UTF-8); String uri request.getRequestURI(); String contextPath request.getContextPath(); String path uri.substring(contextPath.length()); // 白名单直接放行 if (isPublicPath(path)) { chain.doFilter(request, response); return; } // 非白名单路径检查登录状态 HttpSession session request.getSession(false); Object loginUser (session null) ? null : session.getAttribute(LOGIN_USER); if (loginUser ! null) { chain.doFilter(request, response); } else { response.sendRedirect(contextPath /login.html); } } private boolean isPublicPath(String path) { return path.startsWith(/assets/) || path.equals(/login.html) || path.equals(/register.html) || path.equals(/login) || path.equals(/register); } }这个Filter最有价值的点在于request.getSession(false)这行代码。如果传入参数是true那么当会话不存在时容器会强行创建一个新Session结果就是未登录用户访问任何静态资源都会被制造一堆无意义的Session浪费服务器内存。用false就只查询不创建非常干净。白名单列表要特别注意首页如果也想让未登录用户看到应该明确加到列表里去否则一进系统就被弹回登录页体验会很差。在实际项目里白名单通常不止这几个地址可能还包括验证码接口、公告接口、开放API等所以我在Filter里单独把isPublicPath抽了出来方便后续维护。3.6 Session生命周期管理、Cookie安全属性与登出清理登录状态的生命周期是从用户登录成功开始到用户登出、关闭浏览器或超时结束。企业级项目里一般把Session超时时间设置为30分钟超过这个时间用户必须重新登录。配置方式可以在web.xml里搞定session-config session-timeout30/session-timeout /session-config如果希望用户的登录状态在浏览器关闭后仍然保留不要简单地把Cookie的过期时间拉长那是“自动登录/记住我”的范畴需要单独设计。直接拉长Session对应的Cookie生命周期实际上是把服务端会话ID长期暴露在浏览器里很容易被窃取后来冒充用户。真正的“记住我”一般通过额外签发一个长期令牌实现并且令牌要支持吊销。登出接口的逻辑也不只是删除一个Session属性而是直接调用invalidate()把整个Session销毁这样所有会话相关的数据一次性清空。同时如果有自动登录令牌、其他缓存标记也要一并清理。登出后一定要重定向到登录页注意用sendRedirect而不是forward否则浏览器的地址栏还停留在需要登录的页面用户刷新一下又会触发一次受保护资源请求。Cookie方面建议在web.xml或容器配置里给JSESSIONID设置HttpOnly属性这样JavaScript里的document.cookie读取不到这个ID能有效防范XSS攻击窃取会话。Servlet 3.0规范起Session Cookie默认就是HttpOnly的但在老版本容器中要手动验证。SameSite属性也是一道很好的防线它能防止跨站请求携带Cookie对CSRF攻击有显著的缓解作用。3.7 记住我、验证码、并发登录控制这几个进阶能力如果你的项目登录认证要做得更像企业级建议在基础之上至少再补三个能力。第一个是图形验证码。验证码的作用不是防君子是防自动化脚本。比较简单的实现方式是用Java的BufferedImage画一张四位数图片把答案存在Session里提交登录时一并校验。这个能力能拦截绝大多数低端爆破和撞库脚本。如果是更严谨的系统可以上行为验证码、滑块验证码等专业方案。第二个是并发登录控制。很多内部系统允许同一账号最多在一台设备上登录当新设备登录时把旧会话踢掉。实现思路是在内存或Redis里维护一个username到sessionId的映射用户登录时写入新映射发现旧会话仍然存在时把旧会话对应的Session属性移除。对于单机部署用一个ConcurrentHashMap就能实现对于集群环境这个信息要放进Redis等共享存储里这样才能让多台服务器共用一套“在线会话表”。第三个是登录日志审计。企业项目特别是金融、政务类项目登录日志是监管要求。每次登录成功、登录失败、账号锁定、登出行为都应当被记录下来至少包含用户标识、操作时间、来源IP、User-Agent和结果。以后排查账号被盗问题、做安全分析时这套日志能提供关键证据。4. Windows环境下Tomcat发布与Apache整合4.1 把项目打包成war并部署到Tomcat本地开发时通过VS Code或IDEA直接Run on Tomcat很方便但项目要给别人使用、或者部署到测试环境和生产环境时还是要走标准的war包部署流程。如果用Maven管理项目在项目根目录执行mvn clean package会在target目录下生成一个war文件。这个war本质上是一个压缩包里面包含WEB-INF、页面文件、编译后的java字节码和依赖jar包。部署时把这个war复制到Tomcat的webapps目录下然后启动Tomcat容器会在启动过程中自动解压并部署应用。默认访问地址是http://服务器IP:8080/项目名/。如果不想暴露项目的源代码目录可以删除webapps下解压出来的目录保留war包即可以后更新版本时直接替换war包。在Windows环境里如果Tomcat正在运行替换文件前一定要先停止服务否则文件被占用替换会失败。Tomcat端口如果不想用8080可以直接修改conf/server.xml里的Connector端口。但要注意改成80端口后项目访问地址就不用带端口了不过这要求启动Tomcat的账号有管理员权限在Windows上占用80端口经常被IIS或其他服务抢走所以很多团队反而会把Tomcat留在8080然后用前置的Apache或Nginx做转发。4.2 Apache Tomcat整合发布把80端口和静态资源交给Apache在Windows Server上把JavaWeb项目发布出去常见架构是Apache监听80端口或443端口负责接收外部请求、处理静态资源然后把动态请求转发给后面同一台机器上的Tomcat。这里我给出一套比较稳妥的整合方案。首先在Apache的conf/httpd.conf里确保代理模块已被加载LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so然后配置一个虚拟主机把应用程序的请求转发给Tomcat。这里有两种转发协议一种是直接通过HTTP转发到Tomcat的8080端口另一种是通过AJP协议转发到Tomcat的8009端口。日常部署我更推荐HTTP转发配置简单不容易踩权限和配置差异的坑VirtualHost *:80 ServerName www.example.com # 代理转发配置 ProxyRequests Off ProxyPreserveHost On ProxyPass /myweb/ http://127.0.0.1:8080/myweb/ ProxyPassReverse /myweb/ http://127.0.0.1:8080/myweb/ # 将静态资源交给Apache处理减少Tomcat压力 Alias /static/ D:/webapps/myweb/static/ Directory D:/webapps/myweb/static/ Require all granted /Directory /VirtualHost用这种方式整合后外部用户访问的地址就是Apache的80端口Tomcat的8080端口完全可以只监听内网地址。即便同一台机器上跑着Apache和TomcatTomcat端也可以把8080端口绑定到127.0.0.1只允许本机访问。修改Tomcat的conf/server.xml给HTTP Connector加一行address127.0.0.1就可以了。需要注意的是Tomcat 8.5以上版本对AJP连接器有比较严格的安全默认值。如果不需要AJP直接在server.xml里注释掉这个连接器如果需要建议绑127.0.0.1并且配置一个不弱的secret。原因是之前出现过AJP协议相关的严重漏洞暴露在外网风险极高。Apache整合之后还有一个很容易被忽视的Session问题。Apach通过反向代理传递请求时如果应用是通过/myweb这个上下文路径发布的Tomcat生成的Session Cookie路径默认是/myweb这个通常没有问题。但如果你的应用直接部署在根路径下Cookie路径是/代理转发后也没问题。真正需要留意的是当多个应用共用一个域名时Cookie路径不要设成/否则应用A的会话Cookie会被应用到B的请求上带来不必要的混淆。4.3 部署上线后第一时间要验证的清单每次发布完我都会列一张安全与功能检查清单逐项打勾之后才算真正上线完成。这里分享几条经验第一从外网访问域名时80端口必须畅通防火墙入站规则要允许HTTP和HTTPS8080端口尽量不要映射到公网。第二直接访问Tomcat的8080端口应该被拒绝或不可达避免用户绕过Apache直接访问业务服务。第三输入正确密码能够正常登录错误密码连续输5次后账号应该被锁定15分钟。第四浏览器开发者工具里查看CookieJSESSIONID应该带HttpOnly属性请求登录页以外的页面如果未登录应该被重定向到登录页。第五登录成功后再刷新页面登录状态应该保留不应反复跳回登录页。第六Windows任务管理器里要确认Tomcat和Apache进程都在稳定运行如果没有特殊需求最好把这两个服务都注册成Windows服务让它们随系统自动启动。如果这些检查项全部通过这个系统的登录认证模块才算是真正达到“可交付”的状态。5. 登录认证高频问题的排查与实操避坑5.1 关键问题速查表多年的项目经验告诉我登录认证模块出问题时大部分问题集中在一张表上就能快速定位。这里整理了一份我排查问题时经常对照的速查表现象常见原因解决办法登录成功后刷新又跳回登录页Session没保存成功或Cookie没被浏览器带回服务端检查Session写入时机和属性名用浏览器开发者工具看请求头里是否带JSESSIONID每次请求JSESSIONID都不同浏览器禁用了Cookie或Tomcat开启了URL重写检查项目是否有把Session ID拼到URL上若禁用Cookie需前端配合调整密码明明正确却提示错误密码加密算法不一致、盐值读取错误、哈希字段长度被截断写单元测试单独验证同一密码的加密和校验流程数据库连接中文乱码连接URL没有指定字符编码在jdbc url中追加characterEncodingutf8MySQL连接提示Public Key Retrieval is not allowedMySQL 8默认插件导致在jdbc url中追加allowPublicKeyRetrievaltrueuseSSLfalse注解写的Servlet没有生效web.xml中metadata-complete被设置为true检查web.xml中metadata-complete属性设置为false访问页面返回404或403Filter白名单配置错误或应用上下文路径不对确认项目访问URL是否带路径前缀检查Filter放行规则这张表不能覆盖所有问题但我在绝大多数JavaWeb项目里遇到的头疼问题基本都跑不出这几类。5.2 “密码明明对了还是登录失败”到底怎么查这个问题的出现频率非常高我第一次接手一个老系统时就踩过一次。当时查了很久最后发现原因是数据库里存的哈希值是用旧算法生成的代码后来升级成了新算法旧用户的密码没有做平滑迁移导致老用户全部登录失败。正确做法是先打印日志确认代码走了哪条分支是用户不存在、账号被锁定、还是密码校验失败。然后单独写一个JUnit测试把数据库里的password_salt和password_hash读出来手动调用密码校验工具去验证一个你已知的密码很快就能判断问题和加密流程是否一致有关。还有一种常见情况是字符编码问题。前端提交的中文密码在传输过程中如果编码不一致服务端拿到的字节序列就会和注册时不同校验自然失败。我一般建议在Filter的最前面统一设置request.setCharacterEncoding(UTF-8)并且保持前端页面charset是UTF-8双端一致后再刷新测试。如果密码哈希字段长度不够存储时被截断那也会导致比对失败。比如SHA-256哈希结果是64个十六进制字符字段却只定义了50数据库就会截断。这里有个很坑的现象插入数据时不一定报错但读出来和计算的哈希不一致极难排查。所以建表时字段长度一定要根据算法预留充足我在第2节故意把password_hash设计为VARCHAR(128)就是为了容纳未来更长的新算法。5.3 登录状态一会儿就掉问题一般出在哪这个现象通常有三种原因第一种是Session超时时间设置太短用户用了不到几分钟就被强制重新登录这种把web.xml里的session-timeout调长些就能解决第二种是Cookie的Max-Age设置得不合理如果Cookie被设置了明确的过期时间那个时间一到浏览器就不再发送Cookie服务端对应的Session也就找不到了第三种是部署在集群环境下但Session没有共享每次请求被负载均衡到不同节点后就找不到了这种情况必须上Redis等集中式会话存储单靠调配置文件是没用的。还有一个小概率问题是在开发过程中用localhost访问和用127.0.0.1访问浏览器认为它们是两个不同的站点Cookie不会在不同主机名之间共享。如果你一会儿用localhost调试一会儿用IP访问就会看到登录状态忽有忽无。这种一般是开发习惯问题统一一个访问地址就好。更隐蔽的一种情况是代理服务器或浏览器插件主动拦截了Cookie导致响应里的Set-Cookie请求头没有真正生效。排查时用浏览器的无痕模式访问能排除大部分本地Cookie污染和插件干扰的因素。5.4 安全强化这条线能给项目加分的三个习惯除了功能实现我特别建议在代码规范上建立三个习惯。第一个习惯是日志禁止输出密码、Session ID和完整的Cookie信息。密码是高度敏感信息Session ID是用户身份的临时凭证任何一头泄露到日志文件里都相当于把大门钥匙扔在了门口。如果确实需要排查问题可以用脱敏后的形式记录比如只记录用户名字段和IP。第二个习惯是所有对外错误提示尽量模糊化。当用户不存在和密码错误时返回给用户的信息都写成“用户名或密码错误”账号被禁用时提示“账号状态异常请联系统管理员”账号被锁定时提示“尝试次数过多请15分钟后再试”。这样做不是不友好而是不让攻击者通过接口差异判断出某个用户名是否真的存在减少被定向爆破的概率。第三个习惯是每次发布代码前做一遍快速回归。登录接口改动看似是小改动实际上影响面很广。我建议准备一个自动化测试脚本至少覆盖“正确密码登录成功”、“错误密码登录失败并计数”、“连续失败达到阈值后锁定”、“锁定期间即使密码正确也拒绝登录”、“锁定到期后账号恢复登录”、“登出后Session失效无法访问受保护资源”这六条用例。只要有其中任意一条被改坏都不要贸然上线。5.5 一个案例复盘我曾经排查过的线上登录事故有一年团队上线了一个老项目重构版登录功能在测试环境一切正常部署到生产后却出现间歇性登录失败而且只发生在高峰期。一开始我们以为是代码里的密码校验有bug后来翻日志发现大量的登录失败请求都指向同一类异常无法从连接池获取数据库连接。根本原因其实是登录接口里有一个隐藏的坑校验用户是否存在时执行了一次SQL查询查到结果后为了获取密码盐又执行了一次SQL每次登录请求短时间会占用两次数据库连接高峰期连接池被占满后后续请求拿不到连接就直接抛出异常反映到用户端就是“密码错误”。这之后我养成了一个习惯写登录逻辑时尽量把SQL压缩到最少次数。比如查询用户信息时一次性查出username、password_hash、password_salt、status、fail_count、lock_until全部分字段不要先查一次用户存在性再查一次密码。这个案例也很好地说明了为什么业务层封装要清晰否则性能优化时根本不知道一个接口到底发了多少条SQL到数据库。我个人在实际操作中的体会是登录认证这件事代码量不一定大但它是最能检验一个JavaWeb开发者是否具备“企业级思维”的模块。很多人写代码时只想着把功能跑通不考虑密码该用什么算法存、Session周期怎么管理、接口怎么防止被爆破结果功能交付出去本身就是一颗定时炸弹。建议每一位读者在动手前先按照这篇内容把Session流程图、锁定规则、白名单资源在纸上画清楚再动手写代码你会发现真正写起来会顺畅很多。最后分享一个小技巧给登录接口的响应增加一个稳定的业务码规范比如成功返回1000参数错误返回1001账号锁定返回1002密码错误返回1003前后端配合排查问题时能少很多沟通成本这也是团队项目里非常值得提前约定的一件事。