AI ဖြင့် တည်ဆောက်ထားသော App များအတွက် လုံခြုံရေး checklist - Launch မတိုင်မီ စစ်ဆေးရမည့်အရာများ

လူတွေ သင်တည်ဆောက်ထားသော AI app ကို အသုံးပြုမီ အရာခုနစ်ခုကို စစ်ဆေးပါ။ စာမျက်နှာ နှင့် API တိုင်းက အသုံးပြုသူ ဘယ်သူလဲ၊ ဘာလုပ်ခွင့်ရှိလဲ ဆိုသည်ကို စစ်ဆေးရမည်။ လျှို့ဝှက် key များသည် server တွင်သာ ရှိရမည်၊ browser သို့မဟုတ် chat တွင် ဘယ်တော့မှ မရှိရ။ input အားလုံးကို server ပေါ်တွင် validate လုပ်ရမည်။ အသုံးပြုသူတစ်ဦးစီသည် ကိုယ်ပိုင် record များကိုသာ ဝင်ရောက်နိုင်ရမည်။ login နှင့် ကုန်ကျစရိတ်ရှိသော endpoint များကို rate limit ထားရမည်။ dependency များကို အသစ်ဖြစ်အောင် ထားရမည်။ တစ်ခုခု မှားသွားပါက ဒေတာကို ပြန်ယူနိုင်ရမည်။ အောက်ပါ checklist သည် ထိုအရာတစ်ခုစီကို code မဖတ်ဘဲ လုပ်ဆောင်နိုင်သော တိကျသည့် စမ်းသပ်ချက်များအဖြစ် ပြောင်းပေးပါသည်။

AI app builder များသည် feature များ အလုပ်ဖြစ်အောင် လုပ်ရာတွင် ကောင်းမွန်ပါသည်။ သို့သော် အလိုအလျောက် သတိထားသူများ မဟုတ်ပါ၊ "သတိထားခြင်း" ကို prompt ထဲတွင် အများအားဖြင့် မထည့်ကြပါ။ အောက်ပါပြဿနာအများစုသည် မည်သူမျှ မတောင်းဆိုသော အရာများမှ ဖြစ်ပါသည်။ ထို့ကြောင့် ပြင်ဆင်ရန် အများအားဖြင့် မေးရန်သာ လိုပါသည်။

ဤ checklist ကို အသုံးပြုနည်း

အစဉ်လိုက် လုပ်ဆောင်ပါ။ အချက်တစ်ခုစီအတွက် အရာနှစ်ခု လုပ်ပါ- AI ကို မေး ၎င်းကို ကိုင်တွယ်ထားကြောင်း သေချာအောင်၊ နှင့် ကိုယ်တိုင် စမ်းသပ်ပါ။ AI က ခွင့်ပြုချက် စစ်ဆေးချက်ကို ရေးနိုင်ပါသည်၊ သို့သော် အလုပ်လုပ်ကြောင်း သိရန် စမ်းသပ်မှသာ သိနိုင်ပါသည်။ အချက်များကို အောက်ပါအတိုင်း အမှတ်အသားပြုထားပါသည်-

• မဖြစ်မနေ — အခြားသူ မသုံးမီ ဤအရာကို လုပ်ပါ။
• သင့်သည် — အမှန်တကယ် အသုံးပြုသူများ သို့မဟုတ် အမှန်တကယ် ဒေတာရှိမီ ဤအရာကို လုပ်ပါ။
• နောက်မှ — app ကြီးလာသည်နှင့်အမျှ လုပ်ရန် တန်ဖိုးရှိသည်။

နာရီတစ်နာသာ ရှိပါက မဖြစ်မနေ အချက်အားလုံးကို လုပ်ပါ။

၁။ Authentication - ဤသူက ဘယ်သူလဲ?

