သင့်အက်ပ်ရှိ API Key များကို လုံခြုံစွာ ထိန်းသိမ်းနည်း

API key များကို လုံခြုံစွာ ထိန်းသိမ်းရန်၊ host ပေါ်ရှိ secret သို့မဟုတ် environment variable အဖြစ် သိမ်းပါ၊ server-side code တွင်သာ သုံးပါ၊ ချက်ချင်း chat၊ code file၊ screenshot သို့မဟုတ် Git repository ထဲ ဘယ်တော့မှ မကူးထည့်ပါနှင့်။ Key တစ်ခုစီကို လိုအပ်သော ခွင့်ပြုချက်အနည်းဆုံးဖြင့် ပေးပါ၊ provider တွင် ငွေသုံးစွဲမှု ကန့်သတ်ချက်များ သတ်မှတ်ပါ၊ key တစ်ခု ယိုဖိတ်ခဲ့လျှင် ပြောင်းပါ — အသစ်ဖန်တီးပြီး အဟောင်းကို ဖျက်ပါ — ၎င်းပေါ်ရာတွင် ဖုံးထားခြင်းသက်သက်မဟုတ်ပါ။

API key သည် ဝန်ဆောင်မှုတစ်ခု၏ စကားဝှက်တစ်ခုဖြစ်သည်။ သင့် OpenAI key က တစ်စုံတစ်ယောက်အား AI ပေါ်တွင် သင့်ငွေကို သုံးစေနိုင်သည်; သင့် Stripe secret key က refund ပြုလုပ်ခွင့်ပေးနိုင်သည်; သင့် email provider key က သင့်အမည်ဖြင့် mail ပို့ခွင့်ပေးနိုင်သည်။ AI app builder များက ၎င်းတို့ကို ချိတ်ဆက်ရာတွင် ကောင်းသော်လည်း ၎င်းတို့ ဘယ်ကို ရောက်သွားသလဲဆိုသည်ကို အမြဲ ဂရုစိုက်ခြင်းမရှိပါ၊ ထို့ကြောင့် ဤလမ်းညွှန်က ၎င်းတို့ကို လုံခြုံစွာထားနည်းနှင့် စစ်ဆေးနည်းကို ဖော်ပြသည်။

Public key နှင့် secret key

Key အားလုံး လျှို့ဝှက်ထားရန်မလိုပါ။ ကွာခြားချက်ကို သိခြင်းက မှားသော key ကို စိုးရိမ်ပြီး မှန်သော key ကို လျစ်လျူရှုခြင်းမှ ကာကွယ်သည်။

Key အမျိုးအစား မသေချာလျှင် provider ၏ စာရွက်စာတမ်းကို စစ်ပါ။ သံသယရှိလျှင် secret ဟု ယူဆပါ။

အဆင့် ၁: Key များကို code ထဲမဟုတ်ဘဲ secret အဖြစ် သိမ်းပါ

Key များသည် host ၏ environment variable သို့မဟုတ် secrets settings တွင် ရှိရမည်။ သင့် code သည် အမည်ဖြင့် runtime တွင် ဖတ်သည် (ဥပမာ process.env.OPENAI_API_KEY)၊ ထို့ကြောင့် တန်ဖိုးသည် သင့်ဖိုင်များတွင် ဘယ်တော့မှ မပေါ်ပါ။ နောက်ခံအချက်အလက်အတွက် environment variable နှင့် secret ဆိုတာဘာလဲ ကို ကြည့်ပါ။

Code ထဲရှိ API key အားလုံးကို environment variable များသို့ ရွှေ့ပါ။ တွေ့ခဲ့သော key တစ်ခုစီ၊ ၎င်းပါဝင်သော file နှင့် သုံးခဲ့သော variable အမည်ကို စာရင်းပြုစုပါ။ တန်ဖိုးများကို မပြပါနှင့်။

ထို့နောက် ဘာမှ မကျန်ကြောင်း စစ်ပါ:

