Express身份验证后：重定向(redirect)与渲染(render)哪个更安全？最佳实践

嘿，这个问题问到点子上了——身份验证后的页面跳转逻辑直接影响应用的安全性和用户体验，咱结合你给的代码片段，一步步拆解清楚。

一、安全性对比：谁更靠谱？ #

重定向（redirect）的安全优势 #

重走一遍浏览器请求流程的重定向，其实是遵循了Web开发里经典的Post/Redirect/Get（PRG）模式，这玩意儿最大的作用就是防表单重复提交：

• 验证成功后返回3xx状态码，让浏览器重新发起GET请求到/profile，用户地址栏会更新成目标页面的URL，后续刷新页面只会请求/profile，不会重复提交登录表单；
• 更重要的是，/profile路由本身必须单独做身份验证检查（比如校验session里的用户信息），这相当于给页面加了第二层防护——就算有人直接手动输入/profile，也得先过验证这关。

直接渲染（render）的潜在风险 #

直接渲染看起来省事，但藏着不少坑：

• 登录请求是POST，渲染出来的页面是POST请求的结果，用户刷新时浏览器会提示“是否重新提交表单”，很容易造成重复登录操作；
• 地址栏还停留在登录页的URL，用户可能误以为登录没成功，体验拉胯的同时，也可能让攻击者有可乘之机（比如诱导用户重复输入密码）；
• 如果后续/profile路由没做单独验证，有人直接访问该路由时可能绕过身份验证，直接看到页面。

二、最佳实践：该选哪种场景用哪种？ #

1. 验证成功→必须重定向
   严格遵循PRG模式，验证通过后把用户信息存入session，然后重定向到目标页面，再在目标页面的GET路由里做身份校验。
2. 验证失败→直接渲染登录页
   比如密码错误、邮箱不存在这类情况，直接渲染登录模板，同时把错误信息传给模板，让用户看到提示的同时，还能保留之前输入的账号（不用重新打字），体验更好。
3. 所有受保护路由必须单独校验
   不管是/profile还是其他需要登录才能访问的页面，每个路由都要单独检查用户是否已登录（比如req.session.user是否存在），不能依赖登录路由的验证结果——毕竟用户可能直接访问这些路由。

三、优化后的代码示例 #

针对你贴的代码，调整成符合最佳实践的版本：

登录路由（POST /login） #

var User = require('models/user.js');

app.post('/login', async (req, res) => {
  try {
    // 假设authenticate方法验证成功返回user，失败抛出错误
    const user = await User.authenticate(req.body.email, req.body.password);
    // 将用户信息存入session，标记登录状态
    req.session.user = user;
    // 验证成功，重定向到profile页面
    res.redirect('/profile');
  } catch (error) {
    // 验证失败，渲染登录页并传递错误信息
    res.render('login.pug', { errorMsg: '邮箱或密码错误，请重试' });
  }
});

受保护的Profile路由（GET /profile） #

app.get('/profile', (req, res) => {
  // 检查session中是否有用户信息，未登录则重定向到登录页
  if (!req.session.user) {
    return res.redirect('/login');
  }
  // 已登录，渲染profile页面并传递用户数据
  res.render('profile.pug', { user: req.session.user });
});

注：我调整了原代码里的Promise写法——用async/await更简洁，而且原代码中then(function(error, user)的写法不符合Promise的常规逻辑（Promise的then只接收成功结果，错误由catch捕获），实际开发中要注意这点。

内容的提问来源于stack exchange，提问作者user8737957