Authentication ဆိုသည်မှာ တစ်စုံတစ်ဦး၏ ဘယ်သူဖြစ်ကြောင်း အတည်ပြုခြင်း ဖြစ်ပြီး အများအားဖြင့် login ဖြစ်ပါသည်။ အခြေခံအတွက် authentication ဆိုတာ ဘာလဲ နှင့် ရွေးချယ်စရာများအတွက် သင့် app သို့ login ထည့်နည်း ကို ကြည့်ပါ။

• မဖြစ်မနေ: ပုဂ္ဂိုလ်ရေး ဒေတာပြသသော စာမျက်နှာတိုင်းတွင် login လိုအပ်ရမည်။ စမ်းသပ်ရန်: log out လုပ်ပြီး ပုဂ္ဂိုလ်ရေး စာမျက်နှာ၏ URL ကို browser တွင် တိုက်ရိုက် ကူးထည့်ပါ။
• မဖြစ်မနေ: ထိုစာမျက်နှာများနောက်ရှိ API endpoint တိုင်းတွင်လည်း login လိုအပ်ရမည် - စာမျက်နှာသာမဟုတ်ပါ။ စမ်းသပ်ရန်: log out လုပ်ပြီး browser ၏ network tab ကို ဖွင့်ကာ သင် login ဝင်ထားစဉ် app လုပ်ခဲ့သော request ကို ပြန်လုပ်ကြည့်ပါ။
• မဖြစ်မနေ: password များကို နှေးကွေးသော password-hashing algorithm ဖြင့် hash လုပ်ပြီး သိမ်းရမည်၊ plain text ဖြင့် ဘယ်တော့မှ မသိမ်းရ။ OWASP ၏ password သိမ်းဆည်းမှု လမ်းညွှန်ချက်အရ Argon2id ကို ဦးစွာ အကြံပြုပြီး scrypt၊ bcrypt သို့မဟုတ် PBKDF2 တို့ကို အခြားရွေးချယ်စရာအဖြစ် ပြောထားပါသည်။ မေးရန်: 「password တွေကို ဘယ်လို သိမ်းထားလဲ?」
• သင့်သည်: password reset link များသည် သက်တမ်းကုန်ဆုံးပြီး တစ်ကြိမ်သာ အလုပ်လုပ်ရမည်။
• သင့်သည်: session cookie များကို Secure၊ HttpOnly နှင့် SameSite ဖြင့် အမှတ်အသားပြုထားပြီး log out လုပ်ပါက server ပေါ်တွင် session ကို အဆုံးသတ်ရမည်။
• နောက်မှ: two-factor authentication ကို ပေးပါ၊ သို့မဟုတ် ၎င်းကို ပံ့ပိုးသော provider မှတစ်ဆင့် sign-in ပေးပါ။

ဒေတာပြန်ပေးသော API route နှင့် စာမျက်နှာတိုင်းကို စစ်ဆေးပါ။ အသုံးပြုသူ login မဝင်ထားသော request တိုင်းကို ပယ်ချရမည်၊ page ၏ code တွင်သာမက server ပေါ်တွင် ပယ်ချရမည်။ စစ်ဆေးခဲ့သော route များကို စာရင်းပြုစုပါ။

၂။ Authorization - သူတို့ ဘာလုပ်ခွင့်ရှိလဲ?

Authorization သည် login ပြီးနောက် အဆင့်ဖြစ်ပြီး ဤအသုံးပြုသူက ဘာကို မြင်နိုင်သလဲ၊ ဘာကို ပြောင်းနိုင်သလဲ ဆုံးဖြတ်ခြင်း ဖြစ်ပါသည်။ AI ဖြင့် တည်ဆောက်ထားသော app များတွင် အပေါက်ပြဿနာ အပြင်းထန်ဆုံး ရှိတတ်သည့်နေရာ ဖြစ်ပါသည်။ အကြောင်းမှာ app သည် မှန်ကန်နေဟန်ရှိသောကြောင့်ပင်ဖြစ်ပါသည် - အသုံးပြုသူ၏ dashboard တွင် ၎င်းကိုယ်ပိုင် ဒေတာသာ ပြသသော်လည်း server က တိုက်ရိုက် တောင်းဆိုပါက မည်သူ့ဒေတာကိုမဆို အလွယ်တကူ ပေးနိုင်ပါသည်။

