ਆਪਣੀ ਐਪ ਵਿੱਚ ਰੋਲ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ (RBAC) ਕਿਵੇਂ ਜੋੜੀਏ

ਰੋਲ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਜੋੜਨ ਲਈ, ਹਰ ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਜਾਂ ਵੱਧ ਰੋਲ ਦਿਓ (ਜਿਵੇਂ admin, editor, viewer), ਤੈਅ ਕਰੋ ਕਿ ਹਰ ਰੋਲ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਬੇਨਤੀ ਲਈ ਉਹ ਇਜਾਜ਼ਤਾਂ ਸਰਵਰ 'ਤੇ ਜਾਂਚੋ, ਸਿਰਫ਼ ਬਟਨ ਲੁਕਾ ਕੇ ਨਹੀਂ। ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ ਜਿਸ ਰਿਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਹੋ ਰਹੀ ਹੈ ਉਹ ਯੂਜ਼ਰ ਦੇ ਖਾਤੇ ਜਾਂ ਟੀਮ ਦਾ ਹੈ। ਆਪਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੁਝ ਪੱਕੇ ਰੋਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਟੈਸਟ ਕਰੋ ਕਿ ਕੀ ਕੋਈ ਸਿੱਧਾ ਦੂਜੇ ਯੂਜ਼ਰ ਦਾ ਡੇਟਾ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।

ਪ੍ਰਮਾਣੀਕਰਨ ਬਨਾਮ ਅਧਿਕਾਰ

ਦੋ ਸ਼ਬਦ ਜੋ ਅਕਸਰ ਰਲ ਜਾਂਦੇ ਹਨ:

• ਪ੍ਰਮਾਣੀਕਰਨ (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)
);

ਯੂਜ਼ਰਾਂ ਨੂੰ ਆਮ ਪ੍ਰੋਫਾਈਲ ਅੱਪਡੇਟ ਰਾਹੀਂ ਆਪਣਾ ਰੋਲ ਕਦੇ ਵੀ ਬਦਲਣ ਨਾ ਦਿਓ। ਰੋਲ ਬਦਲਣੇ ਇੱਕ ਸਮਰਪਿਤ, ਇਜਾਜ਼ਤ-ਜਾਂਚ ਵਾਲੇ endpoint ਰਾਹੀਂ ਹੋਣ।

3. ਇਜਾਜ਼ਤਾਂ ਸਰਵਰ 'ਤੇ, ਇੱਕ ਥਾਂ ਜਾਂਚੋ

ਇੱਕ ਹੈਲਪਰ ਲਿਖੋ, ਜਿਵੇਂ can(user, 'projects.delete', project), ਅਤੇ ਹਰ API ਰੂਟ, ਸਰਵਰ ਐਕਸ਼ਨ ਅਤੇ ਪਿਛੋਕੜ ਕੰਮ ਵਿੱਚ ਵਰਤੋ ਜੋ ਡੇਟਾ ਪੜ੍ਹਦਾ ਜਾਂ ਬਦਲਦਾ ਹੈ। ਇੱਕ ਕੇਂਦਰੀ ਫੰਕਸ਼ਨ ਕੋਡ ਵਿੱਚ ਖਿੱਲਰੀਆਂ ਜਾਂਚਾਂ ਨਾਲੋਂ ਸਮੀਖਿਆ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਸੌਖਾ ਹੈ। ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਇਨਕਾਰ ਕਰੋ: ਜੇ ਕੋਈ ਨਿਯਮ ਕਾਰਵਾਈ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦੇਵੇ, ਤਾਂ ਉਹ ਰੱਦ ਹੁੰਦੀ ਹੈ।

4. ਹਰ ਕੁਏਰੀ ਦਾ ਦਾਇਰਾ ਤੈਅ ਕਰੋ

ਟੀਮ ਦੇ ਡੇਟਾ ਦੀ ਹਰ ਕੁਏਰੀ ਵਿੱਚ ਟੀਮ ਸ਼ਾਮਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: where organization_id = :currentOrg, ਸਿਰਫ਼ where id = :id ਨਹੀਂ। ਇਹੀ ਰੋਕਦਾ ਹੈ ਕਿ ਕੋਈ /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 ਪੰਨਾ ਜੋੜੋ ਜਿੱਥੇ ਮਾਲਕ ਮੈਂਬਰਾਂ ਦੇ ਰੋਲ ਬਦਲ ਸਕੇ। ਆਖਰੀ ਮਾਲਕ ਨੂੰ ਹਟਾਉਣ ਜਾਂ ਹੇਠਾਂ ਕਰਨ ਤੋਂ ਰੋਕੋ, ਹਰ ਰੋਲ ਬਦਲਾਅ ਨੂੰ ਕਿਸ ਨੇ ਅਤੇ ਕਦੋਂ ਕੀਤਾ ਲਿਖੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਰੋਲ-ਬਦਲਾਅ endpoint ਕਿਸੇ ਗੈਰ-ਮਾਲਕ ਨੂੰ ਰੱਦ ਕਰੇ।

ਆਮ ਗਲਤੀਆਂ

• ਰੋਲ ਸਿਰਫ਼ ਫਰੰਟ ਐਂਡ 'ਤੇ ਜਾਂਚਣੇ। 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 ਵਿੱਚ ਹਰ ਰੋਲ ਟੈਸਟ ਕਰੋ। ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਸੁਰੱਖਿਆ ਪ੍ਰੋਂਪਟ ਅਗਲੇ ਕਦਮ ਲਈ ਲਾਭਦਾਇਕ ਹਨ।

ਸਵਾਲ