fix: enable NEXTAUTH_SECRET by default

[ruhap]

NEXTAUTH_SECRET is not enabled by default but Discord provider keys are. Next-auth needs to have NEXTAUTH_SECRET and its also checked on schema.

Closes #

✅ Checklist

• [x] I have followed every step in the contributing guide (updated 2022-10-06).
• [x] The PR title follows the convention we established conventional-commit
• [ ] I performed a functional test on my final commit

---

Changelog

[Short description of what has changed]

---

Screenshots

[Screenshots]

💯

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: ff2722731a1d863144883af85673da3b3e73d4f2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated
create-t3-app	⬜️ Ignored (Inspect)		Nov 22, 2022 at 0:40AM (UTC)

[ruhap]

This commit would make it more clear that this .env variable needs to be used. Error you get without it:

`[next-auth][error][SIGNIN_OAUTH_ERROR] 
https://next-auth.js.org/errors#signin_oauth_error "ikm" must be at least one byte in length {
  error: {
    message: '"ikm" must be at least one byte in length',
    stack: 'TypeError: "ikm" must be at least one byte in length\n' +`

[c-ehrlich]

This was recently changed in https://github.com/t3-oss/create-t3-app/pull/719

If I understand correctly, the reason was specifically to make it fail - because including an empty key or the same default key in every t3 app are both bad for security.

I would be open to having my mind changed on this, but if we do something it should imo be a default key like changeme.

What does everyone else think?

[AyanavaKarmakar]

I would be open to having my mind changed on this, but if we do something it should imo be a default key like changeme.

IMO, if we set a default value no one will probably bother to change it, since any string works and we will end up with numerous apps using the same secret. Which isn't good since it is used to encrypt the NextAuth.js JWT, and hash email verification tokens.

[juliusmarminge]

I thought if you didn't set one at all (which is the case when it's commented out) that NextAuth would generate one for you by hashing your options?

[c-ehrlich]

I thought if you didn't set one at all (which is the case when it's commented out) that NextAuth would generate one for you by hashing your options?

Yes I think that's right. It does that in dev, and fails in prod, which is good behavior imo (we don't want people to use changeme or whatever as their prod secret).

[nexxeln]

Yeah I like the current implementation as well