做了这么多年后台管理系统我接到过不少类似新闻发布系统后台要求必须登录index界面的需求。看起来就是把后台入口关起来加个登录页但真正落地时会发现这背后牵扯到会话管理、过滤器拦截、权限模型、前端路由守卫、资源放行策略一整条链路。标题里特意点名index界面说明这个项目大概率是遇到过这样的情况后台其它页面都有校验唯独入口页或主框架页是裸奔的或者登录成功后跳转到index但直接输入index的URL照样能访问。今天就从这类实际场景出发把整套登录拦截方案的构思、落地和排错过程完整拆一遍。1. 需求拆解项目标题背后到底藏着哪些硬要求1.1 从必须登录反推系统设计只看新闻发布系统后台要求必须登录这一句话很多人第一反应是做个登录页不就完事了。但把这个需求拆开看它其实包含了几层隐藏硬要求未登录用户访问后台任何URL包括index界面时必须重定向到登录页。已登录用户访问后台URL时可以正常进入并且index界面要正常展示菜单、栏目、内容列表等数据。登录完成后跳转到index界面而不是停留在登录页或跳到一个空白页。会话过期后用户再次操作时要么被自动踢回登录页要么用一些友好的方式提示登录状态已失效。后台的资源图片、CSS、JS文件不能被登录拦截误伤否则会出现页面出来了但样式全乱了的情况。index界面在这里为什么会被单独点名我在几个真实项目里遇到过同样的问题。最常见的一种情况是index.html是后台的前端入口里面用iframe嵌套了其它功能页面开发者只给被嵌套的子页面加了登录校验反而把最外层入口给漏了结果用户直接访问index地址虽然看不到具体数据但后台的菜单结构、栏目信息全部暴露出来了。另一种情况是index页面本身不请求带鉴权的接口但它引用了大量后台配置信息比如站点名称、Logo、管理员昵称这些信息里就有不该泄露的内容。所以标题里的index界面并不是指只保护这一个页面而是强调入口必须最先被拦下来这是整个权限体系的起点。1.2 混合技术栈下的方案选型思路新闻发布系统在真实环境里的技术栈很杂。有些是纯JSP/Servlet的老项目页面由后端渲染有些是前后端分离项目前端用Vue或React后端只出接口还有些是中间态前端静态页面加上后端模板引擎混合着用。我遇到过一个典型的模拟项目X前端是静态HTML页面加jQuery后端是Java Web没有用重量级安全框架整个后台的访问控制靠一个统一的登录过滤链来做。选技术方案的时候核心权衡在于用什么方式判断用户是否登录以及在哪一层做拦截。按照我的实践习惯做一个可复用的方案会比在每一个页面开头都写一段判断Session是否存在的代码要靠谱得多。前者是拦截器/过滤器的思路由统一的入口管理所有URL的访问权限后者是页面散装判断代码重复不说还容易漏掉某个新增的页面。在新闻发布系统这种页面数量不算少、又经常要新增功能模块的项目里统一拦截是必须的。2. 核心技术链路登录鉴权的那几个关键点2.1 会话状态选型Session还是Token登录系统绕不开一个问题登录成功之后怎么证明这个请求是已登录用户发出的。实际项目里用得最多的是两种方式。Session方式是传统方案服务端在用户登录成功后生成一个会话标识存到服务端的内存或缓存里同时通过Cookie把会话ID发给浏览器后续请求带上Cookie服务端一比对就知道当前用户是谁、有没有登录过。这个方案的优势是服务端可以一键踢人、集中管理会话实现成本低劣势是分布式环境下要做会话共享不然用户第一次请求打到服务器A登录了下一次请求被负载均衡转到服务器B那边没有这个会话用户又被踢回登录页。Token方式是前后端分离项目的主流方案用户登录成功后服务端签发一个Token一般是JWT前端保存下来每次请求放进Header里带给后端后端验签就能确认身份。优点是无状态、天然适合多实例部署和移动端复用缺点是一旦签发很难在有效期内主动作废需要额外的黑名单机制才能实现强制退出。对于新闻发布系统这类后台管理项目如果部署规模不大、用户数量有限用Session是最稳妥的踩坑最少。如果项目要做成多人协作、多实例部署或者未来要接APP端Token方案会更合适。我在模拟项目X里最后选的是Session方案原因很简单后台用户本来就少能进后台的人都是内部人员单一服务节点部署Session的简单可靠比Token的灵活更重要。2.2 过滤器、拦截器、路由守卫各管什么很多新手搞不明白这几层东西的职责再加上前端路由守卫容易混在一起。实际在一个完整的必须登录方案里它们是分层协作的关系Filter过滤器Java Servlet规范里的组件位于请求进入Servlet容器的最前端能拿到最原始的请求和响应。它可以拦截所有请求包括静态资源是做全局登录检查的第一道关口。Interceptor拦截器基于Spring MVC的机制工作在Controller之前能拿到HandlerMethod信息适合做更细粒度的权限控制但它对静态资源的处理天然不友好因为静态资源根本不会进入DispatcherServlet。前端路由守卫只针对前端单页应用。用户在浏览器里点击菜单切换页面时前端先检查本地有没有登录态没有就跳去登录页。它能在不请求后端的情况下快速拦截非法访问但它拦不住直接输入URL或刷新页面后由后端返回的页面。我见过一个实际踩坑的例子。某个后台管理项目前后端分离前端做了路由守卫后端所有业务接口也都做了Token校验但唯独没有对根路径和静态页面做后端拦截。结果用户直接访问后台的HTML页面地址后端把页面文件返回了页面里虽然请求接口会失败但整个页面框架和静态配置文件都暴露了。这再次印证了一个原则后端拦截才是底线前端守卫只是提升体验的补充。2.3 密码存储与登录校验的基础规范登录功能除了判断是否登录还有一个前置问题——登录时怎么验证密码。新闻发布系统里用户权限分为编辑、审核、管理员多种角色密码如果明文存储一旦数据库泄露就是灾难级的。正确的做法是加盐哈希存储。简单来说用户注册或修改密码时系统生成一个随机的盐值把原始密码和盐值拼在一起做摘要计算得到一串不可逆的哈希值数据库里只存盐值和哈希结果。用户登录时系统拿输入的密码和数据库里的盐值重新计算哈希比对一致才算通过。常见的算法有SHA-256加盐、PBKDF2、bcrypt等。我在实际项目中偏好bcrypt因为它在设计之初就内置了盐值生成、计算轮数调整可以在硬件性能提升后逐年调高成本防止暴力破解。登录成功之后还要考虑一个问题同一个账号能不能多点登录。多数新闻发布系统后台会限制为同一账号只能在一处登录后续登录会把之前的会话顶掉这与必须登录需求放在一起考虑时也需要提前设计好。3. 实操过程把index界面必须登录完整落地3.1 登录页和会话建立的基础流程先说整体访问流程让心里有个地图。用户请求后台首页index时请求到达服务端首先经过登录过滤器过滤器判断当前请求没有携带有效会话于是把请求重定向到登录页。用户输入账号密码登录接口校验通过服务端建立会话并写入Cookie然后把浏览器重定向回index界面。之后用户在后台的每一次操作过滤器都能识别出会话有效放行请求。在具体实现上登录页的提交和会话建立可以这样做。以Java Web项目为例登录接口的核心流程是接收前端提交的用户名、密码。根据用户名查询用户记录如果用户不存在或状态为禁用直接返回账号或密码错误。取数据库里的盐值和哈希值对提交的密码做同样的哈希计算比对结果。比对通过后创建会话在会话里记录用户ID、用户名、角色编码。根据请求参数里是否勾选记住我决定会话存活时间是随浏览器关闭结束还是保留一段较长时间。返回登录成功标识前端拿到结果后跳转到index界面。从开发角度看整个登录过程本身不复杂但它决定了后续所有鉴权判断的数据基础。Session里放哪些信息也值得想清楚至少要有用户ID和角色编码用来做页面的权限控制。至于用户名、头像这些等页面真正需要时再查库也行或者一并放进Session减少查询次数看系统规模权衡。3.2 后端统一拦截URL匹配、白名单和重定向的实现既然标题里点名了index界面必须登录那后端的拦截范围就应该是整个后台根路径下的所有请求。用一个登录过滤器来统一处理。WebFilter(/admin/*) public class LoginFilter implements Filter { private static final String LOGIN_PAGE /login.html; private static final SetString WHITE_LIST new HashSet(Arrays.asList( /admin/login, /admin/css/, /admin/js/, /admin/images/, /admin/plugins/ )); Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse resp (HttpServletResponse) response; String uri req.getRequestURI(); // 静态资源和登录接口直接放行 for (String prefix : WHITE_LIST) { if (uri.startsWith(prefix)) { chain.doFilter(request, response); return; } } // 会话检查 HttpSession session req.getSession(false); if (session ! null session.getAttribute(loginUser) ! null) { chain.doFilter(request, response); return; } // 未登录AJAX请求返回状态码页面请求重定向 String requestedWith req.getHeader(X-Requested-With); if (XMLHttpRequest.equals(requestedWith)) { resp.setStatus(401); resp.setContentType(application/json;charsetUTF-8); resp.getWriter().write({\code\:401,\msg\:\未登录或登录已过期\}); } else { resp.sendRedirect(req.getContextPath() LOGIN_PAGE); } } }上面这段代码里有几个点值得专门说一下。白名单的放行前缀必须是URL的前缀匹配不能做包含匹配。如果写成uri.contains(/admin/css)那么任何包含这段路径的URL都会跳过过滤器容易出现权限绕过。另一个细节是req.getSession(false)的false参数它表示如果没有会话就返回null不要自动创建。很多过滤器的漏洞就是这么来的用getSession(true)去判断登录状态结果每次未登录的请求反而在服务端创建了大量无意义会话白白占内存。这里还需要特别留意重定向路径的写法。我见过不少项目在重定向时硬编码成/login.html一旦项目部署时加了应用上下文路径重定向会指向错误位置用户被带到404页面。正确写法应该用req.getContextPath()拼出完整应用路径。拦截器方案和过滤器思路类似只是注解方式配置上略有不同。如果项目用的是Spring Boot也可以直接注册一个HandlerInterceptorpublic class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(false); if (session ! null session.getAttribute(loginUser) ! null) { return true; } String requestedWith request.getHeader(X-Requested-With); if (XMLHttpRequest.equals(requestedWith)) { response.setStatus(401); } else { response.sendRedirect(request.getContextPath() /login.html); } return false; } }过滤器方案和拦截器方案不是非此即彼。过滤器能覆盖静态资源拦截器能拿到具体的处理器信息。不少项目会同时用过滤器做粗粒度的登录态检查拦截器做基于角色和权限的细粒度控制。我自己的习惯是登录检查放在过滤器层权限判断放在拦截器层这样职责清晰排查问题时能快速定位是哪一环出了问题。3.3 前端配合路由守卫、请求拦截和登录跳转如果后台是前后端分离的前端也要配合做两层事情。第一层是路由守卫。Vue项目中以Vue Router的全局前置守卫为例router.beforeEach((to, from, next) { const token localStorage.getItem(admin_token) if (to.path /login) { next() return } // 动态配置的后台入口页路由原本指向 /admin if (to.matched.some(record record.meta.requiresAuth)) { if (!token) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } } else { next() } })留意query: { redirect: to.fullPath }这行它记录了用户原本想访问的地址。用户登录成功后拿着这个参数跳回原来的目标页而不是每次登录完都固定回到首页。这个体验细节经常被忽略但实际使用中非常提升好感度。比如编辑正在写一篇新闻稿时登录过期了重新登录后能直接回到编辑页而不是被扔到后台首页再一步步点进去。第二层是HTTP请求拦截。Axios请求拦截器可以统一给请求头加上Token响应拦截器里统一处理401状态码axios.interceptors.response.use( response response, error { if (error.response error.response.status 401) { router.push(/login) } return Promise.reject(error) } )这一层的作用是处理那种登录态已过期、但用户还停留在页面上点击某个按钮触发接口请求的场景。如果没有响应拦截用户会看到接口报错信息体验很差有了拦截器直接把用户带回登录页。需要强调的一点是前端这几层都是体验优化不是安全边界。用户完全可以绕过前端守卫直接向后端接口发请求所以后端拦截必须存在。这个观点我在多个项目里反复跟团队成员强调过——前端路由守卫和请求拦截做得好不好只影响用户感受不影响系统安全真正决定必须登录这个需求是否达标的是后端过滤器链的严密程度。3.4 会话超时、退出登录、记住我这些细节必须登录不是只拦一下入口就完了一个完整的后台登录体系至少要处理下面三个场景。会话超时是第一个必须考虑的。默认的Session过期时间如果设置得太短编辑正在写一篇长稿子停了几分钟再提交就发现被踢出草稿没保存情绪直接崩溃。如果设置得太长后台一直挂着登录态安全风险又变大。新闻发布系统的折中方案一般是把会话策略分成两级。普通操作超时时间设置为30分钟到1小时但通过一个定时心跳接口来续期——只要用户隔一段时间还在页面上活动就重置会话过期时间如果用户很久没操作下一次请求时后端会判断会话失效返回401。这种方式比固定Session过期更像真实用户的使用习惯。第二个场景是退出登录。退出操作不能只是前端清掉Token或跳回登录页后端必须销毁会话。否则会话在服务端还在等于一个半死的登录态留在那里。正确的流程是点击退出前端调用退出接口后端在接口里执行session.invalidate()清掉会话同时前端清掉本地的Token和用户信息再跳转登录页。第三个场景是记住我。这个功能在过去的老后台里经常做成关掉浏览器再打开还在登录实质上就是设置Session永不过期。这个做法安全风险较高尤其后台里如果涉及管理员账号一旦失了浏览器又忘了锁屏等于把整个系统权限交出去了。稳妥的做法是记住我只延长会话有效期到一个合理的时间范围比如7天并通过独立的Cookie标识来识别而不是直接把过期时间设成无限长。4. 权限模型、资源访问控制和边界情况4.1 静态资源分离CSS和图片为什么必须放行很多人在配置登录过滤器时容易把所有路径一股脑拦进去结果登录页面本身引用的CSS、JS文件也被拦了。登录页打开后一片光秃秃的原始HTML布局全乱以为是样式文件坏了排查半天发现是过滤器把静态资源请求重定向回了登录页登录页又加载静态资源静态资源又被重定向形成循环。解决办法是让静态资源独立于后台业务请求。对于路径前缀规则清晰的项目把/admin/css/、/admin/js/、/admin/images/这些路径加入白名单即可就像3.2节代码里做的那样。对于更规范的项目应该把静态资源放到独立域名或独立的静态资源目录下比如/static/路径和后台业务接口的/admin/api/路径天然隔离过滤器里只需要放行整个/static/前缀就行。我实际处理过一个比较隐蔽的问题新闻发布系统里的编辑器组件通常会上传图片到服务器生成的图片URL可能被拼在富文本内容里图片路径是/upload/2025/xxx.jpg。如果登录过滤器把/upload/也拦了那么后台文章列表里的图片全裂前台网站首页的新闻图片也会裂。因为前台页面是不要求登录的它引用后台的图片地址时请求同样会被过滤器拦截重定向。这个问题的本质是上传目录是资源不是页面必须无条件放行。凡是遇到这种登录拦截后图片全挂的情况先检查是不是把资源目录也纳入了保护范围。4.2 登录状态续期和并发会话控制先来说登录状态续期。模型上Session有个最后访问时间每来一次请求就自动刷新。但在新闻发布后台的实际使用场景里有个坑如果用户开着后台页面但长时间不做操作页面上的定时器或心跳机制会周期性访问接口这会持续刷新Session的最后访问时间导致人不在但会话一直不断。这在有些场景是好处在另一些场景是隐患。我见过的做法是让心跳接口不刷新会话而是由后端在处理真正的业务请求时才刷新过期时间这样能比较真实地反映用户活跃度。会话超时时间设多长也值得认真算一下。结合新闻编辑场景写一篇带排版的长新闻稿动辄几十分钟如果时限设为20分钟编辑在提交前被踢出的概率不小。建议基础会话时长设置为60分钟同时叠加空闲超过30分钟则自动失效的二级策略。也就是说会话最长时间1小时但如果连续30分钟没有任何业务操作会话就提前烤掉了。这种方式比单纯一个固定时长更贴近实际工作节奏。并发会话控制在新闻发布系统里通常需要配置成单一会话模式。通俗地说就是同一账号只能在同一个浏览器里保持登录如果换了电脑或浏览器登录同一账号前一个登录会话直接失效。实现上可以在过滤器里做一个当前用户的SessionID是否等于该账号最新登录时的SessionID的比较不等就视为未登录。这样能防止账号被多人共享后权限扩散也方便在账号被盗后通过重新登录把入侵者顶下线。4.3 开放接口与后台接口的权限边界新闻发布系统通常分前台门户和后台管理两个区域。前台展示新闻是公开的后台管理是受限的。如果前后台共用同一个项目部署那过滤器必须按路径严格区分/admin/**后台管理路径全部要求登录。/api/public/**前台公开接口比如新闻列表、新闻详情不要求登录。/upload/**上传的图片、附件不要求登录因为前台页面要展示这些内容。/login*登录页及登录接口不要求登录。听起来很简单但实际项目里最容易出问题的是接口复用。比如新闻列表接口/api/news/list前台要用后台也要用。前台访问时不需要登录后台访问时又要确认是管理员。这种接口就应该拆成两个前台公开接口只返回已发布且状态正常的新闻后台管理接口要求登录后才能访问并且可以拿到未发布的草稿数据。如果图省事共用一个接口要么裸奔暴露了后台数据要求登录又挡住了前台正常访问对必须登录的需求来说后台管理接口一定不能向未登录用户暴露。5. 常见问题与排查技巧实录5.1 登录后循环重定向、样式全乱、页面空白这三组现象是登录拦截需求上线时出现频率最高的。登录后循环重定向最常见的原因是登录页本身被过滤器拦截了。用户访问index被重定向到login请求login这个URL时又被过滤器判定未登录再重定向到login浏览器发现来回跳同一个地址直接报重定向次数过多。排查方式很简单看浏览器地址栏最终停在哪个URL如果反复在index和login之间跳那就去过滤器的白名单里把登录接口和登录页路径加进去。样式全乱基本就是静态资源被拦截。用浏览器开发者工具打开Network面板凡是状态码302的CSS或JS请求都是被过滤器踢掉的。把它们对应的路径前缀加进白名单即可。这里要提醒一点白名单前缀匹配务必精确不要用/admin去匹配因为它会把/admin/login也放行有可能突破必须登录的限制。页面空白往往是跳转地址写错或者前端路由和后端URL没对齐。比如后端重定向到/login.html但前端用的是/login路由且没有对应的物理文件就会在跳转时出现404或白屏。前后端联调时约定好登录页地址和跳转方式能少踩很多坑。5.2 小程序或接口调用方未登录却拿到了页面HTML有些新闻发布系统后台会做移动端适配或者有外部程序需要调用后台接口。如果外部调用方直接请求index地址服务端按页面请求方式处理返回的是302重定向这在浏览器里体验没问题但如果是非浏览器的客户端它可能不会自动跟随重定向结果拿到的是一段HTML跳转提示程序就不知道该怎么处理。这类问题的解决思路在过滤器里区分请求类型我在3.2节的代码里已经做了处理对AJAX请求返回JSON格式的401状态码。但更通用一点的做法是对Accept头里明确只接受JSON的请求也按同样方式处理。接口类请求和页面类请求应该有不同的未登录表现这个区分越早做后面对接第三方时越轻松。5.3 排查方案一套顺口溜式的记忆调试这类问题时我习惯按照下面这个顺序走一遍排查流程基本能覆盖八成的异常场景看浏览器Network面板确认请求有没有到达后端没到达就查前端路由守卫和请求拦截。确认后端有没有收到请求看日志和过滤器是否打印了拦截记录没走过滤器就检查WebFilter的URL映射和注册配置。确认过滤器放行还是拦截如果拦截了看是白名单没匹配上还是会话校验失败。确认会话存在与否排查Cookie有没有正确写入和回传以及Session的过期配置。确认跳转目标地址对不对重点检查应用上下文路径。确认登录页资源加载正常看静态资源是否被误拦截。确认登录成功后回跳地址正确排查redirect参数和路由配置。这套流程在团队里被同事叫过七步抓虫法本质上就是沿着一次请求从浏览器到后端再到浏览器回显的完整路径逐个环节排除。遇到登录类问题远比直接看Session代码更高效。5.4 开发调试期不用每次都重新登录的小技巧开发期间反复测试登录流程是一件挺烦人的事。每次改完代码重启服务Session存的内存里重启后全部失效浏览器又要走一遍登录流程。我在本地开发环境里有一个自定义的调试开关在开发配置里单独加一个过滤器如果请求头里有指定的调试标识直接放行并自动注入一个测试用户身份。这个过滤器只在本地开发环境生效生产环境完全不会注册。测试登录过期场景时关闭调试开关即可。这个技巧能明显提升联调效率比如前端在调页面样式时不用总是被登录流程打断。但它有一个前提绝对不能让配了调试开关的代码打包进生产环境。我见过不止一次因为开发调试代码漏删导致生产环境后台形同虚设的案例每一次都是严重事故。所以这个技巧要么用Maven Profile或环境变量控制要么就老老实实每次重启后手动登录安全第一。6. 一些想再唠叨的实战心得前面把方案、代码和排错流程都讲完了最后再分享几个我在多个项目里反复体会到的经验。第一点是必须登录这个需求最忌讳头疼医头。如果只是给index页面加一段判断没过多久就会有人发现后台的另一个URL可以直接访问然后继续补丁式修复越补越乱。从一开始就把整个后台路径纳入统一拦截范围把白名单做好后面新增页面默认就在保护范围内不需要再逐个添加。第二点是关于记住我和安全强度的取舍。新闻发布系统后台的管理员账号拥有文章发布、删除权限一旦被滥用影响面不小。我见过有项目为了便利把记住我做成永久有效这是一种很危险的预埋雷。即便要做也应该设定合理的过期时限并且定期要求重新验证密码。第三点也是我个人体会最深的一点权限系统是从第一行代码就要设计好的东西不是后期可以轻松补救的功能点。我在一个老项目里见过把后台地址和登录逻辑写在同一个页面里改一次业务动一次登录代码维护成本高到离谱。像登录检查这种横切关注点用过滤器/拦截器统一收敛是成本最低、收益最高的做法。任何说先随便写一下后面再抽出统一逻辑的计划最终都会为这句话付出两到三倍的返工代价。做后台管理系统的登录功能本质上不是做一个登录页而是把什么能访问、什么不能访问、访问不了时怎么办这条链路想清楚。希望这篇基于新闻发布系统后台要求必须登录index界面的完整拆解能帮你少走几趟弯路。