Route Guard Tiers (नेपाली)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇱 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

सिंहावलोकन

सबै OmniRoute व्यवस्थापन API रुटहरूलाई सुरक्षाका तीन तहहरूमध्ये एउटामा वर्गीकृत गरिएको छ। वर्गीकरण स्थिर छ, src/server/authz/routeGuard.ts मा परिभाषित गरिएको छ, र अन्य कुनै पनि प्रमाणीकरण शाखा चल्नुअघि मूल्याङ्कन गरिन्छ।

तहहरू

तह 1 — LOCAL_ONLY

यसद्वारा लागू गरिएको: isLocalOnlyPath(path) → लूपब्याक होस्ट जाँच बाइपास: पूर्वनिर्धारित रूपमा कुनै पनि छैन। अनुरोधमा manage स्कोप भएको मान्य API कुञ्जी हुँदा LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES भित्रका पाथहरूका लागि सीमित अपवाद हुन्छ (Manage-scope अपवाद हेर्नुहोस्)।

यी रुटहरूले चाइल्ड प्रोसेसहरू सुरु गर्छन् वा रनटाइम कोड कार्यान्वयन गर्छन्। तिनीहरूलाई गैर-लूपब्याक ट्राफिकका लागि खुला गर्दा मान्य JWT प्राप्त गरेको आक्रमणकारीले (जस्तै, Cloudflared/Ngrok टनेलमार्फत) प्रोसेस सुरु गर्न सक्नेछ — जुन परिचित CVE वर्ग हो (GHSA-fhh6-4qxv-rpqj)।

GHSA-fhh6-4qxv-rpqj के हो (आक्रमणको वर्ग): कुनै व्यवस्थापन/एजेन्ट सर्भरले सबप्रोसेस सुरु गर्ने (npm install, node, ब्राउजर, प्रोक्सी, git, tar, …) एन्डपोइन्ट खुला गर्छ। यदि त्यो एन्डपोइन्ट बाह्य होस्टबाट पहुँचयोग्य छ भने — किनकि सञ्चालकले OmniRoute लाई nginx/Cloudflare/Tailscale टनेल पछाडि राखेको छ र JWT चुहिएको छ, वा प्रमाणीकरण गलत रूपमा कन्फिगर गरिएको छ — आक्रमणकारीले "API कल गर्ने" कार्यलाई "होस्टमा कमान्ड चलाउने" कार्यमा बदल्छ (रिमोट कोड कार्यान्वयन)। OmniRoute ले प्रत्येक प्रोसेस सुरु गर्न सक्ने रुटमा कुनै पनि प्रमाणीकरण जाँचअघि, अनिवार्य रूपमा लूपब्याक होस्ट जाँच लागू गरेर यसलाई रोक्छ: टनेलमार्फत चुहिएको टोकनले अझै पनि प्रोसेस सुरु गर्ने क्षेत्रसम्म पुग्न सक्दैन।

सम्पूर्ण LOCAL_ONLY समूह। आधिकारिक स्रोत src/server/authz/routeGuard.ts मा रहेको LOCAL_ONLY_API_PREFIXES / LOCAL_ONLY_API_PATTERNS हो; तलको तालिकाले हालको अवस्था प्रतिबिम्बित गर्छ। check-route-guard-membership गेटले प्रोसेस सुरु गर्न सक्ने प्रिफिक्सहरूअन्तर्गतका प्रत्येक route.ts सूचीबद्ध गर्छ र कुनै पनि local-only का रूपमा वर्गीकृत नभएमा CI असफल बनाउँछ।

