உங்கள் குறியீட்டைப் பலப்படுத்துதல்: வகை-பாதுகாப்பான அங்கீகாரம் மற்றும் அனுமதி மேலாண்மை பற்றிய ஒரு ஆழமான ஆய்வு

மென்பொருள் மேம்பாட்டின் சிக்கலான உலகில், பாதுகாப்பு என்பது ஒரு அம்சம் மட்டுமல்ல; அது ஒரு அடிப்படைத் தேவை. நாம் ஃபயர்வால்களை உருவாக்குகிறோம், தரவை என்க்ரிப்ட் செய்கிறோம், மற்றும் ஊடுருவல்களிலிருந்து பாதுகாக்கிறோம். இருப்பினும், ஒரு பொதுவான மற்றும் நயவஞ்சகமான பாதிப்பு பெரும்பாலும் நம் பயன்பாட்டு லாஜிக்கிற்குள், வெளிப்படையாகவே மறைந்திருக்கும்: அங்கீகாரம். குறிப்பாக, நாம் அனுமதிகளை நிர்வகிக்கும் விதம். பல ஆண்டுகளாக, டெவலப்பர்கள் ஒரு அப்பாவியான மாதிரியை—ஸ்ட்ரிங் அடிப்படையிலான அனுமதிகளை—சார்ந்துள்ளனர். இது ஆரம்பிக்க எளிதாக இருந்தாலும், பெரும்பாலும் ஒரு உடையக்கூடிய, பிழை-வாய்ப்புள்ள, மற்றும் பாதுகாப்பற்ற அமைப்புக்கு இட்டுச்செல்கிறது. அங்கீகாரப் பிழைகள் தயாரிப்புக்குச் செல்வதற்கு முன்பே அவற்றைக் கண்டறிய நமது மேம்பாட்டு கருவிகளைப் பயன்படுத்த முடிந்தால் என்ன? கம்பைலர் தானே நமது முதல் தற்காப்புப் பிணையமாக மாற முடிந்தால் என்ன? வகை-பாதுகாப்பான அங்கீகாரம் உலகிற்கு வருக.

இந்த வழிகாட்டி, ஸ்ட்ரிங் அடிப்படையிலான அனுமதிகளின் உடையக்கூடிய உலகத்திலிருந்து ஒரு வலுவான, பராமரிக்கக்கூடிய, மற்றும் மிகவும் பாதுகாப்பான வகை-பாதுகாப்பான அங்கீகார அமைப்பை உருவாக்குவதற்கான ஒரு விரிவான பயணத்தில் உங்களை அழைத்துச் செல்லும். TypeScript இல் நடைமுறை எடுத்துக்காட்டுகளைப் பயன்படுத்தி 'ஏன்', 'என்ன', மற்றும் 'எப்படி' என்பதை நாம் ஆராய்வோம், இது எந்த நிலையான-தட்டச்சு செய்யப்பட்ட மொழிக்கும் பொருந்தக்கூடிய கருத்துக்களை விளக்கும். முடிவில், நீங்கள் கோட்பாட்டைப் புரிந்துகொள்வது மட்டுமல்லாமல், உங்கள் பயன்பாட்டின் பாதுகாப்பு நிலையை வலுப்படுத்தும் மற்றும் உங்கள் டெவலப்பர் அனுபவத்தை மேம்படுத்தும் ஒரு அனுமதி மேலாண்மை அமைப்பைச் செயல்படுத்தும் நடைமுறை அறிவையும் பெறுவீர்கள்.

ஸ்ட்ரிங் அடிப்படையிலான அனுமதிகளின் பலவீனம்: ஒரு பொதுவான சிக்கல்

அதன் மையத்தில், அங்கீகாரம் என்பது ஒரு எளிய கேள்விக்கு பதிலளிப்பதாகும்: "இந்த பயனருக்கு இந்த செயலைச் செய்ய அனுமதி உள்ளதா?" ஒரு அனுமதியைப் பிரதிநிதித்துவப்படுத்த எளிதான வழி ஒரு ஸ்ட்ரிங் ஆகும், அதாவது "edit_post" அல்லது "delete_user". இது போன்ற குறியீட்டிற்கு வழிவகுக்கிறது:

if (user.hasPermission("create_product")) { ... }

இந்த அணுகுமுறை ஆரம்பத்தில் செயல்படுத்த எளிதானது, ஆனால் இது சீட்டுக்கட்டு கோபுரம் போன்றது. "மேஜிக் ஸ்ட்ரிங்ஸ்" ஐப் பயன்படுத்துவது என்று பெரும்பாலும் குறிப்பிடப்படும் இந்த நடைமுறை, கணிசமான அளவு ஆபத்து மற்றும் தொழில்நுட்பக் கடனை அறிமுகப்படுத்துகிறது. இந்த முறை ஏன் மிகவும் சிக்கலானது என்பதை ஆராய்வோம்.

பிழைகளின் பெருக்கம்

