docs: expand key rotation example for future

[rarkins]

I'm guessing/hoping that this is how it works, but I figured it was as much effort to prepare a docs PR in case it is than to ask the question. Does this look right??

[vercel]

Someone is attempting to deploy a commit to a Personal Account owned by @vvo on Vercel.

@vvo first needs to authorize it.

[vvo]

It does look right yes on the explanation. I am not even using rotation on my side (BOOO!).

The rotation strategy can also be simplified to:

• if your sessions are 14 days long
• if you change keys every 7 days
• then you only need at most two keys in the array
• and you can always stick to ids 1., 2.

day 0:

1: abc

day 7:

1. def
2. abc

day 14:

1. ghi
2. def

day 21:

1. jkl
2. ghi

What do you think?

[rarkins]

Does a 2 week session mean that you get logged out and see a login screen every 2 weeks, or that you need to access the site at least every two weeks to remain logged in and never see a login screen?

[vvo]

or that you need to access the site at least every two weeks to remain logged in and never see a login screen?

You need to access the site and do an action that itself will resolve to a session.save(). There's no automatic session refresh for reads only.

[rarkins]

While I agree that your approach sounds feasible, it also looks like something you could easily mess up by accident if you were doing it regularly and had a lot of passwords over time..

[wup-one]

It does look right yes on the explanation. I am not even using rotation on my side (BOOO!).

The rotation strategy can also be simplified to:

• if your sessions are 14 days long
• if you change keys every 7 days
• then you only need at most two keys in the array
• and you can always stick to ids 1., 2.

day 0:

1: abc

day 7:

1. def
2. abc

day 14:

1. ghi
2. def

day 21:

1. jkl
2. ghi

What do you think?

Hey @vvo,
Is this example supposed to work, or is it simply a proposal?

Because I've been testing the password rotation functionality, and I completely agree with your example, but it doesn't seem to work that way.

What I've found is that the password number can't change or the unseal fails.

e.g., this unit test passes

test("Password rotation", async () => {
  const firstPassword = { 1: "BcTv8NKLVfGcTt18HqGf2DhEnmJrLbNU" };
  const secondPassword = {
    1: "BcTv8NKLVfGcTt18HqGf2DhEnmJrLbNU",
    2: "scKVNPWFippYjA3tRjJPuPnK7ocj4Vnn",
  };

  const seal = await sealData(
    { user: { id: 30 } },
    { password: firstPassword },
  );

  const session = await getIronSession(
    {
      ...defaultReq,
      headers: { cookie: `test=${seal}` },
    } as IncomingMessage,
    defaultRes,
    { password: secondPassword, cookieName },
  );

  expect(session).toMatchInlineSnapshot(`
    Object {
      "user": Object {
        "id": 30,
      },
    }
  `);
});

but this one fails

test("Password rotation", async () => {
  const firstPassword = { 1: "BcTv8NKLVfGcTt18HqGf2DhEnmJrLbNU" };
  const secondPassword = {
    1: "scKVNPWFippYjA3tRjJPuPnK7ocj4Vnn",
    2: "BcTv8NKLVfGcTt18HqGf2DhEnmJrLbNU",
  };

  const seal = await sealData(
    { user: { id: 30 } },
    { password: firstPassword },
  );

  const session = await getIronSession(
    {
      ...defaultReq,
      headers: { cookie: `test=${seal}` },
    } as IncomingMessage,
    defaultRes,
    { password: secondPassword, cookieName },
  );

  expect(session).toMatchInlineSnapshot(`
    Object {
      "user": Object {
        "id": 30,
      },
    }
  `);
});

Note the subtle difference being the definition of "secondPassword" where the IDs are in the reverse order. When the password used to encrypt is moved to "2", the unseal fails.

[rarkins]

FWIW I would like to try the approach proposed by @vvo, so I'm also interested in seeing if it works as hoped

[ffakira]

Just wanted to see what is the current status progress for this PR? Sorry for sounding naive, but by any chance we have password rotation at iron-session?