प्रिफिक्स / ढाँचा	यो किन स्थानीयमा मात्र सीमित छ
`/api/mcp/`	MCP सर्भर — stdio ब्रिजहरू + SSE ह्यान्डलरहरू सुरु गर्छ
`/api/cli-tools/runtime/`	CLI उपकरण रनटाइम — स्वेच्छाचारी प्लगइन कोड कार्यान्वयन गर्छ
`/api/cli-tools/{omp,letta,grok-build,forge,jcode,qwen}-settings`	प्रत्येक उपकरणका सेटिङ लेखकहरू, जसले होस्टमा रहेका उपकरण बाइनरी/कन्फिगलाई परिवर्तन गर्न सक्छन्
`/api/cli-tools/{claude,cline,codewhale,codex,crush,deepseek-tui,droid,kilo,openclaw,pi,smelt}-settings`	माथिका छ सहोदरहरूकै समान `getCliRuntimeStatus()` प्रक्रिया सुरु गर्ने कार्य (GHSA-35fw-cv32-2373)
`/api/cli-tools/{all-statuses,status,detect}`	CLI सूची परीक्षणहरू — प्रत्येक उपकरणका लागि `command -v` / `--version` सुरु गर्छन् (GHSA-35fw-cv32-2373)
`/api/cli-tools/antigravity-mitm`	Antigravity MITM प्रोक्सी नियन्त्रण (सिस्टम प्रोक्सी सुरु गर्छ/त्यसतर्फ निर्देशित गर्छ)
`/api/modality-bridge/video/`	कडाइका साथ विश्वसनीय-लुपब्याक Video Bridge रनटाइम परीक्षण र आन्तरिक निष्कर्षण ब्रिज
`/api/services/`	अन्तर्निर्मित सेवाहरू (9Router / CLIProxy / Bifrost / Mux / Dario) — `npm install` + प्रक्रिया सुरु गर्ने
`/dashboard/providers/services/`	अन्तर्निर्मित सेवाका UI हरूतर्फ रिभर्स प्रोक्सी
`/api/tunnels/cloudflared`	cloudflared बाइनरी स्थापना/सुरु गर्छ
`/api/tunnels/tailscale/{install,enable,disable,login,start-daemon}`	होस्टमा tailscaled स्थापना/नियन्त्रण गर्छ
`/api/copilot/`	प्रमाणीकरण नगरिएको LLM ड्राइभर — पूर्वनिर्धारित रूपमा CLI मा मात्र
`/api/tools/agent-bridge/`	AgentBridge — MITM सर्भर सुरु गर्छ + DNS सम्पादन गर्छ
`/api/tools/traffic-inspector/`	Traffic Inspector — http-proxy लिसनर + सिस्टम प्रोक्सी
`/api/settings/mitm`	MITM अवरोधन सक्षम गर्छ (सिस्टम-स्तरीय प्रोक्सी अवस्था)
`/api/issue-agent/`	समस्या एजेन्ट — रिपोजिटरीविरुद्ध स्थानीय उपकरणहरू सुरु गर्छ
`/api/plugins/`, `/api/plugins`	प्लगइनहरू — `worker_threads` + `child_process` मार्फत लोड/कार्यान्वयन गर्छ
`/api/middleware/`	प्रयोगकर्ता मिडलवेयर — प्रक्रियाभित्रै सञ्चालकको कोड लोड/कार्यान्वयन गर्छ
`/api/system/version`	स्वतः-अद्यावधिक (POST मात्र; GET/HEAD/OPTIONS छुट) — `git checkout` + `npm install` सुरु गर्छ
`/api/db-backups/exportAll`	निर्यात अभिलेखका लागि `tar` सुरु गर्छ
`/api/local/`	एक-क्लिक स्थानीय लन्चरहरू (हाल Redis) — podman/docker सुरु गर्छ
`/api/headroom/start`, `/api/headroom/stop`	Headroom प्रोक्सी जीवनचक्र — python CLI सुरु गर्छ / PID लाई सङ्केत पठाउँछ
`/api/jobs`, `/api/jobs/`	कार्य सञ्चालक नियन्त्रण — निर्धारित होस्ट-साइड कार्य कार्यान्वयन गर्छ
`/api/oauth/cursor/auto-import`	प्रमाणपत्रहरू आयात गर्नुअघि `execFile("which", ["cursor"])` चलाउँछ
`/api/oauth/kiro/auto-import`	होस्टबाट Kiro CLI प्रमाणपत्र फाइलहरू पढ्छ
`/api/skills/collect/`	सीप सङ्कलन — स्थानीय उपकरणहरू पत्ता लगाउँछ/स्थापना गर्छ
`/api/skills/install`, `/api/skills/executions`	सीप ह्यान्डलर दर्ता + कार्यान्वयन — स्यान्डबक्स कन्टेनर सुरु गर्ने प्रक्रियासम्म पुग्छ (GHSA-jx89)
`/api/discovery/`	स्थानीय नेटवर्क/प्रदायक खोज परीक्षणहरू
`/api/vnc-session` (`VNC_ROUTE_PREFIX`)	अन्तरक्रियात्मक लगइनका लागि headful ब्राउजर + VNC सत्र सुरु गर्छ
`/api/acp/agents`	ACP — स्थानीय CLI agent बाइनरीहरू पत्ता लगाउँछ र सुरु गर्छ
`/api/resilience/connections`	प्रति-खाता resilience JSON (cooldown, breaker, lockout)। dashboard HTML स्थानीयमा मात्र सीमित छैन।
`/api/providers/cursor/agent-availability`	dashboard को install-nudge जाँच — `cursor-agent status --format json` सुरु गर्छ
`/api/providers/{id}/login` (regex)	web-cookie लगइनका लागि headful Playwright Chromium सुरु गर्छ
`/api/providers/volcengine-plan/connect` (regex)	म्यानुअल headful प्रवाह + सत्र-आधारित फोन/SMS स्वतः-लगइन (Playwright सुरु गर्छ)
`/api/providers/{id}/refresh-cursor` (regex)	म्यानुअल Cursor सत्र नवीकरण — `cursor-agent` लाई सक्रिय गराउँछ
`/api/providers/{id}/chatgpt-web-codex-doctor` (regex)	स्थानीय Codex CLI स्थापना निदान गर्छ (बाइनरी सुरु गर्छ)

