## 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: joel@joellee.org <joel@joellee.org>

## 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: joel@joellee.org <joel@joellee.org>

## 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: joel@joellee.org <joel@joellee.org>

)

## 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: joel@joellee.org <joel@joellee.org>

…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 <lee.yi.jie.joel@gmail.com>

## 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: joel@joellee.org <joel@joellee.org>

## 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: joel@joellee.org <joel@joellee.org>

as per title

Co-authored-by: joel@joellee.org <joel@joellee.org>

## 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: joel@joellee.org <joel@joellee.org>

## 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: joel@joellee.org <joel@joellee.org>

## 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: joel@joellee.org <joel@joellee.org>

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: joel@joellee.org <joel@joellee.org>

## 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 <kang.ming1996@gmail.com>

## 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 <lee.yi.jie.joel@gmail.com>

Needed for supabase#1108.

## 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: joel@joellee.org <joel@joellee.org>

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: joel@joellee.org <joel@joellee.org>
Co-authored-by: Kang Ming <kang.ming1996@gmail.com>

## What kind of change does this PR introduce?

Aims to address supabase#1111

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

…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.

It appears that some Azure accounts may not have an `email` claim but do
have
[`otherMails`](https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-profile-attributes).
GoTrue will also extract those emails and use the first one of those as
the primary if no email is defined.

…abase#1132)

PingIdentity usually sends the email address in `Mail` with capital M.
We also are allowing deleting the user record when the user is SSO with
the admin API.

When GoTrue needs to update the SAML metadata XML by fetching from the
URL, there were a few issues:

- `Update` was being called with a non-pointer argument which generally
fails with a panic in Pop 😞
- Only the `metadata_xml` and `updated_at` columns should be updated

This PR fixes it.

## What kind of change does this PR introduce?
* When updating a user's email or phone number, if the user previously
did not have an email or phone number associated to their account,
gotrue will create an new identity for it. However, subsequent attempts
to update the user's email or phone number will result in gotrue
attempting to create the same identity again. This results in postgres
returning a unique constraint violation.

For example, assuming that the user signed up with email + password
initially:

```bash
# this request will create a phone identity and send an OTP to the user
curl -X PUT "http://localhost:9999/user" -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"phone": "123456789"}'

# this request will return a "duplicate key value violates unique constraint" error because gotrue attempts to create the same phone identity
curl -X PUT "http://localhost:9999/user" -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"phone": "123456789"}'
```

* ~This PR attempts to fix this issue by only creating the identity if
the user's `phone` or `phone_change` columns are empty.~

## What kind of change does this PR introduce?
* Create a `Validate()` method to handle the validation of the request
body separately
* Moves some of the input validation out of the transaction into the
`Validate()` method

…upabase#1138)

Bumps [github.com/lestrrat-go/jwx](https://github.com/lestrrat-go/jwx)
from 1.2.25 to 1.2.26.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/lestrrat-go/jwx/releases">github.com/lestrrat-go/jwx's
releases</a>.</em></p>
<blockquote>
<h2>[SECURITY] v1.2.26</h2>
<pre><code>v1.2.26 - 14 Jun 2023
[Security]
* Potential Padding Oracle Attack Vulnerability and Timing Attack
Vulnerability
for JWE AES-CBC encrypted payloads affecting all v2 releases up to
v2.0.10,
all v1 releases up to v1.2.25, and all v0 releases up to v0.9.2 have
been reported by
    @shogo82148.
<pre><code>Please note that v0 versions will NOT receive fixes.
This release fixes these vulnerabilities for the v1 series.
</code></pre>
<p></code></pre></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/lestrrat-go/jwx/blob/v1.2.26/Changes">github.com/lestrrat-go/jwx's
changelog</a>.</em></p>
<blockquote>
<p>v1.2.26 - 14 Jun 2023
[Security]</p>
<ul>
<li>
<p>Potential Padding Oracle Attack Vulnerability and Timing Attack
Vulnerability
for JWE AES-CBC encrypted payloads affecting all v2 releases up to
v2.0.10,
all v1 releases up to v1.2.25, and all v0 releases up to v0.9.2 have
been reported by
<a
href="https://github.com/shogo82148"><code>@​shogo82148</code></a>.</p>
<p>Please note that v0 versions will NOT receive fixes.
This release fixes these vulnerabilities for the v1 series.</p>
</li>
</ul>
<p>[Miscellaneous]</p>
<ul>
<li>JWE tests now only run algorithms that are supported by the
underlying
<code>jose</code> tool</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/lestrrat-go/jwx/commit/d9ddbc8e5009cfdd8c28413390b67afa7f576dd6"><code>d9ddbc8</code></a>
merge v1 (<a
href="https://github.com/lestrrat-go/jwx/issues/936">#936</a>)</li>
<li>See full diff in <a
href="https://github.com/lestrrat-go/jwx/compare/v1.2.25...v1.2.26">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=github.com/lestrrat-go/jwx&package-manager=go_modules&previous-version=1.2.25&new-version=1.2.26)](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 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] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Returns the SMS message ID as received from the SMS sending provider in
`/otp` and `/resend` to aid in debugging deliverability issues. Logs
also include the message ID when available.

