supabase

Why isn’t my Stripe webhook updating Supabase? --- title: "Why isn’t my Stripe webhook updating Supabase?" published: true description: "Payment succeeded in Stripe but your app still shows the free plan? The usual causes and the fix for Stripe webhooks with Supabase." tags: stripe, supabase, webhooks, webdev canonical_url: badii.studio --- Usually because the webhook points to the wrong URL, fails its signature check, or is blocked by database rules when it writes. > In live mode, Stripe retries a failed webhook for up to three days. Signature checks need the raw request body, so parsing it first makes every event fail. > > Source: Stripe docs, Webhooks, read 3 Nov 2026 The usual causes - The endpoint is registered in a sandbox or test mode only, or still points to a preview URL. - The signing secret in your environment is from a different endpoint or mode, so every event fails verification. - The handler parses the body as JSON before verifying it. Stripe signs the raw body, so the check fails. - The handler is a Supabase Edge Function with JWT verification left on, the default. Stripe sends no Supabase token, so every call gets a 401. Set verify_jwt = false for that function, or deploy it with --no-verify-jwt, and rely on the Stripe signature check instead. - In an Edge Function, the code reads the body with req.json() or calls constructEvent. Read it with await req.text() and verify it with constructEventAsync and Stripe.createSubtleCryptoProvider(), as in the Supabase example. - The handler writes with the anon key, and row-level security blocks the write. - The table is new and has no grants. Since 30 October 2026, Supabase no longer grants new tables to the API roles, so the write fails with a 42501 permission denied error, even with the service_role key. - The function times out or returns an error, and nothing logs it. - The app listens for the wrong event, for example checkout.session.completed but not invoice.paid for renewals. How a reliable setup looks - One endpoint per environment, each with its own signing secret. - Signature verified on the raw body before anything else. - Writes done server-side with a key that never reaches the browser. - Each event ID stored, so a retried event is not processed twice. - A 2xx response only after the event is safely stored, with slow work moved to a queue so Stripe does not time out. - A way to compare Stripe and your database, and fix any that disagree. Where to look first In the Stripe dashboard, open Workbench, then Webhooks, pick your endpoint and open Event deliveries. Click a failed delivery to see its HTTP status code. A 400 usually means a signature problem, a 401 or 403 an auth problem, a 404 a wrong URL, and a 500 an error in your handler. In a sandbox, Stripe retries a failed event only three times over a few hours, so a broken test endpoint goes quiet fast. You can resend an event from the dashboard for up to 15 days. Sources - Stripe docs, Receive Stripe events in your webhook endpoint, read 3 Nov 2026 - Supabase docs, Function configuration, read 3 Nov 2026 - Supabase example, Stripe webhooks Edge Function, read 3 Nov 2026 - Supabase changelog, Tables not exposed to Data and GraphQL API automatically, read 3 Nov 2026 --- First published on badii.studio. I review and fix apps built with Lovable, Bolt and other AI tools before launch. If yours has a bug like this, book a Tech Check.

Stripe webhook signature verification failed: 3 things to check This article was created with the help of AI. Each step was checked against the Stripe docs and the stripe-node library listed at the end. Here's why this error matters. A customer pays, Stripe sends your app a webhook, and your app turns it away because the signature check fails. The customer paid and gets nothing. Stripe keeps retrying for a while, but you may not notice until someone writes in, upset. The good news: the cause is almost always one of three small things. The error: Webhook signature verification failed. No signatures found matching the expected signature for payload. Short answer: Stripe's check uses three things: the raw request body, the Stripe-Signature header and your endpoint's signing secret. If any one of them is wrong, the check fails. Stripe says the most common cause is the wrong secret. Check 1: Is it the right secret? - The secret starts with whsec_. It is not your API key (sk_...) and not the endpoint ID (we_...). - The secret from stripe listen on your laptop is different from the secret of an endpoint you made in the Stripe Dashboard. Don't mix them. - Test mode and live mode use different secrets. When you go live, copy the live endpoint's secret. - To find it: in Stripe, open the endpoint and click Reveal secret. - Look for a space or line break at the end of the value in your environment variables. - Changed the value on your host? Deploy again. Many hosts only load new values on a new deploy. Check 2: Is the body untouched? Stripe signs the exact bytes it sends. If your app turns the body into JSON and back, the bytes change and the check fails. Get the raw body. Next.js (App Router): // app/api/webhooks/stripe/route.ts import Stripe from 'stripe' const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!) export async function POST(req: Request) { const body = await req.text() // raw text. Do not use req.json() const sig = req.headers.get('stripe-signature') if (!sig) return new Response('Missing signature', { status: 400 }) let event: Stripe.Event try { event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!) } catch (err) { return new Response(`Webhook Error: ${(err as Error).message}`, { status: 400 }) } // handle event.type here return Response.json({ received: true }) } Express: put the raw parser on the webhook route, and add express.json() after it. app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => { let event try { event = stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret) } catch (err) { return res.status(400).send(`Webhook Error: ${err.message}`) } // handle event.type here res.json({ received: true }) }) app.use(express.json()) // other routes only Next.js (Pages Router): turn off the body parser for this route and read the raw bytes. // pages/api/webhook.ts import type { NextApiRequest, NextApiResponse } from 'next' import Stripe from 'stripe' export const config = { api: { bodyParser: false } } const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!) async function rawBody(req: NextApiRequest) { const chunks: Buffer[] = [] for await (const chunk of req) chunks.push(typeof chunk === 'string' ? Buffer.from(chunk) : chunk) return Buffer.concat(chunks) } export default async function handler(req: NextApiRequest, res: NextApiResponse) { if (req.method !== 'POST') return res.status(405).end() const sig = req.headers['stripe-signature'] as string try { const event = stripe.webhooks.constructEvent(await rawBody(req), sig, process.env.STRIPE_WEBHOOK_SECRET!) // handle event.type here return res.json({ received: true }) } catch (err) { return res.status(400).send(`Webhook Error: ${(err as Error).message}`) } } Supabase Edge Functions (Deno): use await req.text(), and use the async version with Stripe's crypto provider: const cryptoProvider = Stripe.createSubtleCryptoProvider() const event = await stripe.webhooks.constructEventAsync(body, signature, secret, undefined, cryptoProvider) The plain constructEvent fails there with "SubtleCryptoProvider cannot be used in a synchronous context". Supabase also blocks Stripe with a 401 by default until you set verify_jwt = false for the webhook function. Something in front of your app can also change the body, such as a proxy or a forwarding tool. Even a small change, like extra spaces in the JSON, breaks the check. Check 3: Is the header right? Print the Stripe-Signature header once. It should look like t=...,v1=.... If it is empty, your code is reading the wrong header, or something in between removed it. Tip: a "too old" error Stripe's libraries also reject events whose timestamp is more than 5 minutes off from your server's clock (the default). If you replay a saved request later, it will fail. Send a fresh test event instead, and make sure your server's clock is correct. Make sure fake signatures are refused Once real events pass, check the other side: your endpoint must say no to a bad signature. Try it on your own endpoint: curl -i -X POST https://yourapp.com/api/webhooks/stripe \ -H 'Content-Type: application/json' \ -H 'Stripe-Signature: t=1,v1=bad' \ -d '{}' You want a 4xx, such as 400. If you get a 2xx, your route is not checking the signature. Sources - Stripe, Resolve webhook signature verification errors: <docs.stripe.com> - Stripe, Webhooks: <docs.stripe.com> - Stripe Node library (constructEvent, constructEventAsync): <stripe/stripe-node> - Supabase example code (Deno): <github.com/supabase/supabase/blob/master/examples…> --- More plain-English webhook fix guides: tillping.online Tillping is a small tool that checks the payment-webhook path of your app, so a paying customer isn't left with nothing while you hear nothing. It isn't open yet. If you'd like a heads-up when it is, join the early-bird list: tillping.online