उल्लङ्घन हुँदा प्रतिक्रिया: 403 LOCAL_ONLY

Manage-scope अपवाद

LOCAL_ONLY path हरूको एउटा उपसमूहमा non-loopback बाट पनि पहुँच गर्न सकिन्छ यदि र केवल यदि अनुरोधमा यस्तो Authorization: Bearer <api-key> छ जसको metadata मा manage scope (वा admin) समावेश छ। यो अपवादलाई LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES मार्फत प्रत्येक path का लागि स्पष्ट रूपमा नियन्त्रण गरिन्छ, ताकि कुनै पनि नयाँ LOCAL_ONLY path को पूर्वनिर्धारित अवस्था strict-loopback नै रहोस्। प्रमाणीकरण नगरिएका अनुरोधहरू र non-manage key भएका अनुरोधहरू अझै पनि 403 LOCAL_ONLY सहित अस्वीकार गरिन्छन्।

हाल bypass गर्न सकिने एकमात्र prefix /api/mcp/ हो। /api/cli-tools/runtime/ र /api/services/ लाई जानाजानी समावेश गरिएको छैन, किनकि तिनले स्वेच्छाचारी subprocess हरू (npm install, node) सुरु गर्न सक्छन्, जुन LOCAL_ONLY tier ले रोक्न खोजेको ठ्याक्कै त्यही CVE वर्ग हो।

#7895 — mcp:connect सीमित scope: /api/mcp/ अपवादले सीमित mcp:connect scope भएको Bearer key पनि स्वीकार गर्छ (src/shared/constants/managementScopes.ts::MCP_CONNECT_SCOPE), जसलाई src/server/authz/policies/management.ts को hasMcpConnectOrManageScope() मार्फत जाँचिन्छ। यो /api/mcp/ मा मात्र सीमित छ — mcp:connect ले अन्य कुनै पनि management route मा (भविष्यमा थपिएमा अन्य सबै LOCAL_ONLY bypass prefix सहित) कुनै अनुमति दिँदैन, र यसलाई जानाजानी MANAGEMENT_API_KEY_SCOPES बाट बाहिर राखिएको छ। manage/admin भएको key ले पहिलेझैँ अपवाद पार गर्छ; mcp:connect व्यापक management पहुँच आवश्यक नपर्ने remote MCP-मात्र caller हरूका लागि कम-विशेषाधिकारयुक्त विकल्प हो।