These allow for standards compliant identification of the GoTrue server
issuing the JWTs as well as the key it is signing the keys with.

## What kind of change does this PR introduce?
* There was a regression awhile back for resending email change links so
i've made the fix and added some tests to ensure it doesn't happen in
the future

## What kind of change does this PR introduce?
* Set `IsSSOUser` field on user only after err has been checked, else
this might result in a panic the the rare case where `models.NewUser`
returns an error

## What kind of change does this PR introduce?

Feature

## What is the current behavior?

No provider for Figma.

## What is the new behavior?

This PR adds a new provider for Figma.

## Additional context
The Figma OAuth2 API only provides a single scope ("file_read"), so
there isn't a more restrictive scope solely for getting user metadata.

Figma developer reference: https://www.figma.com/developers/api#oauth2

## What kind of change does this PR introduce?

Aims to add Twilio Verify Support. Twilio Verify is implemented as a
separate provider. Only one of Twilio Verify or Twilio Programmable
messaging an be selected. At this time, we only support the use of the
`whatsapp` and `sms` channels with Twilio Verify.

This will affect the:
1. Signup flow
2. Verification flow (sms and phone_change)
3. Resend

The token is still generated, but not used in the Twilio Verify flow. It
is used as a placeholder so as to try to ensure that to the OTP returned
by the Verify service can only be used with the corresponding flow it
was generated for.

## What is the current behaviour?

We support programmable messaging.

## What is the new behaviour?

Developer can toggle between using Twilio Programmable Messaging on all
flows or Twilio Verify on all flows.

## Additional context

Manual tests:

Probably need to be conducted on both Phone Change and SMS OTP
Verification:

- [x] Existing Programmable Messaging (SMS/WhatsApp)
(Signup/Verify/PhoneChange)
- [x] Twilio Verify(SMS/WhatsApp) 
- [ ] Update Frontend to include Twilio Verify

Admin methods shouldn't need to be updated to send to Twilio Verify
since admin methods don't require confirmation

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>
Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>

This addresses differences in eol handling between OSes by normalizing
the line endings using a `.gitattributes` file.

On Windows, cloning the repo and building the containers causes the
Postgres container to fail to initialize and shutdown early due to
`init_postgres.sh` being copied into the container with Windows line
endings.

Fixes supabase#1155

New clones of the repo shouldn't have issues with this after this PR is
merged. Existing clones which don't already contain `LF` line endings
may have to reset using
```
git rm --cached -r .
git reset --hard
```
to update their files' line endings.

Ignores the built gotrue.exe file generated on Windows.

This improves development experience and repo contribution if the user
clones the repo to a Windows environment.

## What is the current behavior?

Git marks the built gotrue.exe file as untracked.

## What is the new behavior?

Git ignores the gotrue.exe file as it already does with similar built
files.

Switches to github.com/supabase/mailme instead of Netlify's mailme
package.


Fixes:
- supabase#870

…supabase#1152)

Removes `SafeRoundTripper` which was a HTTP `RoundTripper` which did not
allow establishing HTTP connections to servers listening on private IP
addresses.

