Fix bug in passwordResetLink

[timleslie]

These field names need to correspond to const tokenType = 'passwordReset'; in getPasswordSchemaReset.ts. They aren't meant to be dynamic on the field name.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/keystonejs/keystone-next-docs/6QjhrPC6YGzjCvFtGyEf5X63poRM
✅ Preview: https://keystone-next-docs-git-fix-auth-field-names-keystonejs.vercel.app

[changeset-bot]

🦋 Changeset detected

Latest commit: 54112a6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@keystone-next/auth	Major
@keystone-next/example-auth	Patch
@keystone-next/app-basic	Patch
@keystone-next/example-ecommerce	Patch
@keystone-next/example-roles	Patch
@keystone-next/example-todo	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[JedWatson]

You mean getPasswordSchemaReset.ts

[JedWatson]

So overall I think I'm in favour of this, but I'd like to go more comprehensively in one direction or the other.

These fields were supposed to be variable, because it's a "secret" and may not be called "password".

But can we be consistent? it's configured as a secret field, which is almost always called password, and we're hard-coding password in some places while it's still secret in others. Confusing.

I don't think I'm unhappy with this PR, since among other things it fixes a bug, but I do think I'm unhappy with the overall balance of apparently-configurable vs not-actually-configurable combined with (I think) we use two words for the same thing.

@timleslie if you agree, we should probably backlog another pass to clean this up properly even further, align on one consistent term, and be more opinionated overall in the name of simplicity (tbh at this point I'd go for "password" over "secret", and I think "secret" is a hangover from Keystone 5 when it genuinely was less opinionated)

(to be clear, I'm not suggesting we hard code the two primary fields - currently, identity and secret - they are defined by the list schema and only referred to here, that's fine. but you configure the "secret" field, and then we call it "password" in the context of resetting it, and that's confusing... except that devs using keystone will, if they follow the defaults / examples, see "password" and "passwordReset" columns in their database and that actually does make sense 🤦‍♂️)

[JedWatson]

This isn't a patch; it changes database structure for anyone using auth with a field path other than password for the secret field.

We can decide to ship this as a breaking change, or we can fix the bug in the other direction (by making getPasswordResetSchema.ts generate the field path dynamically based on the secretField config when the tokenType is passwordReset)