ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ರೋಲ್-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ (RBAC) ಸೇರಿಸುವುದು ಹೇಗೆ

ರೋಲ್-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಸೇರಿಸಲು, ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ ಒಂದು ಅಥವಾ ಹೆಚ್ಚು ಪಾತ್ರಗಳನ್ನು ನೀಡಿ (ಉದಾಹರಣೆಗೆ ಅಡ್ಮಿನ್, ಎಡಿಟರ್, ವೀಕ್ಷಕ), ಪ್ರತಿ ಪಾತ್ರ ಯಾವ ಕ್ರಿಯೆಗಳನ್ನು ಮಾಡಬಹುದು ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಿ, ಮತ್ತು ಆ ಅನುಮತಿಗಳನ್ನು ಪ್ರತಿ ವಿನಂತಿಗೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ — ಕೇವಲ ಬಟನ್ ಮರೆಮಾಡುವ ಮೂಲಕ ಅಲ್ಲ. ಪ್ರವೇಶಿಸುತ್ತಿರುವ ದಾಖಲೆ ಬಳಕೆದಾರರ ಖಾತೆ ಅಥವಾ ತಂಡಕ್ಕೆ ಸೇರಿದೆಯೇ ಎಂದೂ ಪರಿಶೀಲಿಸಿ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕೆಲವು ಸ್ಥಿರ ಪಾತ್ರಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ನೇರವಾಗಿ ತಲುಪಲು ಪ್ರಯತ್ನಿಸುವ ಮೂಲಕ ಪರೀಕ್ಷಿಸಿ.

ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿಕಾರ

ಗೊಂದಲಕ್ಕೊಳಗಾಗುವ ಎರಡು ಪದಗಳು:

• ದೃಢೀಕರಣ ಎಂದರೆ ನೀವು ಯಾರು? — ಲಾಗಿನ್ ಮಾಡುವುದು. ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗಿನ್ ಸೇರಿಸುವುದು ಹೇಗೆ ನೋಡಿ.
• ಅಧಿಕಾರ ಎಂದರೆ ನೀವು ಏನು ಮಾಡಲು ಅನುಮತಿ ಇದೆ? — ಲಾಗಿನ್ ಆದ ಬಳಕೆದಾರರು ಯಾವ ಪುಟಗಳು, ದಾಖಲೆಗಳು ಮತ್ತು ಕ್ರಿಯೆಗಳನ್ನು ತಲುಪಬಹುದು.

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 organization_id = :currentOrg, ಕೇವಲ where id = :id ಅಲ್ಲ. ಇದೇ ಯಾರಾದರೂ /projects/123 ಅನ್ನು /projects/124 ಗೆ ಬದಲಿಸಿ ಇನ್ನೊಂದು ಕಂಪನಿಯ ಪ್ರಾಜೆಕ್ಟ್ ನೋಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಇತರ ತಂಡಗಳ ದಾಖಲೆಗಳಿಗೆ "forbidden" ಬದಲು "not found" ಹಿಂತಿರುಗಿಸಿ, ಅವು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಎಂದು ಬಹಿರಂಗಪಡಿಸದಿರಲು.

5. ಮುಖ್ಯವಾದ ಕಡೆ ಡೇಟಾಬೇಸ್-ಮಟ್ಟದ ರಕ್ಷಣೆ ಸೇರಿಸಿ

