Supabase master #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## What kind of change does this PR introduce? Currently, the flow states don't expire as expected as the check is faulty Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? With the introduction of an Authentication Method check on `FindFlowStateByUserID` we may wish to add an index. Also introduces an idempotency condition on flow state related migrations. Finally, updates the old Postgres comment by [issuing a new comment to overrwrite previous comment](https://www.postgresql.org/docs/current/sql-comment.html) Left as draft till this is tested together with other remaining PKCE changes. --------- Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? * Email change requests on `PUT /user` should adhere to the max frequency rule.
…Error (supabase#1080) Missed this, follows from supabase#1078 which allows us to substitute the following two errors --------- Co-authored-by: [email protected] <[email protected]>
) ## What kind of change does this PR introduce? Refactor around the redirect url generation for pkce. Done for consistency with how the other redirect urls are generated, and also to cut back on a few lines of code. --------- Co-authored-by: [email protected] <[email protected]>
…er (supabase#1092) ## What kind of change does this PR introduce? * Fixes supabase#1060, supabase#988 * Allows one to pass in an optional `currentUser` into `IsDuplicatedUser` to exclude the user's identities when checking for duplicates * This is optional because on signup / admin create user, there won't be a current user so it's guaranteed that any identities found belongs to a different user. ## Current behaviour * Currently, `IsDuplicatedEmail` only accepts an `email` and an `aud` and uses those fields to check if the `auth.identities` table has identities with the same email. When this is used in the context of updating a user's email (`PUT /user`), `IsDuplicatedEmail` will also include identities that belong to the current user. --------- Co-authored-by: Joel Lee <[email protected]>
## What kind of change does this PR introduce? The current MFA checks are quite unreadable. Have refactored parts of it and I think there's more to refactor. --------- Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? Add PKCE to email Change routes ## What is the current behavior? No PKCE on email change routes ## What is the new behavior? PKCE on email change routes ## Additional context There's an additional AMR claim known as `email_change` I'm not sure whether we want to have a special claim for this given that `email_change` is not typically classed as a login method. The other option would be to use the Magic Link AMR claim instead. Let me know if anyone has a preference here. Should be tested with: https://github.com/supabase/gotrue-js/pull/661/files TODOs: - [x] Tests need to be written for the PKCE path --------- Co-authored-by: [email protected] <[email protected]>
as per title Co-authored-by: [email protected] <[email protected]>
## Overview Captcha providers are treated as generic in this PR. Users can swap out the provider which in turn swaps out only the `siteverify` URL. This approach generally works fine when considering `turnstile` and `hcaptcha` since both have similar feature sets. However, for other providers like `recaptcha` users might want to use specialized features such as Android recaptcha and recaptcha V3 score. Since the [responses slightly differ between an android response and a generic response](https://developers.google.com/recaptcha/docs/verify), we may need to introduce separate structs. Another alternative considered was to initialize a new provider type for each methods (similar to `SMSProvider`) and have corresponding `verifyCaptcha` methods for each provider. This way there is clear separation of decoding logic for response types for each provider but there will be slightly more code to maintain. ### TODOs: - [x] Manual testing with FE components After PR: - Update dashboard to reflect additional provider - Update [hcaptcha docs](https://supabase.com/docs/guides/auth/auth-captcha) --------- Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? Currently, it seems like PKCE flow implementation incorrectly adds a `?` instead of a `&` to the url when there is a redirect with multiple parameters (e.g. on `/resend` like in the url below:) . This PR aims to fix this. --------- Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? Fix the `PUT` `/admin/providers/<id>` endpoint not committing the SAMLProvider changes to the database when updating the metadata XML (resulting in a no-op). ## What is the current behavior? Updates to the metadata XML via the `/admin/providers/<id>` should be reflected on the `saml_provider` database object. ## What is the new behavior? The provider metadata XML can now be correctly updated.
The issue is that the modified account linking algorithm _always_ linked SSO to non-SSO accounts if a similar email account was present.
## What kind of change does this PR introduce? * Migration to remove duplicate index wasn't idempotent
Adds appropriate audit log statements for access tracking and also for metrics tracking. For metrics tracking we can also monitor requests to the endpoint as a whole --------- Co-authored-by: [email protected] <[email protected]>
If the SAML Metadata defined via a URL does not publish validity or cache duration information, forcefully try to update it every 24 hours.
## What kind of change does this PR introduce? * Fix supabase#1095 where `/resend` doesn't work if the user initially signed up with a phone number and is trying to resend an email change email
Certain database entities such as refresh tokens and sessions pile up though normal operation without being cleaned up. This PR attempts to solve the problem by using a `models.Cleanup` function which takes care of these entities. The cleanup runs after each request on non-idempotent HTTP methods (POST, PUT, DELETE, PATCH). It uses fast deletes and updates using [`FOR UPDATE SKIP LOCKED`](https://www.postgresql.org/docs/current/sql-select.html#SQL-FOR-UPDATE-SHARE) so that deletes don't wait for other transactions to complete. It runs after each request as this model scales better than a background job that runs periodically as it is using resources only when the API is being used externally, making database use proportional to work performed. Rows are deleted about 24-72 hours after they have expired to aid in debugging if ever necessary.
…pabase#1099) Aims to prevent the existing issue where the session seems to be lost and a null pointer execption is raised. HS ID: 1575266879 The root cause is still unidentified and we have only been able to reproduce once. Hoping that with the guard check we can flag more instances. Last recorded occurrence was in April We will follow up with the user to see if there are any repeat occurences --------- Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? This PR adds Kakao(https://accounts.kakao.com/) as an external provider. ## What is the current behavior? This provider did not exist before. ## What is the new behavior? Based on Kakao developer docs(https://developers.kakao.com/), this PR creates a provider & test suite for Kakao external provider. ## Additional context Please let me know if there are any changes needed, I do acknowledge that this was once mentioned in another [comment](supabase#451 (comment)), but it seemed like the PR had been frozen since then. I wrote my own version to make sure the tests do pass and the features work properly. --------- Co-authored-by: Kang Ming <[email protected]>
## What kind of change does this PR introduce? * Improves on supabase#725, albeit with a slightly different approach * Gotrue will accept an allow list of domains via a comma-separate string (`DOMAIN_ALLOW_LIST`) , which includes the `API_EXTERNAL_URL` by default. On each request, gotrue will check that the domain being used is also included in the allow list. * When gotrue starts up, it will take the `DOMAIN_ALLOW_LIST` and convert it into a map where the key is the hostname and the value is the url * When a request is made to gotrue, gotrue will check the `DomainAllowListMap` to check if there is a matching hostname before allowing the request through. If there isn't a matching hostname used, gotrue will default to use the `API_EXTERNAL_URL` instead. * This helps to make gotrue usable with multiple custom domains, and also allows the email links to contain the custom domain. * Since the `EXTERNAL_XXX_REDIRECT_URI` is derived during runtime, we can remove that config once this PR is merged in as long as the `REDIRECT_URI` is also included in the `DOMAIN_ALLOW_LIST` --------- Co-authored-by: Joel Lee <[email protected]>
## What kind of change does this PR introduce? This PR extends supabase#875 to clean up MFA challenges as well so that they don't clog the database. ## How this was tested set `GOTRUE_DB_CLEANUP_ENABLED = true` 1. Sign up locally 2. Enroll a factor 3. `ab -p testfileforab -T application/json -H 'Authorization: Bearer <token>' -c 10 -n 100 http://localhost:9999/factors/0bca5d9c-157a-4a15-890c-2ad33415b4f3/challenge` 4. `update auth.mfa_challenges set created_at = created_at - interval '48 hours';` 5. Make about 7 requests to ensure there's a cleanup performed --------- Co-authored-by: [email protected] <[email protected]>
With supabase#999 custom domains were introduced, however for OAuth, the redirect URLs should in fact be the ones specified in the config and not ones interpreted from the `X-Forwarded-Host` header.
…1121) Aims to address supabase#1120 How this was tested: - Remote instance with Github OAuth. Enable captcha 1. Attempt to sign up w/o captcha token - this should fail 2. Attempt to sign in with Github OAuth w/o token - this should succeed and session should be loaded --------- Co-authored-by: [email protected] <[email protected]> Co-authored-by: Kang Ming <[email protected]>
## What kind of change does this PR introduce? Aims to address supabase#1111 --------- Co-authored-by: [email protected] <[email protected]>
…1108) Previously OIDC sign in (i.e. sign-in using an ID token) for Apple, Google and a few other providers was not properly supported. There was no account linking available, and there were a few security issues found with the implementation. This PR attempts to resolve all of the issues, specifically targeting Apple and Google providers, which enables native Sign in with Apple and Google with mobile or desktop apps. Furthermore, this PR paves the way towards SSO with OIDC support. Basically, the whole `POST /token?grant_type=id_token` endpoint is refactored to use the central `createAccountFromExternalIdentity` method which supports both regular and SSO accounts with automatic account linking. For both Apple and Google flows, the important thing to realize is that their OAuth2 flows are in-fact OIDC authentication flows. The Apple OAuth2 flow already used the Apple OIDC ID token to extract user information. The Google OAuth2 flow is refactored to use the OIDC ID token when available (appears to be always) or fall back to the previous implementation. Since it does not matter whether the flow is OAuth2 or OIDC, automatic account linking can take place. The remaining OIDC supported providers -- Azure, Facebook, Keycloak -- remain supported though with upgraded account linking support; however their implementations are best-effort at this point. Furthermore, the Keycloak implementation should be deprecated as it's actually solving a SSO-with-OIDC problem.
Google seem to rotate their OIDC JWKS keys regularly, which made the tests fail. This time the verifier is overridden and uses a static key at the time of generating of the ID token.
## What kind of change does this PR introduce? As per [this PR](supabase#679) and the we have deprecated opentracing and are removing it in favour of opentelemetry. This will make the update of the opentelemetry dependcies easier as we no longer have to consider opentracing specific dependencies. Relevant internal context: https://supabase.slack.com/archives/C022071RB2L/p1699451083111579 --------- Co-authored-by: [email protected] <[email protected]>
Strips the `User-Agent` header so that it's not traced by OpenTelemetry, while making it available for the rest of the middlewares. Fixes: https://github.com/supabase/gotrue/security/dependabot/11
## What kind of change does this PR introduce? See title - [x] Need to update docs PR to update GoTrue: https://github.com/supabase/gotrue/pull/1277/files Docs Update: supabase#1277 --------- Co-authored-by: [email protected] <[email protected]>
Enforces a single session per user with optional tags. If a session has a tag, only the most recently refreshed session with the same tag can be refreshed. If no tags are configured, then only the most recently refreshed session of all of the user's sessions will be refreshed. Sessions that are invalid due to inactivity or timeboxing won't be considered.
## What kind of change does this PR introduce? * If `GOTRUE_ALLOW_UNVERIFIED_EMAIL_SIGN_INS` is enabled, it will allow a user with an unverified email address to sign in and obtain an access token JWT * This is particularly useful for OAuth in cases where the oauth provider doesn't return an email address / the oauth user didn't verify their email address with the OAuth provider. * Tests that broke and needed fixing were due to these reasons: * `RemoveUnconfirmedIdentities` was previously buggy and shouldn't be retaining the user metadata of a previously unconfirmed identity * `GOTRUE_ALLOW_UNVERIFIED_EMAIL_SIGN_INS` is enabled by default which caused some tests to return an access token instead of an error for a user with an unverified email ## Modifications made to automatic linking algorithm * If the candidate identity doesn't have a verified email, the decision should be to create a new account. * If the email belongs to a user already, then we opt to create a new user with no email. Previously, we would attempt to create a new user and the db will return an error due to the partial unique constraint on email violation. In order to add an email to the new user, they would have to call update user (`PUT /user`) to add a new email.
supabase#1310) ## What kind of change does this PR introduce? * This PR introduces a new error type `CommitWithError` that allows one to commit a transaction but also return an error. * This is useful in situations where `GOTRUE_MAILER_ALLOW_UNVERIFIED_EMAIL_SIGN_INS="false"` since oauth users with an unverified email will require email confirmation before being allowed to sign-in. If the transaction doesn't get committed, the new user doesn't get created and the email confirmation sent out will not be mapped to a user in the database.
Refresh token reuse revocation was broken, as an error was returned from the transaction where the revocation took place, which rolled back any changes. This went unnoticed as the reuse error was sent. Ouch.
…upabase#1313) ## What kind of change does this PR introduce? * default `GOTRUE_MAILER_ALLOW_UNVERIFIED_EMAIL_SIGN_INS` to false
## What kind of change does this PR introduce? * We need to be able to have a consistent identifier to fetch an identity from the database. The current approach for using a composite primary key isn't sufficient and not ideal for exposing through the API. * Remove the composite primary key on (`auth.identities.id`, `auth.identities.provider`) * Rename `auth.identities.id` to `auth.identities.provider_id` * Add a new primary key called `auth.identities.id` * Add a unique constraint on (`auth.identities.provider_id`, `auth.identities.provider`) --------- Co-authored-by: Stojan Dimitrovski <[email protected]>
## What kind of change does this PR introduce?
* Adds an endpoint `DELETE /user/identities/{identity_id}` to allow the
user to unlink an identity
* User is only allowed to unlink an identity if they have more than 1
identity linked
* User must be authenticated to unlink the identity
```curl
// successful request
$ curl -X DELETE 'http://localhost:9999/user/identities/{identity_id}' -H 'Authorization: Bearer <user's JWT>'
{}
```
---------
Co-authored-by: Stojan Dimitrovski <[email protected]>
…upabase#1316) Bumps [github.com/go-jose/go-jose/v3](https://github.com/go-jose/go-jose) from 3.0.0 to 3.0.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/go-jose/go-jose/releases">github.com/go-jose/go-jose/v3's releases</a>.</em></p> <blockquote> <h2>Version 3.0.1</h2> <h3>Fixed</h3> <p>Security issue: an attacker specifying a large "p2c" value can cause JSONWebEncryption.Decrypt and JSONWebEncryption.DecryptMulti to consume large amounts of CPU, causing a DoS. Thanks to Matt Schwager (<a href="https://github.com/mschwager"><code>@mschwager</code></a>) for the disclosure and to Tom Tervoort for originally publishing the category of attack. <a href="https://i.blackhat.com/BH-US-23/Presentations/US-23-Tervoort-Three-New-Attacks-Against-JSON-Web-Tokens.pdf">https://i.blackhat.com/BH-US-23/Presentations/US-23-Tervoort-Three-New-Attacks-Against-JSON-Web-Tokens.pdf</a></p> <p>The release is tagged off the release-v3.0.1 branch to avoid mixing in some as-yet unreleased changes on the v3 branch.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/go-jose/go-jose/blob/v3/CHANGELOG.md">github.com/go-jose/go-jose/v3's changelog</a>.</em></p> <blockquote> <h1>v3.0.1</h1> <p>Fixed:</p> <ul> <li>Security issue: an attacker specifying a large "p2c" value can cause JSONWebEncryption.Decrypt and JSONWebEncryption.DecryptMulti to consume large amounts of CPU, causing a DoS. Thanks to Matt Schwager (<a href="https://github.com/mschwager"><code>@mschwager</code></a>) for the disclosure and to Tom Tervoort for originally publishing the category of attack. <a href="https://i.blackhat.com/BH-US-23/Presentations/US-23-Tervoort-Three-New-Attacks-Against-JSON-Web-Tokens.pdf">https://i.blackhat.com/BH-US-23/Presentations/US-23-Tervoort-Three-New-Attacks-Against-JSON-Web-Tokens.pdf</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/go-jose/go-jose/commit/47edce0854d533ac27795c9befd90b1f7ef87554"><code>47edce0</code></a> Fix decryption DoS: Reject too high p2c (<a href="https://redirect.github.com/go-jose/go-jose/issues/66">#66</a>)</li> <li>See full diff in <a href="https://github.com/go-jose/go-jose/compare/v3.0.0...v3.0.1">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/supabase/gotrue/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Follows the pattern where all admin handlers are named `adminXYZ`.
) Password sign-up would perform the password hashing while a database connection is open, thereby blocking it unnecessarily for tens of milliseconds. This can result in behavior where just a few password sign-up calls could slow down Auth entirely as the password hashing causes pool exhaustion and thus increased latency across all Auth APIs not just the password sign-up calls. The hashing is done inside `models.NewUser()` making it very difficult to refactor properly. Therefore, the model object generation is now moved as a function of `api.SignupParams.ToUserModel()`. If these params contain a password, the code is refactored to move the model generation outside of the database transaction.
Refactors all places where the password strength check (right now just length check) is enforced to a single method on the API `checkPasswordStrength`. To do this, both `SignupParams` and `UserUpdateParams` had to be reworked. Furthermore user update now splits basic validation logic from user update validation logic and the main updating transaction which should drastically speed up the method itself.
## What kind of change does this PR introduce? The mfa tests are hard to read. There's also a lot of redundant code which makes testing for hooks quite a bit harder. This PR aims to remove some of the redundancy so that it's easier to write the tests for supabase#1314 Main changes include - Splitting out `enrollAndVerify` into `enroll` and `verify` - Using suite specific constants - Packaging duplicated setup code --------- Co-authored-by: [email protected] <[email protected]>
Adds the `GOTRUE_PASSWORD_REQUIRED_CHARACTERS` config option, which if set, will reject passwords that do not contain at least one character of each set of characters. It is defined like so: `abc...xyz:0123...89`. This means that at least one lowercase and one digit has to be present in the password to be accepted. All other characters are also allowed. To include the `:` character, escape it with `\:`. When a weak password is detected, the HTTP 429 error is sent with an additional JSON field `weak_password` that includes a `reasons` property -- an array of the strings: - `length` if the password is not long enough - `characters` if the password does not use all required character sets --------- Co-authored-by: Kang Ming <[email protected]>
## What kind of change does this PR introduce?
* Adds a new endpoint `GET /user/identities/authorize` which is an
endpoint to initiate the manual linking process and can only be invoked
if the user is authenticated
* `GET /user/identities/authorize` functions similarly to `GET
/authorize` where the user needs to login to the new oauth identity in
order to link the identity
* Example
```curl
// sign in with one of the supported auth methods to get the user's access token JWT first
// start the identity linking process
$ curl -X GET "http://localhost:9999/user/identities/authorize?provider=google" -H "Authorization: Bearer ACCESS_TOKEN_JWT"
{"url":"https://oauth_provider_url.com/path/to/sign-in"}
// visit the url returned and login to the oauth provider
// request will be redirected to the /callback endpoint
// if the identity is successfully linked, the request will be redirected to `http://localhost:3000/#access_token=xxx&....`
// if the identity already exists, the request will be redirect to:
// http://localhost:3000/?error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user#error=invalid_request&error_code=400&error_description=Identity+is+already+linked+to+another+user
```
## Details
* The callback endpoint used will be the same callback as the oauth
sign-in flow so that the developer doesn't have to add any additional
callback URLs to the oauth provider in order to enable manual linking
* A special field `LinkingTargetId` is introduced in the oauth state to
store the linking target user ID. This ID will be used in the callback
to determine the target user to link the candidate identity used
* If the identity is already linked to the current user or another user,
an error will be returned
* If the identity doesn't exist, then it will be successfully linked to
the existing user and a new access & refresh token will be issued.
---------
Co-authored-by: Stojan Dimitrovski <[email protected]>
Uses Supabase's HIBP Go library to perform password strength checks using the HaveIBeenPwned.org Pwned Passwords API. You can configure this behavior by: - `GOTRUE_PASSWORD_HIBP_ENABLED` to turn it on - `GOTRUE_PASSWORD_HIBP_USER_AGENT` to specify your project's identifier - `GOTRUE_PASSWORD_HIBP_FAIL_CLOSED` if the API is unavailable (or unresponsive for 5 seconds) the response is ignored and any password is accepted, set this to true to fail with a 500 error in such cases - `GOTRUE_PASSWORD_HIBP_BLOOM_ENABLED` to enable a bloom filter cache - `GOTRUE_PASSWORD_HIBP_BLOOM_ITEMS` to specify the maximum number of pwned password hashes to be stored in the bloom filter - `GOTRUE_PASSWORD_HIBP_BLOOM_FALSE_POSITIVES` to specify the maximum number of false positives returned by the bloom filter, a value between 0 and 1 indicating _1 in X_ For bloom filters, use this calculator to understand the values: https://hur.st/bloomfilter By default 100,000 password hashes can be stored in the filter (about 100 hash prefixes). The filter resets at 80% of this value to ensure that the cache is cleared and the actual false positive rate does not go too high.
## What kind of change does this PR introduce? Proof of concept hook for MFA Verification. With this hook, developers can introduce additional conditions around when to accept/reject an MFA verification (e.g. log a developer out after a certain number of attempts). We distinguish this from the existing Webhooks implementation via introduction of `hooks` package which will contain future Hook related structs, constants, and utility methods. For the most part we leverage existing Postgres capabilities - as far as possible we will return the PostgreSQL error codes for debugging and use Postgres in-built timeouts to ensure hte hook doesn't overrun. ## Testing The MFA Verification Hook test suite does not guarantee accurate status codes - the test setup (to enroll factors and create a challenge after signup) requires some setup. It is reliant on `signUpAndVerify` which gets the dev to AAL2 and takes time to refactor. As such, most of the cases were manually tested in addition to the current loose check of checking for the absence of an access token. Further edits will be made in GMT +8 morning to properly check for the http status codes in the tests. Also, since `supabase_auth_admin` cannot create functions on the `public` schema we create the functions on the `auth` schema for testing. We typically discourage this on the Supabase platform but in theory there should be no issue when dealing with GoTrue (the OSS project). Will spend a short amount of time looking into alternatives tomorrow. ## Additional Notes Response schema checks are left out of this PR as they don't seem to serve as much benefit for this particular extensibility point and will probably bloat the PR a little with the introduction of a new library --------- Co-authored-by: [email protected] <[email protected]> Co-authored-by: Stojan Dimitrovski <[email protected]>
## What kind of change does this PR introduce? * A primary identity is implicitly defined by the first identity created when the user signs up * Addresses the issue where unlinking a primary identity results in the `auth.users.email` becoming stale. If the other identities do not have the same email, the `auth.users.email` column should be updated to use one of the existing identities emails * Update the `FindProvidersByUser` method to remove duplicates if there is more than 1 identity that share the same provider
Refactors the error handling of hooks so the proper errors bubble up.
## What kind of change does this PR introduce? Similar to the MFA Verification Hook, this hook should allow for developers to customize the behaviour of Supabase after a failed password verification attempt. Example use cases include: - blocking a user after multiple failed attempts. - Imposing additional restrictions on top of password verification. --------- Co-authored-by: [email protected] <[email protected]> Co-authored-by: Kang Ming <[email protected]>
## What kind of change does this PR introduce? Primary goal of this refactor is to reduce number of calls to `generateAccessToken` to ease refactoring of `generateAccessToken`. This PR centralizes a few commonly used functions/objects: - `generateAccessToken` - `models.User` - It also directly accesses `models.Factors` on `ts.TestUser` instead of fetching it from the DB via `models.FindFactorsByUserID` Tests with multiple cases were left untouched as they have interleaving interactions in some cases --------- Co-authored-by: [email protected] <[email protected]>
## What kind of change does this PR introduce? Similar to supabase#1333 we centralize the setup around `generateAccessToken` Co-authored-by: [email protected] <[email protected]>
Pull Request Test Coverage Report for Build 7096792374Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.