Skip to content

AUTHZ_GUIDE.md

Latest commit

 

History

History
269 lines (189 loc) · 33.6 KB

AUTHZ_GUIDE.md

File metadata and controls

269 lines (189 loc) · 33.6 KB
Raw

Authorization Guide (ગુજરાતી)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

સત્યનો સ્ત્રોત: src/server/authz/, src/shared/constants/publicApiRoutes.ts, src/lib/api/requireManagementAuth.ts, src/shared/utils/apiAuth.ts છેલ્લે અપડેટ કરાયેલ: 2026-09-22 — સ્કોપ નેમસ્પેસ MCP-SERVER.md તરફ નિર્દેશ કરે છે

ઓમ્નીરૂટ પાસે રૂટ-અવેર ઓથોરાઇઝેશન પાઇપલાઇન છે જે દરેક API વિનંતીને ગેટ કરે છે. વર્ગીકરણ નિર્ધારિત અને ફેઇલ-ક્લોઝ્ડ છે — જે કંઈપણ વર્ગીકૃત કરી શકાતું નથી તે MANAGEMENT તરીકે સમાપ્ત થાય છે અને સત્ર અથવા મેનેજમેન્ટ-ગ્રેડ ટોકનની માંગ કરે છે. આ પૃષ્ઠ રૂટ જાળવતા અથવા નવા એન્ડપોઇન્ટ્સ ડિઝાઇન કરતા ઇજનેરો માટે મોડેલ સમજાવે છે.

AuthZ પાઇપલાઇન (3 રૂટ ક્લાસ + નીતિ મૂલ્યાંકન)

સ્ત્રોત: diagrams/authz-pipeline.mmd

બે પ્રમાણીકરણ મોડ

1. API કી (Bearer)

OpenAI/Anthropic/Gemini-સુસંગત ક્લાયન્ટ APIs માટે અને કી પાસે manage સ્કોપ હોય ત્યારે કેટલાક મેનેજમેન્ટ રૂટ્સ માટે વપરાય છે.

Authorization: Bearer <api-key>

