还原req.user后为何调用passport.deserializeUser? [英] Why is passport.deserializeUser called after req.user has been restored?

查看:43
本文介绍了还原req.user后为何调用passport.deserializeUser?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据关于会话的护照文档

...仅将用户ID序列化到会话,保持数量会话内存储的数据量很小.当后续请求是收到后,此ID用于查找用户,该用户将被还原到要求用户.

...only the user ID is serialized to the session, keeping the amount of data stored within the session small. When subsequent requests are received, this ID is used to find the user, which will be restored to req.user.

但是我的测试SPA 基于<一个href ="https://github.com/passport/express-4.x-local-example/blob/master/server.js" rel ="nofollow noreferrer">基于护照表单的身份验证示例,其中包含添加的调试消息表明 req.user 在触发 app.get 路由处理程序之前已经恢复.

However my test SPA which is based on Passport form-based authentication sample with debug messages added indicates req.user has already been restored before the app.get route handler is triggered.

这是HTTP POST的输出,其中用户名和通行证字段为空-

Here is the output from an HTTP POST where the username and passport fields are empty -

[nodemon] starting `node app.js`
agenda-spa app listening at http://localhost:3000
handling request for:  / POST
handling request for:  / GET
xxx get root
xxx req.user  undefined
handling request for:  /style.css GET

req.user 未按预期定义

这是HTTP POST的输出,其中包含经过验证的用户名和密码

Here is the output from an HTTP POST with an authenticated username and password

handling request for:  / POST
xxx passport.use  sss
xxx findByUsername sss
xxx password match
xxx serializeUser { id: 1, username: 'sss', password: 'sss' }
xxx auth success
xxx deserializeUser 1
xxx findById 1
handling request for:  / GET
xxx get root
xxx req.user  { id: 1, username: 'sss', password: 'sss' }
xxx deserializeUser 1
xxx findById 1
handling request for:  /style.css GET

我希望它是-

...
xxx deserializeUser 1
xxx findById 1
xxx req.user  { id: 1, username: 'sss', password: 'sss' }
...

为什么在 req.user 恢复后调用 passport.deserializeUser ?

推荐答案

首先,在我的情况下,我得到:

First, in my case I get:

xxx passport.use  sss
xxx findByUsername sss
xxx password match
xxx serializeUser { id: 1, username: 'sss', password: 'sss' }
xxx auth success
xxx deserializeUser 1
xxx findById 1
handling request for:  / GET
xxx get root
xxx req.user  { id: 1, username: 'sss', password: 'sss' }

要重现该问题,我运行以下脚本:

To reproduce the issue I run the following script:

#!/usr/bin/env bash
set -eu
rm cookies.txt || true
args=(
-sSv -b cookies.txt -c cookies.txt
)
curl "${args[@]}" -d 'username=sss&password=sss' localhost:3000
curl "${args[@]}" localhost:3000

让我们添加一些调试信息以了解请求从何处开始

Let's add some debugging information to understand where requests start:

$ DEBUG=* node app.js
...
  express:router dispatching POST / +10s
  express:router session  : / +1ms
  express-session no SID sent, generating session +1ms
  express:router initialize  : / +3ms
  express:router authenticate  : / +1ms
  express:router <anonymous>  : / +0ms
handling request for:  / POST
xxx passport.use  sss
xxx findByUsername sss
xxx password match
xxx serializeUser { id: 1, username: 'sss', password: 'sss' }
xxx auth success
  express-session saving y4TUFn7tzccSARC7kHiDbuKY8qXj1sCU +13ms
  express-session split response +1ms
  express-session set-cookie connect.sid=s%3Ay4TUFn7tzccSARC7kHiDbuKY8qXj1sCU.yxt3TbHx4HSzm03JMrtPcTPrm3K40FbHiuS6NGT%2Fd7E; Path=/; HttpOnly +3ms
...
  express:router dispatching GET / +14ms
  body-parser:urlencoded skip empty body +0ms
  express:router session  : / +0ms
  express-session fetching y4TUFn7tzccSARC7kHiDbuKY8qXj1sCU +1ms
  express-session session found +1ms
  express:router initialize  : / +1ms
  express:router authenticate  : / +0ms
xxx deserializeUser 1
xxx findById 1
  express:router <anonymous>  : / +1ms
handling request for:  / GET
xxx get root
xxx req.user  { id: 1, username: 'sss', password: 'sss' }
...

因此,您的情况下第二个请求的输出是:

As such what is output for the second request in your case is:

xxx deserializeUser 1
xxx findById 1
handling request for:  / GET
xxx get root
xxx req.user  { id: 1, username: 'sss', password: 'sss' }
xxx deserializeUser 1
xxx findById 1

所以它符合您的预期,但是由于某种原因,会话策略被触发了两次.我无法复制.

So it's as you expected, but for some reason the session strategy is triggered twice. That I can't reproduce.

这篇关于还原req.user后为何调用passport.deserializeUser?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