express-session - 是否可以在节点应用程序运行时更改秘密?

发布于 2025-01-14 09:12:42 字数 785 浏览 3 评论 0原文

通常 secret 是在使用 express-session -

const session = require("express-session")
let RedisStore = require("connect-redis")(session)
const { createClient } = require("redis")
let redisClient = createClient({ legacyMode: true })
redisClient.connect().catch(console.error)
app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    saveUninitialized: false,
    secret: "keyboard cat",
    resave: false,
  })
)

显然我可以通过编辑源代码和 <一个href="https://nodejs.dev/learn/run-nodejs-scripts-from-the-command-line" rel="nofollow noreferrer">重新启动节点脚本。可以在应用程序仍在运行时更改它吗?

Usually the secret is hard-coded in node apps which use express-session, for example -

const session = require("express-session")
let RedisStore = require("connect-redis")(session)
const { createClient } = require("redis")
let redisClient = createClient({ legacyMode: true })
redisClient.connect().catch(console.error)
app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    saveUninitialized: false,
    secret: "keyboard cat",
    resave: false,
  })
)

Obviously I can change this secret keyboard cat by editing the source and restarting the node script. It is possible to change it while the app is still running?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

Smile简单爱 2025-01-21 09:12:43

根据此处的指南,可以通过传递一组秘密而不是单个秘密,然后您可以 secrets.unshift(newSecret) 将新秘密放入数组中的第一个位置,同时继续接受已使用数组中其他秘密的 cookie。

因此,在您的代码中,您可以执行以下操作:

const session = require("express-session");

let RedisStore = require("connect-redis")(session);
const { createClient } = require("redis");
let redisClient = createClient({ legacyMode: true });
redisClient.connect().catch(console.error);

const secrets = ["keyboard cat"];

app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    saveUninitialized: false,
    secret: secrets,
    resave: false,
  })
);

然后,稍后在代码中,您可以像这样更新当前使用的秘密:

secrets.unshift("my new secret");

会话中间件将始终在新会话的数组开头使用该秘密,但会继续接受使用数组中其他机密的 cookie。

我的动机是我将大部分代码放在 github 上,并且我不喜欢硬编码任何密码或秘密。

如果这是您的动机,那么通常,您会将会话作为某些配置/部署文件的秘密部分,该文件不会签入 github 并单独管理。这与您放置服务器所需的数据库密码和其他凭据的配置文件类型相同。这样,当您的服务器启动时,它会从未存储在 github 中的本地配置文件获取所需的凭据/秘密。

然后,您也不必尝试动态更改正在运行的会话中间件机密。


既然您提到了 Heroku,下面是 Heroku 提到的用于管理配置变量的技术:

https:// devcenter.heroku.com/articles/config-vars

Per the guidelines here, the session secret can be changed by passing an array of secrets instead of the single secret and you can then secrets.unshift(newSecret) a new secret into the first spot in the array while continuing to accept cookies that have used the other secrets in the array.

So, in your code, you would do this:

const session = require("express-session");

let RedisStore = require("connect-redis")(session);
const { createClient } = require("redis");
let redisClient = createClient({ legacyMode: true });
redisClient.connect().catch(console.error);

const secrets = ["keyboard cat"];

app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    saveUninitialized: false,
    secret: secrets,
    resave: false,
  })
);

Then, sometime later in your code, you can update the current secret being used like this:

secrets.unshift("my new secret");

The session middleware will always use the secret at the start of the array for new sessions, but will continue to accept cookies that use the other secrets in the array.

My motivation is that I put most of my code on github and I prefer not to hard-code any passwords or secrets.

If this is your motivation, then usually, you make the session secret part of some configuration/deployment file that is NOT checked into github and is managed separately. This is the same type of config file you would put database passwords and other credentials needed for your server. That way, when your server starts up, it gets the credentials/secrets it needs from a local configuration file that is not stored in github.

Then, you also don't have to try to change a running session middleware secret on the fly either.


Now that you mention Heroku, here are the techniques that Heroku mentions for managing configuration variables:

https://devcenter.heroku.com/articles/config-vars

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文