mirror of
https://github.com/supabase/supabase.git
synced 2026-05-06 08:56:46 -04:00
docs: fix duplicate-word typos in troubleshooting guides (#45297)
Fixes two small duplicate-word typos in troubleshooting guides: - `apps/docs/content/troubleshooting/using-google-smtp-with-supabase-custom-smtp-ZZzU4Y.mdx`: "easy to to figure out" → "easy to figure out" - `apps/docs/content/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z.mdx`: "for for service role" → "for service role" Pure docs typo fix — no functional changes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation * Corrected grammatical errors in troubleshooting guides for Google Workspace SMTP configuration and service-role key errors. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
This commit is contained in:
+1
-1
@@ -10,7 +10,7 @@ database_id = "4d5390a0-445d-4e0a-ae7e-9b713b7cc4f6"
|
||||
Hey everyone, i've been hearing feedback about how challenging it can be to get google SMTP working properly with Supabase. I've tried setting this up with a trial google workspace account and this is what i've discovered.
|
||||
|
||||
1. The sender email and SMTP username has to be your google workspace admin email.
|
||||
2. The SMTP password used has to be an app password. Google workspace doesn't make it easy to to figure out how to create this. You need to **enable 2FA** on your workspace account first (not inside the admin console but in https://myaccount.google.com/)
|
||||
2. The SMTP password used has to be an app password. Google workspace doesn't make it easy to figure out how to create this. You need to **enable 2FA** on your workspace account first (not inside the admin console but in https://myaccount.google.com/)
|
||||
3. If you want to use `smtp-relay.gmail.com` only port 465 works. If you want to use `smtp.gmail.com`, you can use port 465 or 587.
|
||||
The following screenshots show what those steps look like:
|
||||
|
||||
|
||||
+1
-1
@@ -22,6 +22,6 @@ Three common cases of the `createClient` `apikey` being replaced by a user sessi
|
||||
|
||||
2. Edge functions or other server code setting the `Authorization` header in `createClient` options directly to a user token/JWT. When you set the `Authorization` header directly that overrides the default action of using the `apikey` for the `Authorization` header.
|
||||
|
||||
3. Server client initialized with service role using `signUp` to create a user or other auth functions. Many auth functions will return a user session to the client making the call. When that happens the `apikey` will be replaced by the user token/JWT in the `Authorization` header. If you are wanting to create a user in a service role client use `admin.createUser()` instead. Otherwise use a separate Supabase client for for service role from other actions.
|
||||
3. Server client initialized with service role using `signUp` to create a user or other auth functions. Many auth functions will return a user session to the client making the call. When that happens the `apikey` will be replaced by the user token/JWT in the `Authorization` header. If you are wanting to create a user in a service role client use `admin.createUser()` instead. Otherwise use a separate Supabase client for service role from other actions.
|
||||
|
||||
Also note that adding `service_role` in RLS policies does nothing. Service role will never run the policies to begin with.
|
||||
|
||||
Reference in New Issue
Block a user