अनुरोध	Path	नतिजा
Non-loopback, Bearer छैन	`/api/mcp/*`	403 LOCAL_ONLY
Non-loopback, `manage` scope भएको Bearer	`/api/mcp/*`	अनुमति
Non-loopback, `mcp:connect` scope भएको Bearer	`/api/mcp/*`	अनुमति
Non-loopback, `manage`/`mcp:connect` नभएको Bearer	`/api/mcp/*`	403 LOCAL_ONLY
Non-loopback, `mcp:connect` scope भएको Bearer	`/api/cli-tools/runtime/*`	403 LOCAL_ONLY
Non-loopback, `manage` scope भएको Bearer	`/api/cli-tools/runtime/*`	403 LOCAL_ONLY
Loopback, कुनै पनि/कुनै Bearer छैन	कुनै पनि LOCAL_ONLY	अनुमति (gate पार हुन्छ)

Operator मार्गदर्शन र auditing

यदि तपाईं OmniRoute लाई reverse proxy वा tunnel (nginx, Caddy, Cloudflare Tunnel, Tailscale, Ngrok) पछाडि चलाउनुहुन्छ भने पनि loopback जाँचले माथिका spawn-सक्षम route हरूलाई सुरक्षित राख्छ — client address non-loopback भएको अनुरोधलाई auth चल्नुअघि नै 403 LOCAL_ONLY सहित अस्वीकार गरिन्छ, त्यसैले leak भएको JWT ले spawn सम्म पुग्न सक्दैन। Operator का दुई जिम्मेवारी बाँकी रहन्छन्:

Client IP लाई loopback का रूपमा नक्कली बनाएर 403 लाई "ठीक" नगर्नुहोस्। X-Forwarded-For: 127.0.0.1 सेट गर्दा, वा source address लाई loopback मा पुनर्लेखन गर्ने proxy प्रयोग गर्दा, यो tier ले बन्द गरेको ठ्याक्कै त्यही RCE वर्ग फेरि खुल्छ। Proxy मार्फत dashboard/API उपलब्ध गराउनुहोस् — spawn-सक्षम route हरू कहिल्यै उपलब्ध नगराउनुहोस्।
Manage-scope bypass न्यूनतम राख्नुहोस्। /api/mcp/ मात्र bypass गर्न सकिन्छ, र त्यो पनि manage-scoped API key ले मात्र। SPAWN_CAPABLE_PREFIXES लाई कहिल्यै bypass सूचीमा थप्न सकिँदैन — zod schema ले तिनलाई अस्वीकार गर्छ र isLocalOnlyBypassableByManageScope ले runtime मा तिनलाई रोक्छ (defence-in-depth), dashboard मा "cannot be made bypassable" भन्नुको अर्थ यही हो। /api/providers/ अन्तर्गतका dynamic-segment र static-path spawn-सक्षम route हरू (जस्तै /login, /refresh-cursor) लाई flat SPAWN_CAPABLE_PREFIXES array ले होइन, src/shared/constants/spawnCapablePrefixes.ts मा रहेको regex-आधारित SPAWN_CAPABLE_PATTERNS / SPAWN_CAPABLE_PATTERN_ANCESTORS सहायकले समेट्छ — तिनलाई समात्न flat array ले सम्पूर्ण /api/providers/ prefix समेट्नुपर्ने हुन्थ्यो, जसले remote dashboard हरूले provider CRUD का लागि वैध रूपमा प्रयोग गर्ने route tree लाई अत्यधिक फराकिलो रूपमा प्रतिबन्धित गर्थ्यो।

पहुँच auditing — off-host बाट कुनै पनि अनुरोध यी route हरूमा पुगिरहेको छैन भनी पुष्टि गर्न:

/dashboard/settings/security मा प्राधिकरण सूची खोल्नुहोस्: यसले प्रत्यक्ष LOCAL_ONLY उपसर्ग सूची, कुन-कुन उपसर्गलाई बाइपास गर्न सकिन्छ, र कम्पाइल-समयको प्रक्रिया सुरु गर्न सक्ने ("बाइपासयोग्य बनाउन नसकिने") सेट देखाउँछ।
माथिका उपसर्गहरूलाई non-loopback क्लाइन्ट ठेगानासँग जोडी आफ्नो reverse-proxy / पहुँच लगहरूमा Grep गर्नुहोस्। 403 LOCAL_ONLY को सट्टा 200 फर्काउने त्यस्तो कुनै पनि हिटले प्रोक्सीले वास्तविक क्लाइन्ट IP लुकाइरहेको छ भन्ने जनाउँछ — प्रोक्सी ठीक गर्नुहोस्।
यीमध्ये कुनै पथका लागि OmniRoute का लगहरूमा आएको 403 LOCAL_ONLY भनेको गार्डले अपेक्षित रूपमा काम गरिरहेको हो, दबाउनुपर्ने त्रुटि होइन।