Supabase .NET DevLog #16 Welcome to our weekly log for the Supabase .NET SDK 🎉 As mentioned in the previous post, I focused on the automatic generation of our feature compliance file, which is now done. The SDK provides annotations we place on public members to indicate which feature they relate to. After each push on master, the compliance file is regenerated and ready to be pulled by other systems. An additional step in our quality gate also verifies that every annotated feature exists in our capability matrix. The file is now my "north star", a backlog of its own: every missing feature is an item that I need to implement. FYI the SDK currently sits at roughly 50% parity with our platform. Since I joined Supabase four months ago, I focused on making the SDK robust enough to move fast(er). Now, we're building momentum and starting a new phase: catching up on the feature drift. As usual, stay tuned and happy coding!

10/30~のSupabaseの GRANT 必須化は既存プロジェクトでも要確認! Supabaseから「新しいテーブルが API に自動で公開されなくなります」というお知らせが来ていました。既存のプロジェクトにも、2026年10月30日から適用されるとの事。 supabase.com 告知には「既存のテーブルは影響を受けません」とありますので、うちは関係ないと放置していました。念のため確かめてみました。すると、新しい環境でマイグレーションを流し直すと管理画面もデータの受信もほぼ全滅する状態でした。 同じように読み流している人向けに、確かめ方と直し方をメモしておきます。 何が変わるのか これまでは、public にテーブルを作ると、API 用のロール（anon・authenticated・service_role）に権限が自動で付いていました。RLS のポリシーを書くだけで supabase-js から使えていたのは、このためです。 これからは自動では付きません。テーブルごとに GRANT を書く必要があり、書かないと API から 42501（permission denied）が返ります。 「既存は影響なし」の落とし穴 今あるテーブルの権限は消されません。本番で今動いているものは、そのまま動きます。 困るのは、次の3つです。 1. これから足すテーブル 10月30日以降に足したテーブルは、GRANT を書かないと使えません。ここは告知にも書いてあります。 2. 新しい環境でマイグレーションを最初から流すとき 検証環境を作るときや、本番を作り直すときです。 これまでのマイグレーションは、自動で公開されることに頼っているので、GRANT が1つもありません。そのため新しい環境では、すべてのテーブルが使えなくなります。 3. 関数も使えなくなる 一番気づきにくいのがこれでした。 ログインユーザーだけに呼ばせたい関数を、こう書いてある場合です。 revoke execute on function public.create_api_key(uuid, text) from public, anon; authenticated には何も書いていないのに呼べていたのは、既定の権限で自動で付いていたからです。 ローカルで「自動で公開しない」状態にして流し直すと、誰からも呼べなくなります。うちでは外部からデータを受信する関数もこれに当たり全部止まるところでした。 ローカルで確かめる Supabase CLI の v2.102.0 以降なら、新しい環境と同じ状態を手元で再現できます。 supabase/config.toml に次を書きます。 [api] auto_expose_new_tables = false DB を作り直して、テストを流します。↓これでローカルのテストデータ消したw supabase db reset # ローカルのデータは消えるので注意 supabase test db うちでは、テストがほぼ全部 permission denied で落ちました....しくしく。 直し方 マイグレーションを1つ足して、次の3つを行います。 今あるテーブルに、権限を明示する 一般の実行権限を外した関数に、呼ぶロールを明示する これから作るものに、権限が自動で付かないようにする 1 と 2 は今付いている権限を書き直すだけなので、既存の環境の動きは変わりません。 -- 1. 今あるテーブルに権限を明示する -- 「all tables in schema public」は RLS のないテーブルまで公開するので使わず、名前を並べる grant select, insert, update, delete on table public.profiles, public.todos -- ...今あるテーブルを全部並べる to anon, authenticated, service_role; grant usage, select on all sequences in schema public to anon, authenticated, service_role; -- 2. 一般の実行権限を外した関数に、呼ぶロールを明示する grant execute on function public.create_api_key(uuid, text) to authenticated, service_role; -- 3. これから作るものには、自動で何も付けない -- （告知の手順は select などだけを取り消し、TRUNCATE などが残るため、all にする） alter default privileges for role postgres in schema public revoke all on tables from anon, authenticated, service_role; alter default privileges for role postgres in schema public revoke all on sequences from anon, authenticated, service_role; alter default privileges for role postgres in schema public revoke all on functions from anon, authenticated, service_role; 3 まで入れると、ローカルも CI も新しい環境も同じ状態になります。GRANT を書き忘れると手元で動かなくなるので、本番に出す前に気づけます。 書き忘れをテストで止める pgTAP のテストにも入れておきました。落ちたときは、GRANT を忘れたテーブルや関数の名前が出ます。 select is( (select string_agg(c.relname, ', ') from pg_class c join pg_namespace n on n.oid = c.relnamespace where n.nspname = 'public' and c.relkind = 'r' and not has_table_privilege('authenticated', c.oid, 'select')), null, 'すべてのテーブルに GRANT を書いている'); select is( (select string_agg(p.oid::regprocedure::text, ', ') from pg_proc p join pg_namespace n on n.oid = p.pronamespace where n.nspname = 'public' and p.prorettype <> 'trigger'::regtype and not has_function_privilege('service_role', p.oid, 'execute')), null, 'すべての関数に GRANT を書いている'); AI に頼むなら Claude Code などに任せる時は下記の指示で一通りやってくれます。 Supabase が 2026-10-30 から、新しいテーブルを API に自動で公開しなくなる （supabase#45329 - supabase/config.toml の [api] に auto_expose_new_tables = false を一時的に書き、 ローカルの DB を作り直してテストを流し、何が使えなくなるかを確かめる （db reset はローカルのデータを消すので、実行前に確認して） - 今あるテーブルに、今と同じ API の権限を GRANT で明示するマイグレーションを足す。 all tables in schema public は使わず、テーブル名を並べる - revoke execute ... from public で一般の実行権限を外した関数には、 今それを呼べているロール（authenticated や service_role）への grant execute を明示する - public の既定の権限（テーブル・連番・関数）を revoke all で取り消す - 書き忘れを止めるテストを足す - 最後に auto_expose_new_tables の行を戻し、同じ状態でもテストが通ることを確かめる 大事なのは、最初に「auto_expose_new_tables = false で作り直して確かめる」を頼むことです。これがないと、テーブルに GRANT を足しただけで終わりがちで、関数の問題には気づきません。 直した後も、AI は新しいテーブルを作るときにはGRANT のない昔の書き方をしがちです（テストを書いてうごかしていたら気づいてくれますが）。そこで、CLAUDE.md や AGENTS.md に、決まりとして書いておくと良いでしょう。 - テーブルを作るマイグレーションでは、同じファイルで GRANT を書き、RLS を有効にする （Supabase は新しいテーブルを API に自動で公開しない） - revoke execute ... from public で一般の実行権限を外した関数は、 呼ぶロールに grant execute を書く - grant ... on all tables in schema public は使わない（RLS のないテーブルまで公開するため） まとめ 「既存のテーブルは影響を受けません」が、マイグレーションを流し直す時には修正が必要です。障害で作り直すときに全滅に気づく、という事態は避けたいので一度確かめておくのがおすすめです。