Project တစ်ခုလုံး၊ config file များနှင့် .env file အပါအဝင် API key ဟု ထင်ရသောအရာ သို့မဟုတ် password ကို ရှာပါ။ တန်ဖိုးမဟုတ်ဘဲ file နှင့် line ကိုသာ အစီရင်ခံပါ။

အဆင့် ၂: Secret key များကို server တွင်သာ သုံးပါ

ဤစည်းမျဉ်းသည် အရေးကြီးဆုံးဖြစ်သည်။ Browser ရရှိသည့်အရာမှန်သမျှကို ဝင်ရောက်ကြည့်သူ ဖတ်နိုင်သည် — page source နှင့် JavaScript file များကို developer tools ဖြင့် မြင်နိုင်သည်။

ထို့ကြောင့် အက်ပ်က OpenAI ကို ခေါ်ရန် လိုလျှင် browser သည် သင့် server ကို ခေါ်ရမည်ဖြစ်ပြီး၊ သင့် server က OpenAI ကို key ဖြင့် ခေါ်သည်။ Key သည် server မှ ဘယ်တော့မှ မထွက်ပါ။

Chat feature က browser မှ OpenAI ကို တိုက်ရိုက်ခေါ်နေသည်။ ထိုခေါ်ဆိုမှုကို environment မှ OPENAI_API_KEY ကို ဖတ်သော server API route သို့ ရွှေ့ပါ။ Browser က ကျွန်ုပ်တို့ route ကိုသာ ခေါ်ရမည်။ Route အတွက် login ကို လိုအပ်ပါစေ။

Frontend framework အချို့တွင် အဖြစ်များသော ထောင်ချောက်တစ်ခုကို သတိပြုပါ — Vite တွင် VITE_၊ Next.js တွင် NEXT_PUBLIC_ ကဲ့သို့ public prefix ပါသော variable များကို browser code ထဲ ရည်ရွယ်ချက်ရှိရှိ ထည့်သွင်းထားသည်။ Secret key ကို ထို prefix ဖြင့် ထားလျှင် "environment variable ထဲ ရှိနေသော်လည်း" ယိုဖိတ်နေပြီဖြစ်သည်။

အဆင့် ၃: ဘာမှ မယိုဖိတ်ကြောင်း စမ်းသပ်ပါ

အလုပ်ဖြစ်သည်ဟု မယုံဘဲ live site ကို စစ်ပါ:

1. Published အက်ပ်ကို browser တွင် ဖွင့်ပါ။
2. Developer tools ဖွင့်ပြီး Sources သို့မဟုတ် Network tab ကို သွားပါ။
3. Secret key တစ်ခုစီ၏ ရှေ့ဆုံးစာလုံးများ (ဥပမာ sk_ သို့မဟုတ် sk-) ကို file အားလုံးတွင် ရှာပါ။
4. အက်ပ်ပြုလုပ်သော network request များကို စစ်ပါ။ Browser မှ ငွေကြေးပေးရသော AI provider ဆီ တိုက်ရိုက်သွားသော request သည် သတိပေးချက် ဖြစ်သည်။

Secret key တစ်ခု တွေ့လျှင် server သို့ ရွှေ့ပါ (အဆင့် ၂) ပြီး ပြောင်းပါ (အဆင့် ၆)၊ ၎င်းသည် ရှိပြီးသား ပွင့်လင်းနေပြီဖြစ်သည်။

အဆင့် ၄: Key တစ်ခုစီ ဘာလုပ်နိုင်သည်ကို ကန့်သတ်ပါ

Provider အများအပြားက key ကို ကန့်သတ်ခွင့်ပေးသည်:

• Scoped သို့မဟုတ် restricted key — အက်ပ်လိုအပ်သည်ကိုသာ လုပ်နိုင်သည်။ ဥပမာ Stripe သည် သတ်မှတ်ခွင့်ပါသော restricted key များကို ပံ့ပိုးသည်။
• Domain သို့မဟုတ် IP ကန့်သတ်ချက် — ပွင့်လင်းရမည့် key များအတွက်၊ ဥပမာ maps key။
• အက်ပ်နှင့် environment တစ်ခုစီအတွက် key သီးခြား — တစ်ခု ယိုဖိတ်လျှင် အားလုံး မပေါ်စေရန်၊ တစ်ခုကို ပိတ်လျှင် အခြား မပျက်စေရန်။
• တည်ဆောက်နေစဉ် test key၊ live key ကို published အက်ပ်တွင်သာ။

