તમારી એપમાં રોલ-આધારિત ઍક્સેસ નિયંત્રણ (RBAC) કેવી રીતે ઉમેરશો

રોલ-આધારિત ઍક્સેસ નિયંત્રણ ઉમેરવા માટે, દરેક વપરાશકર્તાને એક કે વધુ રોલ આપો (દા.ત. એડમિન, એડિટર, વ્યૂઅર), નક્કી કરો કે દરેક રોલ કઈ ક્રિયાઓ કરી શકે, અને દરેક રિક્વેસ્ટ માટે તે પરવાનગીઓ સર્વર પર તપાસો — ફક્ત બટન છુપાવીને નહીં. ઉપરાંત તપાસો કે જે રેકોર્ડને ઍક્સેસ કરાય છે તે વપરાશકર્તાના ખાતા કે ટીમનું છે. તમારા ડેટાબેઝમાં થોડા નિશ્ચિત રોલથી શરૂઆત કરો, અને બીજા વપરાશકર્તાનો ડેટા સીધો પહોંચવાનો પ્રયાસ કરીને ચકાસો.

ઓળખ વિરુદ્ધ અધિકાર

બે શબ્દો જે ઘણીવાર ગૂંચવાય છે:

• ઓળખ (Authentication) એટલે તમે કોણ છો? — લૉગ-ઇન કરવું. જુઓ તમારી એપમાં લૉગ-ઇન કેવી રીતે ઉમેરશો.
• અધિકાર (Authorisation) એટલે તમને શું કરવાની મંજૂરી છે? — લૉગ-ઇન થયેલો વપરાશકર્તા કયા પેજ, રેકોર્ડ અને ક્રિયાઓ સુધી પહોંચી શકે.

RBAC અધિકાર માટેની સૌથી સામાન્ય રીત છે. તે મહત્ત્વનું છે: સપ્ટેમ્બર 2026 સુધી, Broken Access Control OWASP Top 10:2025 માં #1 છે, જે વેબ એપ સુરક્ષાના સૌથી ગંભીર જોખમોની વ્યાપક યાદી છે. સામાન્ય નિષ્ફળતાઓ: URL માં ID બદલીને વપરાશકર્તાઓ બીજાના રેકોર્ડ વાંચે, અથવા સામાન્ય વપરાશકર્તાઓ ફક્ત એડમિન માટેના API રૂટ કૉલ કરે.

મોડેલ પસંદ કરો

વ્યવહારમાં મોટાભાગની એપ બે વસ્તુઓ જોડે છે: કોઈ કેવા પ્રકારની ક્રિયાઓ કરી શકે તે માટે રોલ, અને તે કયા રેકોર્ડ પર ક્રિયા કરી શકે તે માટે માલિકી. "એડિટર પોસ્ટ સંપાદિત કરી શકે" એ રોલ નિયમ છે; "…તેમના પોતાના વર્કસ્પેસની પોસ્ટ" એ માલિકી નિયમ છે. તમને બંનેની જરૂર છે.

તમે ધારો છો તેના કરતાં સરળ શરૂ કરો. એડમિન, સભ્ય અને વ્યૂઅર ઘણી એપ માટે પૂરતા છે. કોઈ સમજી ન શકે તેવા દસ રોલ ઉકેલવા કરતાં પછીથી એક રોલ વિભાજિત કરવો સહેલો છે.

કોડ લખતા પહેલા રોલ ડિઝાઇન કરો

પહેલા સાદી ભાષામાં પરવાનગી ટેબલ લખો. તે AI માટે સ્પેક અને તમારી ટેસ્ટ યોજના બંને તરીકે કામ કરે છે:

એજ કેસ પણ નક્કી કરો: શું છેલ્લો માલિક છોડી શકે? શું એડમિન માલિકને દૂર કરી શકે? દૂર કરાયેલા વપરાશકર્તાને શું દેખાય?

પગલે પગલે

1. પહેલા કામ કરતું લૉગ-ઇન રાખો

RBAC ઑથેન્ટિકેશનની ઉપર બેસે છે. સર્વરને વિશ્વસનીય રીતે ખબર હોવી જોઈએ કે દરેક રિક્વેસ્ટ કોણ કરે છે, સેશન કે ચકાસાયેલા ટોકનથી — ક્યારેય રિક્વેસ્ટ બોડીમાં બ્રાઉઝરે મોકલેલી વપરાશકર્તા ID પરથી નહીં.

2. રોલ ડેટાબેઝમાં સંગ્રહો

એક-ટીમની એપ માટે, વપરાશકર્તાઓ પર role કૉલમ બરાબર છે. ટીમો માટે, સભ્યપદ ટેબલ વાપરો:

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)
);

સામાન્ય પ્રોફાઇલ અપડેટ દ્વારા વપરાશકર્તાઓને પોતાનો રોલ સેટ કરવા ક્યારેય ન દો. રોલ બદલવાના ફેરફારો સમર્પિત, પરવાનગી-તપાસેલા એન્ડપોઇન્ટ દ્વારા જ થાય.

