Temporary Access rejects valid scoped PAT for mapped read-only role (28P01)

[jasonscrivens-ai]

Summary

On a managed Supabase Free project using the Temporary Access preview, a fresh scoped Personal Access Token is accepted by the Management API but rejected by the Shared Pooler for an active mapped read-only role.

No database query succeeds. No database password was reset, and no schema or data change was attempted.

Environment

• Managed Supabase Free project
• PostgreSQL 17.6+
• Windows client with PostgreSQL psql 18
• Shared Pooler session mode on port 5432 over IPv4
• SSL enforcement enabled
• Temporary Access enabled
• Active, unexpired rule for the built-in supabase_read_only_user role
• Rule applies to all project databases
• Source-IP restriction matches the current client; no network ban is present
• Fresh 24-hour scoped PAT limited to this project with Database JIT: Read

Connection shape

The token is passed through PGPASSWORD, not embedded in a URI. The connection uses:

user=supabase_read_only_user.
sslmode=require
options='-c jit=true'

The pooler hostname is copied from the Dashboard and DNS/TCP connectivity succeeds.

Verification

• GET /v1/projects/<project-ref>/database/jit with the same token returns HTTP 200.
• The Dashboard shows the member/role mapping as Active and unexpired.
• The client public IP matches the rule's allowed CIDR.
• The token reaches psql without whitespace or URI-encoding ambiguity.
• The failure reproduces through multiple resolved IPs for the same Shared Pooler hostname.

Expected first query:

select current_user, current_setting('transaction_read_only');

Expected result: supabase_read_only_user with read-only mode enabled.

Actual result before any query runs:

FATAL: password authentication failed for user "supabase_read_only_user"

A direct PostgreSQL comparison is unavailable from this client because the current network has no IPv6 default route.

Questions

1. Is a scoped PAT with Database JIT: Read currently supported as the PostgreSQL password for Temporary Access, or does this preview still require a legacy account-level PAT?
2. Does an active JIT role mapping require a propagation delay or managed resynchronization before Supavisor accepts it?
3. Is there a supported diagnostic that distinguishes a PAT-scope rejection from a missing/stale Supavisor JIT mapping?
4. Is direct IPv6 PostgreSQL currently the only supported bypass when Shared Pooler JIT authentication returns 28P01?

Related official material:

• Temporary Access documentation
• Scoped PAT alpha announcement
• Related Supavisor 28P01 discussion

I have intentionally omitted the project reference, IP address, token, email address, and complete connection string from this public report.

[cekuu35]

Teşhise geçmeden önce — Temporary Access (JIT) için doğru bağlantı biçimi

Resmi dokümana göre (Temporary Access) JIT bağlantısında PAT'ınız password olarak kullanılır ve shared pooler'a ekstra bir conninfo option'ı gerekir:

user=supabase_read_only_user.<project-ref>
options='-c jit=true'

Bunu zaten yapmışsınız, o yüzden sorun büyük olasılıkla aşağıdakilerden biri:

1. Scoped PAT, JIT'te henüz kabul edilmiyor olabilir (en sık karşılaşılan)

Temporary Access dokümanı "Personal Access Token" der ve scoped PAT ayrı bir alpha duyurusu (#48717). İkisi aynı şey değildir. Varsayılan davranış, legacy (proje kapsamı dışındaki account-level) PAT'ı JIT password olarak kabul etmektir. Test: aynı rule'da, scoped olmayan bir account-level PAT ile üretim yapın. Scoped PAT ile 28P01, legacy PAT ile 200 → bu sizdeki ayrım faktörüdür.

2. Supavisor mapping'i propagate etmemiş olabilir

JIT rule'u oluşturduktan sonra pooler'ın rol eşlemesini yenilemesi gerekir. Rule'u disable → enable edin, birkaç dakika bekleyin ve yeni bir PAT üretin. İlişkili 28P01 tartışması: #49116. Aynı pooler hostname'inin eski bir DNS rezolüsyonunda takılı kalmadığından emin olmak için ipconfig /flushdns sonrası farklı bir resolved IP ile de deneyin.

3. Ayrıcı teşhis: 28P01 = rejected credential vs. JIT mapping hatası

PostgreSQL'de 28P01 "password authentication failed"'dır — bağlantı rolün kendisine ulaşmış ama password (PAT) reddedilmiş. Eğer Supavisor mapping'i hiç göremezdiyse farklı bir hata (ör. Tenant or user not found) alırdınız. Yani:

• 28P01 alıyorsanız: rol adı doğru, sorun PAT'ın password olarak sağlanan değeri — bu da neredeyse her zaman scoped/expired/insufficient-scope PAT'ı işaret eder.
• Tenant/user-not-found alıyorsanız: username formatı (role.project-ref) sorunu.

4. IPv6 zorunlu değil

Shared pooler IPv4 üzerinden JIT'i destekler (dokümandaki örnekler IPv4 hostname ile). IPv6 yalnızca direct connection (pooler'ı bypass) için gerekir; bypass gerekmeden önce 1+2 çözümlerini deneyin.

Hızlı kontrol listesi

1. Legacy account-level PAT ile dene
2. Rule'u disable/enable et + 2-5 dk bekle
3. Yeni PAT üret (24h scope değil, minimum scope ama JIT: Read)
4. Hâlâ 28P01 → Supabase Support'a bu ticket'ı aç: kesin "scoped PAT + JIT" kombinasyonunun resmi olarak desteklenip desteklenmediğini netleştirmek istediğinizi belirtin