तह 2 — ALWAYS_PROTECTED

यसद्वारा लागू गरिएको: isAlwaysProtectedPath(path) → requireLogin=false बाइपास छोड्ने बाइपास: requireLogin=false हुँदा कुनै पनि छैन; JWT सधैँ आवश्यक हुन्छ

यी रुटहरू विनाशकारी वा अपरिवर्तनीय छन्। तिनलाई "पासवर्ड-रहित" स्थापनामा अनुमति दिनुको अर्थ एउटै LAN मा भएको जोसुकैले डेटाबेस मेटाउन वा सर्भर प्रक्रिया बन्द गर्न सक्ने हुनु हो।

पथ	कारण
`/api/shutdown`	सर्भर प्रक्रिया समाप्त गर्छ
`/api/settings/database`	डेटाबेस निर्यात, आयात र पूर्ण मेटाइ
`/api/db-backups`	पूर्ण डेटाबेस ब्याकअप अभिलेखमा पहुँच
`/api/settings/export-json`	पूर्ण सेटिङ्स ब्लब निर्यात गर्छ (गोप्य कुरासहित)
`/api/settings/import-json`	पूर्ण सेटिङ्स ब्लब प्रतिस्थापन गर्छ
`/api/providers/health-autopilot/actions`	autopilot सुधारात्मक कार्यहरू कार्यान्वयन गर्छ
`/api/settings/obsidian`	कुनै पनि vault root का लागि पुनःप्रयोगयोग्य WebDAV प्रमाणहरू जारी गर्छ

उल्लङ्घनमा प्रतिक्रिया: 401 Authentication required

/api/settings/obsidian ले यसको /webdav चाइल्डलाई समेट्छ: POST ले WebDAV फाइल सेवा — यो पाइपलाइनभन्दा बाहिर, Next.js अघि अनुकूलित Node तहद्वारा सेवा दिइने — लाई कलरले रोजेको root मा निर्देशित गर्छ र भर्खरै जारी गरिएका Basic प्रमाणहरू फर्काउँछ, DELETE ले तिनलाई परिवर्तन गर्छ, र अभिभावक POST ले Obsidian REST API token भण्डारण गर्छ। GHSA-62vw ले GET मार्फत पासवर्ड देखिने कुरा मात्र लुकाएको थियो; प्रमाण जारी गर्ने कार्य अझै पनि fail-open तहमा थियो (GHSA-7pq4-8pvv-rx7r)। enableObsidianVaultSync() ले data directory नै भएको, त्यसभित्र रहेको, वा त्यसलाई समेट्ने vault लाई थप रूपमा अस्वीकार गर्छ।

नयाँ स्थापनाको bootstrap वास्तविक peer का आधारमा loopback-मात्र हो — `Host` का आधारमा होइन

कुनै व्यवस्थापन पासवर्ड कन्फिगर नगरिएको अवस्थामा (र INITIAL_PASSWORD पनि नभएमा), src/shared/utils/apiAuth.ts मा रहेको isAuthRequired() ले अज्ञात bootstrap लाई loopback peer का लागि मात्र खुला राख्छ। loopback विश्वसनीय peer सङ्केतहरूबाट यस क्रममा निर्धारण गरिन्छ: token-stamped वास्तविक TCP peer (PEER_IP_HEADER + VIA_PROXY_HEADER, जसलाई नीतिले देख्छ), पाइपलाइनकै AUTHZ_HEADER_PEER_LOCALITY निर्णय (जसलाई route handler हरूले देख्छन्, OMNIROUTE_PEER_STAMP_TOKEN सेट भएको बेलामा मात्र विश्वसनीय), वा प्रत्यक्ष कलरहरूका लागि वास्तविक socket peer। Host / nextUrl.hostname लाई कहिल्यै हेरिँदैन, र पहिलो-पासवर्ड लेखाइ (POST /api/settings/require-login) हरेक नेटवर्क peer का लागि खुला हुनुको सट्टा यही प्रतिबन्धअन्तर्गत हुन्छ (GHSA-7pq4-8pvv-rx7r)। managementPolicy ले आफ्नै peerContext निर्णयलाई स्पष्ट रूपमा तल पठाउँछ, त्यसैले ORIGINAL (हटाउनुअघिको) अनुरोधका header हरूले यसको निर्णय कहिल्यै गर्दैनन्।