This is probably inherited from the Netlify codebase, and was added as a
safeguard to avoid cyclic requests with their hooks implementation which
is not used by Supabase.

Why it's absolutely normal to expect connections to private IP
addresses:

- Running GoTrue in Kuberenetes, AWS ECS, or other places. 
- Local development with Docker, which loves to create virtual private
networks inside containers all the time.
- Caches inside VPCs.
- Rendering templates served only within the VPC and not those that are
publicly available.

Right now, probably due to a bug, `POST /logout` would log the user out
from _all_ sessions they have. This is not always desired behavior.

This change adds a new `scope` query param on `/logout` with these
values:
- `global` (default when not provided) Logs a user out from all sessions
they have.
- `local` Logs a user out from the current session only.
- `others` Logs a user out from all other sessions except the current
one.

See:
- supabase/auth-js#713

Centralizes the code to log out a user on password change. When an admin
changes a password for a user, the logout is also performed now.

## What kind of change does this PR introduce?
* Maintains the order of the query params passed into the email link

## What kind of change does this PR introduce?
* Updating a user's password should only require reauthentication if the
current session is not recent (created more than 24hrs ago)

When the user updates their password, the new and old passwords must be
different. When an admin does it, this is not checked.

## What kind of change does this PR introduce?
* To enable server-side redirection via an email link, we need some way
to return the session in the response body rather than in the query
fragments (`GET /verify`) because the fragments can't be parsed on the
server-side.

* By allowing `POST /verify` to accept just a token hash, a developer
would be able to set the verification URL in their email template to
point to their own endpoint
(`https://myapp.com/confirm-signup?token_hash=XXX&type=signup`) and
parse the `token_hash` param before calling `POST /verify` with the
following:

```bash
curl -X POST 'http://localhost:9999/verify' -H 'Content-Type: application/json' \ 
-d '{"token_hash": "my_token_hash", "type": "signup" }'
```

If the token hash is valid and the request is successful, this would
return the verified user's session in the response and the developer can
subsequently handle any redirection on their own.

---------

Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>

…base#1167)

`updated_at` was not being updated when the token family was being
revoked, which makes it impossible to figure out when the revocation
actually happened.

## What kind of change does this PR introduce?
* Simplify PKCE param validation logic

---------

Co-authored-by: Joel Lee <lee.yi.jie.joel@gmail.com>