• မဖြစ်မနေ: ဖတ်ခြင်း၊ ပြင်ခြင်းနှင့် ဖျက်ခြင်းတိုင်းတွင် record သည် လက်ရှိအသုံးပြုသူ (သို့မဟုတ် ၎င်းတို့၏ အဖွဲ့) ၏ ဖြစ်ကြောင်း server ပေါ်တွင် စစ်ဆေးရမည်။
• မဖြစ်မနေ: စမ်းသပ်ရန်: အကောင့် နှစ်ခု A နှင့် B ဖန်တီးပါ။ A အဖြစ် A ၏ record တစ်ခုကို ဖွင့်ပြီး URL သို့မဟုတ် network request ထဲရှိ ID ကို မှတ်ပါ။ B အဖြစ် login ဝင်ပြီး ထို ID ကိုပင် တောင်းဆိုပါ။ B သည် error ရရမည်၊ A ၏ ဒေတာကို ရရှိမည် မဟုတ်ပါ။
• မဖြစ်မနေ: admin စာမျက်နှာများနှင့် admin API endpoint များသည် အသုံးပြုသူ၏ role ကို server ပေါ်တွင် စစ်ဆေးရမည်။ admin link ကို ဝှက်ထားခြင်းသည် အကာအကွယ် မဟုတ်ပါ။
• မဖြစ်မနေ: အသုံးပြုသူများသည် request ကို ပြင်ခြင်းဖြင့် ကိုယ်ပိုင် role၊ စျေးနှုန်း၊ လက်ကျန်ငွေ သို့မဟုတ် owner field များကို ပြောင်းခွင့် မရှိရပါ။ စမ်းသပ်ရန်: network tab တွင် profile update က ဘာပို့သလဲ ကြည့်ပါ။ role သို့မဟုတ် isAdmin ကဲ့သို့ field များ ပါလာပါက client မှ ၎င်းတို့ကို လျစ်လျူရှုရန် AI ကို မေးပါ။
• သင့်သည်: URL ထဲရှိ ID များသည် ခန့်မှန်းရခက်ရမည် (1၊ 2၊ 3 အစား ကျပန်း ID များ)။ ၎င်းသည် ခွင့်ပြုချက် စစ်ဆေးချက်ကို အစားထိုးခြင်း မဟုတ်ပါ၊ သို့သော် တစ်ခု ပျောက်နေသည့်အခါ ပျက်စီးမှုကို ကန့်သတ်ပေးပါသည်။

record ကို ဖတ်သော သို့မဟုတ် ပြောင်းသော endpoint တိုင်းအတွက် လော့ဂ်အင်ဝင်ထားသော အသုံးပြုသူသည် ထို record ကို ပိုင်ဆိုင်သည် သို့မဟုတ် ဝင်ရောက်ခွင့်ရှိသည်ကို server ပေါ်တွင် စစ်ဆေးပါ။ မဟုတ်ပါက 404 ပြန်ပါ။ ထို့နောက် အကောင့်နှစ်ခုဖြင့် ဤအရာကို ဘယ်လို စမ်းသပ်မလဲ ပြပါ။

၃။ Database တွင် row-level access

"Row-level access" ဆိုသည်မှာ table ၏ row တစ်ခုစီ (ကြိုတင်ဘိုကင်တစ်ခု၊ ငွေတောင်းခံလွှာတစ်ခု) ကို ၎င်းပိုင်သော အသုံးပြုသူများသာ မြင်နိုင်ခြင်း ဖြစ်ပါသည်။ ၎င်းကို ပြဌာန်းရန် နည်းလမ်းနှစ်ခု အသုံးများပါသည်-

နှစ်ခုစလုံးကို ကောင်းစွာ လုပ်နိုင်ပါသည်။ အရေးကြီးသည်များမှာ-