• மௌனமான எழுத்துப்பிழைகள்: இது மிகவும் வெளிப்படையான சிக்கல். "create_product" என்பதற்குப் பதிலாக "create_pruduct" என்று சரிபார்ப்பது போன்ற ஒரு எளிய எழுத்துப்பிழை, செயலிழப்பை ஏற்படுத்தாது. இது ஒரு எச்சரிக்கையைக் கூட எறியாது. சரிபார்ப்பு வெறுமனே மௌனமாகத் தவறிவிடும், மேலும் அணுகல் இருக்க வேண்டிய ஒரு பயனர் மறுக்கப்படுவார். இதைவிட மோசமாக, அனுமதி வரையறையில் உள்ள ஒரு எழுத்துப்பிழை, அணுகல் இருக்கக் கூடாத இடத்தில் தற்செயலாக அதை வழங்கக்கூடும். இந்த பிழைகளைக் கண்டறிவது மிகவும் கடினம்.
• கண்டறியும் தன்மை இல்லாமை: ஒரு புதிய டெவலப்பர் குழுவில் சேரும்போது, எந்த அனுமதிகள் உள்ளன என்பது அவர்களுக்கு எப்படித் தெரியும்? அனைத்து பயன்பாடுகளையும் கண்டறியும் நம்பிக்கையில், அவர்கள் முழு கோட் பேஸையும் தேட வேண்டும். ஒற்றை உண்மை ஆதாரம் இல்லை, தானியங்கு நிரப்புதல் இல்லை, மற்றும் குறியீடு மூலம் வழங்கப்படும் ஆவணங்கள் இல்லை.
• ரீஃபேக்டரிங் கனவுகள்: உங்கள் அமைப்பு ஒரு கட்டமைக்கப்பட்ட பெயரிடல் மரபைக் கடைப்பிடிக்க முடிவு செய்கிறது என்று கற்பனை செய்து பாருங்கள், "edit_post" என்பதை "post:update" ஆக மாற்றுகிறது. இதற்கு முழு கோட் பேஸிலும்—பேக்கெண்ட், ஃப்ரண்டெண்ட், மற்றும் சாத்தியமான டேட்டாபேஸ் பதிவுகள் உட்பட—ஒரு உலகளாவிய, கேஸ்-சென்சிட்டிவ் தேடல் மற்றும் மாற்று நடவடிக்கை தேவைப்படுகிறது. இது ஒரு உயர்-ஆபத்தான கையேடு செயல்முறையாகும், இதில் ஒரு தவறிய நிகழ்வு ஒரு அம்சத்தை உடைக்கலாம் அல்லது ஒரு பாதுகாப்பு ஓட்டையை உருவாக்கலாம்.
• கம்பைல்-நேர பாதுகாப்பு இல்லை: அடிப்படை பலவீனம் என்னவென்றால், அனுமதி ஸ்ட்ரிங்கின் செல்லுபடியாகும் தன்மை ரன்டைமில் மட்டுமே சரிபார்க்கப்படுகிறது. எந்த ஸ்ட்ரிங்குகள் செல்லுபடியாகும் அனுமதிகள் மற்றும் எந்தவை இல்லை என்பது பற்றி கம்பைலருக்குத் தெரியாது. இது "delete_user" மற்றும் "delete_useeer" ஐ சமமான செல்லுபடியாகும் ஸ்ட்ரிங்காகப் பார்க்கிறது, பிழையைக் கண்டறிவதை உங்கள் பயனர்களுக்கோ அல்லது உங்கள் சோதனை கட்டத்திற்கோ விட்டுவிடுகிறது.

தோல்வியின் ஒரு குறிப்பிட்ட எடுத்துக்காட்டு

ஆவண அணுகலைக் கட்டுப்படுத்தும் ஒரு பேக்கெண்ட் சேவையைக் கவனியுங்கள். ஒரு ஆவணத்தை நீக்குவதற்கான அனுமதி "document_delete" என வரையறுக்கப்படுகிறது.

ஒரு நிர்வாகப் பலகத்தில் பணிபுரியும் ஒரு டெவலப்பர் ஒரு நீக்கு பொத்தானைச் சேர்க்க வேண்டும். அவர்கள் சரிபார்ப்பை பின்வருமாறு எழுதுகிறார்கள்:

// API எண்ட்பாயிண்டில் if (currentUser.hasPermission("document:delete")) { // நீக்குதலைத் தொடரவும் } else { return res.status(403).send("Forbidden"); }

டெவலப்பர், ஒரு புதிய மரபைப் பின்பற்றி, அடிக்கோட்டிற்குப் பதிலாக ஒரு பெருங்குறியைப் (:) பயன்படுத்தினார். குறியீடு தொடரியல் ரீதியாக சரியானது மற்றும் அனைத்து லிண்டிங் விதிகளையும் கடக்கும். ஆனால், வரிசைப்படுத்தப்படும் போது, எந்த நிர்வாகியாலும் ஆவணங்களை நீக்க முடியாது. அம்சம் உடைந்துவிட்டது, ஆனால் அமைப்பு செயலிழக்கவில்லை. அது வெறும் 403 Forbidden பிழையைத் தருகிறது. இந்த பிழை பல நாட்கள் அல்லது வாரங்களுக்கு கவனிக்கப்படாமல் போகலாம், பயனர்களுக்கு விரக்தியை ஏற்படுத்தலாம் மற்றும் ஒரு வேதனையான பிழைதிருத்த அமர்வு தேவைப்படலாம்.

இது தொழில்முறை மென்பொருளை உருவாக்குவதற்கான நிலையான அல்லது பாதுகாப்பான வழி அல்ல. நமக்கு ஒரு சிறந்த அணுகுமுறை தேவை.

வகை-பாதுகாப்பான அங்கீகாரத்தை அறிமுகப்படுத்துதல்: உங்கள் முதல் தற்காப்புப் பிணையமாக கம்பைலர்

வகை-பாதுகாப்பான அங்கீகாரம் ஒரு முன்னுதாரண மாற்றமாகும். கம்பைலருக்குத் தெரியாத தன்னிச்சையான ஸ்ட்ரிங்குகளாக அனுமதிகளைப் பிரதிநிதித்துவப்படுத்துவதற்குப் பதிலாக, அவற்றை நமது நிரலாக்க மொழியின் வகை அமைப்பிற்குள் வெளிப்படையான வகைகளாக வரையறுக்கிறோம். இந்த எளிய மாற்றம் அனுமதி சரிபார்ப்பை ரன்டைம் கவலையிலிருந்து ஒரு கம்பைல்-நேர உத்தரவாதத்திற்கு மாற்றுகிறது.

