name: painel-corretor-api-debug

description: Debug Auth0 JWT failures from server IPs to Painel do Corretor (Trindade) API — Cloudflare blocking server-origin requests

tags:

- painel-do-corretor

- auth0

- cloudflare

- n8n

- supabase

Painel do Corretor - Server-to-API Auth Debug

Problem

JWT Auth0 tokens that work perfectly in the user's browser fail with AUTH_NOT_AUTHORIZED or 403 AUTH when called from any server environment (n8n container, Supabase Edge Functions, VPS, AWS).

Root Cause

Painel do Corretor (Trindade Tecnologia) uses Cloudflare protection that blocks requests originating from known cloud/server IP ranges, even when a valid Auth0 JWT is provided.

Discovery Process

1. Tested n8n container → 403 AUTH from direct HTTPS calls to Painel API

2. Tested Supabase Edge Function (runs on AWS) → AUTH_NOT_AUTHORIZED from negociosElastic

3. Tested browser (same JWT) → 200 OK perfectly

4. Key headers that matter: origin: https://app2.paineldocorretor.com.br, referer: https://app2.paineldocorretor.com.br/crm/negocios, x-tenant: a1af7a2f-7ec6-40cd-b257-86c045875979, full browser User-Agent, sec-fetch-site: cross-site

5. Without these headers (n8n minimal HTTP client) → 400 Bad Request

Failed Solutions

• - Supabase Edge Function proxy: Function deploys and receives calls correctly, but Painel still returns AUTH_NOT_AUTHORIZED because the request still originates from AWS IP
• - n8n HTTP Request node: Same 403 AUTH even with full browser headers
• - Adding cookies (auth0=s%3Av1...): Does not help, token still rejected from server IP

Working Approach

Use the browser as the token source. The user captures a fresh JWT from:

1. Open DevTools → Network tab on CRM page

2. Find POST /graphql request

3. Copy Authorization: Bearer eyJ... header value

4. Use as a manual n8n credential variable, refreshed when workflow fails

Alternative: Refresh Token Flow

The account has offline_access scope — implement Auth0 refresh token rotation:

1. One-time: user provides refresh_token (from Auth0 auth.refreshToken in localStorage)

2. n8n workflow uses a "Refresh Token" node to get new access_token before each sync

3. Refresh token stored as n8n credential, rotated on expiry

Supabase Edge Function (painel-crm-proxy)

Already deployed at dauftiqcvgaydddoxqhh project — accepts FooBarQuery, passes to Painel, but blocked. Keep as template for future when server-IP blocking is resolved.

Painel API Details

• - GraphQL: https://api.paineldocorretor.net/graphql
• - REST: https://api.paineldocorretor.net/api/crm/negocios/
• - Auth: JWT RS256 Auth0, issuer https://auth.paineldocorretor.com.br/
• - Tenant ID: a1af7a2f-7ec6-40cd-b257-86c045875979
• - User: contato@rochasalesseguros.com.br / Auth0 user auth0|6710fefc90c5ce12e2c17b61

Confirmed Root Cause: IP-based Cloudflare Blocking

The Painel API blocks ALL requests originating from cloud/server IP ranges via Cloudflare, regardless of JWT validity. This includes:

• - n8n container IPs
• - Supabase Edge Functions (AWS)
• - Any VPS/cloud provider IP

Evidence: A JWT captured from localStorage (which was confirmed fresh via iat: 1779067089 = 2026-05-18 01:04:49 UTC) still returned AUTH_NOT_AUTHORIZED when routed through a Supabase Edge Function. The same JWT works in the browser on the same machine.

The blocking is purely IP-based — the server/cloud IP is flagged by Cloudflare, not the token.

JWT Extraction from localStorage (easiest method)

In the browser console on any Painel page:

`javascript

JSON.parse(localStorage.getItem('vuex') || '{}').auth?.accessToken

`

This returns the current valid JWT directly — no need to find a Network tab request.

Token details from May 18 2026 session:

• - sub: auth0|6710fefc90c5ce12e2c17b61
• - email: contato@rochasalesseguros.com.br
• - exp: ~1779326289 (may differ by capture)
• - scope: openid profile email offline_access
• - iss: https://auth.paineldocorretor.com.br/

Painel CRM IDs (stable across sessions)

Etapa	ID
-------	-----
Novos Leads	60008110-e9b1-4512-b514-ab1539ea1a1e
Qualificação	885d4f95-99e5-42a0-8150-b494c42c0e34
Remarketing	6699997d-6978-4679-8b4c-eaab9917fefd
Reunião Agendada	4646a3e9-b21a-4339-b75b-6997fa3dbb76
Proposta Enviada	4e61480b-b4dc-4b80-b0c8-dd3ddf8e43b2
Análise Seguradora	29511da1-1e40-4e9c-8b14-a268ccbdc1d0
Aguardando Pgto	2584da59-4c1e-4fcb-8cba-8374acd896a7
Negócios Fechados	df8db361-5b4c-4e66-baac-afcfd9fbe50a
Declinado	70150b84-6864-4cff-aae1-83195a182d8d
Sem Interesse	63f4b9df-55d6-4ff0-a42c-af5ff2ff367b

Failed Solutions (documented)

• - Supabase Edge Function proxy: Deployed at dauftiqcvgaydddoxqhh.supabase.co/functions/v1/painel-crm-proxy — blocked by Cloudflare IP filter
• - Accept-Encoding: identity header: Was a false lead — the issue is IP-based, not encoding-based
• - Adding cookies to request: Does not bypass IP block
• - SERVICE_ROLE_KEY with Supabase: Returns UNAUTHORIZED_LEGACY_JWT at gateway level (not your code) — ANON_KEY passes to function but is rejected by Painel due to IP

Supabase Edge Function Notes

• - ANON_KEY format works for Edge Function auth (your code receives it)
• - SERVICE_ROLE_KEY is rejected by Supabase Gateway before reaching your code (UNAUTHORIZED_LEGACY_JWT)
• - Edge Function deployed here: https://dauftiqcvgaydddoxqhh.supabase.co/functions/v1/painel-crm-proxy
• - ANON_KEY: eyJ_REDACTED

Status

Blocked — permanent IP block. Solutions that avoid server-side HTTP calls needed (see alternatives below).

Alternative Approaches (viable)

1. Browser-based automation (Playwright/Puppeteer on residential IP) — runs on user's local machine with Brazilian IP

2. Auth0 refresh token rotation — get a refresh_token once, use it to generate new access_tokens server-side without the IP block issue (Auth0 API, not Painel API)

3. Residential proxy — route n8n's HTTP calls through a Brazilian residential proxy (e.g., Brightdata, ScraperAPI) with Brazilian IPs

4. User-provided fresh JWT — user manually captures JWT from browser and pastes into n8n credential; valid until expiry (~1 week)