3. પરવાનગીઓ સર્વર પર, એક જ જગ્યાએ તપાસો

એક હેલ્પર લખો — જેમ કે can(user, 'projects.delete', project) — અને ડેટા વાંચતી કે બદલતી દરેક API રૂટ, સર્વર ઍક્શન અને બેકગ્રાઉન્ડ ટાસ્કમાં તેને કૉલ કરો. એક કેન્દ્રિય ફંક્શન કોડમાં વેરવિખેર તપાસો કરતાં સમીક્ષા અને ટેસ્ટ કરવામાં સરળ છે. ડિફૉલ્ટ રૂપે નકારો: જો કોઈ નિયમ ક્રિયાની મંજૂરી ન આપે, તો તે નકારાય છે.

4. દરેક ક્વેરીને મર્યાદિત કરો

ટીમ ડેટાની દરેક ક્વેરીમાં ટીમ શામેલ હોવી જોઈએ: માત્ર where id = :id નહીં, પરંતુ where organization_id = :currentOrg. આ જ કોઈને /projects/123 ને /projects/124 માં બદલીને બીજી કંપનીનો પ્રોજેક્ટ જોતા અટકાવે છે. બીજી ટીમના રેકોર્ડ માટે "forbidden" નહીં, "not found" પાછું આપો, જેથી તેમનું અસ્તિત્વ જાહેર ન થાય.

5. જ્યાં મહત્ત્વનું હોય ત્યાં ડેટાબેઝ-સ્તરનું રક્ષણ ઉમેરો

Postgres row-level security (RLS) ડેટાબેઝને નક્કી કરવા દે છે કે દરેક વપરાશકર્તા કઈ રો જોઈ શકે. જો બ્રાઉઝર સીધું ડેટાબેઝ સાથે વાત કરે (કેટલાક હોસ્ટેડ બેકએન્ડની જેમ), તો તે આવશ્યક છે, અને બાકી સંવેદનશીલ ટેબલ માટે તે ઉપયોગી બીજું સ્તર છે.

6. ઇન્ટરફેસમાં રોલ બતાવો

હવે વપરાશકર્તાઓ જે કરી શકતા નથી તે છુપાવો અથવા નિષ્ક્રિય કરો, જેથી એપ ગૂંચવણભરી ન લાગે. આ ફક્ત ઉપયોગિતા માટે છે; રક્ષણ સર્વર તપાસો કરે છે.

7. સંવેદનશીલ ક્રિયાઓનો લૉગ રાખો

કોણે રોલ બદલ્યા, ડેટા કાઢ્યો કે રેકોર્ડ નિકાસ કર્યા, અને ક્યારે, તે નોંધો. ઑડિટ લૉગ સપોર્ટ પ્રશ્નો અને ઘટનાઓમાં મદદ કરે છે.

8. હુમલાખોરની જેમ ટેસ્ટ કરો

દરેક રોલ તરીકે લૉગ-ઇન કરો અને પરવાનગી ટેબલની દરેક ક્રિયા અજમાવો. પછી જે કામ ન કરવું જોઈએ તે અજમાવો: વ્યૂઅર તરીકે એડમિન API રૂટ કૉલ કરો, URL અને રિક્વેસ્ટમાં ID બદલો, છેલ્લા માલિક તરીકે તમારી જાતને દૂર કરો. નિયમો સ્થિર થાય પછી પરવાનગી ટેબલ માટે સ્વચાલિત ટેસ્ટ લખવા યોગ્ય છે.

કામ કરતા પ્રોમ્પ્ટ

રોલ-આધારિત ઍક્સેસ નિયંત્રણ ઉમેરો. દરેક સંસ્થા માટે રોલ: owner, admin, member, viewer, memberships ટેબલમાં સંગ્રહેલા. પરવાનગીઓ આ ટેબલમાં છે: [તમારું ટેબલ પેસ્ટ કરો]. એક સર્વર-સાઇડ can(user, action, resource) હેલ્પર બનાવો, ડિફૉલ્ટ રૂપે નકારો, અને દરેક API રૂટમાં તેનો ઉપયોગ કરો. દરેક ક્વેરી organization_id થી મર્યાદિત કરો. જે ક્રિયા વપરાશકર્તા કરી ન શકે તે UI માં છુપાવો, પરંતુ સુરક્ષા માટે ક્યારેય તેના પર આધાર ન રાખો.

આ એપની દરેક API રૂટ અને સર્વર ફંક્શન તપાસો. દરેક માટે યાદી બનાવો: તે કયો ડેટા વાંચે કે બદલે છે, શું તે તપાસે છે કે વપરાશકર્તા લૉગ-ઇન છે, શું તે તેનો રોલ તપાસે છે, અને શું તે ક્વેરીને તેની સંસ્થા સુધી મર્યાદિત કરે છે. જેમાં તપાસ ખૂટે તે ઠીક કરો, અને મને યાદી બતાવો.

