feat: Add event information to verifyUserEmails, preventLoginWithUnverifiedEmail to identify invoking signup / login action and auth provider#9963
Conversation
|
🚀 Thanks for opening this pull request! |
📝 WalkthroughWalkthroughAdds a computed createdWith object ({ action: 'signup' | 'login', authProvider }) to request contexts used by email verification and session creation; extends option parsers, types, and docs to accept functions receiving that request; updates RestWrite, UsersRouter, parsers, and tests accordingly. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/RestWrite.js (1)
774-794: Consider refactoring for improved readability.The logic for determining
actionandresolvedAuthProvideris correct but uses nested ternaries that make it harder to follow. Consider refactoring to use explicit conditionals for better maintainability:- const action = authProvider ? 'login' : isCreateOperation ? 'signup' : undefined; - if (!action) { - return; - } - const resolvedAuthProvider = authProvider || (action === 'signup' ? 'password' : undefined); + let action; + let resolvedAuthProvider; + + if (authProvider) { + action = 'login'; + resolvedAuthProvider = authProvider; + } else if (isCreateOperation) { + action = 'signup'; + resolvedAuthProvider = 'password'; + } else { + return; + } + this.storage.createdWith = { action, authProvider: resolvedAuthProvider }; return this.storage.createdWith;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
spec/EmailVerificationToken.spec.js(4 hunks)spec/ValidationAndPasswordsReset.spec.js(1 hunks)src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)src/Options/index.js(2 hunks)src/RestWrite.js(4 hunks)src/Routers/UsersRouter.js(1 hunks)types/Options/index.d.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (8)
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.
Applied to files:
src/Options/docs.jstypes/Options/index.d.tssrc/Options/index.jssrc/Options/Definitions.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise.
Applied to files:
spec/EmailVerificationToken.spec.js
📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls
Repo: parse-community/parse-server PR: 9883
File: spec/CloudCodeLogger.spec.js:410-412
Timestamp: 2025-10-16T19:27:05.311Z
Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant.
Applied to files:
spec/EmailVerificationToken.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise.
Applied to files:
spec/EmailVerificationToken.spec.js
📚 Learning: 2025-05-04T20:41:05.147Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1312-1338
Timestamp: 2025-05-04T20:41:05.147Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`.
Applied to files:
spec/EmailVerificationToken.spec.js
📚 Learning: 2025-12-02T06:55:53.808Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T06:55:53.808Z
Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js.
Applied to files:
types/Options/index.d.tssrc/Options/index.jssrc/Options/Definitions.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.
Applied to files:
src/Options/index.js
📚 Learning: 2025-11-17T15:02:48.786Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.
Applied to files:
src/Options/index.js
🧬 Code graph analysis (3)
spec/EmailVerificationToken.spec.js (1)
src/RestWrite.js (6)
verifyUserEmails(992-992)user(330-330)user(926-926)user(1543-1543)user(1824-1824)res(623-627)
src/RestWrite.js (1)
src/Auth.js (1)
authProvider(552-552)
src/Routers/UsersRouter.js (1)
src/RestWrite.js (3)
authProvider(781-786)request(845-852)request(981-988)
🪛 Biome (2.1.2)
src/Options/index.js
[error] 45-57: type alias are a TypeScript only feature. Convert your file to a TypeScript file or remove the syntax.
TypeScript only syntax
(parse)
[error] 189-189: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 193-193: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 201-201: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (16)
- GitHub Check: Node 20
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: Node 18
- GitHub Check: Node 22
- GitHub Check: Redis Cache
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: Docker Build
- GitHub Check: Code Analysis (javascript)
- GitHub Check: Benchmarks
🔇 Additional comments (15)
src/Options/docs.js (1)
112-112: Documentation update looks good.The updated description clearly explains the new
createdWithparameter that indicates whether the invocation is forsignuporloginand the authentication provider used. This aligns well with the PR objective and the implementation in other files.Based on learnings, ensure this change was generated by running
npm run definitionsafter updatingsrc/Options/index.js.spec/ValidationAndPasswordsReset.spec.js (1)
287-287: Test expectation correctly validates the newcreatedWithparameter.The test verifies that during login verification flow,
createdWithcontains the expectedaction: 'login'andauthProvider: 'password'values. This provides coverage for the primary password-based login scenario.src/Routers/UsersRouter.js (1)
143-157: Implementation correctly derives auth provider for verification context.The logic properly:
- Extracts auth provider(s) from
req.body.authDatakeys, joining multiple providers with comma if present- Defaults to
'password'when no authData is provided- Creates the
createdWithobject withaction: 'login'for the verification callbackThis is consistent with the pattern used in
RestWrite.js(see lines 780-785) and enables the verification function to make conditional decisions based on the authentication method.src/Options/Definitions.js (1)
636-641: Generated definitions correctly reflect the newcreatedWithparameter documentation.Based on learnings, ensure this file was generated by running
npm run definitionsafter making changes tosrc/Options/index.js, rather than being manually edited.types/Options/index.d.ts (2)
29-40: Well-structured interface for the verification request.The
VerifyUserEmailsRequestinterface properly models:
- Standard request fields (
master,ip,installationId)- The new
createdWithobject with typedactionunion ('login' | 'signup') andauthProviderstring- Optional fields are correctly marked (e.g.,
createdWithis optional for scenarios like resend requests)This provides good TypeScript support for developers implementing conditional verification logic.
89-90: Option types correctly updated to support function-based configuration.The type changes properly allow both:
- Simple boolean values for static configuration
- Functions receiving
VerifyUserEmailsRequestand returningboolean | Promise<boolean>for conditional logicThis enables the use case described in the linked issue #9505 (conditional verification based on auth provider).
src/RestWrite.js (2)
837-856: LGTM!The integration of
getCreatedWith()in the email validation flow correctly provides the invocation context for email verification callbacks.
1003-1030: Verify scenarios wheregetCreatedWith()returns undefined.The fallback logic at lines 1014-1018 reconstructs the
createdWithobject whengetCreatedWith()returns undefined. This defensive pattern is appropriate if legitimate scenarios exist wheregetCreatedWith()cannot provide a value at this point in the execution flow. Confirm whether:
- Passing tests exercise code paths where this fallback is used
- There are documented scenarios where
getCreatedWith()returns undefined in the session token creation flowIf no such scenarios exist and tests pass, the fallback may be unnecessary legacy code worth removing.
spec/EmailVerificationToken.spec.js (5)
301-309: LGTM!Test correctly verifies that the
createdWithfield is now included in the verification request and has the expected value for signup scenarios.
370-378: LGTM!Test assertions correctly updated to include the new
createdWithfield in the request keys and verify its value.
413-443: LGTM!The new test effectively verifies that
createdWithis provided during signup when email verification blocks session creation. The test:
- Correctly configures the server with verification requirements
- Verifies the spy is called the expected number of times
- Asserts the correct
createdWithvalue with signup action and password auth provider
445-476: LGTM!The new test properly verifies that
createdWithincludes the correct auth provider during login verification. The test flow is logical:
- Creates a user first
- Reconfigures server with verification callback
- Attempts login and verifies the
createdWithparameter has login action
867-901: LGTM!Correctly asserts that
createdWithisundefinedforverificationEmailRequest(resend) scenarios, which makes sense since resending doesn't represent a new signup or login action.src/Options/index.js (2)
46-57: LGTM!The new
EmailVerificationRequesttype properly documents the request structure passed to email verification callbacks, including the newcreatedWithfield that provides context about the invocation (signup vs login) and auth provider used.
189-203: LGTM!The updated signatures for
verifyUserEmailsandpreventLoginWithUnverifiedEmailcorrectly extend these options to accept functions that receive anEmailVerificationRequestand return a boolean or Promise. This enables conditional verification logic based on thecreatedWithcontext, which was the goal of this PR.The documentation clearly explains the new functionality and indicates that the function receives a request object with
createdWithinformation.Note: The static analysis errors about TypeScript-only syntax are expected for Flow files and can be ignored.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## alpha #9963 +/- ##
==========================================
- Coverage 92.54% 92.52% -0.02%
==========================================
Files 190 190
Lines 15499 15523 +24
Branches 176 176
==========================================
+ Hits 14343 14363 +20
- Misses 1144 1148 +4
Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@coratgerl let's just consider the insights already gained in existing PRs. What't the diff between your PR and #9651? |
|
Key Improvements:
Testing:
Bonus:
|
|
This one is ready for review @mtrezza :) |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
types/Options/index.d.ts (1)
29-40: Consider aligning the interface name with the Flow type.The interface name
VerifyUserEmailsRequestdiffers from the Flow typeEmailVerificationRequestinsrc/Options/index.js. While this file is manually maintained, having consistent naming across both type systems would improve maintainability and reduce confusion for contributors.Consider renaming to match the Flow type:
-export interface VerifyUserEmailsRequest { +export interface EmailVerificationRequest {And update the references on lines 89-90 accordingly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
spec/EmailVerificationToken.spec.js(4 hunks)spec/ValidationAndPasswordsReset.spec.js(1 hunks)src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)src/Options/index.js(2 hunks)types/Options/index.d.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- spec/ValidationAndPasswordsReset.spec.js
- src/Options/docs.js
- spec/EmailVerificationToken.spec.js
- src/Options/Definitions.js
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.
📚 Learning: 2025-12-02T06:55:53.808Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T06:55:53.808Z
Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js.
Applied to files:
types/Options/index.d.tssrc/Options/index.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.
Applied to files:
types/Options/index.d.tssrc/Options/index.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.
Applied to files:
types/Options/index.d.tssrc/Options/index.js
📚 Learning: 2025-11-17T15:02:48.786Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.
Applied to files:
src/Options/index.js
🪛 Biome (2.1.2)
src/Options/index.js
[error] 45-57: type alias are a TypeScript only feature. Convert your file to a TypeScript file or remove the syntax.
TypeScript only syntax
(parse)
[error] 189-189: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 193-193: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 201-201: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: Redis Cache
- GitHub Check: Node 20
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: Node 22
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: Docker Build
- GitHub Check: Code Analysis (javascript)
- GitHub Check: Benchmarks
🔇 Additional comments (3)
src/Options/index.js (2)
46-57: Type definition looks well-structured for the verification context.The
EmailVerificationRequesttype properly captures:
- Standard request context (
original,object,master,ip,installationId)- The new
createdWithfield withactionandauthProvideras specified in issue #9505- The
resendRequestflag for distinguishing resend flowsNote: The static analysis hints from Biome are false positives—this file uses Flow type annotations, not TypeScript.
189-193: UpdatedverifyUserEmailssignature enables conditional verification logic.The updated type signature properly supports:
- Backward compatibility with
boolean- New function variant receiving
EmailVerificationRequestwithcreatedWithcontextThe documentation clearly describes the new capability. This aligns well with the feature request in issue #9505.
types/Options/index.d.ts (1)
89-90: TypeScript option signatures correctly updated.The updated signatures properly reflect the new functional interface, enabling type-safe conditional verification logic. The function variant correctly accepts the request context and supports both synchronous and async (
Promise<boolean>) return values.
|
Is this one not good for you @mtrezza ? Let me know what you think of this version ? |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/Options/index.js`:
- Around line 194-203: Update the JSDoc for the preventLoginWithUnverifiedEmail
option to describe both boolean and function usages: mention it can be true to
block login until verification or be a function that receives an
EmailVerificationRequest and returns a boolean or Promise<boolean>, and document
the EmailVerificationRequest fields (including createdWith like the sibling
verifyUserEmails doc does) so the generated docs (via npm run definitions)
reflect the function signature and available request properties; update the
comment block around preventLoginWithUnverifiedEmail to mirror the style and
details used for verifyUserEmails.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@src/Routers/UsersRouter.js`:
- Around line 143-154: The code repeatedly calls Object.keys(req.body.authData)
and joins multiple keys into a comma string (e.g., "facebook,google"), which
breaks callers expecting a single provider; fix by reading the authData keys
once (e.g., const providers = req.body && req.body.authData ?
Object.keys(req.body.authData) : []) and set authProvider to providers[0] (or
undefined/fallback) instead of joining, then pass that authProvider into
RestWrite.buildCreatedWith('login', authProvider); update the authProvider
variable and remove the duplicate Object.keys calls around Parse.User.fromJSON
and RestWrite.buildCreatedWith to avoid the inefficiency and incorrect
multi-provider string.
- Around line 297-301: The session creation in RestWrite.createSession currently
uses RestWrite.buildCreatedWith('login') which hardcodes
createdWith.authProvider to 'password' even when req.body.authData indicates
another provider; update the handleLogIn flow to either (a) set
createdWith.authProvider based on the computed provider from req.body.authData
(use the same logic that verifies authData) when calling
RestWrite.createSession, or (b) if the existing behavior is intentional, add a
concise clarifying comment near RestWrite.createSession /
RestWrite.buildCreatedWith and in handleLogIn noting that authData is treated as
supplementary and the session creation always records 'password' as the primary
auth method so future readers understand why req.body.authData is not reflected
in createdWith. Ensure you reference RestWrite.createSession,
RestWrite.buildCreatedWith, handleLogIn, and req.body.authData when making the
change.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/Options/index.js (1)
236-236:⚠️ Potential issue | 🟡 MinorFlow type for
sendUserEmailVerificationis inconsistent with its new parser.The type here is
?(boolean | void), butDefinitions.js(line 577) was updated in this PR to useparsers.booleanOrFunctionParser. The Flow type should be updated to also accept a function, similar toverifyUserEmailsandpreventLoginWithUnverifiedEmail:Suggested fix
- sendUserEmailVerification: ?(boolean | void); + sendUserEmailVerification: ?(boolean | void | (EmailVerificationRequest => boolean | Promise<boolean>));
|
@coratgerl the PR had several issues; I found it more efficient to just go ahead and fix them:
|
|
@coderabbitai check whether this contains any breaking changes. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/Options/index.js`:
- Around line 46-61: Rename the Flow or TypeScript type so both use the same
identifier: choose either EmailVerificationRequest or VerifyUserEmailsRequest
and make the other match; update the Flow type declaration for
EmailVerificationRequest or rename the TS interface VerifyUserEmailsRequest
accordingly, and adjust any exports/usages (notably in verifyUserEmails and
preventLoginWithUnverifiedEmail signatures) to reference the unified name so
both type systems stay consistent.
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 5965 🏁 Script executed: Length of output: 6183 🏁 Script executed: Length of output: 6633 🏁 Script executed: Length of output: 6165
Backward Compatibility PreservedBoolean values still work: The new Before (alpha branch):
After (this PR):
Why This Is Non-Breaking
Summary✅ All existing configurations remain valid This is a feature addition with full backward compatibility. 🧠 Learnings used |
mtrezza
changed the title
verifyUserEmailsverifyUserEmails, preventLoginWithUnverifiedEmail to identify invoking signup / login action and auth provider
# [9.3.0-alpha.1](9.2.1-alpha.2...9.3.0-alpha.1) (2026-02-06) ### Features * Add event information to `verifyUserEmails`, `preventLoginWithUnverifiedEmail` to identify invoking signup / login action and auth provider ([#9963](#9963)) ([ed98c15](ed98c15))
|
🎉 This change has been released in version 9.3.0-alpha.1 |
|
Thanks you for your feedback ! |
3 participants
Pull Request
Issue
Fixes: #9505
Summary by CodeRabbit
New Features
Documentation
Types
Tests
Chores