• မဖြစ်မနေ: browser က database နှင့် တိုက်ရိုက် ဆက်သွယ်ပါက (hosted database အချို့က ခွင့်ပြုသည်) table တိုင်းအတွက် row-level စည်းမျဉ်းများကို ဖွင့်ထားရမည်။ မဟုတ်ပါက public key ရှိသူ မည်သူမဆို table တစ်ခုလုံးကို ဖတ်နိုင်သည်။
• မဖြစ်မနေ: query များသည် browser ပို့သော ID ဖြင့် မဟုတ်ဘဲ လက်ရှိအသုံးပြုသူ သို့မဟုတ် အဖွဲ့ဖြင့် filter လုပ်ရမည်။
• သင့်သည်: မျှဝေထားသော ဒေတာ (အဖွဲ့၏ project များ) တွင် အဖွဲ့ထဲ၌ သူဘယ်သူလဲဆိုသည့် စည်းမျဉ်း ရှင်းရှင်းရှိရမည်၊ နေရာတစ်ခုတည်းတွင် ပြဌာန်းထားရမည်။

၄။ Secret များနှင့် API key များ

API key သည် ဝန်ဆောင်မှုတစ်ခု၏ password ဖြစ်ပါသည်။ Stripe၊ email နှင့် AI provider အားလုံးက ၎င်းတို့ကို သုံးကြသည်။ နောက်ခံအတွက် environment variable နှင့် secret ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။

• မဖြစ်မနေ: key များကို ပရောဂျက်၏ environment variable သို့မဟုတ် secret များတွင် သိမ်းရမည်၊ code ထဲတွင် ဘယ်တော့မှ မရေးရ။
• မဖြစ်မနေ: ငွေကုန်စေနိုင်သော သို့မဟုတ် သီးသန့်ဒေတာဖတ်နိုင်သော key များကို server ပေါ်တွင်သာ အသုံးပြုရမည်။ စမ်းသပ်ရန်: live site ကိုဖွင့်ပြီး page source နှင့် JavaScript file များကို devtools တွင် ကြည့်ကာ သင့် key ၏ အစ (ဥပမာ sk_) ကို ရှာပါ။ ၎င်း ပေါ်လာသင့်မည် မဟုတ်ပါ။
• မဖြစ်မနေ: key များကို chat၊ public repository သို့မဟုတ် screenshot တွင် ဘယ်တော့မှ မကူးထည့်ရ။ ကူးထည့်ခဲ့ပါက provider တွင် rotate လုပ်ပါ (အသစ်ဖန်တီးပြီး အဟောင်းကို ဖျက်ပါ)။
• သင့်သည်: provider က ပေးသည့်နေရာတွင် restricted သို့မဟုတ် scoped key များကို အသုံးပြုပါ။ ဥပမာ Stripe က သင့် integration လိုအပ်သော ခွင့်ပြုချက်များသာ ပါသည့် restricted key များကို အကြံပြုပါသည်။
• သင့်သည်: test နှင့် live key များကို သီးခြားထားပြီး live app သည် သင်အဆင်သင့်ဖြစ်မှသာ live key များကို သုံးရမည်။

အချို့ key များသည် public ဖြစ်ရန် ဒီဇိုင်းထုတ်ထားပါသည် - ဥပမာ Stripe ၏ publishable key (pk_…) သို့မဟုတ် သင့် domain သို့ ကန့်သတ်ထားသော maps key။ စည်းမျဉ်းသည် အာဏာပေးသော key များအတွက်ဖြစ်ပြီး key ဟုထင်ရသော စာကြောင်းတိုင်းအတွက် မဟုတ်ပါ။

၅။ Input validation

အသုံးပြုသူ ပို့သည့် အရာတိုင်း - form field များ၊ file upload များ၊ URL parameter များ - သည် သင့် form ခွင့်ပြုသည့်အရာသာ မဟုတ်ဘဲ မည်သည့်အရာမဆို ဖြစ်နိုင်ပါသည်။

