உங்கள் ஆப்பில் Role-Based Access Control (RBAC) சேர்ப்பது எப்படி

role-based access control சேர்க்க, ஒவ்வொரு பயனருக்கும் ஒன்று அல்லது அதற்கு மேற்பட்ட roles கொடுங்கள் (உதாரணமாக admin, editor, viewer), ஒவ்வொரு role செய்யக்கூடிய செயல்களை வரையறுங்கள், ஒவ்வொரு request-க்கும் அந்த permissions-ஐ சர்வரில் சரிபாருங்கள் — பொத்தான்களை மறைப்பதால் மட்டும் அல்ல. அணுகப்படும் பதிவு பயனரின் கணக்கு அல்லது குழுவுக்குச் சொந்தமானதா என்றும் சரிபாருங்கள். உங்கள் database-இல் சில நிலையான roles-உடன் தொடங்குங்கள், பிறரின் தரவை நேரடியாக அடைய முயன்று சோதியுங்கள்.

Authentication எதிர் authorisation

குழப்பப்படும் இரண்டு சொற்கள்:

• Authentication என்பது நீங்கள் யார்? — login செய்வது. உங்கள் ஆப்பில் login சேர்ப்பது எப்படி பார்க்கவும்.
• Authorisation என்பது நீங்கள் என்ன செய்ய அனுமதிக்கப்பட்டுள்ளீர்கள்? — உள்நுழைந்த பயனர் எந்தப் பக்கங்கள், பதிவுகள் மற்றும் செயல்களை அடையலாம்.

RBAC authorisation செய்வதற்கான மிகப் பொதுவான வழி. இது முக்கியமானது: செப்டம்பர் 2026 நிலவரப்படி, Broken Access Control, OWASP Top 10:2025-இல் #1 — பரவலாகப் பயன்படுத்தப்படும், மிக gravஆன web application பாதுகாப்பு அபாயங்களின் பட்டியல். பொதுவான தோல்விகள்: URL-இல் ID-ஐ மாற்றி பிற பயனர்களின் பதிவுகளைப் படிப்பது, அல்லது சாதாரண பயனர்கள் admin-only API routes-ஐ அழைப்பது.

ஒரு மாதிரியைத் தேர்ந்தெடுக்கவும்

நடைமுறையில் பெரும்பாலான ஆப்கள் இரண்டு விஷயங்களை இணைக்கின்றன: யாரால் எவ்வகை செயல்களைச் செய்ய முடியும் என்பதற்கு roles, அவர்கள் எந்தப் பதிவுகளில் அவற்றைச் செய்யலாம் என்பதற்கு உரிமை. "Editors posts-ஐத் திருத்தலாம்" என்பது ஒரு role விதி; "…அவர்களின் சொந்த workspace-இல் உள்ள posts" என்பது ஒரு உரிமை விதி. உங்களுக்கு இரண்டும் தேவை.

நீங்கள் நினைப்பதை விட எளிமையாகத் தொடங்குங்கள். Admin, member மற்றும் viewer ஆச்சரியமான எண்ணிக்கையிலான ஆப்களுக்குப் போதுமானது. யாருக்கும் புரியாத பத்து roles-ஐப் பிரிப்பதை விட, பின்னர் ஒரு role-ஐப் பிரிப்பது எளிது.

code எழுதுவதற்கு முன் roles-ஐ வடிவமைக்கவும்

முதலில் ஒரு permission table-ஐ எளிய மொழியில் எழுதுங்கள். அது AI-க்கான specஆகவும் உங்கள் test plan ஆகவும் இரட்டிப்பாகப் பயன்படும்:

விளிம்பு நிலைகளையும் முடிவு செய்யுங்கள்: கடைசி உரிமையாளர் வெளியேற முடியுமா? ஒரு admin உரிமையாளரை அகற்ற முடியுமா? நீக்கப்பட்ட பயனருக்கு என்ன தெரியும்?

படிப்படியாக

1. முதலில் வேலை செய்யும் login இருக்கட்டும்

RBAC authentication-க்கு மேல் அமர்கிறது. ஒவ்வொரு request-ஐயும் யார் செய்கிறார்கள் என்பதை சர்வர் நம்பகமாக அறிய வேண்டும், session அல்லது சரிபார்க்கப்பட்ட token மூலம் — browser request body-இல் அனுப்பும் user ID-இலிருந்து ஒருபோதும் அல்ல.

2. roles-ஐ database-இல் சேமிக்கவும்

ஒற்றை-குழு ஆப்பிற்கு, users-இல் ஒரு role column போதுமானது. குழுக்களுக்கு, ஒரு memberships table-ஐப் பயன்படுத்துங்கள்:

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

சாதாரண profile புதுப்பிப்பு மூலம் பயனர்கள் தங்கள் சொந்த role-ஐ அமைக்க ஒருபோதும் அனுமதிக்காதீர்கள். role மாற்றங்கள் ஒரு பிரத்யேக, permission-சரிபார்க்கப்பட்ட endpoint வழியாகச் செல்ல வேண்டும்.

3. permissions-ஐ சர்வரில், ஒரே இடத்தில் சரிபாருங்கள்

