* chore(dev): add CognitoProvider to dev app
* feat(log): log `error_description` in OAuth callback
* fix(providers): migrate Cognito to v4
* docs: mention superblog.ai for infra support
* fix: return profile picture for Cognito
* fix(ts): add picture to CognitoProfile
Add some very minimal customization to the built-in pages so people might not immediately need to replace them. This way they can customize some things with their brand color and add their company/project logo. We explicitly **do not** want to go overboard styling this page. This is not an authentication component library or Next.js app template!
Example:
```js
export default NextAuth({
providers: [...],
jwt: {...},
theme: {
colorScheme: 'auto',
brandColor: '#67b246',
logo: 'https://company.com/assets/logo.png'
}
})
```
BREAKING CHANGE:
`staleTime` (previously `clientMaxAge`) has been removed. Check out `refetchInterval` instead. It should cover most of the cases. If not, we can look into adding this back later on.
When using the default settings of the Github provider, with the "user" scope, it grants read/write access to profile info only. By changing to "read:user" and "user:email" it will only request read-only access https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
BREAKING CHANGE:
By default, the GitHub Provider scope won't ask for full write access to user profiles. If you need that, you will now have to add the `user` scope to your configuration.
MS Docs has a lot of local language translations, so it's best to remove locale information from the URLs so that when someone follows them, they land on the right language version of the content.
BREAKING CHANGE:
`prisma-legacy` is now gone. Use `@next-auth/prisma-adapter`. Any features from the old adapter will be migrated over to the new one eventually. This is done so we can require the same default set of options from all the built-in providers, rather than allowing ambiguity on what an official adapter has to support.
The `TypeORM` adapter will probably be the only one migrated as-is, but in the future, we would like to break it down to lighter-weight adapters that only support single databases.
Adapters no longer have to return a `getAdapter()` method, they can return the actual adapter methods instead. All the values previously being provided through the arguments of `getAdapter` will now be available in a more digestible format directly in the concerning methods. This behavior was created so that connections could be handled more efficiently. Our review has shown that currently, the TypeORM adapter is the only one that does not handle connections out-of-the-box, so we are going to look into how we can create a wrapper/util function to make it work in the new version. For all other adapters, this will be a huge gain, as with this new API, methods are actually overrideable without creating a whole new custom adapter! 🥳
Example:
```js
function MySlightlyCustomAdapter(...args) {
const adapter = AdapterFromSomeoneElse(...args)
adapter.someMethodIWantToModify = (...args) => {
// Much better implementation goes here.
}
return adapter
}
```
**The following method names are changing:**
```diff
- getSession
+ getSessionAndUser
```
This method now requires that you return both the user and the session as `{user, session}`. If any of these could not be retrieved, you will have to return `null` instead. (In other words, this must be a transaction.) This requires one less database call, improving the user session retrieval. Any expiry logic included in the Adapter before is now done in the core as well.
```diff
- createVerificationRequest
+ createVerificationToken
```
Better describes the functionality. This method no longer needs to call `provider.sendVerificationRequest`, we are moving this into the core. This responsibility shouldn't have fallen to the adapter in the first place.
`createVerificationToken` will now receive a `VerificationToken` object, which looks like this:
```ts
interface VerificationToken {
identifier: string
expires: Date
token: string
}
```
The token provided is already hashed, so nothing has to be done, simply write it to your database. (Here we lift up the responsibility from the adapter to hash tokens)
```diff
- getVerificationRequest
+ useVerificationToken
```
Better describes the functionality. It now also has the responsibility to delete the used-up token from the database. Most ORMs should support retrieving the value while deleting it at the same time, so it will reduce the number of database calls.
``` diff
- deleteVerificationRequest
```
This method is gone. See `useVerificationToken`.
Most of the method signatures have been changed, have a look at the [TypeScript interface](ba4ec5faa3/types/adapters.d.ts) to get a better picture.