• မဖြစ်မနေ: validation ကို server ပေါ်တွင် လုပ်ရမည်၊ browser တွင်သာ မဟုတ်ပါ။ browser စစ်ဆေးချက်များသည် အဆင်ပြေစေရန်သာ ဖြစ်ပြီး မည်သူမဆို ကျော်နိုင်ပါသည်။
• မဖြစ်မနေ: database query များသည် အသုံးပြုသူ input မှ စာကြောင်းများ ကပ်ထားခြင်း မဟုတ်ဘဲ parameter များ သုံးရမည် (SQL injection ကို ကာကွယ်သည်)။ AI ကို အတည်ပြုရန် မေးပါ။
• မဖြစ်မနေ: အသုံးပြုသူရိုက်သော စာသားကို HTML အဖြစ် မဟုတ်ဘဲ စာသားအဖြစ် ပြရမည်။ စမ်းသပ်ရန်: သင့်နာမည်အဖြစ် <b>hello</b> ကို ရိုက်ပါ။ စာလုံးထူ မဟုတ်ဘဲ tag များကို မြင်ရမည်။
• သင့်သည်: file upload များသည် အမျိုးအစားနှင့် အရွယ်အစားကို စစ်ဆေးရမည်၊ upload လုပ်ထားသော file များကို သင့် app ၏ အဓိက domain မှ run နိုင်သော စာမျက်နှာအဖြစ် မပေးရ။
• သင့်သည်: အသုံးပြုသူများထံ ပြသသော error များသည် ရိုးရှင်းရမည် ("တစ်ခုခု မှားနေသည်")၊ အသေးစိတ် error များကို server log တွင်သာ ထားရမည်။
• သင့်သည်: Stripe ကဲ့သို့ ဝန်ဆောင်မှုများ၏ webhook များက လုပ်ဆောင်မီ provider ၏ signature ကို အတည်ပြုရမည်။ webhook ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။

form နှင့် API endpoint တိုင်းတွင် server-side validation ထည့်ပါ: လိုအပ်သော field များ၊ အရှည်များ၊ format များနှင့် ခွင့်ပြုထားသော တန်ဖိုးများ။ အခြားအရာကို ရှင်းလင်းသော မက်ဆေ့ချ်ဖြင့် ပယ်ချပါ။ အတွင်းပိုင်း error အသေးစိတ်များကို အသုံးပြုသူများအား မပြပါနှင့်။

၆။ Rate limit နှင့် အလွဲသုံးစားမှု

rate limit သည် တစ်စုံတစ်ယောက်က အချိန်ကာလတစ်ခုအတွင်း request ဘယ်နှစ်ခု လုပ်နိုင်သည်ကို ကန့်သတ်ခြင်း ဖြစ်ပါသည်။ ထိုကန့်သတ်ချက်မရှိပါက တစ်စုံတစ်ယောက်သည် တစ်နေ့လုံး password ခန့်မှန်းနိုင်သည်၊ သင့် signup form ကို လွှမ်းမိုးနိုင်သည်၊ သို့မဟုတ် paid API ပေါ်တွင် သင့်ငွေတောင်းခံမှုကို မြင့်တက်စေနိုင်ပါသည်။

• မဖြစ်မနေ: login၊ signup နှင့် password reset ကို IP address တစ်ခုချင်းစီနှင့် account တစ်ခုချင်းစီအလိုက် rate limit ထားရမည်။
• မဖြစ်မနေ: ခေါ်ဆိုမှုတစ်ခုလျှင် ငွေကုန်ကျစေသည့် မည်သည့်အရာမဆို - AI model request များ၊ SMS၊ email - တွင် အသုံးပြုသူတစ်ဦးချင်းစီအတွက် ကန့်သတ်ချက် ရှိရမည်ပြီး login လိုအပ်ရမည်။
• သင့်သည်: public form များ (contact၊ waitlist) တွင် spam ကာကွယ်မှု ရှိရမည်- rate limit၊ ဝှက်ထားသော honeypot field သို့မဟုတ် CAPTCHA။
• သင့်သည်: paid provider များတွင် ငွေသုံးမှု အပေါ်ကန့်သတ်ချက် သို့မဟုတ် သတိပေးချက်များ သတ်မှတ်ပါ၊ ထို့ကြောင့် bug သို့မဟုတ် တိုက်ခိုက်သူက ကန့်သတ်မဲ့ ငွေတောင်းခံမှု မဖြစ်စေရန်။