Supabase functions search path with '' vs explicit schema list On October 21, Supabase merged PR #69 into supabase/vault. Two of its functions changed: search_path = '' → search_path = pg_catalog, pg_temp. Link to the github PR vault#69 1.What is SECURITY DEFINER? A function that runs with its owner's rights, not the caller's. On Supabase the owner is usually postgres, which bypasses RLS. It's a hole in the wall you cut on purpose, so it has to stay exactly the size you planned. 2.'' vs explicit An empty search_path does NOT mean "search nothing". Postgres always searches pg_catalog and the caller's own temp schema (pg_temp). If pg_temp isn't listed, it's searched FIRST, even before pg_catalog, for table and type names. 3.What can go wrong with search_path = ''. Anyone with a direct SQL session can create a temp table that shadows a name your function uses: → An unqualified table can return the attacker's fake row → A temp table named jsonb made auth.uid() fail inside the function. Harmless in itself, but it proves the caller’s objects reach your security definer code. The Supabase API can't do this. Direct connections can: BI tools, contractors or AI agents with database access. 4.The safe pattern create function private.can(p_tenant uuid, p_permission text) returns boolean language sql stable security definer set search_path = pg_catalog, pg_temp as $$ select exists ( select 1 from private.memberships m -- always schema-qualified join private.role_permissions rp on rp.role_id = m.role_id where m.user_id = (select auth.uid()) and m.tenant_id = p_tenant and rp.permission = p_permission ) $$; Both layers matter: the path protects built-in types, and qualified names protect your own tables. Don’t take my word for it: run bellow lines in the SQL editor and compare the order yourself. The temp schema only appears after you create a temp table. --temp FIRST create temp table x (id int); set search_path = ''; select current_schemas(true); -- {pg_temp_N, pg_catalog} --temp LAST set search_path = pg_catalog,pg_temp; select current_schemas(true); -- {pg_catalog, pg_temp_N}

