Jinsi ya Kuongeza Role-Based Access Control (RBAC) kwenye App Yako

Ili kuongeza role-based access control, mpe kila mtumiaji jukumu moja au zaidi (kwa mfano admin, editor, viewer), fafanua vitendo ambavyo kila jukumu linaruhusiwa kufanya, kisha kagua ruhusa hizo kwenye seva kwa kila ombi — si kwa kuficha vitufe pekee. Pia kagua kwamba rekodi inayofikiwa ni ya akaunti au timu ya mtumiaji. Anza na majukumu machache yaliyowekwa kwenye database yako, kisha jaribu kwa kujaribu kufikia data ya mtumiaji mwingine moja kwa moja.

Authentication dhidi ya authorisation

Maneno mawili yanayochanganywa mara nyingi:

• Authentication ni wewe ni nani? — kuingia. Angalia jinsi ya kuongeza login kwenye app yako.
• Authorisation ni unaruhusiwa kufanya nini? — kurasa, rekodi na vitendo gani mtumiaji aliyeingia anaweza kufikia.

RBAC ndiyo njia ya kawaida zaidi ya kufanya authorisation. Ni muhimu: kufikia Septemba 2026, Broken Access Control ndiyo #1 katika OWASP Top 10:2025, orodha inayotumika sana ya hatari kubwa zaidi za usalama wa app za wavuti. Kushindwa kwa kawaida ni watumiaji kusoma rekodi za wengine kwa kubadilisha ID kwenye URL, au watumiaji wa kawaida kuita njia za API zilizo za admin pekee.

Chagua mfumo

Kwa vitendo, app nyingi huchanganya mambo mawili: majukumu kwa aina ya vitendo mtu anavyoweza kuchukua, na umiliki kwa rekodi ambazo anaweza kuvichukulia hatua. "Editors wanaweza kuhariri machapisho" ni kanuni ya jukumu; "…machapisho kwenye workspace yao" ni kanuni ya umiliki. Unahitaji zote mbili.

Anza rahisi kuliko unavyofikiria. Admin, member na viewer vinatosha app nyingi kwa kushangaza. Ni rahisi kugawanya jukumu baadaye kuliko kufumua majukumu kumi ambayo hakuna anayeyaelewa.

Panga majukumu kabla ya kuandika msimbo

Andika jedwali la ruhusa kwa lugha ya kawaida kwanza. Linatumika kama maelezo kwa AI na kama mpango wako wa majaribio:

Amua pia kesi za pembeni: je, mmiliki wa mwisho anaweza kuondoka? Je, admin anaweza kumwondoa mmiliki? Mtumiaji aliyeondolewa anaona nini?

Hatua kwa hatua

1. Kuwa na login inayofanya kazi kwanza

RBAC inakaa juu ya authentication. Seva lazima ijue kwa uhakika nani anatuma kila ombi, kutoka kwenye session au token iliyothibitishwa — kamwe kutoka kwa user ID ambayo browser inatuma kwenye body ya ombi.

2. Hifadhi majukumu kwenye database

Kwa app ya timu moja, safu ya role kwenye watumiaji inatosha. Kwa timu, tumia jedwali la uanachama:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Usiwaruhusu watumiaji kujiwekea jukumu lao kupitia sasisho la kawaida la wasifu. Mabadiliko ya jukumu yapite kwenye endpoint maalum inayokagua ruhusa.

3. Kagua ruhusa kwenye seva, mahali pamoja

Andika kisaidizi kimoja — kwa mfano can(user, 'projects.delete', project) — na ukiite kwenye kila route ya API, server action na kazi ya chinichini inayosoma au kubadilisha data. Kazi moja kuu ni rahisi kukagua na kujaribu kuliko ukaguzi uliotawanyika kwenye msimbo. Kataa kwa chaguo-msingi: ikiwa hakuna kanuni inayoruhusu kitendo, kinakataliwa.

4. Punguza kila swali

Kila swali la data ya timu linapaswa kujumuisha timu: where organization_id = :currentOrg, si where id = :id pekee. Hii ndiyo inazuia mtu kubadilisha /projects/123 kuwa /projects/124 na kuona mradi wa kampuni nyingine. Rudisha "haipatikani" badala ya "marufuku" kwa rekodi za timu nyingine, ili usifichue kuwa zipo.

5. Ongeza ulinzi wa kiwango cha database pale unapohitajika

Row-level security (RLS) ya Postgres inaruhusu database yenyewe kutekeleza ni safu zipi kila mtumiaji anaweza kuona. Ni muhimu sana ikiwa browser inawasiliana moja kwa moja na database (kama kwenye baadhi ya backends zinazoendeshwa), na ni safu muhimu ya pili kwa jedwali nyeti vinginevyo.

6. Onyesha majukumu kwenye kiolesura

Sasa ficha au zima kile ambacho watumiaji hawawezi kufanya, ili app isichanganye. Hii ni kwa urahisi wa matumizi pekee; ukaguzi wa seva ndio unaolinda.

7. Rekodi vitendo nyeti