၇။ Dependency များ

App များသည် open-source package များဖြင့် တည်ဆောက်ထားပြီး package များတွင် သိထားသော အားနည်းချက်များ တစ်ခါတစ်ရံ ရှိတတ်ပါသည်။

• သင့်သည်: JavaScript project များအတွက် npm audit သို့မဟုတ် သင့် package manager ၏ နည်းလမ်းဖြင့် သိထားသော အားနည်းချက်များကို စစ်ဆေးရန် AI ကို မေးပြီး ထိခိုက်သည်များကို update လုပ်ပါ။
• သင့်သည်: app မသုံးတော့သော package များကို ဖယ်ရှားပါ။
• သင့်သည်: အသုံးပြုသူ အလွန်နည်းသော package များ သို့မဟုတ် လူသိများသော package များ၏ စာလုံးမှားနှင့် ဆင်တူသော အမည်များကို သတိထားပါ။
• နောက်မှ: လ တစ်ခု သို့မဟုတ် နှစ်လတိုင်း ပြန်စစ်ပါ၊ သို့မဟုတ် code သည် GitHub တွင်ရှိပါက အလိုအလျောက် သတိပေးချက်များ ဖွင့်ပါ။

၈။ Backup နှင့် ပြန်လည်ရယူခြင်း

လုံခြုံရေးတွင် ဖြစ်ပေါ်လာသော အမှားများ - သင့်ကိုယ်တိုင်၊ AI ၏၊ သို့မဟုတ် တိုက်ခိုက်သူ၏ အမှား - မှ ပြန်ရယူနိုင်ခြင်း ပါဝင်ပါသည်။

• မဖြစ်မနေ: သင့်ဒေတာ ဘယ်မှာရှိသလဲ၊ backup လုပ်ထားသလား သိပါ။ ယူဆမနေပါနှင့်၊ သင့် host ၏ documentation တွင် စစ်ဆေးပါ။
• သင့်သည်: အရေးကြီးသော ဒေတာ၏ ကိုယ်ပိုင် ပုံမှန် export (ဥပမာ CSV export feature သို့မဟုတ် database dump) ကို သီးခြား နေရာတစ်ခုတွင် သိမ်းထားပါ။
• သင့်သည်: code ကို version control တွင် ထားပါ၊ ထို့ကြောင့် ဗားရှင်းမည်သည့်အရာမဆို ပြန်ယူနိုင်မည်။
• သင့်သည်: ဖျက်ဆီးသော လုပ်ဆောင်ချက်များ (account ဖျက်ခြင်း၊ project ဖျက်ခြင်း) သည် အတည်ပြုချက် တောင်းရမည်၊ ကြာချိန်အတော်ကြာ ပြန်ပြင်နိုင်သော "soft delete" ကိုလည်း စဉ်းစားပါ။
• နောက်မှ: restore ကို တစ်ကြိမ် တကယ် စမ်းသပ်ပါ။ ဘယ်တော့မှ restore မလုပ်ဖူးသော backup သည် မျှော်လင့်ချက်ဖြစ်ပြီး စီမံချက် မဟုတ်ပါ။

၉။ Launch မတိုင်မီ

• မဖြစ်မနေ: live site သည် နေရာတိုင်းတွင် HTTPS ကို အသုံးပြုရမည်။
• မဖြစ်မနေ: development မှ sample ဒေတာ၊ test account နှင့် debug စာမျက်နှာများကို ဖယ်ရှားရမည်။
• သင့်သည်: privacy policy တွင် သင်ဘာ ဒေတာ စုဆောင်းပြီး အဘယ်ကြောင့်လဲ ဆိုသည်ကို ဖော်ပြရမည် - ကိုယ်ရေးဒေတာ စုဆောင်းပါက နေရာများစွာတွင် လိုအပ်ပါသည်။ သင့်တွင် မရှိသော ထောက်ခံလက်မှတ်များ (SOC 2၊ HIPAA) ကို မပြောပါနှင့်။
• သင့်သည်: လုံခြုံရေးပြဿနာများအကြောင်း ဆက်သွယ်နိုင်သော နည်းလမ်းရှိရမည်၊ key တိုင်းကို လျင်မြန်စွာ rotate လုပ်နည်း သိရမည်။