Postgres ರೋ-ಮಟ್ಟದ ಭದ್ರತೆ (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 ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

• ಸರಳ ಭಾಷೆಯಲ್ಲಿ ಬರೆದ ಅನುಮತಿ ಕೋಷ್ಟಕ, ಅಂಚಿನ ಪ್ರಕರಣಗಳು ನಿರ್ಧರಿಸಲ್ಪಟ್ಟಿವೆ
• ಸರ್ವರ್ ಬಳಕೆದಾರರನ್ನು ಸೆಷನ್‌ನಿಂದ ತಿಳಿಯುತ್ತದೆ, ವಿನಂತಿ ಡೇಟಾದಿಂದ ಎಂದಿಗೂ ಇಲ್ಲ
• ಪಾತ್ರಗಳು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ; ಬಳಕೆದಾರರು ತಮ್ಮದನ್ನು ಬದಲಿಸಲಾಗುವುದಿಲ್ಲ
• ಒಂದೇ ಕೇಂದ್ರ ಅನುಮತಿ ಪರಿಶೀಲನೆ, ಡೀಫಾಲ್ಟ್ ಆಗಿ ನಿರಾಕರಿಸುವ, ಪ್ರತಿ ಮಾರ್ಗದಲ್ಲೂ ಬಳಸಲಾಗಿದೆ
• ಪ್ರತಿ ಪ್ರಶ್ನೆಯೂ ಬಳಕೆದಾರರ ಸಂಸ್ಥೆ ಅಥವಾ ಮಾಲೀಕತ್ವಕ್ಕೆ ವ್ಯಾಪ್ತಿಗೊಳಿಸಲ್ಪಟ್ಟಿದೆ
• ಬ್ರೌಸರ್ ಡೇಟಾಬೇಸ್ ತಲುಪಬಲ್ಲ ಕಡೆ ರೋ-ಮಟ್ಟದ ಭದ್ರತೆ
• ಬಳಕೆದಾರರು ಮಾಡಲಾಗದ್ದನ್ನು UI ಮರೆಮಾಡುತ್ತದೆ (ಉಪಯುಕ್ತತೆಗಾಗಿ ಮಾತ್ರ)
• ಸೂಕ್ಷ್ಮ ಕ್ರಿಯೆಗಳು ದಾಖಲಿಸಲ್ಪಟ್ಟಿವೆ
• ಪ್ರತಿ ಪಾತ್ರವನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿದೆ, ನೇರ API ಕರೆಗಳು ಮತ್ತು ಬದಲಿಸಿದ ID ಗಳು ಸೇರಿ

ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ದೀರ್ಘ ಪಟ್ಟಿಯ ಒಂದು ಅಂಶ; AI-ನಿರ್ಮಿತ ಆ್ಯಪ್‌ಗಳಿಗೆ ಭದ್ರತಾ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಉಳಿದದ್ದನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ ಸಿಬ್ಬಂದಿಗಾಗಿ ಉಪಕರಣ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಆಂತರಿಕ ಉಪಕರಣವನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು ಪಾತ್ರಗಳು ಎಲ್ಲಿ ಸೇರುತ್ತವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.

Mythex ನಲ್ಲಿ RBAC

Mythex ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಬಳಕೆದಾರರಿಗೆ ಅಂತರ್ನಿರ್ಮಿತ ಲಾಗಿನ್ ಅಥವಾ ಪಾತ್ರ ವ್ಯವಸ್ಥೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ನೀವು ದೃಢೀಕರಣ ಲೈಬ್ರರಿ ಅಥವಾ ಒದಗಿಸುವವರನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಪಾತ್ರಗಳನ್ನು ವಿವರಿಸುತ್ತೀರಿ, ಮತ್ತು ಏಜೆಂಟ್ ಅವನ್ನು ನಿಮ್ಮ ಕೋಡ್ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್‌ನ Postgres ಡೇಟಾಬೇಸ್‌ಗೆ ಜೋಡಿಸುತ್ತದೆ (ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗಿನ್ ಸೇರಿಸಿ). Mythex ನ ಸ್ವಂತ ವರ್ಕ್‌ಸ್ಪೇಸ್ ಪಾತ್ರಗಳು, ಉದಾಹರಣೆಗೆ Owner ಮತ್ತು Member, ನಿಮ್ಮ Mythex ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಯಾರು ಸಂಪಾದಿಸಬಹುದು ಎಂದು ನಿಯಂತ್ರಿಸುತ್ತವೆ, ನೀವು ಪ್ರಕಟಿಸಿದ ಆ್ಯಪ್ ಅನ್ನು ಯಾರು ಬಳಸಬಹುದು ಎಂದಲ್ಲ. ನಿರ್ಮಿಸುವ ಮೊದಲು ಅನುಮತಿ ಕೋಷ್ಟಕವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಲು Plan ಮೋಡ್ ಬಳಸಿ, ನಂತರ ಮೇಲಿನ ಪರಿಶೀಲನಾ ಪ್ರಾಂಪ್ಟ್ ಬಳಸಿ ಮತ್ತು ಪ್ರಕಟಿಸುವ ಮೊದಲು ಪೂರ್ವವೀಕ್ಷಣೆಯಲ್ಲಿ ಪ್ರತಿ ಪಾತ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ. ದಸ್ತಾವೇಜಿನ ಭದ್ರತಾ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಉಪಯುಕ್ತ ಮುಂದಿನ ಹಂತ.

ಪ್ರಶ್ನೆಗಳು