Ayrıca ortamınızla ilgili bir not: docs örneğindeki ?options=-c%20jit%3dtrue URI formatı conninfo'ya options='-c jit=true' olarak geçirilir; psql'de hem PGPASSWORD hem conninfo options kombinasyonu kullanıyorsanız, options parametresinin boşluk içermemesi ve tek tırnak içinde olması gerekir — aksi halde ilk sorgu değil bağlantı zamanı reddedilir.

[cekuu35]

Running into the same 28P01 shape here. Three checks that have reliably separated "JIT not supported for this credential type" from "credential is fine but a kink in the auth path" — worth running in this order:

1. Confirm the auth path isn't eating the options parameter

Temporary Access docs specify the JIT/parsing connection needs (temporary-access → "Connect to your database"): the shared-pooler hostname, <role>.<project-ref> as the user, and the PAT as the password. The password never goes in the URI — it must go through either PGPASSWORD or a non-URI conninfo. If the password is embedded in the URI as .../?password=..., the pooler will reject with 28P01 precisely because the password lands in the wrong place)Skip-scoped-PAT's için not: JIT şu an alpha; eğer scoped PAT kullanılıyorsa legacy (account-level) PAT ile A/B test yap. Alpha kanalı için zaman zaman Supavisor eşleme gecikmesi raporlanıyor (maddeye bakın: Supavisor circuit-breaker discussions).

2. Rule state: is the JIT rule actually active for the exact role+project?

The dashboard "Temporary Access" preview shows the rule list. A rule that exists but is still in "propagating" state (Supavisor refresh) will fail auth until it converges — usually 5–15 seconds, occasionally minutes after a fresh PAT rotation. Disable → wait → re-enable and retest if the rule was just created.

3. IPv6/v4 and pooler mode

Direct-vs-pooler matters: the shared pooler uses a single hostname and the password/credential is resolved against the Supavisor role map. When the pooler cannot see a credential for supabase_read_only_user it returns 28P01 before any jit config is applied. Double-check you're connecting through the session-mode shared pooler (aws-0-<region>.pooler.supabase.com:5432), not the direct connection (which is :5432 on the project host, IPv6-preferred).

Most useful next data point

Since you've already isolated it to this role+token pair, the single most useful thing is a control experiment: connect with the SAME read-only user but using the legacy account-level PAT (not the scoped Database-JIT one). If that succeeds, the gap is scoped-PAT-in-JIT (alpha limitation). If it still 28P01s, it's role/pooler mapping, not token type — and the fix lives in Supavisor/infrastructure rather than in your credential rules.

(For reference, the same distinct-answer pattern — scoped PAT accepted by Management API but rejected by Supavisor — is tracked in the Temporary Access alpha announcement thread. If you want, file the exact pair in that thread so the Supabase team can confirm whether scoped PATs are in-scope for JIT yet.)

[cekuu35]

Running into the same 28P01 shape here. Three checks that have reliably separated "JIT not supported for this credential type" from "credential is fine but a kink in the auth path" — worth running in this order:

1. Confirm the auth path isn't eating the options parameter

Temporary Access docs specify the JIT/parsing connection needs (temporary-access → "Connect to your database"): the shared-pooler hostname, <role>.<project-ref> as the user, and the PAT as the password. The password never goes in the URI — it must go through either PGPASSWORD or a non-URI conninfo. If the password is embedded in the URI as .../?password=..., the pooler will reject with 28P01 precisely because the password lands in the wrong place)Skip-scoped-PAT's için not: JIT şu an alpha; eğer scoped PAT kullanılıyorsa legacy (account-level) PAT ile A/B test yap. Alpha kanalı için zaman zaman Supavisor eşleme gecikmesi raporlanıyor (maddeye bakın: Supavisor circuit-breaker discussions).

2. Rule state: is the JIT rule actually active for the exact role+project?

The dashboard "Temporary Access" preview shows the rule list. A rule that exists but is still in "propagating" state (Supavisor refresh) will fail auth until it converges — usually 5–15 seconds, occasionally minutes after a fresh PAT rotation. Disable → wait → re-enable and retest if the rule was just created.

3. IPv6/v4 and pooler mode

Direct-vs-pooler matters: the shared pooler uses a single hostname and the password/credential is resolved against the Supavisor role map. When the pooler cannot see a credential for supabase_read_only_user it returns 28P01 before any jit config is applied. Double-check you're connecting through the session-mode shared pooler (aws-0-<region>.pooler.supabase.com:5432), not the direct connection (which is :5432 on the project host, IPv6-preferred).

Most useful next data point

Since you've already isolated it to this role+token pair, the single most useful thing is a control experiment: connect with the SAME read-only user but using the legacy account-level PAT (not the scoped Database-JIT one). If that succeeds, the gap is scoped-PAT-in-JIT (alpha limitation). If it still 28P01s, it's role/pooler mapping, not token type — and the fix lives in Supavisor/infrastructure rather than in your credential rules.

(For reference, the same distinct-answer pattern — scoped PAT accepted by Management API but rejected by Supavisor — is tracked in the Temporary Access alpha announcement thread. If you want, file the exact pair in that thread so the Supabase team can confirm whether scoped PATs are in-scope for JIT yet.)