လုံခြုံရေးအပြင် ပိုကျယ်သော launch မတိုင်မီ စစ်ဆေးမှုအတွက် AI prototype ကို production သို့ ယူသွားနည်း ကို ကြည့်ပါ။

ပရော်ဖက်ရှင်နယ် သုံးသပ်ချက် ဘယ်အချိန်ယူရမလဲ

checklist သည် အဖြစ်များသော အမှားများကို ဖမ်းပေးသော်လည်း ကျွမ်းကျင်သူကို အစားထိုးခြင်း မဟုတ်ပါ။ hosted checkout ကို အသုံးမပြုဘဲ ကတ်နံပါတ်များကို ကိုယ်တိုင် ကိုင်တွယ်ပါက၊ ကျန်းမာရေး၊ ဘဏ္ဍာရေး သို့မဟုတ် ကလေးများ၏ ဒေတာကို သိမ်းပါက၊ လုံခြုံရေး questionnaire တောင်းသော ကုမ္ပဏီများသို့ ရောင်းပါက၊ ဒါမှမဟုတ် ယိုစိမ့်မှုကြောင့် ပြင်းထန်စွာ ထိခိုက်နိုင်ပါက သုံးသပ်ချက်အတွက် ပေးဆောင်ရန် စဉ်းစားပါ။ သင့် code ကို export လုပ်နိုင်ခြင်းက ထိုသုံးသပ်ချက်ကို ပိုလွယ်ကူစေပါသည်။

Mythex ဖြင့် တည်ဆောက်သည့်အခါ လုံခြုံရေး

Mythex တွင် security-scan panel မပါဝင်သဖြင့် အထက်ပါ checklist ကို လိုက်နာရမည့် လုပ်ငန်းစဉ် ဖြစ်ပါသည်။ အထောက်အကူဖြစ်စေသော အရာအချို့-

• ပရောဂျက် secret များ။ key များကို ပရောဂျက် settings → Secrets အောက်တွင် သို့မဟုတ် agent က chat တွင်ပြသော secrets card မှတစ်ဆင့် သိမ်းပါ၊ ထို့ကြောင့် code နှင့် message များထဲ မပါဝင်ပါ။ live app အတွက် secret ကို ပြောင်းပြီးနောက် ထပ်မံ publish လုပ်ပါ။
• Plan နှင့် Ask mode။ ဖိုင်မပြင်ဘဲ ခွင့်ပြုချက်များကို စစ်ဆေးရန် agent ကို မေးပါ- "Ask mode တွင် API route တိုင်းနှင့် ၎င်းတို့ လုပ်ဆောင်သော ခွင့်ပြုချက် စစ်ဆေးချက်ကို စာရင်းပြုစုပါ။"
• /test သည် agent ကို သင့် preview တွင် အသုံးပြုသူတစ်ဦးအဖြစ် နှိပ်ကြည့်စေသည် - အပိုင်း ၂ ရှိ အကောင့်နှစ်ခု စမ်းသပ်မှုအတွက် အသုံးဝင်ပါသည်။
• Checkpoint များက ပျက်စီးစေသော ပြောင်းလဲမှုကို ပြန်လှည့်နိုင်စေပါသည်။

docs တွင် သင်တည်ဆောက်သော app များအတွက် လုံခြုံရေး နှင့် Environment variable နှင့် secret များ ကို ကြည့်ပါ။ နောက်တစ်ဆင့်တွင် user account ထည့်မည်ဆိုပါက သင့် app သို့ login ထည့်နည်း ကို ဖတ်ပါ။

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