ஒரு helper-ஐ எழுதுங்கள் — can(user, 'projects.delete', project) போன்றது — தரவைப் படிக்கும் அல்லது மாற்றும் ஒவ்வொரு API route, server action மற்றும் background task-இலும் அதை அழையுங்கள். code முழுவதும் சிதறிய சோதனைகளை விட ஒரு மைய function மதிப்பாய்வு செய்யவும் சோதிக்கவும் எளிது. இயல்பாகவே மறுக்கவும்: எந்த விதியும் ஒரு செயலை அனுமதிக்கவில்லை என்றால், அது மறுக்கப்படுகிறது.

4. ஒவ்வொரு query-யும் வரம்பிடவும்

குழு தரவுக்கான ஒவ்வொரு query-உம் குழுவை உள்ளடக்க வேண்டும்: where id = :id மட்டும் அல்ல, where organization_id = :currentOrg. யாராவது /projects/123-ஐ /projects/124 என்று மாற்றி வேறு நிறுவனத்தின் project-ஐப் பார்ப்பதை இது தடுக்கிறது. வேறு குழுக்களின் பதிவுகளுக்கு "forbidden" என்பதற்கு பதிலாக "not found" திருப்பிக் கொடுங்கள், அவை இருப்பதை வெளிப்படுத்தாமல் இருக்க.

5. முக்கியமான இடங்களில் database-நிலை பாதுகாப்பைச் சேர்க்கவும்

Postgres row-level security (RLS) ஒவ்வொரு பயனரும் எந்த வரிசைகளைப் பார்க்கலாம் என்பதை database அமல்படுத்த அனுமதிக்கிறது. browser நேரடியாக database-உடன் பேசினால் (சில hosted backends-இல் உள்ளது போல) இது அவசியம், மற்ற நேரங்களில் முக்கியமான tables-க்கு ஒரு பயனுள்ள இரண்டாவது அடுக்கு.

6. interface-இல் roles-ஐ பிரதிபலிக்கவும்

இப்போது பயனர்களால் செய்ய முடியாதவற்றை மறைக்கவும் அல்லது முடக்கவும், ஆப் குழப்பமாக இல்லாதபடி. இது பயன்பாட்டுக்கான எளிமைக்கு மட்டுமே; பாதுகாப்பது சர்வர் சோதனைகள்.

7. முக்கியமான செயல்களைப் பதிவு செய்யவும்

roles-ஐ யார் மாற்றினார், தரவை யார் நீக்கினார் அல்லது பதிவுகளை யார் ஏற்றுமதி செய்தார், எப்போது என்று பதிவு செய்யுங்கள். ஒரு audit log support கேள்விகளுக்கும் சம்பவங்களுக்கும் உதவுகிறது.

8. தாக்குபவர் போல சோதிக்கவும்

ஒவ்வொரு role-ஆக login செய்து, permission table-இல் உள்ள ஒவ்வொரு செயலையும் முயற்சிக்கவும். பிறகு வேலை செய்யக்கூடாதவற்றை முயற்சிக்கவும்: viewer-ஆக admin API routes-ஐ அழைக்கவும், URLs மற்றும் requests-இல் IDs-ஐ மாற்றவும், கடைசி உரிமையாளராக உங்களையே அகற்றவும். விதிகள் நிலைப்பட்ட பின், permission table-க்கான தானியங்கி சோதனைகளை எழுதுவது பயனுள்ளது.

வேலை செய்யும் prompts

Role-based access control சேர்க்கவும். ஒவ்வொரு organisation-க்கும் roles: owner, admin, member, viewer, memberships table-இல் சேமிக்கப்பட்டவை. permissions இந்த table-இல் உள்ளன: [உங்கள் table-ஐ ஒட்டவும்]. ஒரு சர்வர்-பக்க can(user, action, resource) helper-ஐ உருவாக்கவும், இயல்பாகவே மறுக்கவும், அதை ஒவ்வொரு API route-இலும் பயன்படுத்தவும். ஒவ்வொரு query-யையும் organization_id மூலம் வரம்பிடவும். பயனர் செய்ய முடியாத செயல்களை UI-இல் மறையுங்கள், ஆனால் பாதுகாப்புக்கு அதை ஒருபோதும் நம்பாதீர்கள்.

இந்த ஆப்பின் ஒவ்வொரு API route மற்றும் server function-ஐ மதிப்பாய்வு செய்யவும். ஒவ்வொன்றுக்கும், அது எந்தத் தரவைப் படிக்கிறது அல்லது மாற்றுகிறது, பயனர் login செய்திருக்கிறாரா என்று சரிபார்க்கிறதா, அவரது role-ஐச் சரிபார்க்கிறதா, query-ஐ அவரது organisation-க்கு வரம்பிடுகிறதா என்று பட்டியலிடவும். சோதனை விடுபட்டிருக்கும் எதையும் சரிசெய்து, பட்டியலை எனக்குக் காட்டவும்.