तह 3 — MANAGEMENT (पूर्वनिर्धारित)

अन्य सबै व्यवस्थापन रुटहरू। requireLogin=false कन्फिगर नगरिएसम्म प्रमाणीकरण आवश्यक हुन्छ। CLI token हरूले यी रुटहरूमा प्रमाणीकरण गर्न सक्छन् (loopback + मान्य HMAC)।

मूल्याङ्कन क्रम

managementPolicy.evaluate(ctx)
  1. isLocalOnlyPath(path)?
     → loopback                                  → अर्को चरणमा जाने
     → non-loopback, manage-scope Bearer
        AND isLocalOnlyBypassableByManageScope   → अनुमति दिने (management_key)
     → अन्यथा                                    → अस्वीकार गर्ने 403 LOCAL_ONLY
  2. isInternalModelSyncRequest(ctx)?
     → अनुमति दिने (system)
  3. hasValidCliToken(headers)?
     → अनुमति दिने (cli) [loopback + timingSafeEqual HMAC जाँच]
  4. isAlwaysProtectedPath(path) वा requireLogin=true?
     → isDashboardSessionAuthenticated?
        → अनुमति दिने (dashboard_session)
     → बाइपास गर्न नमिल्ने पथमा manage-scope Bearer?
        → अनुमति दिने (management_key)
     → अस्वीकार गर्ने 401/403
  5. requireLogin=false?
     → अनुमति दिने (anonymous)

चरण 1 को manage-scope शाखा नै LOCAL_ONLY रुटलाई पूरा गर्न सक्ने एकमात्र प्रमाणीकरण गरिएको पथ हो; auth-backend विफलता मोडले 503 (403 होइन) फर्काउँछ, ताकि म्याद सकिएको DB चुपचाप "अस्वीकार" मा अवनत नहोस्।

नयाँ spawn-सक्षम रुट थप्ने

src/server/authz/routeGuard.ts मा रहेको LOCAL_ONLY_API_PREFIXES मा path prefix थप्नुहोस्
नयाँ prefix का लागि isLocalOnlyPath() ले true फर्काउँछ भनी पुष्टि गर्ने परीक्षण tests/unit/authz/routeGuard.test.ts मा थप्नुहोस्
यो चरण कहिल्यै नछोड्नुहोस् — CLAUDE.md मा रहेको Hard Rule #15 हेर्नुहोस्
निर्णय गर्नुहोस्: के यो रुट LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES मा पनि पर्छ? पूर्वनिर्धारित उत्तर होइन हो। रुटलाई manage-scope धारकका लागि उपलब्ध गराउन सुरक्षित हुँदा मात्र opt-in गर्नुहोस् (अर्थात्, यसले प्रयोगकर्ताद्वारा नियन्त्रित मनमानी code spawn गर्दैन)।

manage-scope-bypassable path थप्ने