အဆင့် ၅: ပျက်စီးမှုကို ကန့်သတ်ပါ

ကောင်းစွာကာကွယ်ထားသော key တစ်ခုပင်လျှင် သင့်အက်ပ်မှတစ်ဆင့် အလွဲသုံးစားလုပ်နိုင်သည် — ဥပမာ တစ်စုံတစ်ယောက်က သင့် AI feature ကို ထောင်ပေါင်းများစွာ script ဖြင့် ခေါ်နေခြင်း။

• Paid provider တိုင်းတွင် spending limit သို့မဟုတ် alert သတ်မှတ်ပါ။
• ခေါ်ဆိုမှုတိုင်း ငွေကုန်ကျသော feature အတွက် login ကို လိုအပ်ပါစေ။
• အသုံးပြုသူတစ်ဦးချင်း rate limit ထည့်ပါ။ rate limiting ဆိုတာဘာလဲ ကို ကြည့်ပါ။

/api/chat တွင် အသုံးပြုသူတစ်ဦးလျှင် တစ်နာရီလျှင် AI request 30 ကန့်သတ်ပါ။ ကန့်သတ်ချက်ရောက်သည့်အခါ ရှင်းလင်းသော မက်ဆေ့ဂျ်ပြပါ။ Login မဝင်ထားသော အသုံးပြုသူများမှ request များကို ပယ်ချပါ။

အဆင့် ၆: ယိုဖိတ်သော key များကို ပြောင်းပါ

Secret key တစ်ခု မသင့်တော်သည့်နေရာ — chat မက်ဆေ့ဂျ်၊ commit၊ screenshot၊ support ticket၊ browser code — တွင် ပေါ်လာလျှင် ပျက်စီးပြီဟု ယူဆပါ။

1. Provider တွင် key အသစ် ဖန်တီးပါ။
2. အက်ပ် settings ရှိ secret ကို update လုပ်ပါ။
3. Live အက်ပ်သည် key အသစ်ကို သုံးစေရန် redeploy သို့မဟုတ် ထပ်မံ publish လုပ်ပါ။
4. Provider တွင် key ဟောင်းကို ဖျက်ပါ။
5. သင်မသိသော activity အတွက် provider ၏ usage log ကို စစ်ပါ။

Chat မက်ဆေ့ဂျ် သို့မဟုတ် Git commit ကို ဖျက်ခြင်းသည် မလုံလောက်ပါ။ Git history သည် ဗားရှင်းဟောင်းများကို သိမ်းထားပြီး အများပြည်သူ ရှိသည်များကို ကူးယူပြီးဖြစ်နိုင်သည်။

အဖြစ်များသော အမှားများ

• Key ကို prompt ထဲ ကူးထည့်ခြင်း။ ယခု chat history တွင် ရှိနေပြီ။ အစား secrets ဖောင် သုံးပါ။
• Secret variable တွင် public prefix။ VITE_OPENAI_API_KEY သည် key ကို ဝင်ရောက်သူတိုင်းထံ ပို့သည်။
• .env file ကို commit လုပ်ခြင်း။ ပထမဆုံး push မမီ .gitignore တွင် ရှိကြောင်း သေချာပါစေ။
• Key တစ်ခုတည်းကို နေရာတိုင်းတွင်သုံးခြင်း။ Test နှင့် live၊ အက်ပ်တစ်ခုစီအတွက် key သီးခြားသုံးပါ။
• သုံးစွဲမှု ကန့်သတ်ချက် မရှိခြင်း။ ယိုဖိတ်ခံရသော သို့မဟုတ် အလွဲသုံးစားလုပ်ခံရသော key သည် သင်မသိမီ ငွေအကြီးအကျယ် ကုန်စေနိုင်သည်။
• ဖုံးထားခြင်းကို ပြောင်းခြင်းအစား ဖုံးထားခြင်း။ Key တစ်ခု ယိုဖိတ်ပြီးနောက် key အသစ်သာ ပြင်ပေးနိုင်သည်။
• Screenshot ထဲ key ပါခြင်း။ အကူအညီတောင်းမီ settings စာမျက်နှာကို ဖြတ်ထုတ်ပါ သို့မဟုတ် မှုန်ဝါးအောင် လုပ်ပါ။