உரிமையாளர் members-இன் roles-ஐ மாற்றக்கூடிய admin-only /admin பக்கத்தைச் சேர்க்கவும். கடைசி உரிமையாளரை அகற்றுவது அல்லது தரம் குறைப்பதைத் தடுக்கவும், ஒவ்வொரு role மாற்றத்தையும் யார் எப்போது செய்தார் என்று பதிவு செய்யவும், உரிமையாளர் அல்லாத எவரையும் role-மாற்ற endpoint நிராகரிப்பதை உறுதி செய்யவும்.

பொதுவான தவறுகள்

• Front end-இல் மட்டும் roles-ஐச் சரிபார்ப்பது. API இன்னும் அதை அழைக்கும் எவருக்கும் திறந்திருக்கும்.
• Client-இலிருந்து வரும் IDs-ஐ நம்புவது — session-க்குப் பதிலாக request body-இல் userId அல்லது role.
• வரம்பிடப்படாத queries பதிவு ID மூலம் மட்டும் பெறுபவை.
• Pages-இல் சரிபார்க்கப்படும் roles, ஆனால் API routes, ஏற்றுமதிகள், கோப்பு பதிவிறக்கங்கள் அல்லது webhooks-இல் இல்லாதது.
• code-இல் கடின-குறியிடப்பட்ட email முகவரி மூலம் admin (if email === 'me@...'), அதை மறப்பது எளிது, மாற்றுவது கடினம்.
• மிக விரைவில் அதிக roles, ஆறு மாதங்கள் கழித்து யாராலும் விளக்க முடியாதவை.
• பழைய sessions: தரம் குறைக்கப்பட்ட பயனர் log out செய்யும் வரை admin உரிமைகளை வைத்திருப்பார். முக்கியமான செயல்களில், roles-ஐ database-இலிருந்து சரிபாருங்கள், அல்லது புதுப்பியுங்கள்.

RBAC சரிபார்ப்புப் பட்டியல்

• எளிய மொழியில் எழுதப்பட்ட permission table, விளிம்பு நிலைகள் முடிவு செய்யப்பட்டுள்ளன
• பயனரை சர்வர் session-இலிருந்து அறிகிறது, request தரவிலிருந்து ஒருபோதும் அல்ல
• roles database-இல் சேமிக்கப்பட்டுள்ளன; பயனர்களால் தங்கள் சொந்த roles-ஐ மாற்ற முடியாது
• ஒரே மைய permission சரிபார்ப்பு, இயல்பாக மறுப்பது, ஒவ்வொரு route-இலும் பயன்படுத்தப்படுவது
• ஒவ்வொரு query-யும் பயனரின் organisation அல்லது உரிமைக்கு வரம்பிடப்பட்டுள்ளது
• browser database-ஐ அடையக்கூடிய இடங்களில் row-level security
• பயனர்களால் செய்ய முடியாதவற்றை UI மறைக்கிறது (பயன்பாட்டுக்கான எளிமைக்கு மட்டும்)
• முக்கியமான செயல்கள் பதிவு செய்யப்படுகின்றன
• ஒவ்வொரு role-உம் சோதிக்கப்பட்டது, நேரடி API அழைப்புகள் மற்றும் மாற்றப்பட்ட IDs உட்பட

அணுகல் கட்டுப்பாடு நீண்ட பட்டியலில் ஒரு உருப்படி; மீதமுள்ளவற்றை AI-built ஆப்களுக்கான பாதுகாப்புப் பட்டியல் உள்ளடக்குகிறது. உங்கள் சொந்த ஊழியர்களுக்காக ஒரு கருவியை உருவாக்குகிறீர்கள் என்றால், roles எங்கே பொருந்தும் என்பதை உள் கருவியை எப்படி உருவாக்குவது காட்டுகிறது.

Mythex-இல் RBAC

Mythex உங்கள் ஆப்பின் பயனர்களுக்கு உள்ளமைந்த login அல்லது roles அமைப்பை வழங்குவதில்லை. நீங்கள் ஒரு auth library அல்லது provider-ஐத் தேர்ந்தெடுத்து roles-ஐ விவரிக்கிறீர்கள், முகவர் அவற்றை உங்கள் code-உடனும் உங்கள் திட்டத்தின் Postgres database-உடனும் இணைக்கிறது (உங்கள் ஆப்பில் login சேர்ப்பது). Mythex-இன் சொந்த workspace roles, உதாரணமாக Owner மற்றும் Member, உங்கள் Mythex projects-ஐ யார் திருத்தலாம் என்பதைக் கட்டுப்படுத்துகின்றன, நீங்கள் publish செய்யும் ஆப்பை யார் பயன்படுத்தலாம் என்பதை அல்ல. கட்டும் முன் permission table-ஐ ஒப்புக்கொள்ள Plan mode-ஐப் பயன்படுத்துங்கள், பிறகு மேலே உள்ள மதிப்பாய்வு prompt-ஐப் பயன்படுத்துங்கள், publish செய்வதற்கு முன் Preview-இல் ஒவ்வொரு role-ஐயும் சோதியுங்கள். ஆவணங்களின் பாதுகாப்பு prompts ஒரு பயனுள்ள அடுத்த படி.

கேள்விகள்