रुटले प्रयोगकर्ताले उपलब्ध गराएको code वा command कार्यान्वयन गर्दैन भनी पुष्टि गर्नुहोस्। यदि गर्छ भने, रोक्नुहोस् — यो carve-out त्यसका लागि सही उपाय होइन।
src/server/authz/routeGuard.ts मा रहेको LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES मा prefix थप्नुहोस्
tests/unit/authz/management-policy.test.ts मा सबै चार request स्वरूपका लागि coverage थप्नुहोस्: Bearer नभएको (403), manage Bearer (allow), non-manage Bearer (403), र manage Bearer हुँदा पनि /api/cli-tools/runtime/* strict-loopback नै रहने प्रति-prefix regression।

फाइलहरू

फाइल	उद्देश्य
`src/server/authz/routeGuard.ts`	Constants र helper functions
`src/server/authz/policies/management.ts`	मूल्याङ्कन logic
`tests/unit/authz/routeGuard.test.ts`	tier helpers का unit tests
`tests/unit/authz/management-policy.test.ts`	evaluate() का unit tests

OpenAPI मा सुरक्षा tiers अभिलेखीकरण गर्ने

docs/openapi.yaml मा नयाँ रुट थप्दा, यदि रुटलाई routeGuard.ts ले वर्गीकृत गरेको छ भने सम्बन्धित vendor extension लागू गर्नुहोस्:

routeGuard.ts वर्गीकरण	YAML annotation	प्रवर्तन
`LOCAL_ONLY_API_PREFIXES`	`x-loopback-only: true`	non-loopback बाट निःसर्त रूपमा अवरुद्ध
`ALWAYS_PROTECTED_API_PATHS`	`x-always-protected: true`	`requireLogin=false` हुँदा पनि auth आवश्यक
आन्तरिक admin/debug रुट	`x-internal: true`	पूर्वनिर्धारित रूपमा /dashboard/api-endpoints बाट लुकाइएको
कुनै पनि होइन (public / standard auth)	(annotation आवश्यक छैन)	मानक `requireLogin`-नियन्त्रित पहुँच

प्रमाणीकरण

दुई scripts ले YAML annotations र routeGuard.ts बीचको एकरूपता लागू गर्छन्:

scripts/check/check-openapi-coverage.mjs — coverage < 99% भएमा असफल हुन्छ
scripts/check/check-openapi-security-tiers.mjs — x-loopback-only वा x-always-protected annotations compile-time constants सँग नमिलेमा असफल हुन्छ

दुवै scripts pre-commit hook र CI मा चल्छन्।

False Positive नियम

यदि routeGuard.ts constant मा नभएको रुटमा x-always-protected वा x-loopback-only annotation गरिएको छ भने coverage script असफल हुन्छ। समाधान भनेको YAML लाई routeGuard.ts ले वास्तवमै लागू गर्ने कुरासँग मिलाउनु हो — enforcement logic पनि कार्यान्वयन नगरी routeGuard.ts मा रुटहरू थप्नु होइन।

यो पनि हेर्नुहोस्

docs/security/CLI_TOKEN.md — CLI मेसिन-ID टोकन
docs/architecture/AUTHZ_GUIDE.md — पूर्ण प्राधिकरण पाइपलाइन
docs/frameworks/MCP-SERVER.md — MCP सर्भर ट्रान्सपोर्टहरू र स्कोपहरू

Navigation Menu

Repository navigation

ROUTE_GUARD_TIERS.md

ROUTE_GUARD_TIERS.md

Route Guard Tiers (नेपाली)

सिंहावलोकन

तहहरू

तह 1 — LOCAL_ONLY

Manage-scope अपवाद

Operator मार्गदर्शन र auditing

तह 2 — ALWAYS_PROTECTED

नयाँ स्थापनाको bootstrap वास्तविक peer का आधारमा loopback-मात्र हो — `Host` का आधारमा होइन

तह 3 — MANAGEMENT (पूर्वनिर्धारित)

मूल्याङ्कन क्रम

नयाँ spawn-सक्षम रुट थप्ने

manage-scope-bypassable path थप्ने

फाइलहरू

OpenAPI मा सुरक्षा tiers अभिलेखीकरण गर्ने

प्रमाणीकरण

False Positive नियम

यो पनि हेर्नुहोस्

FilesExpand file tree

ROUTE_GUARD_TIERS.md

Latest commit

History

ROUTE_GUARD_TIERS.md

File metadata and controls

Route Guard Tiers (नेपाली)

सिंहावलोकन

तहहरू

तह 1 — LOCAL_ONLY

Manage-scope अपवाद

Operator मार्गदर्शन र auditing

तह 2 — ALWAYS_PROTECTED

नयाँ स्थापनाको bootstrap वास्तविक peer का आधारमा loopback-मात्र हो — Host का आधारमा होइन

तह 3 — MANAGEMENT (पूर्वनिर्धारित)

मूल्याङ्कन क्रम

नयाँ spawn-सक्षम रुट थप्ने

manage-scope-bypassable path थप्ने

फाइलहरू

OpenAPI मा सुरक्षा tiers अभिलेखीकरण गर्ने

प्रमाणीकरण

False Positive नियम

यो पनि हेर्नुहोस्

नयाँ स्थापनाको bootstrap वास्तविक peer का आधारमा loopback-मात्र हो — `Host` का आधारमा होइन