Guia Prático para Usar Supabase com Clerk

A autenticação de usuários é crucial para qualquer aplicativo web, mas protegê-la adequadamente pode ser demorado. Para simplificar, muitos desenvolvedores optam por soluções prontas. Este artigo explora como Integrar Clerk com Supabase, utilizando um DB function para conectar os serviços e garantir que os dados do usuário sejam sincronizados e acessíveis no seu aplicativo.

Conectando Clerk e Supabase com um DB Function

Para Integrar Clerk com Supabase de forma eficaz, é essencial conectar os dois serviços. Felizmente, o Clerk oferece um DB function que facilita essa integração. Essa função atua como uma ponte entre o sistema de autenticação do Clerk e o banco de dados do Supabase, garantindo que os dados do usuário sejam sincronizados e acessíveis dentro do seu aplicativo.

Essa função permite que o user_id do Clerk seja utilizado no Supabase, simplificando a gestão de acesso e a segurança dos dados. Ao entender como essa função opera, você garante que a autenticação funcione sem problemas e de forma segura. Com essa função implementada, podemos configurar as políticas de segurança em nível de linha (RLS) em nossas tabelas.

Confira a função abaixo e vamos analisá-la linha por linha:

CREATE OR REPLACE FUNCTION requesting_user_id()
RETURNS TEXT AS $$
    SELECT NULLIF(
        current_setting('request.jwt.claims', true)::json->>'sub',
        ''
    )::text;
$$ LANGUAGE SQL STABLE;

• CREATE OR REPLACE FUNCTION requesting_user_id()
  • Cria uma nova função chamada “requesting_user_id()”
  • Sobrescreve a função se ela já existir
• RETURNS TEXT AS $$
  • Especifica que a função retornará um valor “TEXT”
  • $$ – Usado para iniciar blocos de código SQL. Uma alternativa mais legível às aspas simples ‘’

• Declaração SELECT

  
  SELECT NULLIF(
      current_setting('request.jwt.claims', true)::json->>'sub',
      ''
  )::text;
  

  • NULLIF – Compara ‘sub’ e uma string vazia. Se ‘sub’ estiver vazio, garante que NULL seja retornado em vez de uma string vazia.
  • ::text – Converte o resultado para TEXT para corresponder a como estamos armazenando os user_ids em nossas tabelas Supabase.
  • current_setting() – Uma função PostgreSQL que recupera o valor de uma configuração.
    • Consulte a documentação do PostgreSQL
    • 'request.jwt.claims' – Uma configuração do Supabase que contém o payload JWT para a solicitação do banco de dados.
    • true – Garante que NULL seja retornado se a configuração não existir, em vez de um erro.
  • ::json – Converte o JWT para o formato JSON
  • ->> 'sub' – Obtém o campo subject do JWT
    • sub é o identificador exclusivo do usuário. O Clerk inclui isso no payload JWT.
• LANGUAGE SQL – Especifica que a função está em SQL
• STABLE – Indica que a saída da função permanece a mesma para a mesma entrada, a menos que os dados subjacentes mudem.

Configurando o RLS no Supabase para Clerk

As políticas de segurança em nível de linha (RLS) são usadas para definir as regras de acesso ou modificação dos dados de uma tabela SQL. Sem essas restrições, qualquer pessoa poderia ler, editar ou excluir nossos dados confidenciais armazenados, o que representa um grande risco à privacidade.

O objetivo é garantir que os usuários só possam acessar seus próprios dados quando estiverem logados. Graças à função requesting_user_id(), criada para verificar a autenticação do Clerk, configurar as políticas de RLS se torna muito mais fácil. A Clerk YouTube tutorial e a documentação do Clerk podem te ajudar a entender mais.

Para restringir o acesso a dados para usuários autenticados, usamos uma verificação SQL simples em nossa política RLS para garantir que o user_id atual do Clerk corresponda ao user_id na tabela Supabase. Essa verificação impede que usuários não autorizados acessem ou modifiquem os dados.

requesting_user_id() = user_id

A documentação do Clerk explica claramente como criar suas próprias políticas RLS. Consulte o Passo 3 do tutorial da documentação para criar algumas para o seu próprio projeto.

Aqui está uma consulta usada no meu aplicativo WhereNow que cria uma política RLS para a tabela list_items:

CREATE POLICY "Select list_items policy" 
ON "public"."list_items" 
AS PERMISSIVE 
FOR SELECT 
USING (
  EXISTS (
    SELECT 1 
    FROM "public"."lists" 
    WHERE "lists"."id" = "list_items"."list_id"
    AND "lists"."user_id" = requesting_user_id()
  )
);

Essa consulta faz o seguinte:

• Cria uma política para a tabela list_items:
  • Ela se aplica à tabela list_items no esquema public e define como os usuários podem interagir com ela.
• Define a política como “PERMISSIVE”:
  • Isso significa que a política permite o acesso se a condição for atendida.
• Aplica a política às operações SELECT:
  • Essa política afeta especificamente as consultas SELECT na tabela list_items
    • (Deve criar outras políticas para UPDATE, DELETE e INSERT)
• Define restrições para selecionar linhas
  • USING especifica as condições em que os usuários têm permissão para executar uma consulta SELECT na tabela list_items.
  • Duas condições:
    • A chave estrangeira list_id na linha list_items deve corresponder a uma lista no id de uma lista na tabela lists.
    • O user_id associado a essa list deve corresponder ao requesting_user_id(), que é o ID do usuário autenticado no momento.
• Garante que os usuários só possam acessar seus próprios itens da lista:
  • Ao usar a função requesting_user_id(), a política garante que os usuários só possam ver os list_items associados às suas próprias listas, garantindo privacidade e segurança de dados.

Essa consulta se aplica apenas à operação SELECT, mas você pode aplicar políticas semelhantes para outras operações para proteger ainda mais os dados da sua tabela.

Em resumo, ao Integrar Clerk com Supabase, você garante um sistema de autenticação eficiente e seguro para sua aplicação. O desafio principal é conectar esses dois serviços e entender como fazê-lo corretamente. Exploramos o processo de criação de um DB function personalizado que integra o JWT do Clerk com o Supabase para verificar se os usuários estão devidamente autenticados. Em seguida, implementamos políticas de segurança em nível de linha (RLS) para restringir o acesso a informações confidenciais, garantindo que cada usuário só possa acessar seus próprios dados.

Ao entender e implementar essas etapas, você pode configurar rapidamente um sistema de autenticação seguro para seu aplicativo web e concentrar mais energia na construção de recursos importantes. Desejo muito sucesso em seus projetos!

Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.