ફક્ત એડમિન માટેનું /admin પેજ ઉમેરો જ્યાં માલિક સભ્યોના રોલ બદલી શકે. છેલ્લા માલિકને દૂર કરવા કે તેનો દરજ્જો ઘટાડવાનું અટકાવો, દરેક રોલ બદલાવને કોણે અને ક્યારે કર્યો તે સાથે લૉગ કરો, અને ખાતરી કરો કે રોલ-બદલાવ એન્ડપોઇન્ટ માલિક ન હોય તેવા કોઈપણને નકારે.

સામાન્ય ભૂલો

• ફક્ત ફ્રન્ટ એન્ડમાં રોલ તપાસવા. API હજી પણ તેને કૉલ કરનાર કોઈપણ માટે ખુલ્લું છે.
• ક્લાયન્ટ પાસેથી ID પર ભરોસો — સેશનને બદલે રિક્વેસ્ટ બોડીમાં userId કે role.
• મર્યાદા વગરની ક્વેરી જે ફક્ત રેકોર્ડ ID થી લાવે.
• પેજ પર રોલ તપાસ્યા પણ API રૂટ, નિકાસ, ફાઇલ ડાઉનલોડ કે વેબહૂક પર નહીં.
• કોડમાં સખત-કોડ કરેલું એડમિન ઇમેઇલ (if email === 'me@...'), જે ભૂલવું સરળ છે અને બદલવું મુશ્કેલ.
• ખૂબ વહેલા ઘણા બધા રોલ, જે છ મહિના પછી કોઈ સમજાવી ન શકે.
• જૂના સેશન: દરજ્જો ઘટાડાયેલો વપરાશકર્તા લૉગ આઉટ કરે ત્યાં સુધી એડમિન અધિકારો રાખે છે. સંવેદનશીલ ક્રિયાઓ પર ડેટાબેઝમાંથી રોલ તપાસો, અથવા તાજા કરો.

RBAC ચેકલિસ્ટ

• એજ કેસ નક્કી કરેલા, સાદી ભાષામાં લખેલું પરવાનગી ટેબલ
• સર્વર વપરાશકર્તાને સેશનમાંથી ઓળખે, ક્યારેય રિક્વેસ્ટ ડેટામાંથી નહીં
• રોલ ડેટાબેઝમાં સંગ્રહેલા; વપરાશકર્તાઓ પોતાના બદલી ન શકે
• એક કેન્દ્રિય પરવાનગી તપાસ, ડિફૉલ્ટ રૂપે નકારો, દરેક રૂટમાં વપરાય
• દરેક ક્વેરી વપરાશકર્તાની સંસ્થા કે માલિકી સુધી મર્યાદિત
• બ્રાઉઝર ડેટાબેઝ સુધી પહોંચી શકે ત્યાં row-level security
• UI વપરાશકર્તા જે કરી ન શકે તે છુપાવે છે (ફક્ત ઉપયોગિતા માટે)
• સંવેદનશીલ ક્રિયાઓનો લૉગ
• દરેક રોલ ટેસ્ટ થયેલો, સીધા API કૉલ અને બદલેલી ID સહિત

ઍક્સેસ નિયંત્રણ લાંબી યાદીની એક વસ્તુ છે; AI થી બનેલી એપ માટે સુરક્ષા ચેકલિસ્ટ બાકીનું આવરી લે છે. જો તમે તમારા પોતાના સ્ટાફ માટે ટૂલ બનાવી રહ્યા હો, તો આંતરિક ટૂલ કેવી રીતે બનાવશો બતાવે છે કે રોલ ક્યાં બંધબેસે છે.

Mythex પર RBAC

Mythex તમારી એપના વપરાશકર્તાઓ માટે બિલ્ટ-ઇન લૉગ-ઇન કે રોલ સિસ્ટમ પૂરી પાડતું નથી. તમે ઑથ લાઇબ્રેરી કે પ્રદાતા પસંદ કરો અને રોલ વર્ણવો, અને એજન્ટ તેમને તમારા કોડ અને તમારા પ્રોજેક્ટના Postgres ડેટાબેઝ સાથે જોડે છે (તમારી એપમાં લૉગ-ઇન ઉમેરો). Mythex ના પોતાના વર્કસ્પેસ રોલ, જેમ કે Owner અને Member, નક્કી કરે છે કે કોણ તમારા Mythex પ્રોજેક્ટ સંપાદિત કરી શકે, કોણ તમે પબ્લિશ કરેલી એપ વાપરી શકે તે નહીં. બિલ્ડ કરતા પહેલા પરવાનગી ટેબલ નક્કી કરવા Plan mode વાપરો, પછી ઉપરનો સમીક્ષા પ્રોમ્પ્ટ વાપરો અને પબ્લિશ કરતા પહેલા Preview માં દરેક રોલ ચકાસો. દસ્તાવેજના સુરક્ષા પ્રોમ્પ્ટ આગળના પગલા માટે ઉપયોગી છે.

પ્રશ્નો