MCP クライアントが OAuth でMCP サーバにつながる仕組み Claude アプリの設定で MCP サーバーの URL を貼ると、ブラウザでログイン画面が開き、「許可する」を押すだけでつながります。API キーを発行した覚えも、アプリを登録した覚えもありません。最近よく見るこの認証です。 でも、考えてみると不思議です。Claude アプリに入力したのは MCP サーバーの URL だけなのに、ログイン画面の場所はどうやって分かったのでしょうか。逆に、接続先のサービスは Claude というアプリのことをどうやって知ったのでしょう。同意画面に出ている「Claude」は、本当に Claude 自分の使っている Claude アプリなのでしょうか。 MCP の OAuth には、まず次の 2つの「相手を知る」仕組みがあります。 認可サーバーを見つける：MCP クライアントは、どこにログインしに行けばいいのか？ → OAuth discovery MCP クライアントを識別する：認可サーバーは、接続してきたアプリが誰なのか？ → 事前登録・DCR・CIMD この順番で見ると、MCP サーバーの URL だけで接続できる理由が分かります。最後に Better Auth、Neon、Supabase の対応状況も比較します。 まずは登場人物 MCP クライアント：Claude や ChatGPT、Cursor など、MCP サーバーにつなぐ AI アプリ。OAuth では「クライアント」 MCP サーバー：ツールやデータを提供する側。OAuth ではアクセスを保護される「リソースサーバー」 認可サーバー：ユーザーのログインと同意を受け付け、MCP サーバー用のアクセストークン（通行証）を発行する側 MCP サーバーと認可サーバーは同じサービス内にあっても、別のドメインや別のサービスにあっても構いません。だから、MCP サーバーの URL を知っているだけでは、認可サーバーの場所が分からない場合があります。 1. 認可サーバーの場所をどう伝えるか：OAuth discovery discovery がなかったらどうなる？ 従来の OAuth 連携では、アプリの開発者が接続先のサービスをあらかじめ知っていて、認可エンドポイントやトークンエンドポイントを設定しておくのが一般的でした。 例えば、次の情報を手動で用意します。 MCP サーバー: mcp.example.com 認可エンドポイント: auth.example.com トークンエンドポイント: auth.example.com これは接続先が決まっているアプリなら問題ありません。しかし MCP では、MCP クライアント に新しい MCP サーバーの URL を貼るたびに、そのサーバーがどの認可サーバーを使うか分かるとは限りません。認可先が別のドメインなら、MCP サーバーの URL から推測することもできません。 実は 2025年3月版の MCP 仕様には、メタデータで発見できない場合、MCP サーバーと同じオリジンの /authorize、/token、/register を試すフォールバックがありました。例えば mcp.example.com なら mcp.example.com を試す方式です。 ただし、このフォールバックは認可サーバーが別の場所にあれば使えません。 そこで 2025年6月版以降の MCP 仕様では、MCP サーバーが認可サーバーの場所を公開する仕組みを使います。これが OAuth discovery です。 discovery がある場合：2段階で見つける ポイントは、見つけるメタデータが 2種類あることです。 誰が公開する？ 仕様 クライアントに教えること MCP サーバー RFC 9728：Protected Resource Metadata どの認可サーバーを使うか 認可サーバー RFC 8414：Authorization Server Metadata（または OIDC Discovery） ログイン先・トークン発行先・対応する登録方式 例えば mcp.example.com にアクセスしてトークンを持っていないと、MCP サーバーは次のように応答します。 HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="mcp.example.com" クライアントがその URL にアクセスすると、次のような Protected Resource Metadata を受け取ります。 { "resource": "mcp.example.com", "authorization_servers": ["auth.example.com"] } これで「認可サーバーは auth.example.com にある」と分かります。続いて認可サーバーの /.well-known/oauth-authorization-server などを取得すると、例えば次の情報が分かります。 { "issuer": "auth.example.com", "authorization_endpoint": "auth.example.com", "token_endpoint": "auth.example.com", "client_id_metadata_document_supported": true } authorization_endpoint がブラウザでログイン・同意を受ける先、token_endpoint が認可コードをトークンに交換する先です。最後の client_id_metadata_document_supported は、後半で説明する CIMD に対応していることを示します。 図の alt の部分がポイントです。WWW-Authenticate にメタデータの URL がなくても、discovery がないとは限りません。ヘッダー経由か well-known URL 経由かの違いで、どちらも RFC 9728 の discovery です。MCP サーバー側はどちらか一方を実装すればよく、ヘッダーで場所を伝えるなら、メタデータの URL は標準の well-known パスでなくても構いません。 一方、RFC 9728 のメタデータ自体がない場合は別です。手動で認可先を設定する独自の接続方法は考えられますが、MCP の OAuth 仕様には適合しません。RFC 9728 の実装は 2025年6月版から必須で、2026年7月版（現行）でも変わっていません。 ここまでで「どこへログインしに行くか」が分かりました。しかし、認可サーバーにはもう1つ知りたいことがあります。「あなたはどのアプリですか？」です。 2. 接続するアプリをどう識別するか：事前登録・DCR・CIMD OAuth では、アプリを識別する ID を client_id と呼びます。認可サーバーは、ログインの要求に付いてくる client_id を見て、アプリの情報やログイン後の戻り先を確認します。 この client_id を使えるようにする仕組みが3つあります。 方式 client_id を用意するのは たとえるなら 事前登録 管理者が事前に登録し、認可サーバーが発行 受付の名簿に前もって名前を載せてもらう DCR（Dynamic Client Registration） アプリが要求し、認可サーバーが発行 受付で自分で用紙を書き、番号札をもらう CIMD（Client ID Metadata Document） アプリ自身が公開する HTTPS URL 公式サイト上の名刺を渡し、受付が見に行く 事前登録：人が登録してから使う 従来の OAuth では、管理者が認可サーバーの管理画面でアプリを登録し、発行された client_id をアプリの設定に書き込みます。 利点：登録済みの相手を管理しやすい。既知のアプリ同士ならシンプル 課題：アプリと認可サーバーの組み合わせごとに事前の登録作業が必要 Web アプリが数個なら手作業で回ります。しかし MCP では、たくさんの AI アプリがたくさんのサーバーにつながるので、登録作業が掛け算で増えます。 DCR：アプリが自分で登録する DCR は、アプリが認可サーバーの登録エンドポイントに「私はこういう名前で、ログイン後はここに戻してほしい」と送り、その場で client_id を受け取る方式です。 解決したこと：人手による事前登録なしで「MCP サーバーの URL を貼るだけ」の体験を実現しやすくなった 課題： アプリ名は原則として自己申告で、追加の審査がなければ誰でも「Claude」を名乗れる 再登録のたびに client_id が増える運用では、同じアプリの登録が溜まる client_id は認可サーバーごとに別物になる CIMD：自己紹介ファイルの URL を ID にする CIMD は、アプリが自分の HTTPS サイトに自己紹介の JSON を置き、その URL 自体を client_id として使う方式です。認可サーバーがその URL を取りに行って内容を確かめるため、接続のたびに登録 API から ID を発行してもらう必要がありません。 Claude も、実際に自己紹介ファイルを公開しています。 Claude（claude.ai、デスクトップ版などの MCP 接続向け）：claude.ai 以下は主要な項目の抜粋です。 { "client_id": "claude.ai", "client_name": "Claude", "client_uri": "claude.ai", "redirect_uris": ["claude.ai"], "token_endpoint_auth_method": "none" } client_id が自分自身の URL、client_name が表示名、redirect_uris がログイン後の戻り先です。token_endpoint_auth_method: "none" は、このクライアントがトークンエンドポイントでクライアントシークレットによる認証をしないことを示します。Claude Code は 別の自己紹介ファイル を使い、戻り先を localhost にして利用者の PC に戻す構成です。 解決したこと： 身元をアプリが管理する HTTPS ドメインと結びつけられる。誰でも登録時に「Claude」と書ける DCR より、表示名の出所を確認しやすい 登録 API を呼ばずに、同じ client_id を複数の対応する認可サーバーで再利用できる 接続のたびに新しい ID を発行する必要がない 注意点： URL の取得先を悪用した SSRF（内部ネットワークへの不正アクセス）への対策が必要 認可サーバーが取得したメタデータをキャッシュ・保存する場合はある。「何も保存しない」という意味ではない ドメインを確認しても、動いているプログラムそのものの身元まで完全に証明できるわけではない。特にローカルアプリの戻り先には追加の注意が必要 MCP の推奨は DCR から CIMD へ 時期 MCP 仕様での扱い 2025年3月 認可の仕組みが導入され、DCR を推奨 2025年6月 認可サーバーの発見に RFC 9728 が必須になり、旧フォールバックは廃止。登録方式は引き続き DCR を推奨 2025年11月 CIMD を推奨し、DCR は任意対応に 2026年7月（現行） DCR を非推奨（deprecated）と明記。互換性のため残る 2026-07-28 版の MCP 仕様は、次の順番で選ぶよう勧めています。 すでに登録情報を持っていれば、事前登録を使う 認可サーバーが client_id_metadata_document_supported: true を公開していれば、CIMD を使う それが使えず、registration_endpoint があれば、DCR を使う どれも使えなければ、ユーザーにクライアント情報の入力を求める ここで client_id_metadata_document_supported や registration_endpoint を知る手段が、先ほどの 認可サーバーの discovery（RFC 8414） です。つまり discovery と CIMD は別の仕組みですが、接続フローの中ではつながっています。 3. URL を貼ってから「許可する」まで 2つの仕組みを合わせると、最初の疑問に答えられます。 ユーザーが Claude (MCP クライアント) に MCP サーバーの URL を設定する Claude が MCP サーバーの Protected Resource Metadata（RFC 9728） から認可サーバーを知る Claude が認可サーバーの メタデータ（RFC 8414 など） からログイン先と利用可能な登録方式を知る Claude が client_id を用意する（事前登録・CIMD・DCR のいずれか） ブラウザにログイン・同意画面が開く ユーザーが「許可する」を押すと、Claude が認可コードを受け取り、PKCE を使ってトークンに交換する。このとき resource パラメータで「どの MCP サーバー用のトークンか」も指定する Claude が アクセストークン を付けて MCP サーバーのツールを呼ぶ 利用者には「URL を貼る → ログインする → 許可する」だけに見えますが、裏側では 認可先の発見 と クライアントの識別 が別々に進んでいます。 観点 OAuth discovery 事前登録・DCR・CIMD 解決する疑問 どこでログインする？ どのアプリが接続する？ 主に情報を示す側 MCP サーバーと認可サーバー MCP クライアントと認可サーバー 重要なメタデータ authorization_servers、authorization_endpoint など client_id、redirect_uris など 2026年7月版 MCP での扱い RFC 9728 による discovery が必須（2025年6月版から） CIMD を推奨、DCR は非推奨 4. Better Auth・Neon・Supabase の対応状況 Better Auth：discovery と CIMD の両方に対応 Better Auth の MCP プラグインは、OAuth の認可サーバー情報と RFC 9728 の Protected Resource Metadata を公開できます。さらに CIMD プラグインを組み合わせることで、URL 形式の client_id を受け入れられます。CIMD は 1.7（2026年8月）で追加された機能で、プラグインを入れたときだけ discovery に client_id_metadata_document_supported が載ります。 CIMD プラグイン自体は IETF draft の新しい版（draft-02）に準拠しており、MCP 2026年7月版が参照する draft-00 の要件（client_name と redirect_uris の必須化）は metadataProfile: "mcp-2026-07-28" を指定して上乗せします。DCR は明示的に有効化しない限り無効です。 Neon：公式 MCP サーバーは DCR のまま、Neon Auth は CIMD が既定 Neon の公式 MCP サーバー（mcp.neon.tech OAuth discovery に対応していますが、クライアント登録は DCR です。CIMD を受け入れる PR #380 が2026年10月に出されていますが、本記事執筆時点では未マージです。 一方、Neon Auth（Managed Better Auth）の OAuth provider プラグインで MCP サーバーの URL を設定すると、CIMD が既定で有効になり、DCR は「legacy」扱いで既定オフになります。2026年10月にこの既定が切り替わったため、それ以前に設定したブランチで DCR に依存していた場合は、明示的にオンにし直す必要があります。管理用の API と後述の SDK はベータ扱いですが、プラグイン自体はすべての Managed Better Auth プロジェクトで使えます。Neon 公式 MCP サーバーの仕組みと、Neon Auth を使った自作 MCP サーバーの実装は分けて考える必要があります。 2026年10月には、Neon Auth を使うアプリや MCP サーバー向けの @neon/oauth（ベータ） も加わりました。MCP サーバー用の RFC 9728 メタデータ公開とトークン検証に加えて、OAuth クライアントが CIMD で名乗るための自己紹介ファイルの生成にも対応しています。 Supabase：discovery を簡単に実装できるが、クライアント登録は DCR Supabase は2026年10月22日に Give your Supabase app its own MCP server を公開しました。新しい MCP Server block を使うと、Edge Functions に MCP サーバーを追加できます。 @supabase/server の withOAuthProtectedResource() が OAuth discovery（RFC 9728） を担当し、認可サーバーの場所を示すメタデータや、未認証時の 401 / WWW-Authenticate 応答を提供します。このメタデータは標準の well-known パスではなく関数配下の URL で配信され、場所は WWW-Authenticate ヘッダーで伝えます。前半で触れた「ヘッダー経由の discovery」の実例です。withSupabase({ auth: 'user' }) はトークンを検証し、ツールをログインユーザーの権限（RLS）で動かします。OAuth Consent block も用意されています。 ただし、discovery に対応したことは CIMD に対応したことを意味しません。外部 MCP クライアント向けの MCP Server block のガイドでは、今も DCR を有効にするよう案内されています。 [auth.oauth_server] enabled = true authorization_url_path = "/oauth/consent" allow_dynamic_registration = true CIMD 対応を求める Issue #2850 は2026年10月23日時点で未解決です。Claude のように CIMD を優先するクライアントも、Supabase Auth を認可サーバーとする接続では DCR に切り替えることになります。 今回の Supabase の発表は、MCP サーバー側の認証と discovery の実装を楽にしたという進歩です。一方、接続してくるアプリの識別を DCR から CIMD に移す課題は残っています。 3つを並べると discovery（RFC 9728） CIMD DCR Better Auth 対応 プラグインで対応 明示的に有効化 Neon Auth 対応 既定で有効 legacy、既定オフ Supabase Auth 対応 未対応 有効化を案内 まとめ MCP サーバーの URL を貼るだけでつながる体験は、2つの問いを順番に解決することで成り立っています。 認可サーバーはどこ？ → OAuth discovery（RFC 9728 と RFC 8414 / OIDC Discovery） 接続してきたアプリは誰？ → 事前登録・DCR・CIMD OAuth discovery がなければ、認可先を人が設定したり固定パスから推測したりする必要がありました。MCP の OAuth 仕様は 2025年6月版からその発見方法を標準化しています。そして、認可先が分かった後のクライアント識別も、自己申告の DCR から、HTTPS ドメインに結びつく CIMD へ移りつつあります。Better Auth と Neon Auth はすでに CIMD を推奨または既定にし、Supabase は DCR のままという違いが、その移行の途中経過を表しています。 次に同意画面で「Claude」と表示されたら、どこにログインするのか、そしてその「Claude」という名前をどう確かめたのか。この2つを思い出すと、OAuth の仕組みが少し違って見えるはずです。 参考 MCP 仕様 2026-07-28：Authorization MCP 仕様 2026-07-28：Authorization Server Discovery MCP 仕様 2026-07-28：Client Registration MCP 仕様 2025-11-25：Authorization MCP 仕様 2025-06-18：Authorization（RFC 9728 必須化） MCP 仕様 2025-03-26：Authorization（旧フォールバック） IETF draft：OAuth Client ID Metadata Document Better Auth：MCP Better Auth：CIMD Neon：MCP Server Neon：mcp-server-neon PR #380（CIMD 対応提案） Neon Auth：OAuth Provider プラグイン Neon：@neon/oauth PR #869 Supabase：Give your Supabase app its own MCP server Supabase Library：MCP Server block Supabase Auth：CIMD 対応 Issue #2850