Checklist

• Key အားလုံးကို secret သို့မဟုတ် environment variable အဖြစ် သိမ်းထားသည်၊ code ထဲမဟုတ်ပါ။
• .env file သို့မဟုတ် key မည်သည်မျှ Git သို့ commit မလုပ်ထားပါ။
• Secret key များကို server-side code တွင်သာ သုံးသည်။
• VITE_ သို့မဟုတ် NEXT_PUBLIC_ ကဲ့သို့ public prefix ပါသော secret variable မရှိပါ။
• Live site ၏ JavaScript တွင် key prefix တစ်ခုစီကို ရှာပြီး ဘာမှမတွေ့ပါ။
• Provider ခွင့်ပြုသည့်နေရာတွင် key များကို scoped သို့မဟုတ် restricted လုပ်ထားသည်။
• Test နှင့် live key များ သီးခြားဖြစ်သည်။
• ငွေကုန်ကျသော feature များတွင် login လိုအပ်ပြီး အသုံးပြုသူတစ်ဦးချင်း ကန့်သတ်ချက်ရှိသည်။
• Paid provider တိုင်းတွင် spending cap သို့မဟုတ် alert ရှိသည်။
• Key တစ်ခုစီကို ပြောင်းနည်း သိသည်၊ ဘယ်တော့မှ ယိုဖိတ်ခဲ့ဖူးသော key အားလုံးကို ပြောင်းပြီးပြီ။

Mythex ဖြင့် key များကို လုံခြုံစွာ ထိန်းသိမ်းခြင်း

Mythex သည် key များကို သင့် code နှင့် chat မှ ခွဲထားရန် နည်းလမ်းနှစ်ခုဖြင့် ကူညီသည်:

• Secrets request card။ Agent က key လိုအပ်သောအခါ chat ထဲတွင် card ပြသပြီး သင်က message box မဟုတ်ဘဲ form field များတွင် တန်ဖိုးကို ရိုက်ထည့်သည်၊ ၎င်းသည် project secret အဖြစ် သိမ်းသည်။ Secrets in chat ကို ကြည့်ပါ။
• Project settings → Secrets၊ သို့မဟုတ် chat ထဲ /secrets ဖြင့် သင်ကိုယ်တိုင် key ထည့်ခြင်း သို့မဟုတ် ပြောင်းခြင်း။ Environment variable နှင့် secret များ ကို ကြည့်ပါ။

Published အက်ပ်အတွက် secret ပြောင်းပြီးနောက် live အက်ပ်က ယူသွားစေရန် ထပ်မံ publish လုပ်ပါ။ Export လုပ်ထားသော project များတွင် secret များ မပါဝင်ပါ၊ ထို့ကြောင့် code ကို နောက်တစ်ခု run မည့်နေရာတွင် ပြန်ထည့်ပါ။ Key တစ်ခု chat ထဲ ပေါ်ခဲ့လျှင် provider တွင် ပြောင်းပါ။

Launch မမီ လုံခြုံရေး စစ်ဆေးမှု အပိုင်းအတွက် AI ဖြင့် တည်ဆောက်ထားသော အက်ပ်များ၏ လုံခြုံရေး checklist ကို လုပ်ပါ။ AI feature များ ထည့်နေပါက LLM API များကို သုံးနည်း တွင် key နှင့် ကုန်ကျစရိတ်ကို ပိုမိုအသေးစိတ် ရှင်းပြထားသည်။

မေးခွန်းများ