நீங்கள் ஒரு வகை-பாதுகாப்பான அமைப்பைப் பயன்படுத்தும்போது, செல்லுபடியாகும் அனுமதிகளின் முழுத் தொகுப்பையும் கம்பைலர் புரிந்துகொள்கிறது. இல்லாத ஒரு அனுமதியை நீங்கள் சரிபார்க்க முயற்சித்தால், உங்கள் குறியீடு தொகுக்கப்படாது. எங்கள் முந்தைய எடுத்துக்காட்டில் இருந்து வந்த எழுத்துப்பிழை, "document:delete" எதிராக "document_delete", நீங்கள் கோப்பைச் சேமிக்கும் முன்பே உங்கள் குறியீடு எடிட்டரில் உடனடியாகக் கண்டறியப்பட்டு, சிவப்பு நிறத்தில் அடிக்கோடிட்டுக் காட்டப்படும்.

முக்கிய கொள்கைகள்

• மையப்படுத்தப்பட்ட வரையறை: சாத்தியமான அனைத்து அனுமதிகளும் ஒற்றை, பகிரப்பட்ட இடத்தில் வரையறுக்கப்படுகின்றன. இந்த கோப்பு அல்லது தொகுதி முழு பயன்பாட்டின் பாதுகாப்பு மாதிரிக்கான மறுக்க முடியாத உண்மை ஆதாரமாகிறது.
• கம்பைல்-நேர சரிபார்ப்பு: ஒரு சரிபார்ப்பு, ஒரு பங்கு வரையறை அல்லது ஒரு UI கூறு எதுவாக இருந்தாலும், அனுமதிக்கு எந்த குறிப்பும் செல்லுபடியாகும், தற்போதுள்ள அனுமதி என்பதை வகை அமைப்பு உறுதி செய்கிறது. எழுத்துப்பிழைகள் மற்றும் இல்லாத அனுமதிகள் சாத்தியமற்றது.
• மேம்பட்ட டெவலப்பர் அனுபவம் (DX): user.hasPermission(...) என்று தட்டச்சு செய்யும்போது டெவலப்பர்கள் தானியங்கு நிரப்புதல் போன்ற IDE அம்சங்களைப் பெறுகிறார்கள். அவர்கள் கிடைக்கக்கூடிய அனைத்து அனுமதிகளின் கீழ்தோன்றும் பட்டியலைக் காணலாம், இது அமைப்பைத் தானே ஆவணப்படுத்துகிறது மற்றும் துல்லியமான ஸ்ட்ரிங் மதிப்புகளை நினைவில் வைத்துக்கொள்வதற்கான மன உழைப்பைக் குறைக்கிறது.
• நம்பிக்கையான ரீஃபேக்டரிங்: ஒரு அனுமதியை மறுபெயரிட நீங்கள் தேவைப்பட்டால், உங்கள் IDE இன் உள்ளமைக்கப்பட்ட ரீஃபேக்டரிங் கருவிகளைப் பயன்படுத்தலாம். அதன் மூலத்தில் அனுமதியை மறுபெயரிடுவது தானாகவே மற்றும் பாதுகாப்பாக திட்டத்தின் அனைத்து பயன்பாடுகளையும் புதுப்பிக்கும். ஒரு காலத்தில் அதிக ஆபத்துள்ள கையேடு பணி ஒரு அற்பமான, பாதுகாப்பான மற்றும் தானியங்கு பணியாகிறது.

அடிப்படையை உருவாக்குதல்: ஒரு வகை-பாதுகாப்பான அனுமதி அமைப்பைச் செயல்படுத்துதல்

கோட்பாட்டிலிருந்து நடைமுறைக்கு வருவோம். நாம் முழுமையான, வகை-பாதுகாப்பான அனுமதி அமைப்பை அடித்தளத்திலிருந்து உருவாக்குவோம். எங்கள் எடுத்துக்காட்டுகளுக்கு, TypeScript ஐப் பயன்படுத்துவோம், ஏனெனில் அதன் சக்திவாய்ந்த வகை அமைப்பு இந்த பணிக்கு மிகச்சரியாகப் பொருந்துகிறது. இருப்பினும், அடிப்படைக் கொள்கைகளை C#, Java, Swift, Kotlin, அல்லது Rust போன்ற பிற நிலையான-தட்டச்சு செய்யப்பட்ட மொழிகளுக்கும் எளிதாக மாற்றியமைக்க முடியும்.

படி 1: உங்கள் அனுமதிகளை வரையறுத்தல்

அனைத்து அனுமதிகளுக்கும் ஒரு ஒற்றை உண்மை ஆதாரத்தை உருவாக்குவதே முதல் மற்றும் மிக முக்கியமான படியாகும். இதை அடைய பல வழிகள் உள்ளன, ஒவ்வொன்றிற்கும் அதன் சொந்த வர்த்தக-விலகல்கள் உள்ளன.

விருப்பம் A: ஸ்ட்ரிங் லிட்டரல் யூனியன் வகைகளைப் பயன்படுத்துதல்

இது எளிமையான அணுகுமுறை. சாத்தியமான அனைத்து அனுமதி ஸ்ட்ரிங்குகளின் யூனியனாக ஒரு வகையை நீங்கள் வரையறுக்கிறீர்கள். இது சிறிய பயன்பாடுகளுக்கு சுருக்கமானது மற்றும் பயனுள்ளது.

// src/permissions.ts export type Permission = | "user:create" | "user:read" | "user:update" | "user:delete" | "post:create" | "post:read" | "post:update" | "post:delete";

நன்மைகள்: எழுதவும் புரிந்துகொள்ளவும் மிகவும் எளிது.
குறைபாடுகள்: அனுமதிகளின் எண்ணிக்கை அதிகரிக்கும்போது சிக்கலாக மாறலாம். தொடர்புடைய அனுமதிகளைக் குழுவாக்க இது ஒரு வழியை வழங்கவில்லை, மேலும் அவற்றைப் பயன்படுத்தும் போது நீங்கள் இன்னும் ஸ்ட்ரிங்குகளைத் தட்டச்சு செய்ய வேண்டும்.