supabase — open-source Postgres backend with auth and realtime Open source Firebase alternative built on Postgres with auth, storage, and realtime APIs. Repository: supabase/supabase What you get: • Provides a hosted Postgres database for web, mobile, and AI apps. • Auto-generates REST and GraphQL APIs directly from your Postgres database. • Supports realtime database change subscriptions over WebSockets. Requirements: • No install needed for the hosted platform; just sign up. Independent summary of a public open-source project. Neural Nexus is not affiliated with, endorsed by, or sponsored by the project authors or GitHub. The voiceover is AI-generated and checked against the public README. The repository is the source of truth. #AI #supabase #opensource #postgres #database [ar] Supabase — واجهة خلفية مفتوحة المصدر لـ Postgres مع ميزات المصادقة والبيانات الفورية بديل مفتوح المصدر لـ Firebase مبني على Postgres، مع ميزات المصادقة والتخزين وواجهات برمجة التطبيقات (APIs) الفورية. المستودع: supabase/supabase المميزات: • قاعدة بيانات Postgres مستضافة لتطبيقات الويب والهواتف المحمولة والذكاء الاصطناعي. • إنشاء واجهات برمجة تطبيقات REST وGraphQL تلقائيًا من قاعدة بيانات Postgres الخاصة بك. • دعم اشتراكات تغييرات قاعدة البيانات الفورية عبر WebSockets. المتطلبات: • لا يتطلب تثبيتًا للمنصة المستضافة؛ ما عليك سوى التسجيل. ملخص مستقل لمشروع مفتوح المصدر. لا تنتمي Neural Nexus إلى مؤلفي المشروع أو GitHub، ولا تحظى برعايتهم أو دعمهم. تم إنشاء التعليق الصوتي بواسطة الذكاء الاصطناعي وتمت مراجعته مع ملف README العام. المستودع هو المصدر الموثوق. #الذكاء_الاصطناعي #supabase #مفتوح_المصدر #postgres #قاعدة_بيانات [bn] Supabase — অথ এবং রিয়েল-টাইম সুবিধাসহ ওপেন-সোর্স পোস্টগ্রেস ব্যাকএন্ড পোস্টগ্রেস-এর উপর নির্মিত ওপেন সোর্স ফায়ারবেস বিকল্প, যাতে অথেন্টিকেশন, স্টোরেজ এবং রিয়েলটাইম এপিআই রয়েছে। রিপোজিটরি: supabase/supabase আপনি যা পাবেন: • ওয়েব, মোবাইল এবং এআই অ্যাপের জন্য একটি হোস্টেড পোস্টগ্রেস ডেটাবেস প্রদান করে। • আপনার পোস্টগ্রেস ডেটাবেস থেকে সরাসরি স্বয়ংক্রিয়ভাবে REST এবং GraphQL এপিআই তৈরি করে। • ওয়েবসকেটের মাধ্যমে রিয়েলটাইম ডেটাবেস পরিবর্তন সাবস্ক্রিপশন সমর্থন করে। প্রয়োজনীয়তা: • হোস্টেড প্ল্যাটফর্মের জন্য কোনো ইনস্টলের প্রয়োজন নেই; শুধু সাইন আপ করুন। একটি পাবলিক ওপেন-সোর্স প্রকল্পের স্বাধীন সারসংক্ষেপ। নিউরাল নেক্সাস এই প্রকল্পের লেখক বা গিটহাবের সাথে অধিভুক্ত নয়, তাদের দ্বারা অনুমোদিত নয় বা তাদের পৃষ্ঠপোষকতাও পায় না। ভয়েসওভারটি এআই দ্বারা তৈরি এবং পাবলিক README-এর সাথে মিলিয়ে পরীক্ষা করা হয়েছে। রিপোজিটরিটিই তথ্যের মূল উৎস। #AI #supabase #opensource #postgres #database [de-DE] Supabase — Open-Source-Postgres-Backend mit Auth und Realtime Open-Source-Alternative zu Firebase, basierend auf PostgreSQL mit Authentifizierung, Speicherung und Echtzeit-APIs. Repository: supabase/supabase Leistungen: • Gehostete PostgreSQL-Datenbank für Web-, Mobil- und KI-Anwendungen. • Automatische Generierung von REST- und GraphQL-APIs direkt aus Ihrer PostgreSQL-Datenbank. • Unterstützung von Echtzeit-Datenbankänderungsabonnements über WebSockets. Voraussetzungen: • Keine Installation für die gehostete Plattform erforderlich; einfach registrieren. Unabhängige Zusammenfassung eines öffentlichen Open-Source-Projekts. Neural Nexus steht in keiner Verbindung zu den Projektautoren oder GitHub und wird weder von ihnen unterstützt noch gesponsert. Die Sprachausgabe wurde KI-generiert und mit der öffentlichen README-Datei abgeglichen. Das Repository ist die maßgebliche Quelle. #KI #supabase #opensource #postgres #datenbank [es-US] supabase — backend de Postgres de código abierto con autenticación y tiempo real Alternativa de código abierto a Firebase basada en PostgreSQL con autenticación, almacenamiento y API en tiempo real. Repositorio: supabase/supabase Lo que obtienes: • Base de datos PostgreSQL alojada para aplicaciones web, móviles y de IA. • Genera automáticamente API REST y GraphQL directamente desde tu base de datos PostgreSQL. • Admite suscripciones a cambios de base de datos en tiempo real mediante WebSockets. Requisitos: • No se requiere instalación para la plataforma alojada; solo regístrate. Resumen independiente de un proyecto público de código abierto. Neural Nexus no está afiliado, respaldado ni patrocinado por los autores del proyecto ni por GitHub. La narración es generada por IA y verificada con el archivo README público. El repositorio es la fuente de información principal. #IA #supabase #códigoabierto #postgres #basededatos [fr-FR] Supabase — backend Postgres open source avec authentification et temps réel Alternative open source à Firebase, basée sur Postgres et offrant authentification, stockage et API temps réel. Dépôt : supabase/supabase Fonctionnalités : • Base de données Postgres hébergée pour applications web, mobiles et d'IA. • Génération automatique d'API REST et GraphQL directement à partir de votre base de données Postgres. • Prise en charge des abonnements aux modifications de la base de données en temps réel via WebSockets. Prérequis : • Aucune installation requise pour la plateforme hébergée ; il suffit de s'inscrire. Résumé indépendant d'un projet open source public. Neural Nexus n'est ni affilié à, ni approuvé par, ni sponsorisé par les auteurs du projet ou GitHub. La voix off est générée par IA et vérifiée par rapport au fichier README public. Le dépôt fait foi. #IA #supabase #opensource #postgres #base_de_données [hi] Supabase — ऑथेंटिकेशन और रीयल-टाइम फीचर्स के साथ ओपन-सोर्स Postgres बैकएंड Postgres पर आधारित Firebase का ओपन-सोर्स विकल्प, जिसमें प्रमाणीकरण, संग्रहण और रीयलटाइम API शामिल हैं। रिपॉजिटरी: supabase/supabase आपको क्या मिलेगा: • वेब, मोबाइल और AI ऐप्स के लिए होस्टेड Postgres डेटाबेस प्रदान करता है। • आपके Postgres डेटाबेस से सीधे REST और GraphQL API स्वतः उत्पन्न करता है। • WebSockets के माध्यम से रीयलटाइम डेटाबेस परिवर्तन सदस्यता का समर्थन करता है। आवश्यकताएं: • होस्टेड प्लेटफ़ॉर्म के लिए किसी इंस्टॉलेशन की आवश्यकता नहीं है; बस साइन अप करें। एक सार्वजनिक ओपन-सोर्स प्रोजेक्ट का स्वतंत्र सारांश। Neural Nexus का प्रोजेक्ट लेखकों या GitHub से कोई संबंध नहीं है, न ही यह उनके द्वारा समर्थित या प्रायोजित है। वॉइसओवर AI द्वारा जनरेट किया गया है और सार्वजनिक README के ​​अनुसार जांचा गया है। रिपॉजिटरी जानकारी का स्रोत है। #AI #supabase #opensource #postgres #database [id] Supabase — backend Postgres open-source dengan autentikasi dan realtime Alternatif Firebase sumber terbuka yang dibangun di atas Postgres dengan otentikasi, penyimpanan, dan API waktu nyata. Repositori: supabase/supabase Yang Anda dapatkan: • Menyediakan basis data Postgres yang dihosting untuk aplikasi web, seluler, dan AI. • Secara otomatis menghasilkan API REST dan GraphQL langsung dari basis data Postgres Anda. • Mendukung langganan perubahan basis data waktu nyata melalui WebSocket. Persyaratan: • Tidak perlu instalasi untuk platform yang dihosting; cukup mendaftar. Ringkasan independen dari proyek sumber terbuka publik. Neural Nexus tidak berafiliasi dengan, didukung oleh, atau disponsori oleh penulis proyek atau GitHub. Narasi suara dihasilkan oleh AI dan diperiksa terhadap README publik. Repositori adalah sumber kebenaran. #AI #supabase #opensource #postgres #database [it] Supabase — backend Postgres open-source con autenticazione e tempo reale Alternativa open source a Firebase basata su PostgreSQL con autenticazione, storage e API in tempo reale. Repository: supabase/supabase Cosa offre: • Fornisce un database PostgreSQL ospitato per applicazioni web, mobile e di intelligenza artificiale. • Genera automaticamente API REST e GraphQL direttamente dal database PostgreSQL. • Supporta le sottoscrizioni in tempo reale alle modifiche del database tramite WebSockets. Requisiti: • Non è necessaria alcuna installazione per la piattaforma ospitata; basta registrarsi. Riepilogo indipendente di un progetto open source pubblico. Neural Nexus non è affiliato, approvato o sponsorizzato dagli autori del progetto o da GitHub. La voce narrante è generata dall'IA e verificata rispetto al README pubblico. Il repository è la fonte di riferimento. #AI #supabase #opensource #postgres #database [iw] Supabase — backend בקוד פתוח מבוסס Postgres עם אימות וזמן אמת אלטרנטיבה בקוד פתוח ל-Firebase הבנויה על Postgres עם אימות, אחסון וממשקי API בזמן אמת. מאגר: supabase/supabase מה תקבלו: • מספק מסד נתונים Postgres מתארח עבור אפליקציות אינטרנט, מובייל ובינה מלאכותית. • יוצר אוטומטית ממשקי API של REST ו-GraphQL ישירות ממסד הנתונים Postgres שלכם. • תומך במנויים לשינוי מסד נתונים בזמן אמת דרך WebSockets. דרישות: • אין צורך בהתקנה עבור הפלטפורמה המתארחת; פשוט הירשמו. סיכום עצמאי של פרויקט קוד פתוח ציבורי. Neural Nexus אינו מזוהה עם, מאושר על ידי או ממומן על ידי מחברי הפרויקט או GitHub. הקריינות נוצרת על ידי בינה מלאכותית ונבדקת מול קובץ ה-README הציבורי. המאגר הוא מקור האמת. #AI #supabase #opensource #postgres #database [ja] Supabase — 認証とリアルタイム機能を備えたオープンソースのPostgresバックエンド 認証、ストレージ、リアルタイムAPIを備えたPostgresベースのオープンソースFirebase代替サービス。 リポジトリ：supabase/supabase 提供内容： • Web、モバイル、AIアプリ向けのホスト型Postgresデータベースを提供します。 • Postgresデータベースから直接RESTおよびGraphQL APIを自動生成します。 • WebSocket経由のリアルタイムデータベース変更サブスクリプションをサポートします。 必要条件： • ホスト型プラットフォームはインストール不要。サインアップするだけです。 これは公開されているオープンソースプロジェクトの独立した概要です。Neural Nexusは、プロジェクトの作者またはGitHubと提携、承認、またはスポンサー関係にありません。音声はAIによって生成され、公開されているREADMEと照合されています。リポジトリが真の情報源です。 #AI #supabase #opensource #postgres #database [ko] Supabase — 인증 및 실시간 기능을 갖춘 오픈소스 Postgres 백엔드 인증, 스토리지 및 실시간 API를 제공하는 PostgreSQL 기반의 오픈 소스 Firebase 대체 솔루션입니다. 리포지토리: supabase/supabase 주요 기능: • 웹, 모바일 및 AI 앱을 위한 호스팅된 PostgreSQL 데이터베이스를 제공합니다. • PostgreSQL 데이터베이스에서 REST 및 GraphQL API를 자동으로 생성합니다. • WebSocket을 통한 실시간 데이터베이스 변경 구독을 지원합니다. 요구 사항: • 호스팅 플랫폼은 설치가 필요 없으며, 가입만 하면 됩니다. 본 내용은 공개 오픈 소스 프로젝트에 대한 독립적인 요약입니다. Neural Nexus는 프로젝트 작성자 또는 GitHub와 제휴, 보증 또는 후원 관계가 없습니다. 음성 해설은 AI로 생성되었으며 공개 README를 기준으로 검증되었습니다. 저장소가 정확한 정보의 원천입니다. #AI #supabase #opensource #postgres #database [ml] Supabase — ഓതന്റിക്കേഷനും റിയൽ-ടൈം സൗകര്യവുമുള്ള ഓപ്പൺ-സോഴ്സ് പോസ്റ്റ്ഗ്രെസ് ബാക്ക്എൻഡ് ഓത്ത്, സ്റ്റോറേജ്, റിയൽടൈം API-കൾ എന്നിവ ഉപയോഗിച്ച് പോസ്റ്റ്‌ഗ്രെസിൽ നിർമ്മിച്ച ഓപ്പൺ സോഴ്‌സ് ഫയർബേസ് ബദൽ. ശേഖരം: supabase/supabase നിങ്ങൾക്ക് ലഭിക്കുന്നത്: • വെബ്, മൊബൈൽ, AI ആപ്പുകൾക്കായി ഹോസ്റ്റ് ചെയ്‌ത പോസ്റ്റ്‌ഗ്രെസ് ഡാറ്റാബേസ് നൽകുന്നു. • നിങ്ങളുടെ പോസ്റ്റ്‌ഗ്രെസ് ഡാറ്റാബേസിൽ നിന്ന് നേരിട്ട് REST, GraphQL API-കൾ സ്വയമേവ ജനറേറ്റ് ചെയ്യുന്നു. • വെബ്‌സോക്കറ്റുകൾ വഴി റിയൽടൈം ഡാറ്റാബേസ് മാറ്റ സബ്‌സ്‌ക്രിപ്‌ഷനുകളെ പിന്തുണയ്ക്കുന്നു. ആവശ്യകതകൾ: • ഹോസ്റ്റ് ചെയ്‌ത പ്ലാറ്റ്‌ഫോമിന് ഇൻസ്റ്റാളേഷൻ ആവശ്യമില്ല; സൈൻ അപ്പ് ചെയ്‌താൽ മതി. ഒരു പൊതു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്റ്റിന്റെ സ്വതന്ത്ര സംഗ്രഹം. ന്യൂറൽ നെക്‌സസ് പ്രോജക്റ്റ് രചയിതാക്കളുമായോ GitHub-മായോ അഫിലിയേറ്റ് ചെയ്തിട്ടില്ല, അംഗീകരിച്ചിട്ടില്ല, അല്ലെങ്കിൽ സ്പോൺസർ ചെയ്തിട്ടില്ല. വോയ്‌സ്‌ഓവർ AI- സൃഷ്ടിച്ചതും പൊതു README-യ്‌ക്കെതിരെ പരിശോധിച്ചതുമാണ്. സത്യത്തിന്റെ ഉറവിടമാണ് ശേഖരം. #AI #supabase #opensource #postgres #database [nl-NL] supabase — open-source Postgres-backend met authenticatie en realtime Open source Firebase-alternatief gebouwd op PostgreSQL met authenticatie, opslag en realtime API's. Repository: supabase/supabase Wat je krijgt: • Biedt een gehoste PostgreSQL-database voor web-, mobiele en AI-applicaties. • Genereert automatisch REST- en GraphQL-API's rechtstreeks vanuit je PostgreSQL-database. • Ondersteunt realtime abonnementen op databasewijzigingen via WebSockets. Vereisten: • Installatie is niet nodig voor het gehoste platform; meld je gewoon aan. Onafhankelijke samenvatting van een openbaar open-source project. Neural Nexus is niet gelieerd aan, onderschreven door of gesponsord door de projectauteurs of GitHub. De voice-over is door AI gegenereerd en gecontroleerd aan de hand van de openbare README. De repository is de bron van waarheid. #AI #supabase #opensource #postgres #database [pa] Supabase — ਓਪਨ-ਸੋਰਸ Postgres ਬੈਕਐਂਡ, ਪ੍ਰਮਾਣੀਕਰਨ (auth) ਅਤੇ ਰੀਅਲਟਾਈਮ ਦੇ ਨਾਲ ਪੋਸਟਗ੍ਰੇਸ 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ, ਸਟੋਰੇਜ, ਅਤੇ ਰੀਅਲਟਾਈਮ API ਦੇ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਓਪਨ ਸੋਰਸ ਫਾਇਰਬੇਸ ਵਿਕਲਪ। ਰਿਪੋਜ਼ਟਰੀ: supabase/supabase ਤੁਹਾਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ: • ਵੈੱਬ, ਮੋਬਾਈਲ ਅਤੇ AI ਐਪਸ ਲਈ ਇੱਕ ਹੋਸਟਡ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। • ਤੁਹਾਡੇ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਤੋਂ ਸਿੱਧੇ REST ਅਤੇ GraphQL API ਨੂੰ ਸਵੈ-ਜਨਰੇਟ ਕਰਦਾ ਹੈ। • WebSockets 'ਤੇ ਰੀਅਲਟਾਈਮ ਡੇਟਾਬੇਸ ਤਬਦੀਲੀ ਗਾਹਕੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਲੋੜਾਂ: • ਹੋਸਟ ਕੀਤੇ ਪਲੇਟਫਾਰਮ ਲਈ ਕੋਈ ਇੰਸਟਾਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਸਿਰਫ਼ ਸਾਈਨ ਅੱਪ ਕਰੋ। ਇੱਕ ਜਨਤਕ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦਾ ਸੁਤੰਤਰ ਸਾਰ। ਨਿਊਰਲ ਨੈਕਸਸ ਪ੍ਰੋਜੈਕਟ ਲੇਖਕਾਂ ਜਾਂ GitHub ਨਾਲ ਸੰਬੰਧਿਤ, ਸਮਰਥਨ ਜਾਂ ਸਪਾਂਸਰ ਨਹੀਂ ਹੈ। ਵੌਇਸਓਵਰ AI-ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜਨਤਕ README ਦੇ ਵਿਰੁੱਧ ਜਾਂਚਿਆ ਗਿਆ ਹੈ। ਰਿਪੋਜ਼ਟਰੀ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਹੈ। #AI #supabase #opensource #postgres #database [pl] Supabase — open-source'owy backend Postgres z autoryzacją i funkcjami czasu rzeczywistego Alternatywa open source dla Firebase oparta na Postgres z uwierzytelnianiem, pamięcią masową i interfejsami API czasu rzeczywistego. Repozytorium: supabase/supabase Co otrzymasz: • Udostępnia hostowaną bazę danych Postgres dla aplikacji internetowych, mobilnych i AI. • Automatycznie generuje interfejsy API REST i GraphQL bezpośrednio z bazy danych Postgres. • Obsługuje subskrypcje zmian w bazie danych w czasie rzeczywistym przez WebSockets. Wymagania: • Nie wymaga instalacji platformy hostowanej; wystarczy się zarejestrować. Niezależne podsumowanie publicznego projektu open source. Neural Nexus nie jest powiązany, wspierany ani sponsorowany przez autorów projektu ani GitHub. Nagranie głosowe jest generowane przez sztuczną inteligencję i sprawdzane pod kątem publicznego pliku README. Repozytorium jest źródłem prawdy. #AI #supabase #opensource #postgres #database [pt-BR] supabase — backend Postgres open-source com autenticação e tempo real Alternativa de código aberto ao Firebase, construída sobre o Postgres, com autenticação, armazenamento e APIs em tempo real. Repositório: supabase/supabase O que você ganha: • Fornece um banco de dados Postgres hospedado para aplicativos web, mobile e de IA. • Gera automaticamente APIs REST e GraphQL diretamente do seu banco de dados Postgres. • Suporta assinaturas de alterações de banco de dados em tempo real via WebSockets. Requisitos: • Não é necessário instalar nada na plataforma hospedada; basta se cadastrar. Resumo independente de um projeto público de código aberto. A Neural Nexus não é afiliada, endossada ou patrocinada pelos autores do projeto ou pelo GitHub. A narração foi gerada por IA e verificada com o README público. O repositório é a fonte oficial. #IA #supabase #códigoaberto #postgres #bancodedados [ru] Supabase — бэкенд на базе Postgres с открытым исходным кодом, аутентификацией и поддержкой real-time Альтернатива Firebase с открытым исходным кодом, построенная на Postgres, с аутентификацией, хранилищем и API в реальном времени. Репозиторий: supabase/supabase Что вы получаете: • Предоставляет размещенную базу данных Postgres для веб-, мобильных и ИИ-приложений. • Автоматически генерирует REST и GraphQL API непосредственно из вашей базы данных Postgres. • Поддерживает подписки на изменения в базе данных в реальном времени через WebSockets. Требования: • Для размещенной платформы не требуется установка; просто зарегистрируйтесь. Независимое описание публичного проекта с открытым исходным кодом. Neural Nexus не связан, не поддерживается и не спонсируется авторами проекта или GitHub. Голосовое сопровождение сгенерировано ИИ и проверено на соответствие общедоступному файлу README. Репозиторий является источником достоверной информации. #AI #supabase #opensource #postgres #database [ta] Supabase — அங்கீகாரம் (auth) மற்றும் நிகழ்நேர வசதிகளுடன் கூடிய ஓப்பன் சோர்ஸ் Postgres பேக்எண்ட் அங்கீகாரம், சேமிப்பு மற்றும் நிகழ்நேர API-களுடன் Postgres-இல் கட்டமைக்கப்பட்ட திறந்த மூல Firebase மாற்று. களஞ்சியம்: supabase/supabase நீங்கள் பெறுபவை: • வலை, மொபைல் மற்றும் AI செயலிகளுக்காக ஒரு ஹோஸ்ட் செய்யப்பட்ட Postgres தரவுத்தளத்தை வழங்குகிறது. • உங்கள் Postgres தரவுத்தளத்திலிருந்து நேரடியாக REST மற்றும் GraphQL API-களைத் தானாக உருவாக்குகிறது. • WebSockets வழியாக நிகழ்நேர தரவுத்தள மாற்ற சந்தாக்களை ஆதரிக்கிறது. தேவைகள்: • ஹோஸ்ட் செய்யப்பட்ட தளத்திற்கு நிறுவல் தேவையில்லை; பதிவு செய்தால் மட்டும் போதும். ஒரு பொது திறந்த மூல திட்டத்தின் சுயாதீனமான சுருக்கம். Neural Nexus, இந்த திட்டத்தின் ஆசிரியர்கள் அல்லது GitHub உடன் இணைக்கப்படவில்லை, அவர்களால் அங்கீகரிக்கப்படவில்லை அல்லது நிதியுதவி செய்யப்படவில்லை. குரல் பதிவு AI-ஆல் உருவாக்கப்பட்டு, பொது README உடன் சரிபார்க்கப்பட்டது. களஞ்சியமே உண்மையின் ஆதாரம். #AI #supabase #opensource #postgres #database [te] Supabase — ఆథ్ మరియు రియల్ టైమ్‌తో కూడిన ఓపెన్-సోర్స్ Postgres బ్యాకెండ్ ప్రామాణీకరణ, నిల్వ, మరియు రియల్ టైమ్ APIలతో Postgres ఆధారంగా నిర్మించబడిన ఓపెన్ సోర్స్ Firebase ప్రత్యామ్నాయం. రిపోజిటరీ: supabase/supabase మీకు లభించేవి: • వెబ్, మొబైల్, మరియు AI యాప్‌ల కోసం హోస్ట్ చేయబడిన Postgres డేటాబేస్‌ను అందిస్తుంది. • మీ Postgres డేటాబేస్ నుండి నేరుగా REST మరియు GraphQL APIలను స్వయంచాలకంగా రూపొందిస్తుంది. • WebSockets ద్వారా రియల్ టైమ్ డేటాబేస్ మార్పు సబ్‌స్క్రిప్షన్‌లకు మద్దతు ఇస్తుంది. అవసరాలు: • హోస్ట్ చేయబడిన ప్లాట్‌ఫారమ్ కోసం ఇన్‌స్టాల్ చేయవలసిన అవసరం లేదు; కేవలం సైన్ అప్ చేయండి. ఒక పబ్లిక్ ఓపెన్-సోర్స్ ప్రాజెక్ట్ యొక్క స్వతంత్ర సారాంశం. న్యూరల్ నెక్సస్‌కు ప్రాజెక్ట్ రచయితలు లేదా GitHubతో ఎలాంటి అనుబంధం లేదు, వారిచే ఆమోదించబడలేదు, లేదా స్పాన్సర్ చేయబడలేదు. వాయిస్‌ఓవర్ AI ద్వారా రూపొందించబడింది మరియు పబ్లిక్ READMEతో సరిపోల్చి తనిఖీ చేయబడింది. రిపోజిటరీయే అసలైన ఆధారం. #AI #supabase #opensource #postgres #database [uk] Supabase — open-source Postgres-бекенд з аутентифікацією та реальним часом Альтернатива Firebase з відкритим кодом, побудована на Postgres з автентифікацією, сховищем та API реального часу. Репозиторій: supabase/supabase Що ви отримуєте: • Надає розміщену базу даних Postgres для веб-, мобільних та штучного інтелекту (AI) додатків. • Автоматично генерує REST та GraphQL API безпосередньо з вашої бази даних Postgres. • Підтримує підписки на зміни в базі даних у реальному часі через WebSockets. Вимоги: • Не потрібно встановлювати розміщену платформу; просто зареєструйтесь. Незалежний огляд публічного проекту з відкритим кодом. Neural Nexus не пов'язаний, не схвалений та не спонсорований авторами проекту чи GitHub. Закадровий голос згенеровано штучним інтелектом та перевірено на відповідність публічному README. Репозиторій є джерелом достовірної інформації. #AI #supabase #opensource #postgres #database

