* fix(core\pages\signin.tsx): set type of built-in email sign-in input to email for browse validation
* fix(core\pages\signin.tsx): add required attribute to built-in sign-in email input
Co-authored-by: Lluis Agusti <hi@llu.lu>
* docs: Update JWT docs to reflect JWE changes in v4
This PR https://github.com/nextauthjs/next-auth/pull/3039 changed the defaults for JWT tokens to be encrypted by default (JWE). We have conflicting documentation across the docs site and readme.
Additionatlly this PR https://github.com/nextauthjs/next-auth/pull/3783 made providing a secret required in production via NEXTAUTH_SECRET or an option.
* Missed a reference
* Update docs/docs/faq.md
Co-authored-by: Nico Domino <yo@ndo.dev>
* Update docs/docs/faq.md
Co-authored-by: Nico Domino <yo@ndo.dev>
Co-authored-by: Nico Domino <yo@ndo.dev>
* docs: fix Custom Client Session Handling example
It made reference to a useEffect call that was no longer needed.
* Update docs/docs/getting-started/client.md
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Lluis Agusti <hi@llu.lu>
* chore(docs): add carbon ads to docs page
* fix: add carbon-wrap element
* fix: script in docusaurus config object
* fix: add _carbonads_js id
* fix: add script directly to sidebar
* fix: carbon ads style
* chore: bump ad container down a bit
BREAKING CHANGE
From now on, you will need a minimum version of `@upstash/redis@v1` installed if you want to use this adapter.
You can upgrade by running `npm i @upstash/redis@latest` or `yarn add @upstash/redis@latest`
Until we migrate to v1 there might be people installing the latest
version of @upstash/redis and then encountering errors.
With this they will at least get a warning.
This is obsolete and should be updated once
https://github.com/nextauthjs/next-auth/issues/4183 is resolved.
Co-authored-by: Balázs Orbán <info@balazsorban.com>
I saw in the documentation that v4 now uses
session: {
strategy: "jwt"
},
instead of
session: {
jwt: true
},
also there was double ;; at the end of the return statement, fixing it
* added saml-jackson provider
* incorporated code review changes
* fixed SAMLJacksonProfile type
* trying to adjust code for monorepo
* cleanup from merge with main
* updated docs link
* added example
* consistent naming
* Incorporated code review changes:
- env var default values moved to env.local.example
- consistent naming and use of id
* email is guaranteed to be present
This field is already nullable in the database, so this should only
affect types.
Because the type is being widened, not narrowed, this should also be
fully backwards-compatible, since pre-existing custom entities of type
`string` will be substitutable for the new default type of `string |
null`.
See #4055 for more specifics on the impact.
* chore: separate build commands for core and app
* Move emitDeclarationOnly to next-auth
* Update release.yml
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* refactor(dev): moved dev app
* chore(dev): fix dev app
* fix(providers): WorkOS to TS, use `client_secret_post`
* chore: decrease test concurrency
* chore: remove org
* chore: run tests sequentially
* feat(providers): use `picture` in WorkOS if available
* fix labeler
* try fixing test runs in GitHub Actions
* pass flags to test command
* test version pr
* move versoin-pr action
* remove --dry-run flag
* re-enable testing, re-add semantic release for now
* add docs
* use `yarn.lock` and different docs port
* simplify dev app config
* fix coverage report
* fix provider source links
* fix more links
* fix(providers): properly warn when using Twitter OAuth 2
* refactor(providers): move Twitter OAuth2 warning to `assert`
* fix: use proper warning code
* refactor: only set boolean
* Fix: Add OpenID to authorization scope
* Fix: Check for valid profile picture response before converting to base64
* Update src/providers/azure-ad.ts
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Confirm that profile photo was returned
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* feat(providers): add support to Twitter OAuth 2.0
* docs: add docs comment
* chore: cleanup
* chore: remove comments
* chore: give warning for OAuth 2 for now
* Added patreon provider - tested and working
* Update src/providers/patreon.js
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Update src/providers/patreon.js
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Update src/providers/patreon.js
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Update src/providers/patreon.js
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Switched to TS, restore .env.local, restore package.json as per comments on the PR
* chore: ran Prettier
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* fix: add eslintIgnore in package.json
* Let eslint runs in app, config + js files
* Add a separate tsconfig.eslint.json file
We want to run the lint command on `app`, `src` and `config`, but at the same time want `tsc` to compile files in `src` only. A separate `tsconfig.eslint.json` is a suitable solution to satisfy both `eslint` and `tsc`: 04d1f3e549/packages/parser/README.md
* Update client.ts
Set custom.setHttpOptionsDefaults before Issuer.discover(.wellKnown). This allow discover the .wellKnown endpoint behind a proxy
* chore: address code review
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Update strava.js
Auth with Strava was throwing errors before, this works.
* Update strava.js
changed according to commenters' suggestions
* chore: run linter
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Ensure that GitHub provider always gives an email
* Update src/providers/github.js
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* fix(provider): correct authorization for Atlassian
* feat(providers): use wellKnown for better configuration
* fix(atlassian): switch back to raw config
* fix(providers): pass generic to `OAuthUserConfig`
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* refactor EVEOnlineProvider into typescript, fix default scopes
* Update src/providers/eveonline.ts
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* update to new OIDC SSO endpoints
* set idToken: true
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Added support for zoom in beta
* Converted to typescript
* rename
* Now reflects response from Zoom
* chore: Prettier
Co-authored-by: Balázs Orbán <info@balazsorban.com>
If the expected cookie size would exceed the 4096 bytes most browsers allow, we split up the cookie value and put the content into multiple cookies, then assemble it upon reading it back. This eliminates the need for a database or user-land solutions in case the user wants to save more data or is constrained by their IdP for certain fields.
With no scope defined, it sets `openid` by default, which is an invalid 42 scope.
Co-authored-by: Alaa Zorkane <alaazorkane@gmail.com>
Co-authored-by: Alaa Zorkane <alaazorkane@gmail.com>
BREAKING CHANGE:
The `session.jwt: boolean` option has been renamed to `session.strategy: "jwt" | "database"`. The goal is to make the user's options more intuitive:
1. No adapter, `strategy: "jwt"`: This is the default. The session is saved in a cookie and never persisted anywhere.
2. With Adapter, `strategy: "database"`: If an Adapter is defined, this will be the implicit setting. No user config is needed.
3. With Adapter, `strategy: "jwt"`: The user can explicitly instruct `next-auth` to use JWT even if a database is available. This can result in faster lookups in compromise of lowered security. Read more about: https://next-auth.js.org/faq#json-web-tokens
Example:
```diff
session: {
- jwt: true,
+ strategy: "jwt",
}
```
* feat(react): preserve history on client-side navigation
* chore(deps): upgrade jest
* test(client): use absolute URL since `whatwg-*` refusing relative URLs
Updates the `jose` and `openid-client` packages.
BREAKING CHANGE:
The `jwt` option has been simplified and the NextAuth.js issued JWT is now encrypted by default.
If you want to override the defaults, you can still use the `encode` and `decode` functions. These are advanced options and they should only be used if you know what you are doing.
The default secret generation has been removed in this PR, which will be added back in a separate one. Remember, that is only for developer convenience, it is **highly** recommended to always create your own secret for production.
Spreading the object into the input tag allows developers to specify any attribute for the input tag used in the builtin sign-in page, such as 'autocomplete', 'autofocus', etc.
Removed the hardcoded attributes which just set the defaults of the 'input' tag and won't cause any behavior change in case they are absence from the object.
Signed-off-by: Gegham Zakaryan <zakaryan.2004@outlook.com>
* 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.
Adds a new way to import providers for modularity and better tree-shaking.
BREAKING CHANGE:
Providers now have to be imported one-by-one:
Example:
```diff
- import Provider from "next-auth/providers"
- Providers.Auth0({...})
+ import Auth0Provider from "next-auth/providers/auth0"
+ Auth0Provider({...})
```
> This touches on all OAuth providers, so there is a big potential for breaking by default. We have let new providers be added for contributors' specific needs, but from now on, we will require a more strict default on all new providers, so the basic behavior is predictable for everyone.
⚠ Unfortunately, we will not have the capacity to test each and every provider that has been added to the default providers, but we will do our best to test the most popular ones. (@ndom91 has worked on setting up the infrastructure for this). If you wish to make sure that the provider you are using will stay working, please reach out with your concerns and tell us how can you help us test that particular provider in the future. 🙏
That said, I will try my best to not break ANY of the currently built-in providers, or at least make the migration super easy. So hopefully, you won't have to change anything. It will most probably affect you if you defined a custom provider though.
We will monitor the default configuration much more closely, so the behavior will be more consistent across providers by default.
Closes#1846, Closes#1605, Closes#1607
BREAKING CHANGES:
Basecamp provider is removed. See the explanation [here](https://github.com/basecamp/api/blob/master/sections/authentication.md#on-authenticating-users-via-oauth)
**ALL** OAuth providers' `profile` callback is expected to only return these fields by default from now on: `id`, `name`, `email`, and `image` at most. Any of these missing values should be set to `null`.
The following new options are available:
1. `authorization` (replaces `authorizationUrl`, `authorizationParams`, `scope`)
2. `token` replaces (`accessTokenUrl`, `headers`, `params`)
3. `userinfo` (replaces `profileUrl`)
These three options map nicely to the OAuth spec's three endpoints for
1. initiating the login flow
2. retrieve OAuth tokens
3. retrieve user information
They all take the form of `EndpointHandler`:
```ts
type EndpointRequest<C, R> = (
context: C & {
/** `openid-client` Client */
client: Client
/** Provider is passed for convenience, ans also contains the `callbackUrl`. */
provider: OAuthConfig & {
signinUrl: string
callbackUrl: string
}
}
) => Awaitable<R>
/** Gives granular control of the request to the given endpoint */
type AdvancedEndpointHandler<P extends UrlParams, C, R> = {
/** Endpoint URL. Can contain parameters. Optionally, you can use `params`*/
url?: string
/** These will be prepended to the `url` */
params?: P
/**
* Control the corresponding OAuth endpoint request completely.
* Useful if your provider relies on some custom behavior
* or it diverges from the OAuth spec.
*
* - ⚠ **This is an advanced option.**
* You should **try to avoid using advanced options** unless you are very comfortable using them.
*/
request?: EndpointRequest<C, R>
}
/** Either an URL (containing all the parameters) or an object with more granular control. */
type EndpointHandler<P extends UrlParams, C = any, R = any> =
| string
| AdvancedEndpointHandler<P, C, R>
```
In case of `authorization`, the `EndpointHandler` can define the `params` as [`AuthorizationParameters`](51dc47d9ac/types/index.d.ts (L108-L143))
> Note: `authorization` does not implement `request` yet. We will have to see if there is demand for it.
From now on, instead of using the `...` spread operator when adding a new built-in provider, the user is expected to add `options` as a property at the end of the default config. This way, we can deep merge the user config with the default one. This is needed to let the user do something like this:
```js
MyProvider({
clientId: "",
clientSecret: "",
authorization: { params: {scope: ""} }
})
```
So even if the default config defines anything in `authorization`, only the user-defined parts will be overridden.
* chore(deps): add openid-client
* chore: merge in next
* refactor(provider): remove redundant requestUrl param
* feat(provider): make profile callback optional
* refactor: use openid-client for OAuth2/OIDC
* refactor: use openidClient in oauth signin handler
* refactor: use openidClient in oauth callback handler
* docs(warn): add async issuer/old config warnings
* chore(deps): remove jsonwebtoken
* chore: add issuer property for testing locally
* chore(dev): import providers one-by-one
* fix(oauth): handle when no user in body/query
* chore(deps): remove pkce-challenge
* chore(dev): change Auth0 protection
* refactor(oauth): simplify pkce/state
* refactor: split OAuth1 client, reduce openid client
will improve API in another PR
* chore: change comment, dev app
* chore: mention OIDC client config discovery
* fix: add new operator when creating OIDC client
* refactor: delete req.query.nextauth after use
* docs(ts): use `TokenSet` from `openid-client`
* chore: simplify/type signin route
* refactor: rename to client-legacy to indicate intnet of maintenance
* chore(deps): try setting `oauth` as optional peer dep
* chore(deps): add `oauth` back as regular dependency
* chore(deps): add @types/oauth as dev dependency
* chore: remove params kept for backwards compatibility
* chore: don't make breaking changes in this PR
* chore(core): use correct TS declarations
* refactor: move files/add more accurate types internally
* chore: remove TODO comment
* chore: catch all errors in authorization URL generation
* docs(readme): add opencollective details to readme
* docs(www): add sponsors to docs footer
* docs(readme): move support under ack
* docs(www): dropped docusaurus link in footer
* Update Fauna Adapter
- added one-liner to explain how to use the setup scripts inside of the Fauna dashboard
- updated the `verification_request_by_token` index name to match what is expected inside of the SDK which is `verification_request_by_token_and_identifier`
* Update Typo
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Unified API for all of our user-facing methods.
NOTE: `events.error` has been removed. This method has never been called in the core, so it did actually nothing. If you want to log errors to a third-party, check out the [`logger`](https://next-auth.js.org/configuration/options#logger) option instead.
BREAKING CHANGE:
Two event signatures changed to use named params, `signOut` and `updateUser`:
```diff
// [...nextauth].js
...
events: {
- signOut(tokenOrSession),
+ signOut({ token, session }), // token if using JWT, session if DB persisted sessions.
- updateUser(user)
+ updateUser({ user })
}
```
Similar to #2342, this aims to unify the user-facing API and provide an easier way to extend in the future.
In addition, this PR also solves the problem when the `logger.error` method sometimes did not print results, because `Error` instances are not serializable and will be printed as empty objects `"{}"`.
After this PR, we make any `Error` instances serializable as described here: https://iaincollins.medium.com/error-handling-in-javascript-a6172ccdf9afCloses#1602
Achieved by adding a `client: true` flag when logs are coming from the frontend.
BREAKING CHANGE:
The main change is that instead of an unknown number of parameters, the log events have at most two, where the second parameter is usually an object. In the case of the `error` event, it can also be an `Error` instance (that is serializable by `JSON.stringify`). If it is an object, an `Error` instance will be available on `metadata.error`, and `message` will default to `metadata.error.message`. This is done so that an error event always provides some kind of a stack to see where the error happened
```diff
// [...nextauth.js]
import log from "some-logger-service"
...
logger: {
- error(code, ...message) {},
+ error(code, metadata) {},
- warn(code, ...message) {},
+ warn(code) {}
- debug(code, ...message) {}
+ debug(code, metadata) {}
}
```
This change aligns the API with `openid-client`'s `checks` https://github.com/panva/node-openid-client/blob/main/docs/README.md#clientcallbackredirecturi-parameters-checks-extras, a library which we intend to migrate to in the future. Aligning our API early, so people get used to it.
Also, objectively the name `protection` might not have been as clear as I first thought. `checks` better describe the intention.
BREAKING CHANGE:
The `state` option on OAuth providers is now deprecated. Use `checks: ["state"]` instead.
`protections` is renamed to `checks`, here is an example:
```diff
- protection: ["pkce"]
+ checks: ["pkece"]
```
Furthermore, string values are not supported anymore. This is to be able to handle fewer cases internally.
```diff
- checks: "state"
+ checks: ["state"]
```
A living session could be a requirement for specific pages (like dashboards). If it doesn’t exist, the user should be redirected to a page asking them to sign in again.
Sometimes, a user might log out by accident, or by deleting cookies on purpose. If that happens (e.g. on a separate tab), then `useSession({ required: true })` should detect the absence of a session cookie and always return a non-nullable Session object type.
When `required: true` is set, the default behavior will be to redirect the user to the sign-in page. This can be overridden by an `action()` callback:
```js
const session = useSession({
required: true,
action() {
// ....
}
})
if (session.status === "Loading") return "Loading or not authenticated..."
// session.data is always defined here.
```
Co-authored-by: Kristóf Poduszló <kripod@protonmail.com>
Co-authored-by: Lluis Agusti <hi@llu.lu>
BREAKING CHANGE:
The `useSession` hook now returns an object. Here is how to accommodate for this change:
```diff
- const [ session, loading ] = useSession()
+ const { data: session, status } = useSession()
+ const loading = status === "loading"
```
With the new `status` option, you can test states much more clearly.
* (docs) initial issue template forms as per #2271
* (typo) fix grammar and typo
* (forms) make the requested changes
* (chore) delete the old .md files
* (forms) fix type key
Some of our user-facing callbacks come with a bunch of parameters, and it is not always the case that a user needs all of them. Picking out certain parameters from the end of the list would require the user to define params that they wouldn't even need.
Therefore this PR changes such callbacks so the user can only pick the necessary parameters.
This comes with the bonus of better TS support on the `session` and `signIn` callbacks, where some parameters historically could have been different types.
In the `session` callback, the second param could have been `token` (when using JWT sessions) or `user` (when using DB persisted sessions). Now they are separate parameters.
In the `signIn` callback, we now separate `profile` (OAuth), `email` (Email) and `credentials` (Credentials) provider params.
BREAKING CHANGE:
The `callbacks` method signatures are changing the following way:
```diff
- signIn(user, account, profileOrEmailOrCredentials)
+ signIn({ user, account, profile, email, credentials })
```
```diff
- redirect(url, baseUrl)
+ redirect({ url, baseUrl })
```
```diff
- session(session, tokenOrUser)
+ session({ session, token, user })
```
```diff
- jwt(token, user, account, OAuthProfile, isNewUser)
+ jwt({ token, user, account, profile, isNewUser })
```
> NOTE: You only need to define the params that you actually need (no more need for `_` params.)
This way, if you only need `token` and `account` in the `jwt` callback, you can write:
```js
jwt({ token, account }) {
if(account) {
token.accessToken = account.access_token
}
return token
}
```
Node 10 has reached end-of-life, Next.js stopped supporting it in Next 11. Since we are a Next.js library, it doesn't make sense for us to support anything lower than that either.
I also upgraded a bunch of dependencies and dropped some that weren't necessary anymore.
BREAKING CHANGE:
The lowest supported Node version is 12. (We still support IE11 in browsers, until that is not dropped by Next.js itself)
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Add useState dependency
I went to execute the signin.js file and received an error that useState was undefined. Was able to reconcile this by adding the dependency.
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Sangwon Park <dev.psw@gmail.com>
* fix(docs): scope expects space separated string
Currently the docs list string[] as possible type for scope.
However, It only accepts a string (with space as separator).
Co-authored-by: Balázs Orbán <info@balazsorban.com>
commit 665445818e
Author: Balázs Orbán <info@balazsorban.com>
Date: Sat Jun 12 17:11:53 2021 +0200
docs(config): link to next documentation instead of canary
commit 67cf2a11bb
Author: ndom91 <yo@ndo.dev>
Date: Sat Jun 12 16:42:48 2021 +0200
docs: fix alt client provider example
**What**:
These changes ensure that we work more tightly with React that can also result in unforeseen performance boosts. In case we would decide on expanding to other libraries/frameworks, a new file per framework could be added.
**Why**:
Some performance issues (https://github.com/nextauthjs/next-auth/issues/844) could only be fixed by moving more of the client code into the `Provider`.
**How**:
Refactoring `next-auth/client`
Related: #1461, #1084, #1462
BREAKING CHANGE:
**1.** `next-auth/client` is renamed to `next-auth/react`.
**2.** In the past, we exposed most of the functions with different names for convenience. To simplify our source code, the new React specific client code exports only the following functions, listed with the necessary changes:
- `setOptions`: Not exposed anymore, use `SessionProvider` props
- `options`: Not exposed anymore, use `SessionProvider` props
- `session`: Rename to `getSession`
- `providers`: Rename to `getProviders`
- `csrfToken`: Rename to `getCsrfToken`
- `signin`: Rename to `signIn`
- `signout`: Rename to `signOut`
- `Provider`: Rename to `SessionProvider`
**3.** `Provider` changes.
- `Provider` is renamed to `SessionProvider`
- The `options` prop is now flattened as the props of `SessionProvider`.
- `clientMaxAge` has been renamed to `staleTime`.
- `keepAlive` has been renamed to `refetchInterval`.
An example of the changes:
```diff
- <Provider options={{clientMaxAge: 0, keepAlive: 0}}>{children}</Provider>
+ <SessionProvider staleTime={0} refetchInterval={0}>{children}</SessionProvider>
```
**4.** It is now **required** to wrap the part of your application that uses `useSession` into a `SessionProvider`.
Usually, the best place for this is in your `pages/_app.jsx` file:
```jsx
import { SessionProvider } from "next-auth/react"
export default function App({
Component,
pageProps: { session, ...pageProps }
}) {
return (
// `session` comes from `getServerSideProps` or `getInitialProps`.
// Avoids flickering/session loading on first load.
<SessionProvider session={session}>
<Component {...pageProps} />
</SessionProvider>
)
}
```
* feat(adapter): remove built-in adapters and database
BREAKING CHANGE:
From now on, you will have to import your own adapter
Check out https://github.com/nextauthjs/adapters
The migration is super easy and has HUGE advantages for those not using TypeORM.
```diff
// [...nextauth].js
+ import TypeORMAdapter from "@next-auth/typeorm-legacy-adapter"
import NextAuth from "next-auth"
...
export default NextAuth({
- database: "yourconnectionstring",
+ adapter: TypeORMAdapter("yourconnectionstring")
})
```
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Giovanni Carnel <479046+g10@users.noreply.github.com>
Contains the following squashed commits:
* chore(lint): run prettier on pre-commit
* chore(lint): format files on pre-commit
* chore(npm): update lock file
* docs(adapters): reorganise adapter docs for new pkg
* docs(adapters): fix link typos
* docs(adapters): add vercel.json redirects for new adapters URLs
I'm not sure when this changed, but it's no longer true. If the person logging in doesn't have a stored user account, the ID will be the provider_account_id
* docs: explain where pageProps come from in Provider docs
* chore: formatting
* docs(getting-started): add alternative client session handling methods
* docs(getting-started): update alternative client api docs
* Constrain the adapters type generics more accurately
* Add types for the incoming messages to events callbacks
* Code review comments from @lluia
* Rebase from trunk and fix merge conflicts
* Update documentation
* Rip out generics
* fix(build): export aliases from client (#1909)
* docs(provider): update providers documentation (#1900)
* docs(providers): update providers documentation
- delineate clearly the 3 provider types (oauth, email, credentials)
- make each section structure consistent
- update the option list for every provider type
- use emojis
* docs(providers): instructions on new provider types
* docs(providers): remove emojis
To stay consistent with the rest of our documentation, for now we should not emojis on the sections of our documentation pages.
* docs(providers): reword sentence
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* docs(providers): add tip on overriding options
* docs(providers): clarify `params` option usage
* docs(providers): make names list inline
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* fix(ts): unset generics defaults for overriding (#1891)
Co-authored-by: Lluis Agusti <hi@llu.lu>
* fix(ts): tweak Adapter related types (#1914)
Contains the following squashed commits:
* fix(ts): make first adapter parameter non-optional
* fix(ts): make defaulted values non-optional internally
* test(ts): fix linting
* fix(page): don't pass params to custom signout page (#1912)
* For the custom signout page addressed two issues with the query params being added to the signout url. A conditional check on the error value is now made before adding it as a query param. Also added a conditional check on the callbackUrl and if present that then gets appended as a query param to the signout api call.
* Changed fix for bug #192 to have no querystring params in the custom signout page url.
Co-authored-by: anubisoft <anubisoftprez@gmail.com>
Co-authored-by: Lluis Agusti <hi@llu.lu>
* docs(www): fix typo (#1922)
* docs(provider): Update IdentityServer 4 demo configuration (#1932)
* Responding to code review comments
* Fix tests
* Fix lint error
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Kristóf Poduszló <kripod@protonmail.com>
Co-authored-by: Anubisoft <1471887+anubisoft@users.noreply.github.com>
Co-authored-by: anubisoft <anubisoftprez@gmail.com>
Co-authored-by: Ernie Miranda <emiranda04@users.noreply.github.com>
Co-authored-by: Mathis Møller <thisen-dk@hotmail.com>
* For the custom signout page addressed two issues with the query params being added to the signout url. A conditional check on the error value is now made before adding it as a query param. Also added a conditional check on the callbackUrl and if present that then gets appended as a query param to the signout api call.
* Changed fix for bug #192 to have no querystring params in the custom signout page url.
Co-authored-by: anubisoft <anubisoftprez@gmail.com>
Co-authored-by: Lluis Agusti <hi@llu.lu>
Contains the following squashed commits:
* fix(ts): make first adapter parameter non-optional
* fix(ts): make defaulted values non-optional internally
* test(ts): fix linting
* docs(providers): update providers documentation
- delineate clearly the 3 provider types (oauth, email, credentials)
- make each section structure consistent
- update the option list for every provider type
- use emojis
* docs(providers): instructions on new provider types
* docs(providers): remove emojis
To stay consistent with the rest of our documentation, for now we should not emojis on the sections of our documentation pages.
* docs(providers): reword sentence
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* docs(providers): add tip on overriding options
* docs(providers): clarify `params` option usage
* docs(providers): make names list inline
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* chore(github): fix typos on issue templates...
* chore(github): use statements rather than comments
on the PR template
* chore(github): Typescript -> TypeScript
* chore(github): add links to Codesanbox on issue templates
* Apply suggestions from code review
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* feat(build): optionally include TypeORM
If the user doesn't use databases,
it shouldn't be necessary to iclude it in the bundle.
This can more than half the package size!
* feat(build): clean up in dependencies
Remove unused dependencies, move optional ones to be optional
* feat(build): add exports field
* fix: use peerDependenciesMeta instead of non-standard peerOptionalDependecns field
* fix: ts-standard string quotes
* fix: ts-standard string quotes
* refactor: use asnyc/await for sendVerificationRequest
* chore(deps): upgrade mongodb, remove require_optional
Co-authored-by: ndom91 <yo@ndo.dev>
BREAKING CHANGE:
`typeorm`, and `nodemailer` are no longer dependencies added by default.
If you need any of them, you will have to install them yourself in your project directory.
TypeOrm is the default adapter, so if you only provide an `adapter` configuration or a `database`, you will need `typeorm`. You could also check out `@next-auth/typeorm-adapter`. In case you are using the Email provider, you will have to install `nodemailer` (or you can use the choice of your library in the `sendVerificationRequest` callback to send out the e-mail.)
BREAKING CHANGE: adding `state: true` is already redundant
as `protection: "state` is the default value. `state: false`
can be substituted with `protection: "state"`
BREAKING CHANGE: We have supported throwing strings
for redirections, while we were showing a waring.
From now on, it is not possible. The user MUST return a string,
rather than throw it.
2021-02-15 21:47:35 +01:00
857 changed files with 56943 additions and 53946 deletions
Thanks for taking the time to fill out this issue after reading/searching through the [documentation](https://next-auth.js.org) first!
Is this your first time contributing? Check out this video: https://www.youtube.com/watch?v=cuoNzXFLitc
### Important :exclamation:
_Providing incorrect/insufficient information or skipping steps to reproduce the issue may result in closing the issue or converting to a discussion without further explanation._
If you have a generic question specific to your project, it is best asked in Discussions under the [Questions category](https://github.com/nextauthjs/next-auth/discussions/new?category=Questions)
# Let's wait with this until adoption in other frameworks.
# - type: dropdown
# attributes:
# label: Framework
# description: Which framework(s) is this issue related to?
# multiple: true
# options:
# - "Next.js"
# - "Other"
- type:textarea
attributes:
label:Environment
description:|
Run this command in your project's root folder and paste the result:
Alternatively, you can manually gather the version information from your package.json for these packages: "next", "react" and "next-auth". Please also mention your OS and Node.js version, as well as the browser you are using.
validations:
required:true
- type:input
attributes:
label:Reproduction URL
description:A URL to a repository/code that clearly reproduces your issue. You can use our [`next-auth-example`](https://github.com/nextauthjs/next-auth-example) template repository to get started more easily, or link to your project if it's public
validations:
required:true
- type:textarea
attributes:
label:Describe the issue
description:Describe us what the issue is and what have you tried so far to fix it. Add any extra useful information in this section. Feel free to use screenshots (but prefer [code blocks](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#syntax-highlighting) over a picture of your code) or a video explanation.
validations:
required:true
- type:textarea
attributes:
label:How to reproduce
description:Explain with clear steps how to reproduce the issue
validations:
required:true
- type:textarea
attributes:
label:Expected behavior
description:Explain what should have happened instead of what actually happened
Thanks for taking the time to fill out this [Provider](https://next-auth.js.org/providers/overview) related issue!
Is this your first time contributing? Check out this video: https://www.youtube.com/watch?v=cuoNzXFLitc
### Important :exclamation:
_Providing incorrect/insufficient information or skipping steps to reproduce the issue may result in closing the issue or converting to a discussion without further explanation._
If you have a generic question specific to your project, it is best asked in Discussions under the [Questions category](https://github.com/nextauthjs/next-auth/discussions/new?category=Questions)
- type:dropdown
attributes:
label:Provider type
description:Provider(s) this issue is related to
multiple:true
options:
- "Credentials"
- "Email"
- "Custom provider"
- "42 School"
- "Apple"
- "Atlassian"
- "Auth0"
- "Authentik"
- "Azure Active Directory"
- "Azure Active Directory B2C"
- "Battlenet"
- "Box"
- "Bungie"
- "Cognito"
- "Coinbase"
- "Discord"
- "Dropbox"
- "EVE Online"
- "Facebook"
- "FACEIT"
- "Foursquare"
- "Freshbooks"
- "FusionAuth"
- "GitHub"
- "GitLab"
- "Google"
- "Identity Server 4"
- "Instagram"
- "Kakao"
- "Keycloak"
- "Line"
- "LinkedIn"
- "Mailchimp"
- "Mail.ru"
- "Medium"
- "Naver"
- "Netlify"
- "Okta"
- "OneLogin"
- "Osso"
- "Osu"
- "Patreon"
- "Pipedrive"
- "Reddit"
- "Salesforce"
- "Slack"
- "Spotify"
- "Strava"
- "Trakt"
- "Twitch"
- "Twitter"
- "Vk"
- "Wordpress"
- "WorkOS"
- "Yandex"
- "Zoho"
- "Zoom"
validations:
required:true
- type:textarea
attributes:
label:Environment
description:|
Run this command in your project's root folder and paste the result:
Alternatively, you can manually gather the version information from your package.json for these packages: "next", "react" and "next-auth". Please also mention your OS and Node.js version, as well as the browser you are using.
validations:
required:true
- type:input
attributes:
label:Reproduction URL
description:A URL to a repository/code that clearly reproduces your issue. You can use our [`next-auth-example`](https://github.com/nextauthjs/next-auth-example) template repository to get started more easily, or link to your project if it's public
validations:
required:true
- type:textarea
attributes:
label:Describe the issue
description:Describe us what the issue is and what have you tried so far to fix it. Add any extra useful information in this section. Feel free to use screenshots (but prefer [code blocks](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#syntax-highlighting) over a picture of your code) or a video explanation.
validations:
required:true
- type:textarea
attributes:
label:How to reproduce
description:Explain with clear steps how to reproduce the issue
validations:
required:true
- type:textarea
attributes:
label:Expected behavior
description:Explain what should have happened instead of what actually happened
Thanks for taking the time to fill out this [Adapter](https://next-auth.js.org/adapters/overview) related issue!
Is this your first time contributing? Check out this video: https://www.youtube.com/watch?v=cuoNzXFLitc
### Important :exclamation:
_Providing incorrect/insufficient information or skipping steps to reproduce the issue may result in closing the issue or converting to a discussion without further explanation._
If you have a generic question specific to your project, it is best asked in Discussions under the [Questions category](https://github.com/nextauthjs/next-auth/discussions/new?category=Questions)
- type:dropdown
attributes:
label:Adapter type
description:Adapter(s) this issue is related to
multiple:true
options:
- "Custom adapter"
- "@next-auth/dgraph-adapter"
- "@next-auth/dynamodb-adapter"
- "@next-auth/fauna-adapter"
- "@next-auth/firebase-adapter"
- "@next-auth/mikro-orm-adapter"
- "@next-auth/mongodb-adapter"
- "@next-auth/neo4j-adapter"
- "@next-auth/pouchdb-adapter"
- "@next-auth/prisma-adapter"
- "@next-auth/sequelize-adapter"
- "@next-auth/typeorm-legacy-adapter"
- "@next-auth/upstash-redis-adapter"
validations:
required:true
- type:textarea
attributes:
label:Environment
description:|
Run this command in your project's root folder and paste the result:
Alternatively, if the above command did not work, we need the version of the following packages from your package.json: "next", "react", "next-auth" and your adapter. Please also mention your OS and Node.js version, as well as the browser you are using.
validations:
required:true
- type:input
attributes:
label:Reproduction URL
description:A URL to a repository/code that clearly reproduces your issue. You can use our [`next-auth-example`](https://github.com/nextauthjs/next-auth-example) template repository to get started more easily, or link to your project if it's public
validations:
required:true
- type:textarea
attributes:
label:Describe the issue
description:Describe us what the issue is and what have you tried so far to fix it. Add any extra useful information in this section. Feel free to use screenshots (but prefer [code blocks](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#syntax-highlighting) over a picture of your code) or a video explanation.
validations:
required:true
- type:textarea
attributes:
label:How to reproduce
description:Explain with clear steps how to reproduce the issue
validations:
required:true
- type:textarea
attributes:
label:Expected behavior
description:Explain what should have happened instead of what actually happened
Thank you very much for reaching out to us regarding the awesome feature that you believe should be included in the NextAuth.js library.
_NOTE: Feature requests are converted to [discussions (Ideas 💡)](https://github.com/nextauthjs/next-auth/discussions/categories/ideas). Make sure your idea hasn't been asked yet, and upvote the existing one before opening a new instead._
### Important :exclamation:
Please proceed by providing the following information:
- type:textarea
id:description
attributes:
label:Description 📓
description:Please provide a more in-depth description of the feature proposed.
validations:
required:true
- type:markdown
attributes:
value:|
Make sure you provide plenty of [links]() to external documentation and inline code examples like so:
```js
function myAwesomeNextAuthFeature() {
return 💚
}
```
Take time thinking about what you want to say and help us understand your proposal making sure that this description contains:
- **purpose of the feature**
- **potential problems**
- **potential alternatives**
- type:textarea
id:reproduction
attributes:
label:How to reproduce ☕️
description:If you have a CodeSandbox playground or some code snippets to help us visualize your idea better, please provide it here.
validations:
required:true
- type:markdown
attributes:
value:|
You can use one of the templates set up on **CodeSandbox** to better illustrate your idea:
description:Please provide an in-depth description of the question you have when using NextAuth.js on a Typescript project or when consuming the built-in types for `next-auth`.
validations:
required:true
- type:markdown
attributes:
value:|
Make sure you [link]() to external documentation if necessary and provide inline code examples like so:
```js
function myAwesomeNextAuthFeature() {
return 💚
}
```
**NOTE:** Questions will be converted to Discussions. You can find them [here](https://github.com/nextauthjs/next-auth/discussions)!
- type:textarea
id:codesandbox
attributes:
label:How to reproduce ☕️
description:Please provide a link to a minimal reproduction or code snippets that represents your question
validations:
required:true
- type:markdown
attributes:
value:|
We encourage you to use the template set-up on **CodeSandbox** as a playground to represent your question or doubt:
A clear and concise description of the bug in NextAuth.js.
Do not report bugs with your own project here, ask from help by raising a question instead - this helps us a lot with administration overhead.
**Steps to reproduce**
Steps to reproduce the behavior.
Include a link to public repository which can be used to reproduce the behaviour.
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots or error logs**
If applicable add screenshots or error logs to help explain the problem.
**Additional context**
Add any other context about the problem here.
**Feedback**
*Documentation refers to searching through [online documentation](https://next-auth.js.org), code comments and issue history. The example project refers to [next-auth-example](https://github.com/iaincollins/next-auth-example).*
about: Ask a question about NextAuth.js or for help using it
labels: question
assignees: ''
---
<!-- NOTE: Questions will be converted to Discussions. You can find them at https://github.com/nextauthjs/next-auth/discussions! -->
**Your question**
<!-- A clear and concise question. -->
**What are you trying to do**
<!-- A description of what you are trying to do, for context. -->
**Reproduction**
<!-- If your question is code related, adding a reproduction to your use case can greatly reduce the time it takes us to figure out how to better help you. -->
**Feedback**
*Documentation refers to searching through [online documentation](https://next-auth.js.org), code comments and issue history. The example project refers to [next-auth-example](https://github.com/iaincollins/next-auth-example).*
@@ -11,43 +11,53 @@ Please raise any significant new functionality or breaking change an issue for d
## For contributors
Anyone can be a contributor. Either you found a typo, or you have an awesome feature request you could implement, we encourage you to create a Pull Request.
### Pull Requests
* The latest changes are always in `main`, so please make your Pull Request against that branch.
* Pull Requests should be raised for any change
* Pull Requests need approval of a [core contributor](https://next-auth.js.org/contributors#core-team) before merging
* We use ESLint/Prettier for linting/formatting, so please run `npm run lint:fix` before committing to make resolving conflicts easier (VSCode users, check out [this ESLint extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) and [this Prettier extension](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) to fix lint and formatting issues in development)
* We encourage you to test your changes, and if you have the opportunity, please make those tests part of the Pull Request
* If you add new functionality, please provide the corresponding documentation as well and make it part of the Pull Request
- The latest changes are always in `main`, so please make your Pull Request against that branch.
- Pull Requests should be raised for any change
- Pull Requests need approval of a [core contributor](https://next-auth.js.org/contributors#core-team) before merging
- We use ESLint/Prettier for linting/formatting, so please run `yarn lint:fix` before committing to make resolving conflicts easier (VSCode users, check out [this ESLint extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) and [this Prettier extension](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) to fix lint and formatting issues in development)
- We encourage you to test your changes, and if you have the opportunity, please make those tests part of the Pull Request
- If you add new functionality, please provide the corresponding documentation as well and make it part of the Pull Request
### Setting up local environment
A quick guide on how to setup *next-auth* locally to work on it and test out any changes:
A quick guide on how to setup _next-auth_ locally to work on it and test out any changes:
Copy `app/.env.local.example` to `app/.env.local`, and add your env variables for each provider you want to test.
> NOTE: You can add any environment variables to .env.local that you would like to use in your dev app.
> You can find the next-auth config under`app/pages/api/auth/[...nextauth].js`.
Copy `apps/dev/.env.local.example` to `apps/dev/.env.local`, and add your env variables for each provider you want to test.
1. Start the dev application/server:
```sh
npm run dev
cd apps/dev
cp .env.local.example .env.local
```
Your dev application will be available on ```http://localhost:3000```
> NOTE: You can add any environment variables to .env.local that you would like to use in your dev app.
> You can find the next-auth config under`apps/dev/pages/api/auth/[...nextauth].js`.
4. Start the developer application/server:
```sh
yarn dev:app
```
Your developer application will be available on `http://localhost:3000`
That's it! 🎉
@@ -55,15 +65,16 @@ If you need an example project to link to, you can use [next-auth-example](https
#### Hot reloading
When running `npm run dev`, you start a Next.js dev server on `http://localhost:3000`, which includes hot reloading out of the box. Make changes on any of the files in `src` and see the changes immediately.
When running `yarn dev:app`, you start a Next.js developer server on `http://localhost:3000`, which includes hot reloading out of the box. Make changes on any of the files in `src` and see the changes immediately.
> NOTE: When working on CSS, you will have to manually refresh the page after changes. The reason for this is our pages using CSS are server-side rendered. (Improving this through a PR is very welcome!)
> NOTE: When working on CSS, you will have to manually refresh the page after changes. The reason for this is our pages using CSS are server-side rendered (using API routes). (Improving this through a PR is very welcome!)
> NOTE: The setup is as follows: The development application lives inside the `app` folder, and whenever you make a change to the `src` folder in the root (where next-auth is), it gets copied into `app` every time (gitignored), so Next.js can pick them up and apply hot reloading. This is to avoid some annoying issues with how symlinks are working with different React builds, and also to provide a super-fast feedback loop while developing core features.
#### Providers
If you think your custom provider might be useful to others, we encourage you to open a PR and add it to the built-in list so others can discover it much more easily! You only need to add two changes:
1. Add your config: [`src/providers/{provider}.js`](https://github.com/nextauthjs/next-auth/tree/main/src/providers) (Make sure you use a named default export, like `export default function YourProvider`!)
@@ -73,58 +84,28 @@ You can look at the existing built-in providers for inspiration.
#### Databases
Included is a Docker Compose file that starts up MySQL, PostgreSQL, and MongoDB databases on localhost.
It will use port `3306`, `5432`, and `27017` on localhost respectively; please make sure those ports are not used by other services on localhost.
You can start them with `npm run db:start` and stop them with `npm run db:stop`.
You will need Docker and Docker Compose installed to be able to start / stop the databases.
When stopping the databases, it will reset their contents.
If you would like to contribute to an existing database adapter or help create a new one, head over to the [nextauthjs/adapters](https://www.github.com/nextauthjs/adapters) repository and follow the instructions provided there.
#### Testing
Tests can be run with `npm run test`.
Tests can be run with `yarn test`.
Automated tests are currently crude and limited in functionality, but improvements are in development.
Currently, to run tests you need to first have started local test databases (e.g. using `npm run db:start`).
The databases can take a few seconds to start up, so you might need to give it a minute before running the tests.
## For maintainers
We use [semantic-release](https://github.com/semantic-release/semantic-release) together with [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) to automate releases. This makes the maintainenance process easier and less error-prone to human error. Please study the "Conventional Commits" site to understand how to write a good commit message.
We use [a custom script](https://github.com/nextauthjs/next-auth/tree/main/scripts/index.ts) together with [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) to automate releases. This makes the maintenance process easier and less error-prone. Please study the "Conventional Commits" site to understand how to write a good commit message.
When accepting Pull Requests, make sure the following:
* Use "Squash and merge"
* Make sure you merge contributor PRs into `main`
* Rewrite the commit message to conform to the `Conventional Commits` style. Check the "Recommended Scopes" section for further advice.
* Optionally link issues the PR will resolve (You can add "close" in front of the issue numbers to close the issues automatically, when the PR is merged. `semantic-release` will also comment back to connected issues and PRs, notifying the users that a feature is added/bug fixed, etc.)
### Recommended Scopes
A typical conventional commit looks like this:
```
type(scope): title
body
```
Scope is the part that will help groupping the different commit types in the release notes.
Some recommened scopes are:
- **provider** - Provider related changes. (eg.: "feat(provider): add X provider", "docs(provider): fix typo in X documentation"
- **adapter** - Adapter related changes. (eg.: "feat(adapter): add X provider", "docs(provider): fix typo in X documentation"
- **db** - Database related changes. (eg.: "feat(db): add X database", "docs(db): fix typo in X documentation"
- **deps** - Adding/removing/updating a dependency (eg.: "chore(deps): add X")
> NOTE: If you are not sure which scope to use, you can simply ignore it. (eg.: "feat: add something"). Adding the correct type already helps a lot when analyzing the commit messages.
- Use "Squash and merge"
- Make sure you merge contributor PRs into `main`
- Rewrite the commit message to conform to the `Conventional Commits` style.
- Using `fix` releases a patch (x.x.1)
- Using `feat` releases a minor (x.1.x)
- Using `feat` when `BREAKING CHANGE` is present in the commit messgae releases a major (1.x.x)
- Optionally link issues the PR will resolve (You can add "close" in front of the issue numbers to close the issues automatically, when the PR is merged. `semantic-release` will also comment back to connected issues and PRs, notifying the users that a feature is added/bug fixed, etc.)
### Skipping a release
Every commit that contains [skip release] or [release skip] in their message will be excluded from the commit analysis and won't participate in the release type determination. This is useful, if the PR being merged should not trigger a new `npm` release.
If a commit contains `[skip release]` in their message will be excluded from the commit analysis and won't participate in the release type determination. This is useful, if the PR being merged should not trigger a new `npm` release.
NextAuth.js is a complete open source authentication solution for [Next.js](http://nextjs.org/) applications.
It is designed from the ground up to support Next.js and Serverless.
## Getting Started
```
npm install --save next-auth
```
The easiest way to continue getting started, is to follow the [getting started](https://next-auth.js.org/getting-started/example) section in our docs.
We also have a section of [tutorials](https://next-auth.js.org/tutorials) for those looking for more specific examples.
See [next-auth.js.org](https://next-auth.js.org) for more information and documentation.
## Features
### Flexible and easy to use
* Designed to work with any OAuth service, it supports OAuth 1.0, 1.0A and 2.0
* Built-in support for [many popular sign-in services](https://next-auth.js.org/configuration/providers)
* Supports email / passwordless authentication
* Supports stateless authentication with any backend (Active Directory, LDAP, etc)
* Supports both JSON Web Tokens and database sessions
* Designed for Serverless but runs anywhere (AWS Lambda, Docker, Heroku, etc…)
### Own your own data
NextAuth.js can be used with or without a database.
* An open source solution that allows you to keep control of your data
* Supports Bring Your Own Database (BYOD) and can be used with any database
* Built-in support for [MySQL, MariaDB, Postgres, Microsoft SQL Server, MongoDB and SQLite](https://next-auth.js.org/configuration/databases)
* Works great with databases from popular hosting providers
* Can also be used *without a database* (e.g. OAuth + JWT)
### Secure by default
* Promotes the use of passwordless sign in mechanisms
* Designed to be secure by default and encourage best practice for safeguarding user data
* Uses Cross Site Request Forgery Tokens on POST routes (sign in, sign out)
* Default cookie policy aims for the most restrictive policy appropriate for each cookie
* When JSON Web Tokens are enabled, they are signed by default (JWS) with HS512
* Use JWT encryption (JWE) by setting the option `encryption: true` (defaults to A256GCM)
* Auto-generates symmetric signing and encryption keys for developer convenience
* Features tab/window syncing and keepalive messages to support short lived sessions
* Attempts to implement the latest guidance published by [Open Web Application Security Project](https://owasp.org/)
Advanced options allow you to define your own routines to handle controlling what accounts are allowed to sign in, for encoding and decoding JSON Web Tokens and to set custom cookie security policies and session properties, so you can control who is able to sign in and how often sessions have to be re-validated.
### TypeScript
NextAuth.js comes with built-in types. For more information and usage, check out the [TypeScript section](https://next-auth.js.org/getting-started/typescript) in the documentaion.
The package at `@types/next-auth` is now deprecated.
## Example
### Add API Route
```javascript
importNextAuthfrom'next-auth'
importProvidersfrom'next-auth/providers'
exportdefaultNextAuth({
providers:[
// OAuth authentication providers
Providers.Apple({
clientId:process.env.APPLE_ID,
clientSecret:process.env.APPLE_SECRET
}),
Providers.Google({
clientId:process.env.GOOGLE_ID,
clientSecret:process.env.GOOGLE_SECRET
}),
// Sign in with passwordless email link
Providers.Email({
server:process.env.MAIL_SERVER,
from:'<no-reply@example.com>'
}),
],
// SQL or MongoDB database (or leave empty)
database:process.env.DATABASE_URL
})
```
### Add React Component
```javascript
import{
useSession,signIn,signOut
}from'next-auth/client'
exportdefaultfunctionComponent(){
const[session,loading]=useSession()
if(session){
return<>
Signedinas{session.user.email}<br/>
<buttononClick={()=>signOut()}>Signout</button>
</>
}
return<>
Notsignedin<br/>
<buttononClick={()=>signIn()}>Signin</button>
</>
}
```
## Acknowledgements
[NextAuth.js is made possible thanks to all of its contributors.](https://next-auth.js.org/contributors)
<img width="170px" src="https://raw.githubusercontent.com/nextauthjs/next-auth/canary/www/static/img/powered-by-vercel.svg" alt="Powered By Vercel" />
</a>
</div>
<div>
<p align="left">Thanks to Vercel sponsoring this project by allowing it to be deployed for free for the entire NextAuth.js Team</p>
</div>
## Contributing
We're open to all community contributions! If you'd like to contribute in any way, please first read our [Contributing Guide](https://github.com/nextauthjs/next-auth/blob/canary/CONTRIBUTING.md).
Security updates are only released for the current version.
Old releases are not maintained and do not receive updates.
## Reporting a Vulnerability
We request that you contact us directly to report serious issues that might impact the security of sites using NextAuth.js.
If you contact us regarding a serious issue:
* We will endeavor to get back to you within 72 hours.
* We will aim to publish a fix within 30 days.
* We will disclose the issue (and credit you, with your consent) once a fix to resolve the issue has been released.
* If 90 days has elapsed and we still don't have a fix, we will disclose the issue publically.
- We will endeavor to get back to you within 72 hours.
- We will aim to publish a fix within 30 days.
- We will disclose the issue (and credit you, with your consent) once a fix to resolve the issue has been released.
- If 90 days has elapsed and we still don't have a fix, we will disclose the issue publicly.
Currently, the best way to report an issue is by emailing me@iaincollins.com
The best way to report an issue is by contacting us via email at info@balazsorban.com or me@iaincollins.com and yo@ndo.dev, or raise a public issue requesting someone get in touch with you via whatever means you prefer for more details. (Please do not disclose sensitive details publicly at this stage.)
For less serious issues (e.g. RFC compliance for unsupported flows or potential issues that may cause a problem future or default behaviour / options) it is appropriate to submit these these publically as bug reports or feature requests or to raise a question to open a discussion around them.
> For less serious issues (e.g. RFC compliance for unsupported flows or potential issues that may cause a problem in the future) it is appropriate to submit these these publically as bug reports or feature requests or to raise a question to open a discussion around them.
## Supported Versions
Security updates are only released for the current version.
Old releases are not maintained and do not receive updates.
> The example repository is maintained from a [monorepo](https://github.com/nextauthjs/next-auth/tree/main/apps/example-gatsby). Pull Requests should be opened against [`nextauthjs/next-auth`](https://github.com/nextauthjs/next-auth).
NextAuth.js is a complete open source authentication solution.
This is an example application that shows how `next-auth` is applied to a basic Gatsby app. We are showing how to configure the backend both as a [Vercel Function](https://vercel.com/docs/concepts/functions/introduction) for deployment to Vercel, and also for [Gatsby Functions](https://www.gatsbyjs.com/docs/reference/functions) for other platforms.
The deployed version can be found at [`next-auth-gatsby-example.vercel.app`](https://next-auth-gatsby-example.vercel.app)
### About NextAuth.js
NextAuth.js is an easy to implement, full-stack (client/server) open source authentication library originally designed for [Next.js](https://nextjs.org) and [Serverless](https://vercel.com), but this example shows how to use it in a Gatsby project. Our goal is to [support even more frameworks](https://github.com/nextauthjs/next-auth/issues/2294) in the future.
Go to [next-auth.js.org](https://next-auth.js.org) for more information and documentation.
> *NextAuth.js is not officially associated with Vercel or Next.js.*
## Getting Started
### 1. Clone the repository and install dependencies
Copy the .env.local.example file in this directory to .env.local (which will be ignored by Git):
```
cp .env.local.example .env.local
```
Add details for one or more providers (e.g. Google, Twitter, GitHub, Email, etc).
#### Database
A database is needed to persist user accounts and to support email sign in. However, you can still use NextAuth.js for authentication without a database by using OAuth for authentication. If you do not specify a database, [JSON Web Tokens](https://jwt.io/introduction) will be enabled by default.
You **can** skip configuring a database and come back to it later if you want.
For more information about setting up a database, please check out the following links:
1. Review and update options in `nextauth.config.js` as needed.
2. When setting up OAuth, in the developer admin page for each of your OAuth services, you should configure the callback URL to use a callback path of `{server}/api/auth/callback/{provider}`.
e.g. For Google OAuth you would use: `http://localhost:3000/api/auth/callback/google`
A list of configured providers and their callback URLs is available from the endpoint `/api/auth/providers`. You can find more information at https://next-auth.js.org/configuration/providers/oauth
3. You can also choose to specify an SMTP server for passwordless sign in via email.
### 4. Start the application
To run your site locally, use:
```
npm run dev
```
To run it in production mode, use:
```
npm run build
npm run start
```
### 5. Preparing for Production
Follow the [Deployment documentation](https://next-auth.js.org/deployment)
> The example repository is maintained from a [monorepo](https://github.com/nextauthjs/next-auth/tree/main/apps/example-nextjs). Pull Requests should be opened against [`nextauthjs/next-auth`](https://github.com/nextauthjs/next-auth).
NextAuth.js is a complete open source authentication solution.
This is an example application that shows how `next-auth` is applied to a basic Next.js app.
The deployed version can be found at [`next-auth-example.vercel.app`](https://next-auth-example.vercel.app)
### About NextAuth.js
NextAuth.js is an easy to implement, full-stack (client/server) open source authentication library originally designed for [Next.js](https://nextjs.org) and [Serverless](https://vercel.com). Our goal is to [support even more frameworks](https://github.com/nextauthjs/next-auth/issues/2294) in the future.
Go to [next-auth.js.org](https://next-auth.js.org) for more information and documentation.
> *NextAuth.js is not officially associated with Vercel or Next.js.*
## Getting Started
### 1. Clone the repository and install dependencies
Copy the .env.local.example file in this directory to .env.local (which will be ignored by Git):
```
cp .env.local.example .env.local
```
Add details for one or more providers (e.g. Google, Twitter, GitHub, Email, etc).
#### Database
A database is needed to persist user accounts and to support email sign in. However, you can still use NextAuth.js for authentication without a database by using OAuth for authentication. If you do not specify a database, [JSON Web Tokens](https://jwt.io/introduction) will be enabled by default.
You **can** skip configuring a database and come back to it later if you want.
For more information about setting up a database, please check out the following links:
1. Review and update options in `pages/api/auth/[...nextauth].js` as needed.
2. When setting up OAuth, in the developer admin page for each of your OAuth services, you should configure the callback URL to use a callback path of `{server}/api/auth/callback/{provider}`.
e.g. For Google OAuth you would use: `http://localhost:3000/api/auth/callback/google`
A list of configured providers and their callback URLs is available from the endpoint `/api/auth/providers`. You can find more information at https://next-auth.js.org/configuration/providers/oauth
3. You can also choose to specify an SMTP server for passwordless sign in via email.
### 4. Start the application
To run your site locally, use:
```
npm run dev
```
To run it in production mode, use:
```
npm run build
npm run start
```
### 5. Preparing for Production
Follow the [Deployment documentation](https://next-auth.js.org/deployment)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