விருப்பம் B: Enums ஐப் பயன்படுத்துதல்

Enums தொடர்புடைய மாறிலிகளை ஒரே பெயரின் கீழ் குழுவாக்க ஒரு வழியை வழங்குகிறது, இது உங்கள் குறியீட்டை மேலும் படிக்கக்கூடியதாக மாற்றும்.

// src/permissions.ts export enum Permission { UserCreate = "user:create", UserRead = "user:read", UserUpdate = "user:update", UserDelete = "user:delete", PostCreate = "post:create", // ... மேலும் பல }

நன்மைகள்: பெயரிடப்பட்ட மாறிலிகளை (Permission.UserCreate) வழங்குகிறது, இது அனுமதிகளைப் பயன்படுத்தும் போது எழுத்துப்பிழைகளைத் தடுக்கலாம்.
குறைபாடுகள்: TypeScript enums சில நுணுக்கங்களைக் கொண்டுள்ளன மற்றும் பிற அணுகுமுறைகளை விட குறைவான நெகிழ்வுத்தன்மை கொண்டதாக இருக்கலாம். ஒரு யூனியன் வகைக்கு ஸ்ட்ரிங் மதிப்புகளைப் பிரித்தெடுக்க ஒரு கூடுதல் படி தேவை.

விருப்பம் C: Object-as-Const அணுகுமுறை (பரிந்துரைக்கப்படுகிறது)

இது மிகவும் சக்திவாய்ந்த மற்றும் அளவிடக்கூடிய அணுகுமுறை. TypeScript இன் `as const` உறுதிப்பாட்டைப் பயன்படுத்தி, ஆழமாக கூடு கட்டப்பட்ட, படிக்க-மட்டும் பொருள்கள் மூலம் அனுமதிகளை வரையறுக்கிறோம். இது நமக்கு எல்லா உலகங்களிலும் சிறந்தவற்றை வழங்குகிறது: அமைப்பு, டாட் நோட்டேஷன் மூலம் கண்டறியும் தன்மை (எ.கா., `Permissions.USER.CREATE`), மற்றும் அனைத்து அனுமதி ஸ்ட்ரிங்குகளின் யூனியன் வகையை மாறும் வகையில் உருவாக்கும் திறன்.

இதை எவ்வாறு அமைப்பது என்பது இங்கே:

// src/permissions.ts // 1. Define the permissions object with 'as const' export const Permissions = { USER: { CREATE: "user:create", READ: "user:read", UPDATE: "user:update", DELETE: "user:delete", }, POST: { CREATE: "post:create", READ: "post:read", UPDATE: "post:update", DELETE: "post:delete", }, BILLING: { READ_INVOICES: "billing:read_invoices", MANAGE_SUBSCRIPTION: "billing:manage_subscription", } } as const; // 2. Create a helper type to extract all permission values type TPermissions = typeof Permissions; // This utility type recursively flattens the nested object values into a union type FlattenObjectValues = T extends object ? FlattenObjectValues : T; // 3. Create the final union type of all permissions export type AllPermissions = FlattenObjectValues; // The generated 'AllPermissions' type will be: // "user:create" | "user:read" | "user:update" | "user:delete" | ... and so on

இந்த அணுகுமுறை சிறந்தது, ஏனெனில் இது உங்கள் அனுமதிகளுக்கு ஒரு தெளிவான, படிநிலை கட்டமைப்பை வழங்குகிறது, இது உங்கள் பயன்பாடு வளரும்போது மிக முக்கியமானது. இதை உலாவ எளிதானது, மேலும் `AllPermissions` வகை தானாகவே உருவாக்கப்படுகிறது, அதாவது நீங்கள் ஒரு யூனியன் வகையை கைமுறையாக புதுப்பிக்க வேண்டியதில்லை. இது எங்கள் அமைப்பின் மீதமுள்ளவற்றிற்கு நாம் பயன்படுத்தும் அடிப்படையாகும்.

படி 2: பங்குகளை வரையறுத்தல்

ஒரு பங்கு என்பது அனுமதிகளின் பெயரிடப்பட்ட தொகுப்பு ஆகும். எங்கள் பங்கு வரையறைகளும் வகை-பாதுகாப்பானவை என்பதை உறுதிப்படுத்த இப்போது எங்கள் `AllPermissions` வகையைப் பயன்படுத்தலாம்.

// src/roles.ts import { Permissions, AllPermissions } from './permissions'; // Define the structure for a role export type Role = { name: string; description: string; permissions: AllPermissions[]; }; // Define a record of all application roles export const AppRoles: Record = { GUEST: { name: 'Guest', description: 'அநாமதேய பயனர்களுக்கு வரையறுக்கப்பட்ட அணுகல்.', permissions: [ Permissions.POST.READ, // இடுகைகளை படிக்க முடியும் Permissions.USER.READ, // பயனர் சுயவிவரங்களைக் காண முடியும் ], }, EDITOR: { name: 'Editor', description: 'தங்கள் சொந்த உள்ளடக்கத்தை உருவாக்கவும் நிர்வகிக்கவும் முடியும்.', permissions: [ Permissions.POST.READ, Permissions.POST.CREATE, Permissions.POST.UPDATE, // குறிப்பு: இது *எந்த* இடுகையைக் குறிப்பிடவில்லை. இதை பின்னர் பார்ப்போம். Permissions.POST.DELETE, Permissions.USER.READ, ], }, ADMIN: { name: 'Administrator', description: 'அனைத்து கணினி அம்சங்களுக்கும் முழு அணுகல்.', // நிர்வாகிக்கு அனைத்து அனுமதிகளையும் மாறும் வகையில் வழங்குதல் permissions: Object.values(Permissions).flatMap(resource => Object.values(resource)), }, }; // கூடுதல் பாதுகாப்புக்காக எங்கள் பங்கு விசைகளுக்கான ஒரு வகையையும் நாம் உருவாக்கலாம் export type AppRoleKey = keyof typeof AppRoles; // "GUEST" | "EDITOR" | "ADMIN"

