mirror of
https://github.com/SrIzan10/next-auth.git
synced 2026-05-01 10:55:20 +00:00
Compare commits
11 Commits
@auth/core
...
@auth/svel
| Author | SHA1 | Date | |
|---|---|---|---|
|
b277e937e2 | ||
|
|
59b2847274 | ||
|
|
e32fb16b17 | ||
|
|
45e721c3f7 | ||
|
|
de8ad4f5af | ||
|
|
9462b8ffb4 | ||
|
|
1cf0eeace6 | ||
|
|
7cf0074417 | ||
|
|
899098ccc4 | ||
|
|
67c29039c7 | ||
|
|
e9ad688a5a |
2
.github/version-pr/action.yml
vendored
2
.github/version-pr/action.yml
vendored
@@ -4,5 +4,5 @@ outputs:
|
||||
version:
|
||||
description: "npm package version"
|
||||
runs:
|
||||
using: "node16"
|
||||
using: "node20"
|
||||
main: "index.js"
|
||||
|
||||
@@ -25,7 +25,6 @@
|
||||
"@supabase/supabase-js": "^2.0.5",
|
||||
"faunadb": "^4",
|
||||
"next": "13.4.0",
|
||||
"next-auth": "workspace:*",
|
||||
"nodemailer": "^6",
|
||||
"react": "^18",
|
||||
"react-dom": "^18"
|
||||
|
||||
@@ -114,61 +114,9 @@ Yes! Check out the [TypeScript docs](/getting-started/typescript)
|
||||
|
||||
---
|
||||
|
||||
## Databases
|
||||
## Session strategies
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3 style={{display: "inline-block"}}>What databases are supported by Auth.js?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
Auth.js can be used with MySQL, Postgres, MongoDB, SQLite and compatible databases (e.g. MariaDB, Amazon Aurora, Amazon DocumentDB…) or with no database.
|
||||
|
||||
It also provides an Adapter API which allows you to connect it to any database.
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3 style={{display: "inline-block"}}>What does Auth.js use databases for?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
Databases in Auth.js are used for persisting users, OAuth accounts, email sign-in tokens and sessions.
|
||||
|
||||
Specifying a database is optional if you don't need to persist user data or support email sign-in. If you don't specify a database then JSON Web Tokens will be enabled for session storage and used to store session data.
|
||||
|
||||
If you are using a database with Auth.js, you can still explicitly enable JSON Web Tokens for sessions (instead of using database sessions).
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3 style={{display: "inline-block"}}>Should I use a database?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
- Using Auth.js without a database works well for internal tools - where you need to control who can sign in, but when you do not need to create user accounts for them in your application.
|
||||
|
||||
- Using Auth.js with a database is usually a better approach for a consumer-facing application where you need to persist accounts (e.g. for billing, to contact customers, etc).
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3 style={{display: "inline-block"}}>What database should I use?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
Managed database solutions for MySQL, Postgres and MongoDB (and compatible databases) are well supported by cloud providers such as Amazon, Google, Microsoft and Atlas.
|
||||
|
||||
If you are deploying directly to a particular cloud platform you may also want to consider serverless database offerings they have (e.g. [Amazon Aurora Serverless on AWS](https://aws.amazon.com/rds/aurora/serverless/)).
|
||||
|
||||
</p>
|
||||
</details>
|
||||
Check out the [Session strategies page](/concepts/session-strategies) to learn more.
|
||||
|
||||
---
|
||||
|
||||
@@ -257,99 +205,3 @@ Ultimately if your request is not accepted or is not actively in development, yo
|
||||
</p>
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## JSON Web Tokens
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3>Does Auth.js use JSON Web Tokens?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
Auth.js by default uses JSON Web Tokens for saving the user's session. However, if you use a [database adapter](/guides/adapters/using-a-database-adapter), the database will be used to persist the user's session. You can force the usage of JWT when using a database [through the configuration options](/reference/configuration/auth-config#session). Since v4 all our JWTs are now encrypted by default with A256GCM.
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3>What are the advantages of JSON Web Tokens?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
JSON Web Tokens can be used for session tokens, but are also used for lots of other things, such as sending signed objects between services in authentication flows.
|
||||
|
||||
- Advantages of using a JWT as a session token include that they do not require a database to store sessions, this can be faster and cheaper to run and easier to scale.
|
||||
|
||||
- JSON Web Tokens in Auth.js are secured using cryptographic encryption (JWE) to store the included information directly in a JWT session token. You may then use the token to pass information between services and APIs on the same domain without having to contact a database to verify the included information.
|
||||
|
||||
- You can use JWT to securely store information you do not mind the client knowing even without encryption, as the JWT is stored in a server-readable-only cookie so data in the JWT is not accessible to third-party JavaScript running on your site.
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3>What are the disadvantages of JSON Web Tokens?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
- It's difficult to invalidate a JSON Web Token - doing so requires maintaining a server-side blocklist of the tokens (at least until they expire) and checking every token against the list every time a token is presented.
|
||||
|
||||
Shorter session expiry times are used when using JSON Web Tokens as session tokens to allow sessions to be invalidated sooner and simplify this problem.
|
||||
|
||||
Auth.js client includes advanced features to mitigate the downsides of using shorter session expiry times on the user experience, including automatic session token rotation, optionally sending keep-alive messages to prevent short-lived sessions from expiring if there is a window or tab opened, background re-validation, and automatic tab/window syncing that keeps sessions in sync across windows any time session state changes or a window or tab gains or loses focus.
|
||||
|
||||
- As with database session tokens, JSON Web Tokens are limited in the amount of data you can store in them. There is typically a limit of around 4096 bytes per cookie, though the exact limit varies between browsers, proxies and hosting services. If you want to support most browsers, then do not exceed 4096 bytes per cookie. If you want to save more data, you will need to persist your sessions in a database (Source: [browsercookielimits.iain.guru](http://browsercookielimits.iain.guru/))
|
||||
|
||||
The more data you try to store in a token and the more other cookies you set, the closer you will come to this limit. Auth.js uses cookie chunking so that cookies over the 4kb limit get split and reassembled upon parsing. However, since this data needs to be transmitted on every request, in case you wish to store more than ~4 KB of data you're probably at the point where you want to store a unique ID in the token and persist the data elsewhere (e.g. in a server-side key/value store).
|
||||
|
||||
- Data stored in an encrypted JSON Web Token (JWE) may be compromised at some point.
|
||||
|
||||
Even if appropriately configured, information stored in an encrypted JWT should not be assumed to be impossible to decrypt at some point - e.g. due to the discovery of a defect or advances in technology.
|
||||
|
||||
Avoid storing any data in a token that might be problematic if it were to be decrypted in the future.
|
||||
|
||||
- If you do not explicitly specify a secret for Auth.js, existing sessions will be invalidated any time your Auth.js configuration changes, as Auth.js will default to an auto-generated secret. Since v4 this only impacts development and generating a secret is required in production.
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3>Are JSON Web Tokens secure?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
By default, tokens are encrypted (JWE).
|
||||
|
||||
You can specify other valid algorithms - [as specified in RFC 7518](https://tools.ietf.org/html/rfc7517) - with either a secret (for symmetric encryption) or a public/private key pair (for asymmetric encryption).
|
||||
|
||||
Using explicit public/private keys for signing is strongly recommended.
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<h3>What signing and encryption standards does Auth.js support?</h3>
|
||||
</summary>
|
||||
<p>
|
||||
|
||||
Auth.js includes a largely complete implementation of JSON Object Signing and Encryption (JOSE):
|
||||
|
||||
- [RFC 7515 - JSON Web Signature (JWS)](https://tools.ietf.org/html/rfc7515)
|
||||
- [RFC 7516 - JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516)
|
||||
- [RFC 7517 - JSON Web Key (JWK)](https://tools.ietf.org/html/rfc7517)
|
||||
- [RFC 7518 - JSON Web Algorithms (JWA)](https://tools.ietf.org/html/rfc7518)
|
||||
- [RFC 7519 - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519)
|
||||
|
||||
This incorporates support for:
|
||||
|
||||
- [RFC 7638 - JSON Web Key Thumbprint](https://tools.ietf.org/html/rfc7638)
|
||||
- [RFC 7787 - JSON JWS Unencoded Payload Option](https://tools.ietf.org/html/rfc7797)
|
||||
- [RFC 8037 - CFRG Elliptic Curve ECDH and Signatures](https://tools.ietf.org/html/rfc8037)
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
49
docs/docs/concepts/session-strategies.md
Normal file
49
docs/docs/concepts/session-strategies.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: Session strategies
|
||||
---
|
||||
|
||||
When a user logs into your application, you usually want them to not need to log in for some time. This is called a session. Auth.js libraries support different session strategies, which are described below.
|
||||
|
||||
:::note
|
||||
Both strategies have advantages and disadvantages which you have to evaluate based on your requirements
|
||||
:::
|
||||
|
||||
Check out the [`session.strategy`](/reference/core#session) option to see how you can configure the session strategy of your Auth.js library.
|
||||
|
||||
## JWT
|
||||
|
||||
Auth.js libraries can create sessions using [JSON Web Tokens (JWT)](https://datatracker.ietf.org/doc/html/rfc7519). This is the default session strategy for Auth.js libraries. When a user signs in, a JWT is created in a `HttpOnly` cookie. Making the cookie HttpOnly prevents JavaScript from accessing it client-side (`document.cookie`), which makes it harder for attackers to steal the value. In addition, the JWT is encrypted with a secret key only known to the server. So even if an attacker were to steal the JWT from the cookie, they would not be able to decrypt it. Combined with a short expiration time, this makes JWTs a secure way to create sessions.
|
||||
|
||||
When a user signs out, the JWT is deleted from the cookies, and the session is destroyed.
|
||||
|
||||
### Advantages
|
||||
|
||||
- JWTs as a session do not require a database to store sessions, this can be faster and cheaper to run and easier to scale.
|
||||
- Retrieving a JWT session can always run on the Edge.
|
||||
- Using this strategy requires fewer resources as you don't need to manage an extra database/service.
|
||||
- You may then use the created token to pass information between services and APIs on the same domain without having to contact a database to verify the included information.
|
||||
- You can use JWT to securely store information without exposing it to third-party JavaScript running on your site.
|
||||
|
||||
### Disadvantages
|
||||
|
||||
- Expiring a JSON Web Token before its encoded expiry is not possible - doing so requires maintaining a server-side blocklist of invalidated tokens (at least until they truly expire) and checking every token against the list every time a token is presented. Auth.js **will** destroy the cookie, but if the user has the JWT saved elsewhere, it will be valid (the server will accept it) until it expires. (Shorter session expiry times are used when using JSON Web Tokens as session tokens to allow sessions to be invalidated sooner and simplify this problem.)
|
||||
- Auth.js clients enable advanced features to mitigate the downsides of using shorter session expiry times on the user experience, including automatic session token rotation, optionally sending keep-alive messages (session polling) to prevent short-lived sessions from expiring if there is a window or tab open, background re-validation, and automatic tab/window syncing that keeps sessions in sync across windows any time session state changes or a window or tab gains or loses focus.
|
||||
- As with database session tokens, JSON Web Tokens are limited in the amount of data you can store in them. There is typically a limit of around 4096 bytes per cookie, though the exact limit varies between browsers. The more data you try to store in a token and the more other cookies you set, the closer you will come to this limit. Auth.js libraries implement session cookie chunking so that cookies over the 4kb limit will get split and reassembled upon parsing. However since this data needs to be transmitted on every request, you need to be aware of how much data you want to transfer using this technique.
|
||||
- Even if appropriately configured, information stored in an encrypted JWT should not be assumed to be impossible to decrypt at some point - e.g. due to the discovery of a defect or advances in technology. Data stored in an encrypted JSON Web Token (JWE) _may_ be compromised at some point. The recommendation is to generate a [secret](/reference/core#secret) with high entropy.
|
||||
|
||||
## Database
|
||||
|
||||
Alternatively, to a JWT session strategy, Auth.js libraries also support database sessions. In this case, instead of saving a JWT with user data after signing in, Auth.js libraries will create a session in your database. A session ID is then saved in a `HttpOnly` cookie. This is similar to the JWT session strategy, but instead of saving the user data in the cookie, it only stores an obscure value pointing to the session in the database. So whenever you will try to access the user session, you will query the database for the data.
|
||||
|
||||
When a user signs out, the session is deleted from the database, and the session ID is deleted from the cookies.
|
||||
|
||||
### Advantages
|
||||
|
||||
- Database sessions can be at any time modified server-side, so you can implement features that might be more difficult - but not impossible - using the JWT strategy, etc.: "sign out everywhere", or limiting concurrent logins
|
||||
- Auth.js has no opinion on the type of database you are using, we have a big list of [official database adapters](/reference/adapters), but you can [implement your own](guides/adapters/creating-a-database-adapter) as well
|
||||
|
||||
### Disadvantages
|
||||
|
||||
- Database sessions need a roundtrip to your database, so they might be slower on scale unless your connections/databases are accommodated for it
|
||||
- Many database adapters are not yet compatible with the Edge, which would allow faster and cheaper session retrieval
|
||||
- Setting up a database takes more effort and requires extra services to manage compared to the stateless JWT strategy
|
||||
@@ -247,7 +247,7 @@ const docusaurusConfig = {
|
||||
const file = docPath.split("reference/adapter/")[1].replace("index.md", "src/index.ts")
|
||||
return `${base}/adapter-${file}`
|
||||
}
|
||||
return "https://github.com/nextauthjs/next-auth/edit/main/docs"
|
||||
return `https://github.com/nextauthjs/next-auth/edit/main/docs/docs/${docPath}`
|
||||
},
|
||||
lastVersion: "current",
|
||||
showLastUpdateAuthor: true,
|
||||
|
||||
@@ -47,7 +47,7 @@
|
||||
"typescript": "5.2.2"
|
||||
},
|
||||
"engines": {
|
||||
"node": "^16.13.0 || ^18.12.0"
|
||||
"node": "^18.18.0 || ^20.8.0"
|
||||
},
|
||||
"packageManager": "pnpm@8.7.1",
|
||||
"funding": [
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@auth/typeorm-adapter",
|
||||
"version": "1.0.2",
|
||||
"version": "1.0.3",
|
||||
"description": "TypeORM adapter for Auth.js.",
|
||||
"homepage": "https://authjs.dev/reference/adapter/typeorm",
|
||||
"repository": "https://github.com/nextauthjs/next-auth",
|
||||
@@ -62,8 +62,8 @@
|
||||
"typescript": "5.2.2"
|
||||
},
|
||||
"peerDependencies": {
|
||||
"mssql": "^6.2.1 || 7",
|
||||
"mysql": "^2.18.1",
|
||||
"mssql": "^6.2.1 || ^7 || ^8 || ^9",
|
||||
"mysql": "^2.18.1 || ^3",
|
||||
"pg": "^8.2.1",
|
||||
"sqlite3": "^5.0.2",
|
||||
"typeorm": "^0.3.7"
|
||||
@@ -85,4 +85,4 @@
|
||||
"jest": {
|
||||
"preset": "@auth/adapter-test/jest"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@auth/upstash-redis-adapter",
|
||||
"version": "1.0.0",
|
||||
"version": "1.0.1",
|
||||
"description": "Upstash adapter for Auth.js.",
|
||||
"homepage": "https://authjs.dev",
|
||||
"repository": "https://github.com/nextauthjs/next-auth",
|
||||
@@ -49,11 +49,9 @@
|
||||
"@types/uuid": "^8.3.3",
|
||||
"@upstash/redis": "^1.0.1",
|
||||
"dotenv": "^10.0.0",
|
||||
"isomorphic-fetch": "3.0.0",
|
||||
"jest": "^27.4.3",
|
||||
"next-auth": "workspace:*"
|
||||
"jest": "^27.4.3"
|
||||
},
|
||||
"jest": {
|
||||
"preset": "@auth/adapter-test/jest"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,4 +1,3 @@
|
||||
import "isomorphic-fetch"
|
||||
import { Redis } from "@upstash/redis"
|
||||
import { runBasicTests } from "@auth/adapter-test"
|
||||
import { hydrateDates, UpstashRedisAdapter } from "../src"
|
||||
|
||||
@@ -1,4 +1,3 @@
|
||||
import "isomorphic-fetch"
|
||||
import { runBasicTests } from "@auth/adapter-test"
|
||||
import "dotenv/config"
|
||||
import { XataClient } from "../src/xata"
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "@auth/solid-start",
|
||||
"description": "Authentication for SolidStart.",
|
||||
"version": "0.1.1",
|
||||
"version": "0.1.2",
|
||||
"type": "module",
|
||||
"files": [
|
||||
"client.*",
|
||||
@@ -31,7 +31,6 @@
|
||||
"@auth/core": "workspace:*",
|
||||
"@solidjs/meta": "^0.28.0",
|
||||
"@types/node": "^18.7.14",
|
||||
"next-auth": "workspace:*",
|
||||
"solid-js": "^1.5.7",
|
||||
"solid-start": "^0.2.14",
|
||||
"tsup": "^6.5.0",
|
||||
@@ -50,4 +49,4 @@
|
||||
"author": "OrJDev <orjdeveloper@gmail.com>",
|
||||
"repository": "https://github.com/nextauthjs/next-auth",
|
||||
"license": "ISC"
|
||||
}
|
||||
}
|
||||
@@ -1,14 +1,35 @@
|
||||
import type {
|
||||
LiteralUnion,
|
||||
SignInOptions,
|
||||
SignInAuthorizationParams,
|
||||
SignOutParams,
|
||||
} from "next-auth/react"
|
||||
import type {
|
||||
BuiltInProviderType,
|
||||
RedirectableProviderType,
|
||||
} from "@auth/core/providers"
|
||||
|
||||
type LiteralUnion<T extends U, U = string> = T | (U & Record<never, never>)
|
||||
|
||||
interface SignInOptions extends Record<string, unknown> {
|
||||
/**
|
||||
* Specify to which URL the user will be redirected after signing in. Defaults to the page URL the sign-in is initiated from.
|
||||
*
|
||||
* [Documentation](https://next-auth.js.org/getting-started/client#specifying-a-callbackurl)
|
||||
*/
|
||||
callbackUrl?: string
|
||||
/** [Documentation](https://next-auth.js.org/getting-started/client#using-the-redirect-false-option) */
|
||||
redirect?: boolean
|
||||
}
|
||||
|
||||
interface SignOutParams<R extends boolean = true> {
|
||||
/** [Documentation](https://next-auth.js.org/getting-started/client#specifying-a-callbackurl-1) */
|
||||
callbackUrl?: string
|
||||
/** [Documentation](https://next-auth.js.org/getting-started/client#using-the-redirect-false-option-1 */
|
||||
redirect?: R
|
||||
}
|
||||
|
||||
/** Match `inputType` of `new URLSearchParams(inputType)` */
|
||||
export type SignInAuthorizationParams =
|
||||
| string
|
||||
| string[][]
|
||||
| Record<string, string>
|
||||
| URLSearchParams
|
||||
|
||||
/**
|
||||
* Client-side method to initiate a signin flow
|
||||
* or send the user to the signin page listing all possible providers.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@auth/sveltekit",
|
||||
"version": "0.3.7",
|
||||
"version": "0.3.8",
|
||||
"description": "Authentication for SvelteKit.",
|
||||
"keywords": [
|
||||
"authentication",
|
||||
@@ -36,7 +36,6 @@
|
||||
"@sveltejs/adapter-auto": "^1.0.0",
|
||||
"@sveltejs/kit": "^1.0.0",
|
||||
"@sveltejs/package": "^1.0.0",
|
||||
"next-auth": "workspace:*",
|
||||
"svelte": "^3.54.0",
|
||||
"svelte-check": "^2.9.2",
|
||||
"tslib": "^2.4.1",
|
||||
|
||||
@@ -1,14 +1,35 @@
|
||||
import type {
|
||||
LiteralUnion,
|
||||
SignInOptions,
|
||||
SignInAuthorizationParams,
|
||||
SignOutParams,
|
||||
} from "next-auth/react"
|
||||
import type {
|
||||
BuiltInProviderType,
|
||||
RedirectableProviderType,
|
||||
} from "@auth/core/providers"
|
||||
import { base } from "$app/paths";
|
||||
import { base } from "$app/paths"
|
||||
|
||||
type LiteralUnion<T extends U, U = string> = T | (U & Record<never, never>)
|
||||
|
||||
interface SignInOptions extends Record<string, unknown> {
|
||||
/**
|
||||
* Specify to which URL the user will be redirected after signing in. Defaults to the page URL the sign-in is initiated from.
|
||||
*
|
||||
* [Documentation](https://next-auth.js.org/getting-started/client#specifying-a-callbackurl)
|
||||
*/
|
||||
callbackUrl?: string
|
||||
/** [Documentation](https://next-auth.js.org/getting-started/client#using-the-redirect-false-option) */
|
||||
redirect?: boolean
|
||||
}
|
||||
|
||||
interface SignOutParams<R extends boolean = true> {
|
||||
/** [Documentation](https://next-auth.js.org/getting-started/client#specifying-a-callbackurl-1) */
|
||||
callbackUrl?: string
|
||||
/** [Documentation](https://next-auth.js.org/getting-started/client#using-the-redirect-false-option-1 */
|
||||
redirect?: R
|
||||
}
|
||||
|
||||
/** Match `inputType` of `new URLSearchParams(inputType)` */
|
||||
export type SignInAuthorizationParams =
|
||||
| string
|
||||
| string[][]
|
||||
| Record<string, string>
|
||||
| URLSearchParams
|
||||
|
||||
/**
|
||||
* Client-side method to initiate a signin flow
|
||||
|
||||
15
pnpm-lock.yaml
generated
15
pnpm-lock.yaml
generated
@@ -109,9 +109,6 @@ importers:
|
||||
next:
|
||||
specifier: 13.4.0
|
||||
version: 13.4.0(react-dom@18.2.0)(react@18.2.0)
|
||||
next-auth:
|
||||
specifier: workspace:*
|
||||
version: link:../../../packages/next-auth
|
||||
nodemailer:
|
||||
specifier: ^6
|
||||
version: 6.8.0
|
||||
@@ -774,15 +771,9 @@ importers:
|
||||
dotenv:
|
||||
specifier: ^10.0.0
|
||||
version: 10.0.0
|
||||
isomorphic-fetch:
|
||||
specifier: 3.0.0
|
||||
version: 3.0.0
|
||||
jest:
|
||||
specifier: ^27.4.3
|
||||
version: 27.5.1
|
||||
next-auth:
|
||||
specifier: workspace:*
|
||||
version: link:../next-auth
|
||||
|
||||
packages/adapter-xata:
|
||||
dependencies:
|
||||
@@ -866,9 +857,6 @@ importers:
|
||||
'@types/node':
|
||||
specifier: ^18.7.14
|
||||
version: 18.11.10
|
||||
next-auth:
|
||||
specifier: workspace:*
|
||||
version: link:../next-auth
|
||||
solid-js:
|
||||
specifier: ^1.5.7
|
||||
version: 1.6.6
|
||||
@@ -900,9 +888,6 @@ importers:
|
||||
'@sveltejs/package':
|
||||
specifier: ^1.0.0
|
||||
version: 1.0.1(svelte@3.54.0)(typescript@5.2.2)
|
||||
next-auth:
|
||||
specifier: workspace:*
|
||||
version: link:../next-auth
|
||||
svelte:
|
||||
specifier: ^3.54.0
|
||||
version: 3.54.0
|
||||
|
||||
Reference in New Issue
Block a user