JWT路由验证中间件Authorization bearer为undefined跳转登录页问题

• 首先检查登录接口逻辑：你当前的/login接口仅在服务端控制台打印生成的JWT，既没有将token返回给调用方，也没有做存储处理，前端/客户端后续发起请求时自然无法携带token，是导致Authorization头为undefined的最常见原因。
• 检查请求发起逻辑：浏览器默认的页面跳转、form表单提交行为不会主动在请求头中添加Authorization字段，只有你手动配置的AJAX/fetch/axios等异步请求，才可以自定义请求头携带token。
• 接口测试场景校验：如果你用Postman、Apifox等工具测试，确认你已经在请求配置的Authorization模块选择Bearer Token类型，并填入了登录接口生成的有效token。
• 增加调试日志：在verifyToken函数首行打印console.log(req.headers)，确认请求全头信息，排查是否头名称拼写错误、或者token放在了其他自定义头字段中。

根据你的业务场景选择对应实现方案：

方案1：前后端分离（接口供前端异步调用） #

第一步：修改登录接口，将生成的token返回给前端

app.post("/login", (req, res) => {
  const password = req.body.password
  const user = { name: password }
  jwt.sign({ user }, "secretkey", (err, token) => {
      if(err) return res.sendStatus(500)
      // 返回token给前端
      res.json({ code: 200, token })
  });
});

第二步：前端拿到token后存储在localStorage/sessionStorage中，后续所有请求手动添加Authorization头

// 前端请求示例
const token = localStorage.getItem('login_token')
fetch('/your-api', {
  headers: {
    'Authorization': `Bearer ${token}`
  }
})

方案2：服务端渲染（登录后直接跳转页面） #

这种场景使用请求头携带token的逻辑不符合浏览器原生行为，改为cookie存储token更合理：
第一步：先安装cookie解析中间件

npm install cookie-parser

第二步：在项目入口注册中间件

const cookieParser = require('cookie-parser')
app.use(cookieParser())

第三步：修改登录接口，登录成功后将token写入cookie

app.post("/login", (req, res) => {
  const password = req.body.password
  const user = { name: password }
  jwt.sign({ user }, "secretkey", (err, token) => {
      if(err) return res.sendStatus(500)
      // httpOnly配置防止前端JS读取token，降低XSS风险
      res.cookie('auth_token', token, { httpOnly: true, maxAge: 24 * 60 * 60 * 1000 })
      // 跳转首页
      res.redirect('/')
  });
});

第四步：修改verifyToken中间件，从cookie中读取token

function verifyToken(req, res, next) {
  const token = req.cookies.auth_token;
  if (typeof token !== "undefined") {
    req.token = token;
    next();
  } else {
    res.redirect("/login");
  }
}

额外注意：你当前首页路由的res.render方法中使用的result变量未定义，需要补充对应逻辑否则接口会抛出500错误。

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