如果使用授权承载令牌,则为400错误请求

我正在使用PostMan来解决与我的Angular / NodeJS应用程序奇怪的400错误。

我正在尝试获取https://example.com/login.html ,请求有两个标题:

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...==Accept: text/html

这将返回一个400 Bad Request错误(服务器:cloudflare-nginx)

这工作正常(返回200 ),如果:

  • 我访问我的本地环境中的文件http://localhost:5000/login.html (无https因素?) – 或 –

  • 我从标题中删除Authorization: Bearer

如果我看我的NodeJS服务器日志,我甚至不会看到请求通过。 所以/login.html甚至没有被击中,我假设,因为快递在我的app.use(logger('dev'));之前拒绝它app.use(logger('dev')); 捡起来。

更新:我相信Cloudflare在请求到达Heroku之前就已经开始使用400了。

还有几点:

  • 我正在使用JWT对用户进行身份validation,这是不记名令牌的来源。

  • 如果我访问其他terminal(例如/profile持有人令牌的/profile ,则会通过解码令牌的用户configuration文件正确响应。

我的问题是:

  • 为什么这个请求在其他端点上工作时会成为“错误请求”?

  • 有没有一种方法来捕捉这个问题,并在返回400之前对请求做些什么?

事实certificate,这个问题与我实施JWT有关。 出于某种原因,一个用户继续收到导致这400个错误的令牌,即使使用JWT.io将令牌validation为有效。

我做了两个重大的修改,解决了这个问题:

  1. 我在令牌有效载荷中embedded了完整的用户configuration文件(长JSON)。 我把它缩小到只是他们的用户名,既出于性能方面的原因(更小的尺寸),以及在复杂的有效载荷的东西造成的问题。

  2. 我在我的节点实现中从JWT-Simple切换到jsonwebtoken

我只是很高兴的工作。 我的下一步是从“授权”切换到“x-encoded-auth”或其他一些自定义名称。

@詹姆斯,我没有足够的声望发表评论你的答案,但我认为这将有助于其他人努力解决这个问题,以表明你的build议,以减less签名用户的复杂性/规模确实导致解决类似的问题,我正在经历。 无论如何,这是在我的性能优化列表 – 但我没有想到这可能是在这种情况下的错误的原因 – 所以你值得信贷…谢谢!

对于读者来说,在这个SO线程中有一些关于令牌最大大小的有用链接: 什么是JWT令牌的最大大小?

这是我用来检查生成的令牌的有效性的工具… https://www.base64decode.org/

希望这certificate从评论升级到答案!