5 個開源專案都能幫 AI 工作，從寫程式到找工作 今天的 GitHub 開源熱榜由 ponytail 領先，一天增加 2,079 星。其他上榜專案還包括 Supabase、vLLM、freehire 與 Twenty，涵蓋 AI coding agent、Postgres 平台、LLM serving、求職搜尋及客製化 CRM。 1｜ponytail：讓 AI 少寫程式碼 DietrichGebert/ponytail 2｜supabase：Postgres 開發平台 supabase/supabase 3｜vllm：高效 LLM 推論引擎 vllm-project/vllm 4｜freehire：開源職缺搜尋引擎 strelov1/freehire 5｜twenty：可客製化開源 CRM twentyhq/twenty 資料來源：GitHub Trending（今日新增 star） 每天幫你篩一遍 GitHub 開源熱榜。 排名依 GitHub Trending 當日新增 star 數，僅供參考，不代表推薦或背書。 #GitHub #開源 #程式設計 #開源專案 #GitHubTrending #軟體開發 #ponytail #JavaScript #TypeScript #Python #GitHub熱榜 #Supabase #Shorts

Reminder: new tables will require explicit API grants from October 30 Starting October 30, newly created tables in the public schema on existing Supabase projects will need explicit GRANT statements to be accessible through the Data and GraphQL APIs, including via supabase-js. Existing tables keep their current grants and will continue working. RLS behavior is unchanged, and direct Postgres connections aren’t affected. If your migrations or AI tools create tables, make sure they include the appropriate grants alongside your RLS policies. Full details and SQL examples

I did the same thing and ran haiku on low for about 3min46s to reverse engineer @pascal editor I open-sourced it here: pascalorg/editor Save your tokens. Agent-ftiendly 3D architecture is here: 100% free It already got 25k 🌟!!