…ase#1170)

Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from
1.46.2 to 1.53.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/grpc/grpc-go/releases">google.golang.org/grpc's
releases</a>.</em></p>
<blockquote>
<h2>Release 1.53.0</h2>
<h1>API Changes</h1>
<ul>
<li>balancer: support injection of per-call metadata from LB policies
(<a
href="https://github.com/grpc/grpc-go/issues/5853">#5853</a>)</li>
<li>resolver: remove deprecated field
<code>resolver.Target.Endpoint</code> and replace with
<code>resolver.Target.Endpoint()</code> (<a
href="https://github.com/grpc/grpc-go/issues/5852">#5852</a>)
<ul>
<li>Special Thanks: <a
href="https://github.com/kylejb"><code>@​kylejb</code></a></li>
</ul>
</li>
</ul>
<h1>New Features</h1>
<ul>
<li>xds/ringhash: introduce <code>GRPC_RING_HASH_CAP</code> environment
variable to override the maximum ring size. (<a
href="https://github.com/grpc/grpc-go/issues/5884">#5884</a>)</li>
<li>rls: propagate headers received in RLS response to backends (<a
href="https://github.com/grpc/grpc-go/issues/5883">#5883</a>)</li>
</ul>
<h1>Bug Fixes</h1>
<ul>
<li>transport: drain client transport when streamID approaches
MaxStreamID (<a
href="https://github.com/grpc/grpc-go/issues/5889">#5889</a>)</li>
<li>server: after GracefulStop, ensure connections are closed when final
RPC completes (<a
href="https://github.com/grpc/grpc-go/issues/5968">#5968</a>)</li>
<li>server: fix a few issues where grpc server uses RST_STREAM for
non-HTTP/2 errors (<a
href="https://github.com/grpc/grpc-go/issues/5893">#5893</a>)</li>
<li>xdsclient: fix race which can happen when multiple load reporting
calls are made at the same time. (<a
href="https://github.com/grpc/grpc-go/issues/5927">#5927</a>)</li>
<li>rls: fix a data race involving the LRU cache (<a
href="https://github.com/grpc/grpc-go/issues/5925">#5925</a>)</li>
<li>xds: fix panic involving double close of channel in xDS transport
(<a
href="https://github.com/grpc/grpc-go/issues/5959">#5959</a>)</li>
<li>gcp/observability: update method name validation (<a
href="https://github.com/grpc/grpc-go/issues/5951">#5951</a>)</li>
</ul>
<h1>Documentation</h1>
<ul>
<li>credentials/oauth: mark <code>NewOauthAccess</code> as deprecated
(<a
href="https://github.com/grpc/grpc-go/issues/5882">#5882</a>)
<ul>
<li>Special Thanks: <a
href="https://github.com/buzzsurfr"><code>@​buzzsurfr</code></a></li>
</ul>
</li>
</ul>
<h2>Release 1.52.3</h2>
<h1>Bug Fixes</h1>
<ul>
<li>Fix user-agent version</li>
</ul>
<h2>Release 1.52.2</h2>
<h1>Bug Fixes</h1>
<ul>
<li>xds: fix panic involving double close of channel in xDS transport
(<a
href="https://github.com/grpc/grpc-go/issues/5959">#5959</a>)</li>
</ul>
<h2>Release 1.52.1</h2>
<h1>Bug Fixes</h1>
<ul>
<li>grpclb: rename grpclbstate package back to state (<a
href="https://github.com/grpc/grpc-go/issues/5963">#5963</a>)</li>
</ul>
<h2>Release 1.52.0</h2>
<h1>New Features</h1>
<ul>
<li>xdsclient: log node ID with verbosity INFO (<a
href="https://github.com/grpc/grpc-go/issues/5860">#5860</a>)</li>
<li>ringhash: impose cap on <code>max_ring_size</code> to reduce
possibility of OOMs (<a
href="https://github.com/grpc/grpc-go/issues/5801">#5801</a>)</li>
</ul>
<h1>Behavior Changes</h1>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/grpc/grpc-go/commit/dba26e15a07f43875ccf806a2dd6cbcbc1c12eab"><code>dba26e1</code></a>
Change version to 1.53.0 (<a
href="https://github.com/grpc/grpc-go/issues/5983">#5983</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/2a1e9348ff7b5d9f4b5039e84e6c9873b5b3e26e"><code>2a1e934</code></a>
server: after GracefulStop, ensure connections are closed when final RPC
comp...</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/e2d69aa076dd070e3668784c4dc8bcf7131b3f67"><code>e2d69aa</code></a>
tests: fix spelling of variable (<a
href="https://github.com/grpc/grpc-go/issues/5966">#5966</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/a6376c9893f56fc3819bee9ef5d71f55cc2d38dd"><code>a6376c9</code></a>
xds/resolver: cleanup tests to use real xDS client 3/n (<a
href="https://github.com/grpc/grpc-go/issues/5953">#5953</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/bf8fc46fa6eb913e4ed0f6dee6c6a7b75e85fbf0"><code>bf8fc46</code></a>
xds/resolver: cleanup tests to use real xDS client 5/n (<a
href="https://github.com/grpc/grpc-go/issues/5955">#5955</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/3930549b38c0fc4cd94a95efccf7cef5f90515fd"><code>3930549</code></a>
resolver: replace resolver.Target.Endpoint field with Endpoint() method
(<a
href="https://github.com/grpc/grpc-go/issues/5852">#5852</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/894816c487f8dd48fc971c45a7c5baa4b86ef7de"><code>894816c</code></a>
grpclb: rename <code>grpclbstate</code> package back to
<code>state</code> (<a
href="https://github.com/grpc/grpc-go/issues/5962">#5962</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/e5a0237a46a5f95fa571624929be10c7afebb180"><code>e5a0237</code></a>
encoding: fix duplicate compressor names (<a
href="https://github.com/grpc/grpc-go/issues/5958">#5958</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/4adb2a7a00d8b62df5ea34d520fe3ca13bffd31a"><code>4adb2a7</code></a>
xds/resolver: cleanup tests to use real xDS client 2/n (<a
href="https://github.com/grpc/grpc-go/issues/5952">#5952</a>)</li>
<li><a
href="https://github.com/grpc/grpc-go/commit/52a8392f374b8cd60e176b67925a7f8c1605d014"><code>52a8392</code></a>
gcp/observability: update method name validation (<a
href="https://github.com/grpc/grpc-go/issues/5951">#5951</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/grpc/grpc-go/compare/v1.46.2...v1.53.0">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=google.golang.org/grpc&package-manager=go_modules&previous-version=1.46.2&new-version=1.53.0)](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 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] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

supabase#1129)

## What kind of change does this PR introduce?

We amend the error messages to return both ? messages and # messages
when using the PKCE flow for backward compatibility with the client
libraries. The client libraries will be able to fetch error message from
error fragments with this change.

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?
* Remove captcha protection on `id_token` grant since the protection is
provided by the OIDC issuer
* Fixes supabase#1172

…base#1177)

## What kind of change does this PR introduce?
* Allow `POST /verify` to accept the email verification type when used
together with the `token_hash`
* For example:
```
curl -X POST "http://localhost:9999/verify" -H "Content-Type: application/json" -d '{"token_hash": "d00bae897e954fd46a72d72ee9e00eb3e061541413395f08f7f754c1", "type": "email"}'
```

…abase#1176)

## What kind of change does this PR introduce?

Allow autoconfirm signup to be used with PKCE. When used with PKCE,
autoconfirm signups retain their behaviour of returning an access token
directly

## What is the current behavior?

Calling signup with autoconfirm enabled will throw an error

## What is the new behavior?

Calling signup with autoconfirm enabled will return a session similar to
implicit flow

## Additional context

Linked to:
https://github.com/supabase/gotrue/pulls?q=is%3Apr+is%3Aclosed++accept+

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?

Removes the expiry on flow state which might overshadow the `OTP expiry`
since default OTP expiry (1 day) is typically longer than default flow
state expiry (5 mins). Flow state expiry is still enforced on token
exchange.

## What is the current behavior?

Flow state expiry is checked on verification/issuance of Auth code

## What is the new behavior?

No flow state expiry check on verification of magic link. Flow state
expiry continues to be enforced on token exchange.

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?

Docs update.

## What is the current behavior?

There is no table of contents so it is not easy to search the docs.

## What is the new behavior?

There is now a table of contexts for easier searching of the docs.

## Additional context

N/A

## What kind of change does this PR introduce?
* Currently, we always log
[`r.Referer()`](https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/net/http/request.go;l=454)
in the gotrue logs. However, this assumes that the referrer is always
sent in the header which is false.
* Move the functions to get the referrer and validate the referrer to
the `utilities` package so it can be used across the `api` and
`observability` packages
* Removed `getRedirectURLOrReferrer` because it's basically a repeat of
`getReferrer`. You would still need to parse the `redirect_to` before
calling `getRedirectURLOrReferrer` and `getReferrer` handles the parsing
+ validation for us already.

## What kind of change does this PR introduce?
* Rate limit for total emails / sms-es sent should only be applied when
autoconfirm is disabled

To make the `token.go` file less busy.

## What kind of change does this PR introduce?

Removes currently unused code to improve maintainability of codebase and
to increase code coverage. Feel free to let me know if there's anything
people would like to keep though as some functions may have use in the
near future.

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

…#1190)

Improves the `refresh_token` grant flow by serializing access over the
session ID, so that a session cannot concurrently be refreshed.

It achieves this by adding a boolean `forUpdate` parameter to
`models.FindSessionByID()` and `models.FindUserWithRefreshToken()`. This
in turn uses a [`SELECT ... FOR
UPDATE`](https://www.postgresql.org/docs/current/sql-select.html#SQL-FOR-UPDATE-SHARE)
query that locks the row from use with other flows that select it with a
`FOR UPDATE` clause.

## What kind of change does this PR introduce?

withDefault returns a string, so cast isn't strictly needed

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?

see title -  relevant command:
```
#!/bin/bash

# Function to apply sed command to files in a directory
replace_in_files() {
  # The sed command with the pattern for replacement
  sed -E -i '' 's/fmt\.Sprintf\("%x", sha256\.Sum224\(\[\]byte\(([^+]+)\+([^)]+)\)\)\)/crypto.GenerateTokenHash(\1, \2)/g' "$1"
}

# Check if a directory is provided as an argument
if [ -z "$1" ]; then
  echo "Please provide the directory path as an argument."
  exit 1
fi

# Check if the directory exists
if [ ! -d "$1" ]; then
  echo "Directory not found: $1"
  exit 1
fi

# Loop through all files in the directory and apply the sed command
for file in "$1"/*; do
  if [ -f "$file" ]; then
    replace_in_files "$file"
  fi
done
```

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

Should be using `tx` in refresh token grant instead of `db`. Thanks
@bnjmnt4n for [spotting
this](supabase#1190 (comment)).

Adds a new `GOTRUE_CORS_ALLOWED_HEADERS` config option to add additional
allowed headers when performing CORS with GoTrue.

There are cases where the response for an access and refresh token takes
more than 1 second. In such cases, `gotrue-js` will record the *expiry
time* as the time it received the response + `expires_in`. However, this
is not correct because the access token is likely to have already
expired by the recorded time.

With this change, `gotrue-js` can just use an `expires_at` value
instead. `expires_in` is still sent for backward compatibility.

Was not using the latest version.

## What kind of change does this PR introduce?
* We're querying for the session redundantly when we already have the
sessionId. Every time we query for a session, it fetches all the amr
claims tied to the session too.
* There's no need to query for the entire session when we already have
the session id, since the `auth.mfa_amr_claims` table already has a
foreign-key constraint on the `auth.sessions.id` column, the insert will
fail if the given `sessionId` doesn't exist

When developers build mobile apps that use phone login, they need to
provide pre-determined phone numbers and OTPs that will work so that
automated and manual app reviewers (that work at Apple's AppStore or
Google's Play Store) can test and confirm compliance with the phone
system.

Those reviewers / systems cannot be expected to provide their own phone
number.

Developers can thus set up the following environment variable:

```
GOTRUE_EXTERNAL_SMS_TEST_OTP="<phone-1>=<otp-1>, <phone-2>=<otp-2>..."
GOTRUE_EXTERNAL_SMS_TEST_OTP_VALID_UNTIL="<ISO date time>"
```

SMS messages are not sent to those test phone numbers. Furthermore after
the validity period has expired, they will automatically not be used.
This enhances the security so that people don't forget test OTPs
accidentally.

Incidentally this makes it possible to use phone number logins when
developing locally.

WhatsApp is supported by Twilio Verify but we've missed the validation
here.

With supabase#1190 each refresh token request was serialized with other such
requests. However, in cases where there's a not-insignificant number of
parallel refresh token requests for the same refresh token, a situation
arises where a significant number of connections are opened against the
database that perform little work. Furthermore, if GoTrue is configured
with a bounded connection pool, this could lead to significantly reduced
performance of the server.

With these changes, when `SELECT ... FOR UPDATE` is used on the refresh
token and session row, it is now done using the `SKIP LOCKED` clause. If
one or both of those rows are already locked, GoTrue will immediately
release the database connection, wait 10-30 ms and try to refresh the
token again. If after 5s the lock cannot be acquired, a HTTP 409
Conflict error will be returned. Clients should consider waiting at
least a few seconds before retrying on this error.

Support the use of Message IDs for Twilio Programmable Messaging on the
WhatsApp channel. Arising from a customer request during their launch.

The`whatsapp:` channel currently only works when using a phone number in
the Message Service ID field. It was assumed that developers would only
wish to use `whatsapp` channel with a phone number.

However, customers may wish to use
[Geomatch](https://support.twilio.com/hc/en-us/articles/223181268-What-is-Geomatch-and-how-does-it-work-)
in order to use both SMS and WhatsApp channels. When using Geomatch,
Twilio will select the best suited number within the Sender pool of the
Message Service and use that as the sender. For instance, if sending to
the UK and there is a UK number Twilio and a German number will likely
the UK number over the German number.

As Geomatch only works with Message IDs we need to add support for using
MessageIDs on the `whatsapp` channel on Programmable Messaging.


Not needed for Twilio Verify as Twilio Verify does not require the
channel to be prefixed before a phone number.

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

…messages (supabase#1188)

## What kind of change does this PR introduce?

As per microtask, refactors the way in which we generate the sms message
template.

Cautionary note: if merged, an error will be thrown if a Key other than
Code is placed into the SMS template (e.g. `Your code is {{ .Code}} and
{{ .SomeOtherKey}}`) and an attempt to send SMS is made. While users
hopefully do not have such templates we will need to update the FE input
to guard agains this

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?

Bug fix, setting sane defaults

## What is the current behavior?
supabase#1194

- If the configuration API_EXTERNAL_URL is not set requests to gotrue
return 500 errors. This configuration was undocumented and only part of
some examplary configurations.

- If the URLPaths for the Mailer are not set they defaulted to / which
by default is not the correct endpoint to handle verification requests.

## What is the new behavior?

- API_EXTERNAL_URL needs to be set for gotrue to start.
- URLPaths for Invite,Confirmation,Recovery and EmailChange are set to
"/verify" by default instead of "/"

…e#1213)

- Move metric counter to observability package so that we can reuse it
to track other metrics
- Rename `NetlifyMicroserviceClaims` to `AuthMicroserviceClaims`


Supports the email rate limit task

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?

This PR aims to expose a set of email rate limit metrics as a Prometheus
metric that can then be consumed by an alerting system like Prometheus.
When a rate limit is triggered we increment a counter. This can then be
passed to a monitoring system such as Prometheus alert manager which can
fire off a notification (or similar) when a threshold (say 5 occurrences
in an hour) has been breached.

Extends: supabase#1213 


The presence of the metric was tested via using the default
`prometheus.yml` file that comes on download. To test that the rate
limit is firing, we decreased `GOTRUE_RATE_LIMIT_EMAIL_SENT="5"` to 5
and ran `ab` against the endpoint like

`ab -p mass_signup.txt -T application/json -c 10 -n 50
http://localhost:9999/otp`

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?
* OTP should be test if not using the test OTP

---------

Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>

## What kind of change does this PR introduce?

Move the check for whether email logins are enabled into the resend
function. Also checks if Phone Logins are enabled before proceeding to
resend

## What is the current behavior?

Currently, the check is done in middleware. This would mean that resend
requests with phone based logins will not go through if email logins are
disabled.

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

## What kind of change does this PR introduce?

Adds support for PKCE to the SSO flow

- We don't introduce a foreign key since we can have relay states which
use the implicit flow and won't have an associated flow state.

How this was tested:
- On staging with Okta as IDP, on an instance with the branch version of
GoTrue uploaded

GoTrue-js PR:
- supabase/auth-js#707

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>

…ase#1231)

## What kind of change does this PR introduce?
- Exposes the email address that we're sending to so that devs can
customize the email conditionally

### Follow Up Tasks
- [x] [Update Docs around Email Templates and Update Dashboard to
reflect that the SendingTo parameter
exists](https://github.com/supabase/supabase/blob/master/studio/stores/authConfig/schema/AuthProviders/AuthTemplatesValidation.tsx#L128)
See [the dashboard PR](supabase/supabase#16970)

### How this was tested

Build and update a staging project to use the GoTrue binary from this
branch.

On staging, add `{{.SendingTo}}` as a parameter and execute email
change. Confirm that the parameter is parsed on both emails when using
secure email change.

---------

Co-authored-by: joel@joellee.org <joel@joellee.org>
Co-authored-by: Kang Ming <kang.ming1996@gmail.com>

…upabase#1234)

Fixes an issue when `GOTRUE_SMS_TEST_OTP_VALID_UNTIL=""` the
[time.Time.UnmarshalText()](https://pkg.go.dev/time#Time.UnmarshalText)
function is called which does not handle empty strings. An empty string
generally means unset.

Note that `*time.Time` would not work for the same reason.