Rekodi nani amebadilisha majukumu, amefuta data au amesafirisha rekodi, na lini. Kumbukumbu ya ukaguzi inasaidia maswali ya usaidizi na matukio.

8. Jaribu kama mshambuliaji

Ingia kama kila jukumu na ujaribu kila kitendo kwenye jedwali la ruhusa. Kisha jaribu mambo ambayo hayapaswi kufanya kazi: piga njia za API za admin kama viewer, badilisha IDs kwenye URL na maombi, jiondoe kama mmiliki wa mwisho. Majaribio ya kiotomatiki ya jedwali la ruhusa yanafaa kuandikwa mara kanuni zikishatulia.

Maagizo yanayofanya kazi

Ongeza role-based access control. Majukumu kwa kila shirika: owner, admin, member, viewer, yakihifadhiwa kwenye jedwali la memberships. Ruhusa ziko kwenye jedwali hili: [bandika jedwali lako]. Tengeneza kisaidizi kimoja cha upande wa seva can(user, action, resource), kikatae kwa chaguo-msingi, na ukitumie kwenye kila route ya API. Punguza kila swali kwa organization_id. Ficha vitendo ambavyo mtumiaji hawezi kufanya kwenye UI, lakini usitegemee hilo kwa usalama.

Kagua kila route ya API na kila server function kwenye app hii. Kwa kila moja, orodhesha data inayosomwa au kubadilishwa, kama inakagua mtumiaji ameingia, kama inakagua jukumu lake, na kama inapunguza swali kwa shirika lake. Rekebisha yoyote isiyo na ukaguzi, kisha nionyeshe orodha.

Ongeza ukurasa wa /admin wa admin pekee ambapo mmiliki anaweza kubadilisha majukumu ya wanachama. Zuia kuondoa au kushusha cheo cha mmiliki wa mwisho, rekodi kila mabadiliko ya jukumu kwa aliyeyafanya na lini, na hakikisha endpoint ya mabadiliko ya jukumu inakataa yeyote asiye mmiliki.

Makosa ya kawaida

• Kukagua majukumu upande wa frontend pekee. API bado iko wazi kwa yeyote anayeiita.
• Kuamini IDs kutoka kwa client — userId au role kwenye body ya ombi badala ya session.
• Maswali yasiyopunguzwa yanayochukua rekodi kwa ID pekee.
• Majukumu kukaguliwa kwenye kurasa lakini si kwenye routes za API, exports, upakuaji wa faili au webhooks.
• Admin kwa anwani ya barua pepe iliyowekwa ndani ya msimbo (if email === 'me@...'), ambayo ni rahisi kusahau na ngumu kubadilisha.
• Majukumu mengi mapema mno, ambayo hakuna anayeweza kuyaeleza baada ya miezi sita.
• Session zilizopitwa na wakati: mtumiaji aliyeshushwa cheo anaendelea kuwa na haki za admin hadi atoke. Kagua majukumu kutoka kwenye database, au yasasishe, kwa vitendo nyeti.

Orodha ya ukaguzi ya RBAC

• Jedwali la ruhusa limeandikwa kwa lugha ya kawaida, kesi za pembeni zimeamuliwa
• Seva inamjua mtumiaji kutoka kwenye session, kamwe kutoka data ya ombi
• Majukumu yamehifadhiwa kwenye database; watumiaji hawawezi kubadilisha yao wenyewe
• Ukaguzi mmoja mkuu wa ruhusa, kukataa kwa chaguo-msingi, unatumika kwenye kila route
• Kila swali limepunguzwa kwa shirika au umiliki wa mtumiaji
• Row-level security pale browser inapoweza kufikia database
• UI inaficha kile watumiaji hawawezi kufanya (kwa urahisi wa matumizi pekee)
• Vitendo nyeti vimerekodiwa
• Kila jukumu limejaribiwa, ikijumuisha maombi ya moja kwa moja ya API na IDs zilizobadilishwa

Udhibiti wa ufikiaji ni kipengee kimoja kwenye orodha ndefu zaidi; orodha ya usalama kwa app zilizojengwa na AI inashughulikia mengine. Ikiwa unajenga zana kwa wafanyakazi wako wa ndani, jinsi ya kujenga zana ya ndani inaonyesha mahali majukumu yanapofaa.

RBAC kwenye Mythex

Mythex haitoi mfumo uliojengwa ndani wa login au majukumu kwa watumiaji wa app yako. Unachagua maktaba au mtoa huduma wa auth na kueleza majukumu, kisha wakala anayaunganisha kwenye msimbo wako na database yako ya Postgres ya mradi (ongeza login kwenye app yako). Majukumu ya nafasi ya kazi ya Mythex yenyewe, kama Owner na Member, yanadhibiti nani anaweza kuhariri miradi yako ya Mythex, si nani anaweza kutumia app unayochapisha. Tumia hali ya Plan kukubaliana jedwali la ruhusa kabla ya kujenga, kisha tumia maagizo ya ukaguzi hapo juu na ujaribu kila jukumu kwenye Preview kabla ya kuchapisha. Maagizo ya usalama ya nyaraka ni ufuatiliaji mzuri.

Maswali