src/sse/services/auth.ts માં isValidApiKey() / extractApiKey() દ્વારા માન્ય કરવામાં આવે છે અને src/shared/utils/apiAuth.ts મારફતે ફરીથી નિકાસ કરવામાં આવે છે. વેલિડેટર OMNIROUTE_API_KEY / ROUTER_API_KEY એન્વાયરમેન્ટ વેરિએબલ્સને સ્થાયી પાસથ્રૂ કીઓ તરીકે પણ સ્વીકારે છે (ઇશ્યૂ #1350).

2. ડૅશબોર્ડ સેશન (auth_token કૂકી)

ડૅશબોર્ડ પાનાંઓ અને એડમિન ઑપરેશન્સ માટે.

Cookie: auth_token=<JWT signed with JWT_SECRET>

કૂકી માત્ર ત્યારે જ સેશન ગણાય છે જ્યારે JWT ચકાસાય અને તેમાં authenticated: true હોય (src/shared/utils/dashboardSessionToken.ts → verifyDashboardSessionToken). કૂકીનો દરેક ઉપભોક્તા (રૂટ ગાર્ડ, authz પાઇપલાઇન રિફ્રેશ, WebSocket હૅન્ડશેક, લાઇવ સર્વર, /api/settings/require-login, /api/auth/status) તે હેલ્પર મારફતે જાય છે. JWT_SECRET વડે સહી કરાયેલા અન્ય JWTs પણ અસ્તિત્વમાં છે — Cursor CLI પાસથ્રૂ કી ધારકો માટે iss "omniroute" / aud "cursor-cli" ટોકન્સ બનાવે છે — અને તે ક્યારેય સેશન્સ નથી (#13298).

src/shared/utils/apiAuth.ts માં isDashboardSessionAuthenticated() દ્વારા ચકાસવામાં આવે છે. જ્યારે JWTના 30-દિવસના જીવનકાળમાંથી 7 દિવસથી ઓછો સમય બાકી હોય ત્યારે પાઇપલાઇન તેને આપમેળે રિફ્રેશ કરે છે.

કેટલાક મેનેજમેન્ટ રૂટ્સ બેમાંથી કોઈપણ મોડ સ્વીકારે છે: કૂકી અથવા Bearer <key>, જ્યારે API કી પાસે manage (અથવા admin) સ્કોપ હોય. આ જ બાબત v3.8 માં ઉમેરાયેલ "API કૉલ્સ દ્વારા કૉન્ફિગર કરી શકાય તેવું" વર્કફ્લો સક્ષમ કરે છે.

વૈકલ્પિક OIDC લૉગિન ગેટ (#6973)

ડૅશબોર્ડ એડમિન લૉગિન ડિફૉલ્ટ પાસવર્ડ લૉગિનની સાથે ઑપ્ટ-ઇન OIDC (OpenID Connect) ફ્લોને પણ સપોર્ટ કરે છે — પાસવર્ડ લૉગિન ક્યારેય દૂર થતું નથી, માત્ર તેમાં ઉમેરો થાય છે:

  • જ્યાં સુધી settings.oidcEnabled === true અને oidcIssuer / oidcClientId / oidcClientSecret બધાં કૉન્ફિગર થયેલાં ન હોય ત્યાં સુધી અક્ષમ રહે છે (સેટિંગ્સ → પ્રમાણીકરણ). અન્યથા GET /api/auth/oidc/login 400 પરત કરે છે.
  • GET /api/auth/oidc/login ઇશ્યૂઅરના /.well-known/openid-configuration માંથી authorization_endpoint શોધે છે (<issuer>/authorize નો ફૉલબૅક તરીકે ઉપયોગ કરે છે), આવનારી વિનંતીમાંથી રીડાયરેક્ટ URI બનાવે છે (x-forwarded-proto-જાગૃત), અને httpOnly oidc_state કૂકીમાં સંગ્રહિત રૅન્ડમ state સાથે IdP તરફ રીડાયરેક્ટ કરે છે.
  • GET /api/auth/oidc/callback state ને માન્ય કરે છે, ઑથોરાઇઝેશન કોડની અદલાબદલી કરે છે અને ઇશ્યૂઅરના JWKS મારફતે ID ટોકનની સહી ચકાસે છે (joseનું createRemoteJWKSet, દરેક JWKS URI માટે કૅશ કરેલું), જેમાં issuer/audience ચકાસણીઓ સામેલ છે. વૈકલ્પિક oidcAllowedSubjects અનુમતિસૂચિ ટોકનના sub ક્લેમ અથવા તેના email ક્લેમ સાથે મેળ ખાય છે — email ક્લેમને માત્ર ત્યારે જ માન્ય ગણવામાં આવે છે જ્યારે email_verified === true હોય, તેથી IdP પરનું અચકાસાયેલું email ક્યારેય ગેટ પાર કરી શકતું નથી.
  • સફળતા પર તે પાસવર્ડ લૉગિન દ્વારા જારી થતા ચોક્કસ એ જ 30-દિવસના auth_token JWT ને બનાવે છે (src/app/api/auth/login/route.ts), તેથી બાકીની ડૅશબોર્ડ સેશન પાઇપલાઇન (ઑટો-રિફ્રેશ, કૂકી ફ્લૅગ્સ) યથાવત્ રહે છે — OIDC માત્ર કૂકી કેવી રીતે બનાવવામાં આવે છે તેને બદલે છે, તે કયા અધિકારો આપે છે તેને નહીં.

રૂટ વર્ગો

src/server/authz/types.ts ત્રણ વર્ગો વ્યાખ્યાયિત કરે છે; જે કોઈ રૂટનું નિશ્ચિતપણે વર્ગીકરણ કરી શકાતું નથી તે MANAGEMENT પર પાછું જાય છે.

વર્ગ વર્ણન જરૂરી પ્રમાણીકરણ
PUBLIC સ્પષ્ટપણે સુરક્ષિત રૂટ્સ — લૉગિન, લૉગઆઉટ, સ્થિતિ, પ્રારંભ, હેલ્થ, ઑનબોર્ડિંગ બુટસ્ટ્રૅપ. કોઈ નહીં
CLIENT_API મૉડલ-સર્વિંગ એન્ડપોઇન્ટ્સ — /api/v1/*, /api/v1beta/*, તેમજ ઉપનામો /v1/*, /v1beta/*, /chat/completions, /responses, /models, /codex/*. અસરકારક REQUIRE_API_KEY ફીચર ફ્લૅગ સક્ષમ હોય ત્યારે Bearer કી
MANAGEMENT ડૅશબોર્ડ પૃષ્ઠો, સેટિંગ્સ, પ્રોવાઇડર્સ, કીઓ, ઍડમિન અને ડાયગ્નોસ્ટિક્સ એન્ડપોઇન્ટ્સ. ડૅશબોર્ડ સેશન અથવા manage સ્કોપ ધરાવતું Bearer

પાઇપલાઇન

આવતી રિક્વેસ્ટ → src/proxy.ts
  → src/server/authz/pipeline.ts માં runAuthzPipeline()
    1. વિશ્વસનીય આંતરિક હેડર્સ દૂર કરો (x-omniroute-auth-*, x-omniroute-route-class)
    2. રિક્વેસ્ટ id બનાવો, classifyRoute() દ્વારા રૂટનું વર્ગીકરણ કરો
    3. જો pathname == "/" → /dashboard પર રીડાયરેક્ટ કરો
    4. જો ડ્રેઇનિંગ (ગ્રેસફુલ શટડાઉન) ચાલુ હોય અને /api/* હોય → 503
    5. જો non-GET /api/* હોય → checkBodySize() ગાર્ડ
    6. જો OPTIONS હોય → CORS પ્રીફ્લાઇટ 204
    7. જો options.enforce == false હોય → route-class હેડર્સ સાથે પાસ-થ્રૂ
    8. અન્યથા: POLICIES[routeClass].evaluate(ctx)
       - મંજૂર કરો  → x-omniroute-auth-{kind,id,label,scopes} લગાવો → NextResponse.next()
       - નકારો → correlation_id સાથે JSON ભૂલ (ડૅશબોર્ડ પૃષ્ઠો → 302 /login)

વિશ્વસનીય આંતરિક હેડર્સ (src/server/authz/headers.ts માં વ્યાખ્યાયિત) વર્ગીકરણ પહેલાં આવતી રિક્વેસ્ટ્સમાંથી દૂર કરવામાં આવે છે — ક્લાયન્ટ્સ કોઈ સબ્જેક્ટનો ઢોંગ કરવા માટે x-omniroute-auth-* ને અગાઉથી ભરી શકતા નથી.

પૉલિસી કરારો

દરેક રૂટ વર્ગ માટે src/server/authz/policies/ માં એક પૉલિસી છે:

  • publicPolicy (policies/public.ts) — હંમેશા allow({ kind: "anonymous", id: "anonymous" }) પરત કરે છે.
  • clientApiPolicy (policies/clientApi.ts) — Bearer કાઢે છે, validateApiKey() દ્વારા તેને માન્ય કરે છે. અસરકારક REQUIRE_API_KEY ફીચર ફ્લૅગ અક્ષમ હોય ત્યારે જ અનામી ઍક્સેસ પર આગળ વધે છે. અસરકારક ફ્લૅગનું નિરાકરણ isRequireApiKeyEnabled() (DB ફીચર ફ્લૅગ ઓવરરાઇડ > process.env.REQUIRE_API_KEY > ડિફૉલ્ટ) દ્વારા થાય છે, જેથી ડૅશબોર્ડ ફીચર ફ્લૅગ્સ અને એન્વાયર્નમેન્ટ વેરિએબલ્સ /api/v1/*, /api/v1beta/* અને ઉપનામોને સુસંગત રીતે નિયંત્રિત કરે; રિઝોલ્વર નિષ્ફળતાઓ સુરક્ષિત રીતે ઍક્સેસ નકારે છે. ક્લાયન્ટ API રૂટ્સ પર ડૅશબોર્ડ-સેશન રિક્વેસ્ટ્સને મંજૂરી આપે છે (ડૅશબોર્ડ મૉડલ કૅટલૉગ દ્વારા ઉપયોગમાં લેવાતા /api/v1/models સહિત).
  • managementPolicy (policies/management.ts) — ડૅશબોર્ડ સેશન, આંતરિક મૉડલ-સિંક રિક્વેસ્ટ્સ (/api/providers/[name]/(sync-models|models) સામે મેળ ખાતી) સ્વીકારે છે અથવા જો isAuthRequired() false પરત કરે તો સંપૂર્ણપણે અવગણે છે. Bearer ટોકન હાજર પરંતુ અમાન્ય હોય ત્યારે 403 (AUTH_001), અન્યથા 401 પરત કરે છે. કોઈપણ પ્રમાણીકરણ શાખા પહેલાં રૂટ-ગાર્ડ સ્તરો (LOCAL_ONLY / ALWAYS_PROTECTED) પણ લાગુ કરે છે — રૂટ ગાર્ડ સ્તરો જુઓ. LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES માં રહેલા LOCAL_ONLY પાથ્સ (હાલમાં: /api/mcp/) ને Bearer કી manage સ્કોપ ધરાવતી હોય ત્યારે non-loopback પરથી ઍક્સેસ કરી શકાય છે; અન્ય તમામ LOCAL_ONLY પાથ્સ સ્કોપને ધ્યાનમાં લીધા વિના strict-loopback જ રહે છે.

સફળ પૉલિસી kind ∈ { client_api_key, dashboard_session, management_key, anonymous } સાથે AuthSubject પરત કરે છે. ડાઉનસ્ટ્રીમ હૅન્ડલર્સ પ્રમાણીકરણ લૉજિક ફરીથી ચલાવવાને બદલે src/server/authz/assertAuth.ts માં assertAuth(request, "CLIENT_API") દ્વારા તેને વાંચી શકે છે.

જાહેર રૂટ્સની સૂચિ

src/shared/constants/publicApiRoutes.ts એ સ્પષ્ટ allowlist છે:

સૂચિને આકાર અનુસાર વિભાજિત કરવામાં આવી છે, અને આ વિભાજન અત્યંત મહત્ત્વપૂર્ણ છે (GHSA-74g9-q8f6-793h): prefix ને startsWith() વડે match કરવામાં આવે છે, તેથી તે સમાન શરૂઆતના અક્ષરો ધરાવતા દરેક નજીકના path સાથે પણ match થાય છે. prefix તરીકે /api/usage/om-usage એ /api/usage/om-usage<anything> ને PUBLIC તરીકે ચિહ્નિત કર્યું હતું, અને Next તેને /api/usage/[connectionId] તરીકે resolve કરે છે — એવો handler જેનું પોતાનું કોઈ auth નથી.

// વાસ્તવિક subtrees. દરેક entry "/" પર સમાપ્ત થવી જ જોઈએ (unit test દ્વારા ચકાસાયેલ).
PUBLIC_API_ROUTE_PREFIXES = [
  "/api/auth/oidc/",
  "/api/v1/", // classify માં CLIENT_API તરીકે ગણાય છે, "no-auth public" તરીકે નહીં
  "/api/oauth/",
  "/api/codex/connect/",
  "/api/telegram/",
  "/api/cursor-cli/",
];

// એકલ routes, EXACTLY match કરવામાં આવે છે (અંતે slash હોય કે ન હોય).
PUBLIC_API_ROUTES_EXACT = new Set([
  "/api/auth/login",
  "/api/auth/logout",
  "/api/auth/status",
  "/api/init",
  "/api/sync/bundle",
  "/api/cli/connect",
  "/api/usage/om-usage",
  "/api/skills/collect/chaos",
]);

// ફક્ત વાંચવા માટેના એકલ routes, જેમને CORS origin relaxation પણ મળે છે.
PUBLIC_READONLY_CORS_API_ROUTES = [
  "/api/health/ping",
  "/api/monitoring/health",
  "/api/settings/require-login",
];

// CORS relaxation વિનાનો ફક્ત વાંચવા માટેનો એકલ route.
PUBLIC_READONLY_API_ROUTES_EXACT = new Set(["/api/health"]);

PUBLIC_READONLY_METHODS = new Set(["GET", "HEAD", "OPTIONS"]);

ફક્ત વાંચવા માટેના routes માત્ર સુરક્ષિત methods માટે જ જાહેર છે. નોંધ: classifyRoute() /api/v1/* અને /api/v1beta/* ને PUBLIC fall-through માંથી બાકાત રાખે છે — તે હંમેશાં CLIENT_API હોય છે, જેથી Bearer-key policy હજી પણ લાગુ પડે.

નવો Route ઉમેરવો

Pattern 1 — જાહેર client API endpoint (Bearer-auth)

/api/v1/ અને /api/v1beta/ હેઠળના routes આપમેળે CLIENT_API તરીકે classify થાય છે. middleware Bearer check લાગુ કરે છે; route handlers એ તેને ફરી કરવાની જરૂર નથી, પરંતુ ઉપયોગી હોય તો subject વાંચી શકે છે.

// src/app/api/v1/your-route/route.ts
import { NextRequest, NextResponse } from "next/server";
import { assertAuth } from "@/server/authz/assertAuth";

export async function POST(req: NextRequest) {
  const subject = assertAuth(req, "CLIENT_API");
  // subject.kind === "client_api_key" | "anonymous" | "dashboard_session"
  // ... handler logic
}

Pattern 2 — Management endpoint (session અથવા Bearer + manage)

src/lib/api/requireManagementAuth.ts માંથી requireManagementAuth() નો ઉપયોગ કરો:

import { requireManagementAuth } from "@/lib/api/requireManagementAuth";

export async function POST(request: Request) {
  const rejection = await requireManagementAuth(request);
  if (rejection) return rejection;
  // ... handler logic
}

સફળતા પર requireManagementAuth() null પરત કરે છે અથવા JSON error Response પરત કરે છે:

  • 401 AUTH_001 "પ્રમાણીકરણ જરૂરી છે" — કોઈ credentials જ નથી
  • 403 — અમાન્ય Bearer અથવા Bearer હાજર છે, પરંતુ key પાસે manage / admin scope નથી

hasManageScope(scopes) "manage" અથવા "admin" માટે true પરત કરે છે.

Pattern 3 — જાહેર allowlist માં ઉમેરવું

સુવિધા અનુસાર નહીં, પણ આકાર અનુસાર set પસંદ કરો. એક route PUBLIC_API_ROUTES_EXACT માં જાય છે (અથવા માત્ર GET માટે PUBLIC_READONLY_CORS_API_ROUTES માં); માત્ર વાસ્તવિક subtree જ PUBLIC_API_ROUTE_PREFIXES માં જાય છે, અને તે / પર સમાપ્ત થવું જ જોઈએ. prefix સૂચિમાં એકલ route મૂકવાથી સમાન શરૂઆતના અક્ષરો ધરાવતા દરેક નજીકના path પણ જાહેર થઈ જાય છે — જેમાં પછીથી ઉમેરાયેલા dynamic-segment siblings પણ સામેલ છે (GHSA-74g9-q8f6-793h). tests/unit/public-api-routes.test.ts, tests/unit/authz/public-route-exact-match.test.ts અને tests/unit/authz/classify.test.ts ખાતેના unit tests અપડેટ કરો.

સ્કોપ્સ

ત્રણ નેમસ્પેસ. દરેક ચેકર ફક્ત તેની પોતાની સ્ટ્રિંગ્સ વાંચે છે. બાજુ-બાજુની સરખામણી, જેમાં શા માટે manage read:compression માટે scopeMatches માં નિષ્ફળ જાય છે અને શા માટે read એક્સેસ ટોકન PATCH /api/keys/{id} કરી શકતું નથી, તે ત્રણ સ્કોપ નેમસ્પેસ માં છે.

API કી scopes એરે ધરાવે છે (જે api_keys.scopes માં JSON તરીકે સંગ્રહિત છે, જુઓ src/lib/db/apiKeys.ts).

મેનેજમેન્ટ સ્કોપ

  • manage / admin — hasManageScope. મેનેજમેન્ટ API રૂટ્સ માટે બેરર એક્સેસ.
  • mcp:connect, self:usage, self:account-quota, અને policy:bypass-provider-quota એ એડિટિવ એક્ઝેક્ટ-મેચ સ્કોપ્સ છે. તેઓ MANAGEMENT_API_KEY_SCOPES ની બહાર છે. mcp:connect ફક્ત /api/mcp/ નોન-લૂપબેક કાર્વ-આઉટ ખોલે છે.

MCP ટૂલ સ્કોપ્સ

કેટલોગ અને મેચિંગ નિયમો (સમાન સ્ટ્રિંગ, અથવા * માં સમાપ્ત થતો ગ્રાન્ટેડ સ્કોપ): MCP ટૂલ સ્કોપ્સ. src/shared/constants/mcpScopes.ts માં MCP_SCOPE_LIST એ મૂળ ટાઈપ્ડ સબસેટ છે, તે સંપૂર્ણ કેટલોગ નથી. અમલીકરણ open-sse/mcp-server/scopeEnforcement.ts માં resolveCallerScopeContext() MCP ઓથ માહિતી, વિનંતી મેટાડેટા, અથવા OMNIROUTE_MCP_SCOPES માંથી સ્કોપ્સને રિઝોલ્વ કર્યા પછી ચાલે છે. જો OMNIROUTE_MCP_ENFORCE_SCOPES=true ન હોય તો તે બંધ રહે છે.

એક્સેસ-ટોકન સ્કોપ્સ

oma_live_… ટોકન્સ પર read / write / admin, scopeSatisfies (src/lib/accessTokens/scopes.ts) દ્વારા ક્રમાંકિત. આ ક્રમ ફક્ત એક્સેસ-ટોકન ક્રેડેન્શિયલને લાગુ પડે છે. જુઓ મેનેજમેન્ટ ઓથેન્ટિકેશન.

પ્રમાણીકરણ આવશ્યકતા ટૉગલ

src/shared/utils/apiAuth.ts માંનું isAuthRequired() નક્કી કરે છે કે વિનંતી માટે કોઈપણ પ્રમાણીકરણ લાગુ કરવામાં આવે છે કે નહીં:

  • settings.requireLogin === false → પ્રમાણીકરણ વૈશ્વિક રીતે અક્ષમ છે.
  • કોઈ પાસવર્ડ કૉન્ફિગર કરેલો ન હોય અને INITIAL_PASSWORD env var ન હોય → બૂટસ્ટ્રૅપ મોડ ઑનબોર્ડિંગ વિઝાર્ડ અને લૂપબૅક વિનંતીઓને મંજૂરી આપે છે, પરંતુ નેટવર્ક પર એક્સપોઝ કરેલી વિનંતીઓ માટે હજુ પણ ઓળખપત્રો જરૂરી છે.
  • કોઈપણ DB ભૂલ → ઍક્સેસ નકારી દે છે (મૂળભૂત રીતે સુરક્ષિત).

ક્લાયન્ટ API કીનું અમલીકરણ સીધું process.env.REQUIRE_API_KEY વાંચવાને બદલે src/shared/utils/featureFlags.ts માંના isRequireApiKeyEnabled() નો ઉપયોગ કરે છે. ડિપ્લોય કરેલા ઇન્સ્ટન્સ માટે આ મહત્ત્વપૂર્ણ છે: Dashboard → Feature Flags માં REQUIRE_API_KEY ટૉગલ કરવાથી DB ઓવરરાઇડ સંગ્રહિત થાય છે અને તરત જ /v1/*, /v1beta/*, /models, /responses, /chat/completions, /codex/* તથા આ હેલ્પરનો ઉપયોગ કરતી અન્ય ક્લાયન્ટ-API પ્રમાણીકરણ ચકાસણીઓને અસર કરે છે. જો ફીચર ફ્લૅગ સ્ટોર વાંચી ન શકાય, તો ક્લાયન્ટ API પ્રમાણીકરણ ઍક્સેસ નકારી દે છે અને કી જરૂરી બનાવે છે.

બ્રેકિંગ ફેરફાર — v3.8.0

/api/v1/agents/tasks/* અને /api/resilience/model-cooldowns એન્ડપોઇન્ટ્સને હવે મેનેજમેન્ટ પ્રમાણીકરણ જરૂરી છે (કમિટ 588a0333). અગાઉ manage સ્કોપ વિના સામાન્ય API કી મોકલતા ક્લાયન્ટ્સને 403 મળે છે. માઇગ્રેશન: API Keys ડૅશબોર્ડમાં કીને manage સ્કોપ આપો અથવા લૉગ-ઇન કરેલા ડૅશબોર્ડ સેશનનો ઉપયોગ કરો.

વર્તન ફેરફાર — v3.8.2

/api/mcp/* (રિમોટ MCP સર્વર) મૂળભૂત રીતે હજુ પણ LOCAL_ONLY છે, પરંતુ હવે જ્યારે Authorization: Bearer <api-key> હેડરમાં manage સ્કોપ હોય ત્યારે તે નૉન-લૂપબૅક વિનંતીઓ સ્વીકારે છે. આ અપવાદને src/server/authz/routeGuard.ts માં LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES મારફતે દરેક પાથ માટે સ્પષ્ટ રીતે નિયંત્રિત કરવામાં આવે છે; સમકક્ષ LOCAL_ONLY પ્રીફિક્સ /api/cli-tools/runtime/* ને ઇરાદાપૂર્વક બાયપાસ કરી શકાતું નથી, કારણ કે તે મનસ્વી સબપ્રોસેસ શરૂ કરી શકે છે. નૉન-લૂપબૅકમાંથી /api/mcp/* માટેની અનામી વિનંતીઓ હજુ પણ 403 LOCAL_ONLY પરત કરે છે — કોઈપણ નવા LOCAL_ONLY પાથ માટે મૂળભૂત નિયમ કડક-લૂપબૅક જ રહે છે. રાઉટ ગાર્ડ સ્તરો જુઓ.

પરીક્ષણ

  • યુનિટ પરીક્ષણો: tests/unit/authz/ — classify.test.ts, pipeline.test.ts, client-api-policy.test.ts, management-policy.test.ts, public-policy.test.ts.
  • જાહેર અલાઉલિસ્ટ: tests/unit/public-api-routes.test.ts.
  • કેન્દ્રિત પરીક્ષણ ચલાવો: node --import tsx/esm --test tests/unit/authz/classify.test.ts.

ડિબગિંગ

પાઇપલાઇન હંમેશા પ્રતિસાદો પર નીચેના હેડર્સ મૂકે છે:

x-request-id:               <correlation id, ભૂલના પ્રતિસાદના મુખ્ય ભાગમાં પુનરાવર્તિત>
x-omniroute-route-class:    PUBLIC | CLIENT_API | MANAGEMENT

પ્રમાણિત વિનંતીઓ માટે અપસ્ટ્રીમ (હેન્ડલર-સાઇડ) વિનંતીના હેડર્સમાં નીચેના પણ સામેલ હોય છે:

x-omniroute-auth-kind:      client_api_key | dashboard_session | management_key | anonymous
x-omniroute-auth-id:        key_<last-4> | "dashboard" | "anonymous"
x-omniroute-auth-label:     (વૈકલ્પિક)
x-omniroute-auth-scopes:    અલ્પવિરામથી અલગ કરેલી સૂચિ

હેન્ડલર્સની અંદર assertAuth(req, expectedClass) નો ઉપયોગ કરો — જો મિડલવેરને બાયપાસ કરવામાં આવ્યું હોય, તો તે AUTHZ_NOT_INITIALIZED કોડ સાથે AuthzAssertionError થ્રો કરે છે (ટેસ્ટ્સમાં કન્ફિગરેશન રિગ્રેશન્સ શોધવા માટે ઉપયોગી).

આ પણ જુઓ

  • API_REFERENCE.md — દરેક એન્ડપોઇન્ટ દીઠ ઓથ માર્કર
  • COMPLIANCE.md — ઓથ ઇવેન્ટ્સ માટે ઓડિટ લોગ
  • MCP-SERVER.md — ત્રણ સ્કોપ નેમસ્પેસ અને MCP ટૂલ-સ્કોપ કેટલોગ
  • સ્ત્રોત: src/server/authz/, src/lib/api/requireManagementAuth.ts