`Permissions` பொருளை (எ.கா., `Permissions.POST.READ`) அனுமதிகளை ஒதுக்க நாம் எவ்வாறு பயன்படுத்துகிறோம் என்பதைக் கவனியுங்கள். இது எழுத்துப்பிழைகளைத் தடுக்கிறது மற்றும் செல்லுபடியாகும் அனுமதிகளை மட்டுமே நாம் ஒதுக்குகிறோம் என்பதை உறுதி செய்கிறது. `ADMIN` பங்கிற்காக, புதிய அனுமதிகள் சேர்க்கப்படும்போது, நிர்வாகிகள் தானாகவே அவற்றைப் பெறுவதை உறுதிசெய்ய, ஒவ்வொரு அனுமதியையும் வழங்க எங்கள் `Permissions` பொருளை நிரல்ரீதியாக சமன்படுத்துகிறோம்.

படி 3: வகை-பாதுகாப்பான சரிபார்ப்பு செயல்பாட்டை உருவாக்குதல்

இது எங்கள் அமைப்பின் முக்கிய இணைப்பு. ஒரு பயனருக்கு ஒரு குறிப்பிட்ட அனுமதி உள்ளதா என்பதை சரிபார்க்கும் ஒரு செயல்பாடு நமக்குத் தேவை. செயல்பாட்டின் கையொப்பத்தில் தான் முக்கிய அம்சம் உள்ளது, இது செல்லுபடியாகும் அனுமதிகளை மட்டுமே சரிபார்க்க முடியும் என்பதை கட்டாயப்படுத்தும்.

முதலில், ஒரு `User` பொருள் எப்படி இருக்கும் என்பதை வரையறுப்போம்:

// src/user.ts import { AppRoleKey } from './roles'; export type User = { id: string; email: string; roles: AppRoleKey[]; // பயனரின் பங்குகள் கூட வகை-பாதுகாப்பானவை! };

இப்போது, அங்கீகார லாஜிக்கை உருவாக்குவோம். திறனுக்காக, ஒரு பயனரின் மொத்த அனுமதி தொகுப்பை ஒருமுறை கணக்கிட்டு, பின்னர் அந்த தொகுப்புக்கு எதிராக சரிபார்ப்பது சிறந்தது.

// src/authorization.ts import { User } from './user'; import { AppRoles } from './roles'; import { AllPermissions } from './permissions'; /** * ஒரு குறிப்பிட்ட பயனருக்கான முழுமையான அனுமதி தொகுப்பை கணக்கிடுகிறது. * திறமையான O(1) தேடல்களுக்கு ஒரு Set ஐப் பயன்படுத்துகிறது. * @param user பயனர் பொருள். * @returns பயனருக்கு உள்ள அனைத்து அனுமதிகளையும் கொண்ட ஒரு Set. */ function getUserPermissions(user: User): Set { const permissionSet = new Set(); user.roles.forEach(roleKey => { const role = AppRoles[roleKey]; if (role) { role.permissions.forEach(permission => { permissionSet.add(permission); }); } }); return permissionSet; } /** * ஒரு பயனருக்கு ஒரு குறிப்பிட்ட அனுமதி உள்ளதா என்பதை சரிபார்க்கும் முக்கிய வகை-பாதுகாப்பான செயல்பாடு. * @param user சரிபார்க்க வேண்டிய பயனர். * @param permission சரிபார்க்க வேண்டிய அனுமதி. செல்லுபடியாகும் AllPermissions வகையாக இருக்க வேண்டும். * @returns பயனருக்கு அனுமதி இருந்தால் True, இல்லையெனில் False. */ export function hasPermission( user: User | null, permission: AllPermissions ): boolean { if (!user) { return false; } const userPermissions = getUserPermissions(user); return userPermissions.has(permission); }

`hasPermission` செயல்பாட்டின் `permission: AllPermissions` அளவுருவில் தான் மேஜிக் உள்ளது. இந்த கையொப்பம் TypeScript கம்பைலருக்கு இரண்டாவது ஆர்க்யுமென்ட் எங்கள் உருவாக்கப்பட்ட `AllPermissions` யூனியன் வகையிலிருந்து ஒரு ஸ்ட்ரிங்காக இருக்க வேண்டும் என்று கூறுகிறது. வேறு ஸ்ட்ரிங்கை பயன்படுத்த முயற்சித்தால் கம்பைல்-நேரப் பிழையில் முடிவடையும்.

நடைமுறையில் பயன்பாடு

இது எங்கள் தினசரி குறியீட்டை எவ்வாறு மாற்றுகிறது என்பதைப் பார்ப்போம். Node.js/Express பயன்பாட்டில் ஒரு API எண்ட்பாயிண்டைப் பாதுகாப்பதை கற்பனை செய்து பாருங்கள்:

import { hasPermission } from './authorization'; import { Permissions } from './permissions'; import { User } from './user'; app.delete('/api/posts/:id', (req, res) => { const currentUser: User = req.user; // அங்கீகார மிடில்வேரிலிருந்து பயனர் இணைக்கப்பட்டுள்ளதாகக் கருதுங்கள் // இது மிகச்சரியாக செயல்படுகிறது! Permissions.POST.DELETE க்கு தானியங்கு நிரப்புதல் கிடைக்கிறது if (hasPermission(currentUser, Permissions.POST.DELETE)) { // இடுகையை நீக்கும் லாஜிக் res.status(200).send({ message: 'Post deleted.' }); } else { res.status(403).send({ error: 'இடுகைகளை நீக்க உங்களுக்கு அனுமதி இல்லை.' }); } }); // இப்போது, ஒரு தவறு செய்ய முயற்சிப்போம்: app.post('/api/users', (req, res) => { const currentUser: User = req.user; // பின்வரும் வரி உங்கள் IDE இல் சிவப்பு சுருக்கக் கோட்டைக் காட்டும் மற்றும் தொகுக்கத் தவறிவிடும்! // பிழை: Argument of type '"user:creat"' is not assignable to parameter of type 'AllPermissions'. // நீங்கள் '"user:create"' என்று கருதினீர்களா? if (hasPermission(currentUser, "user:creat")) { // 'create' இல் எழுத்துப்பிழை // இந்த குறியீடு அடைய முடியாதது } });

ஒரு முழு வகை பிழைகளையும் நாம் வெற்றிகரமாக நீக்கிவிட்டோம். எங்கள் பாதுகாப்பு மாதிரியை அமல்படுத்துவதில் கம்பைலர் இப்போது ஒரு செயலில் உள்ள பங்கேற்பாளராகும்.

அமைப்பை அளவிடுதல்: வகை-பாதுகாப்பான அங்கீகாரத்தில் மேம்பட்ட கருத்துக்கள்

ஒரு எளிய பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாடு (RBAC) அமைப்பு சக்தி வாய்ந்தது, ஆனால் நிஜ உலகப் பயன்பாடுகளுக்கு பெரும்பாலும் சிக்கலான தேவைகள் உள்ளன. தரவைப் பொறுத்து இருக்கும் அனுமதிகளை நாம் எவ்வாறு கையாளுகிறோம்? எடுத்துக்காட்டாக, ஒரு `EDITOR` ஒரு இடுகையைப் புதுப்பிக்க முடியும், ஆனால் தங்கள் சொந்த இடுகையை மட்டுமே.

பண்பு அடிப்படையிலான அணுகல் கட்டுப்பாடு (ABAC) மற்றும் வள அடிப்படையிலான அனுமதிகள்

இங்குதான் பண்பு அடிப்படையிலான அணுகல் கட்டுப்பாடு (ABAC) என்ற கருத்தை நாம் அறிமுகப்படுத்துகிறோம். கொள்கைகள் அல்லது நிபந்தனைகளைக் கையாள எங்கள் அமைப்பை விரிவுபடுத்துகிறோம். ஒரு பயனருக்கு பொதுவான அனுமதி (எ.கா., `post:update`) இருப்பது மட்டுமல்லாமல், அவர்கள் அணுக முயற்சிக்கும் குறிப்பிட்ட வளத்துடன் தொடர்புடைய ஒரு விதியையும் பூர்த்தி செய்ய வேண்டும்.

ஒரு கொள்கை அடிப்படையிலான அணுகுமுறையுடன் இதை மாதிரியாக்கலாம். சில அனுமதிகளுக்கு ஒத்த கொள்கைகளின் வரைபடத்தை வரையறுக்கிறோம்.

// src/policies.ts import { User } from './user'; // நமது வள வகைகளை வரையறுக்கவும் type Post = { id: string; authorId: string; }; // கொள்கைகளின் வரைபடத்தை வரையறுக்கவும். விசைகள் எங்கள் வகை-பாதுகாப்பான அனுமதிகள்! type PolicyMap = { [Permissions.POST.UPDATE]?: (user: User, post: Post) => boolean; [Permissions.POST.DELETE]?: (user: User, post: Post) => boolean; // பிற கொள்கைகள்... }; export const policies: PolicyMap = { [Permissions.POST.UPDATE]: (user, post) => { // ஒரு இடுகையைப் புதுப்பிக்க, பயனர் அதன் ஆசிரியராக இருக்க வேண்டும். return user.id === post.authorId; }, [Permissions.POST.DELETE]: (user, post) => { // ஒரு இடுகையை நீக்க, பயனர் அதன் ஆசிரியராக இருக்க வேண்டும். return user.id === post.authorId; }, }; // நாம் ஒரு புதிய, மிகவும் சக்திவாய்ந்த சரிபார்ப்பு செயல்பாட்டை உருவாக்கலாம் export function can(user: User | null, permission: AllPermissions, resource?: any): boolean { if (!user) return false; // 1. முதலில், பயனருக்கு அவர்களின் பங்கிலிருந்து அடிப்படை அனுமதி உள்ளதா என சரிபார்க்கவும். if (!hasPermission(user, permission)) { return false; } // 2. அடுத்து, இந்த அனுமதிக்கு ஒரு குறிப்பிட்ட கொள்கை உள்ளதா என சரிபார்க்கவும். const policy = policies[permission]; if (policy) { // 3. ஒரு கொள்கை இருந்தால், அது பூர்த்தி செய்யப்பட வேண்டும். if (!resource) { // கொள்கைக்கு ஒரு வளம் தேவை, ஆனால் எதுவும் வழங்கப்படவில்லை. console.warn(`Policy for ${permission} was not checked because no resource was provided.`); return false; } return policy(user, resource); } // 4. எந்த கொள்கையும் இல்லாவிட்டால், பங்கு அடிப்படையிலான அனுமதி இருப்பது போதுமானது. return true; }

இப்போது, ​​எங்கள் API எண்ட்பாயிண்ட் மேலும் நுட்பமானதாகவும் பாதுகாப்பானதாகவும் மாறுகிறது:

import { can } from './policies'; import { Permissions } from './permissions'; app.put('/api/posts/:id', async (req, res) => { const currentUser = req.user; const post = await db.posts.findById(req.params.id); // இந்த *குறிப்பிட்ட* இடுகையை புதுப்பிக்கும் திறனை சரிபார்க்கவும் if (can(currentUser, Permissions.POST.UPDATE, post)) { // பயனருக்கு 'post:update' அனுமதி உள்ளது மற்றும் அவர் ஆசிரியர். // புதுப்பித்தல் லாஜிக்கைத் தொடரவும்... } else { res.status(403).send({ error: 'இந்த இடுகையைப் புதுப்பிக்க உங்களுக்கு அங்கீகாரம் இல்லை.' }); } });

ஃப்ரண்டெண்ட் ஒருங்கிணைப்பு: பேக்கெண்ட் மற்றும் ஃப்ரண்டெண்டிற்கு இடையில் வகைகளைப் பகிர்தல்

இந்த அணுகுமுறையின் மிக முக்கியமான நன்மைகளில் ஒன்று, குறிப்பாக ஃப்ரண்டெண்ட் மற்றும் பேக்கெண்ட் இரண்டிலும் TypeScript ஐப் பயன்படுத்தும்போது, ​​இந்த வகைகளைப் பகிரும் திறன் ஆகும். உங்கள் `permissions.ts`, `roles.ts` மற்றும் பிற பகிரப்பட்ட கோப்புகளை ஒரு மோனோரெப்போவில் (Nx, Turborepo அல்லது Lerna போன்ற கருவிகளைப் பயன்படுத்தி) ஒரு பொதுவான தொகுப்பில் வைப்பதன் மூலம், உங்கள் ஃப்ரண்டெண்ட் பயன்பாடு அங்கீகார மாதிரியை முழுமையாக அறிந்திருக்கும்.

இது உங்கள் UI குறியீட்டில் சக்திவாய்ந்த வடிவங்களை செயல்படுத்துகிறது, அதாவது ஒரு பயனரின் அனுமதிகளை அடிப்படையாகக் கொண்டு கூறுகளை நிபந்தனைக்குட்பட்டு வழங்குவது, அனைத்தும் வகை அமைப்பின் பாதுகாப்புடன்.

ஒரு React கூறுவைக் கவனியுங்கள்:

// ஒரு React கூறுவில் import { Permissions } from '@my-app/shared-types'; // ஒரு பகிரப்பட்ட தொகுப்பிலிருந்து இறக்குமதி செய்தல் import { useAuth } from './auth-context'; // அங்கீகார நிலைக்கான ஒரு தனிப்பயன் ஹூக் interface EditPostButtonProps { post: Post; } const EditPostButton = ({ post }: EditPostButtonProps) => { const { user, can } = useAuth(); // 'can' என்பது எங்கள் புதிய கொள்கை அடிப்படையிலான லாஜிக்கைப் பயன்படுத்தும் ஒரு ஹூக் // சரிபார்ப்பு வகை-பாதுகாப்பானது. UI அனுமதிகள் மற்றும் கொள்கைகளைப் பற்றி அறிந்திருக்கிறது! if (!can(user, Permissions.POST.UPDATE, post)) { return null; // பயனரால் செயலைச் செய்ய முடியாவிட்டால் பொத்தானை வழங்க வேண்டாம் } return Edit Post; };

இது ஒரு கேம்-சேஞ்சர். உங்கள் ஃப்ரண்டெண்ட் குறியீடு இனி UI தெரிவுநிலையைக் கட்டுப்படுத்த யூகிக்கவோ அல்லது ஹார்ட்கோடட் ஸ்ட்ரிங்குகளைப் பயன்படுத்தவோ தேவையில்லை. இது பேக்கெண்டின் பாதுகாப்பு மாதிரியுடன் மிகச்சரியாக ஒத்திசைக்கப்படுகிறது, மேலும் பேக்கெண்டில் அனுமதிகளில் ஏதேனும் மாற்றங்கள் செய்யப்பட்டால், அவை புதுப்பிக்கப்படாவிட்டால், ஃப்ரண்டெண்டில் உடனடியாக வகை பிழைகளை ஏற்படுத்தும், UI முரண்பாடுகளைத் தடுக்கும்.

வணிகக் காரணம்: உங்கள் அமைப்பு ஏன் வகை-பாதுகாப்பான அங்கீகாரத்தில் முதலீடு செய்ய வேண்டும்

இந்த மாதிரியை ஏற்றுக்கொள்வது ஒரு தொழில்நுட்ப மேம்பாட்டை விட அதிகம்; இது உறுதியான வணிக நன்மைகளைக் கொண்ட ஒரு மூலோபாய முதலீடு.

• குறைக்கப்பட்ட பிழைகள்: அங்கீகாரம் தொடர்பான பாதுகாப்பு பாதிப்புகள் மற்றும் ரன்டைம் பிழைகளின் ஒரு முழு வகையையும் நீக்குகிறது. இது ஒரு நிலையான தயாரிப்பு மற்றும் குறைவான விலையுயர்ந்த உற்பத்தி நிகழ்வுகளுக்கு வழிவகுக்கிறது.
• துரிதப்படுத்தப்பட்ட மேம்பாட்டு வேகம்: தானியங்கு நிரப்புதல், நிலையான பகுப்பாய்வு மற்றும் சுய-ஆவணப்படுத்தும் குறியீடு டெவலப்பர்களை வேகமானதாகவும் மேலும் நம்பிக்கையாகவும் ஆக்குகிறது. அனுமதி ஸ்ட்ரிங்குகளைத் தேடுவதற்கோ அல்லது மௌனமான அங்கீகார தோல்விகளைப் பிழைதிருத்தம் செய்வதற்கோ குறைந்த நேரம் செலவிடப்படுகிறது.
• எளிதாக்கப்பட்ட உள்ளீடு மற்றும் பராமரிப்பு: அனுமதி அமைப்பு இனி பழங்குடி அறிவு அல்ல. புதிய டெவலப்பர்கள் பகிரப்பட்ட வகைகளை ஆய்வு செய்வதன் மூலம் பாதுகாப்பு மாதிரியை உடனடியாகப் புரிந்துகொள்ள முடியும். பராமரிப்பு மற்றும் ரீஃபேக்டரிங் குறைந்த ஆபத்துள்ள, கணிக்கக்கூடிய பணிகளாக மாறும்.
• மேம்படுத்தப்பட்ட பாதுகாப்பு நிலை: ஒரு தெளிவான, வெளிப்படையான மற்றும் மையமாக நிர்வகிக்கப்படும் அனுமதி அமைப்பு தணிக்கை செய்யவும் பகுத்தறியவும் மிகவும் எளிதானது. "பயனர்களை நீக்க யாருக்கு அனுமதி உள்ளது?" போன்ற கேள்விகளுக்கு பதிலளிப்பது அற்பமானதாகிறது. இது இணக்கம் மற்றும் பாதுகாப்பு மதிப்பாய்வுகளை வலுப்படுத்துகிறது.

சவால்கள் மற்றும் பரிசீலனைகள்

சக்திவாய்ந்ததாக இருந்தாலும், இந்த அணுகுமுறை அதன் பரிசீலனைகள் இல்லாமல் இல்லை:

• ஆரம்ப அமைவு சிக்கலானது: உங்கள் குறியீடு முழுவதும் ஸ்ட்ரிங் சரிபார்ப்புகளை வெறுமனே சிதறடிப்பதைக் காட்டிலும், இதற்கு அதிக முன்மாதிரி கட்டிடக்கலை சிந்தனை தேவைப்படுகிறது. இருப்பினும், இந்த ஆரம்ப முதலீடு திட்டத்தின் முழு வாழ்நாள் முழுவதும் பலன்களைத் தருகிறது.
• அளவிலான செயல்திறன்: ஆயிரக்கணக்கான அனுமதிகள் அல்லது மிகவும் சிக்கலான பயனர் படிநிலைகளைக் கொண்ட அமைப்புகளில், ஒரு பயனரின் அனுமதி தொகுப்பை (`getUserPermissions`) கணக்கிடும் செயல்முறை ஒரு தடங்கலாக மாறக்கூடும். அத்தகைய சூழ்நிலைகளில், கேச்சிங் உத்திகளைச் செயல்படுத்துவது (எ.கா., கணக்கிடப்பட்ட அனுமதி தொகுப்புகளைச் சேமிக்க Redis ஐப் பயன்படுத்துவது) மிக முக்கியம்.
• கருவி மற்றும் மொழி ஆதரவு: இந்த அணுகுமுறையின் முழு நன்மைகளும் வலுவான நிலையான தட்டச்சு அமைப்புகளைக் கொண்ட மொழிகளில் உணரப்படுகின்றன. பைதான் அல்லது ரூபி போன்ற டைனமிக்-தட்டச்சு செய்யப்பட்ட மொழிகளில் வகை குறிப்பு மற்றும் நிலையான பகுப்பாய்வு கருவிகள் மூலம் தோராயமாக சாத்தியமானாலும், இது TypeScript, C#, Java மற்றும் Rust போன்ற மொழிகளுக்கு மிகவும் இயல்பானது.

முடிவுரை: மிகவும் பாதுகாப்பான மற்றும் பராமரிக்கக்கூடிய எதிர்காலத்தை உருவாக்குதல்

மேஜிக் ஸ்ட்ரிங்குகளின் ஆபத்தான நிலப்பரப்பிலிருந்து வகை-பாதுகாப்பான அங்கீகாரத்தின் நன்கு பலப்படுத்தப்பட்ட நகரத்திற்கு நாம் பயணித்திருக்கிறோம். அனுமதிகளை எளிய தரவுகளாகக் கருதாமல், எங்கள் பயன்பாட்டின் வகை அமைப்பின் ஒரு முக்கிய பகுதியாகக் கருதுவதன் மூலம், கம்பைலரை ஒரு எளிய குறியீடு சரிபார்ப்பிலிருந்து ஒரு விழிப்புள்ள பாதுகாப்பு காவலராக மாற்றுகிறோம்.

வகை-பாதுகாப்பான அங்கீகாரம் என்பது நவீன மென்பொருள் பொறியியல் கொள்கையான இடதுபுறம் நகர்வதற்கு ஒரு சான்றாகும்—மேம்பாட்டு வாழ்க்கைச் சுழற்சியில் முடிந்தவரை சீக்கிரம் பிழைகளைக் கண்டறிதல். இது குறியீட்டுத் தரம், டெவலப்பர் உற்பத்தித்திறன் மற்றும் மிக முக்கியமாக, பயன்பாட்டுப் பாதுகாப்பில் ஒரு மூலோபாய முதலீடு. சுய-ஆவணப்படுத்தும், எளிதாக ரீஃபேக்டரிங் செய்யக்கூடிய மற்றும் தவறாகப் பயன்படுத்த முடியாத ஒரு அமைப்பை உருவாக்குவதன் மூலம், நீங்கள் சிறந்த குறியீட்டை எழுதுவது மட்டுமல்ல; உங்கள் பயன்பாடு மற்றும் உங்கள் குழுவிற்கு மிகவும் பாதுகாப்பான மற்றும் பராமரிக்கக்கூடிய எதிர்காலத்தை உருவாக்குகிறீர்கள். அடுத்த முறை நீங்கள் ஒரு புதிய திட்டத்தைத் தொடங்கும்போது அல்லது ஒரு பழைய திட்டத்தை ரீஃபேக்டரிங் செய்யும்போது, ​​உங்களை நீங்களே கேட்டுக்கொள்ளுங்கள்: உங்கள் அங்கீகார அமைப்பு உங்களுக்குச் சாதகமாகச் செயல்படுகிறதா, அல்லது உங்களுக்கு எதிராகச் செயல்படுகிறதா?