ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਨੈਵੀਗੇਸ਼ਨ ਮੈਨੂ ਜੋ ਫਿਰ ਵੀ ਐਕਸੈਸ ਲਾਗੂ ਕਰਦੇ ਹਨ

ਅਸਲ ਵਿੱਚ ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੇਨੂ ਕਿਹੜਾ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੇ ਹਨ

ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “ਬਟਨ ਲੁਕਾ ਦਿਓ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਮਤਲਬ ਹੁੰਦੇ ਹਨ: ਉਹਨਾਂ ਉਪਭੋਗਤਿਆਂ ਲਈ ਗੁੰਝਲ ਘਟਾਉਣਾ ਜੋ ਫੀਚਰ ਵਰਤ ਨਹੀਂ ਸਕਦੇ, ਜਾਂ ਗਲਤ ਵਰਤੋਂ ਰੋਕਣਾ। ਫਰੰਟਐਂਡ 'ਤੇ ਸਿਰਫ ਪਹਿਲਾ ਮਕਸਦ ਹਕੀਕਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ।

ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਨੈਵੀਗੇਸ਼ਨ ਮੇਨੂ ਮੁੱਖ ਤੌਰ ਤੇ ਇੱਕ UX ਟੂਲ ਹਨ। ਉਹ ਕਿਸੇ ਨੂੰ ਐਪ ਖੋਲ੍ਹਣ ਤੇ ਤੁਰੰਤ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਹਰ ਦੂਜੇ ਕਲਿੱਕ 'ਤੇ “Access denied” ਸਕਰਿਨ ਦੇ ਸਾਹਮਣੇ ਆਉਣ ਦੇ। ਇਹ ਸਮਝ ਨੂੰ ਵੀ ਘਟਾਉਂਦੇ ਹਨ ਜਿਵੇਂ “ਮੈਂ ਇਨਵਾਇਸ ਕਿੱਥੇ ਅਨੁਮੋਦਿਤ ਕਰਾਂ?” ਜਾਂ “ਇਹ ਪੇਜ਼ ਕਿਉਂ ਐਰਰ ਕਰ ਰਿਹਾ ਹੈ?”

UI ਨੂੰ ਲੁਕਾਉਣਾ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹੈ। ਇਹ ਸਪਸ਼ਟਤਾ ਹੈ।

ਇੱਕ ਜਿਗਿਆਸੂ ਸਹਿਕਰਮੀ ਫਿਰ ਵੀ ਕਰ ਸਕਦਾ ਹੈ:

• ਜੇ ਉਹ URL ਜਾਣਦਾ ਹੈ ਤਾਂ ਕਿਸੇ ਲੁਕੇ ਹੋਏ ਪੇਜ਼ ਦਾ ਡੀਪ ਲਿੰਕ ਟਾਈਪ ਕਰ ਸਕਦਾ ਹੈ
• ਪੁਰਾਣਾ ਬੁੱਕਮਾਰਕ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ ਜੋ ਐਡਮਿਨ ਸਕਰੀਨ ਤੇ ਲੈ ਜਾਵੇ
• ਆਪਣੀ ਸਕ੍ਰਿਪਟ ਜਾਂ ਟੂਲ ਨਾਲ ਤੁਹਾਡੀ API ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ
• ਬ੍ਰਾਉਜ਼ਰ ਤੋਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸੋਧ ਕੇ ਵੱਖ-ਵੱਖ IDs ਟ੍ਰਾਈ ਕਰ ਸਕਦਾ ਹੈ

ਸੋ ਅਸਲ ਸਮੱਸਿਆ ਜੋ ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੇਨੂ ਹੱਲ ਕਰਦੇ ਹਨ ਉਹ ਇਮਾਨਦਾਰ ਮਾਰਗਦਰਸ਼ਨ ਹੈ। ਇਹ ਇੰਟਰਫੇਸ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਕੰਮ, ਰੋਲ ਅਤੇ ਸੰਦਰਭ ਨਾਲ ਸੰਗਤ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕੁਝ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਇੱਕ ਵਧੀਆ ਅੰਤਿਮ ਹਾਲਤ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ:

• ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹੀ ਐਕਸ਼ਨਾਂ ਵੇਖਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਲਈ ਮੱਤਲਬੀ ਹਨ, ਅਤੇ ਅਚਾਨਕ ਗਲਤੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।
• ਡਿਵੈਲਪਰਾਂ ਕੋਲ ਐਕਸੇਸ ਨਿਯਮਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਸਰੋਤ ਹੁੰਦਾ ਹੈ, ਵੱਖ-ਵੱਖ ਜਾਂਚਾਂ ਵਿੱਚ ਨਹੀਂ ਫਟਦਾ।
• ਪ੍ਰੋਡਕਟ ਬਦਲਾਅ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਨਵਾਂ ਮੈਨੂ ਆਈਟਮ ਬਣਾਉਂਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਕਿਹੜੀ ਪਰਮੀਸ਼ਨ ਚਾਹੀਦੀ ਹੈ।
• ਸੁਰੱਖਿਆ ਓਥੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਇਹ ਮਾਇਆ ਰੱਖਦੀ ਹੈ: ਬੈਕਐਂਡ ਹਰ ਵਾਰੀ ਮਨਜ਼ੂਰੀ ਨਾ ਹੋਣ 'ਤੇ ਕਾਰਵਾਈ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਚਾਹੇ UI ਉਨ੍ਹਾਂ ਨੂੰ ਗਲਤੀ ਨਾਲ ਦਿਖਾਉਂਦਾ ਹੋਵੇ।

ਉਦਾਹਰਣ: ਇੱਕ ਛੋਟੇ CRM ਵਿੱਚ, Sales Rep ਨੂੰ Leads ਅਤੇ Tasks ਵੇਖਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ User Management ਨਹੀਂ. ਜੇ ਉਹ ਫਿਰ ਵੀ user management URL ਪੇਸਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਪੇਜ਼ ਨੂੰ fail closed ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਕਿਸੇ ਵੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਯੂਜ਼ਰਾਂ ਦੀ ਸੂਚੀ ਦਿਖਾਉਣ ਜਾਂ ਰੋਲ ਬਦਲਣ ਤੋਂ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ।

ਵਿਜਿਬਿਲਟੀ authorization ਨਹੀਂ ਹੈ

ਵਿਜ਼ਿਬਿਲਟੀ ਉਹ ਹੈ ਜੋ ਇੰਟਰਫੇਸ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਥਰਾਈਜ਼ੇਸ਼ਨ ਉਹ ਹੈ ਜੋ ਸਿਸਟਮ ਸੱਚ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕਰੇਗਾ ਜਦੋਂ ਬੇਨਤੀ ਸਰਵਰ ਤੇ ਪਹੁੰਚੇਗੀ।

ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੇਨੂ ਨੂੰਨੂੰ ਭੁਲਾਵਟ ਘਟਾਉਂਦੇ ਹਨ। ਜੇ ਕਿਸੇ ਨੂੰ ਕਦੇ ਵੀ Billing ਜਾਂ Admin ਦੇਖਣ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੈ, ਉਹਨਾਂ ਆਈਟਮਾਂ ਨੂੰ ਲੁਕਾਉਣਾ ਐਪ ਨੂੰ ਸਾਫ ਰੱਖਦਾ ਹੈ ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਘਟਾਉਂਦਾ ਹੈ। ਪਰ ਬਟਨ ਨੂੰ ਲੁਕਾਉਣਾ ਲੌਕ ਨਹੀਂ ਹੈ। ਲੋਕ ਫਿਰ ਵੀ dev tools, ਪੁਰਾਣੇ ਬੁੱਕਮਾਰਕ ਜਾਂ ਨਕਲ ਕੀਤੀ ਗਈ ਬੇਨਤੀ ਨਾਲ underlying endpoint ਨੂੰ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਨ।

ਇੱਕ ਵਿਹਾਰਕ ਨਿਯਮ: ਇਹ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤਜੁਰਬੇ ਦੀ ਇਛਾ ਰੱਖਦੇ ਹੋ, ਫਿਰ ਨਿਯਮ ਨੂੰ ਬੈਕਐਂਡ 'ਤੇ ਲਾਗੂ ਕਰੋ ਭਾਵੇਂ UI ਕੁਝ ਵੀ ਕਰੇ।

ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਐਕਸ਼ਨ ਨੂੰ ਪ੍ਰਸਤੁਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੋ, ਤਿੰਨ ਪੈਟਰਨ ਵੱਧਤਰ ਕੇਸ ਕਵਰ ਕਰਦੇ ਹਨ:

• ਛੁਪਾਓ ਜਦੋਂ ਫੀਚਰ ਜ਼ਿਆਦਾਤਰ ਰੋਲਾਂ ਲਈ ਅਣਖੋਜਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਉਦਾਹਰਣ: ਸਿਰਫ ਅੰਦਰੂਨੀ ਸਰੁਕਾਰ)।
• ਡਿਸੇਬਲ ਕਰੋ ਜਦੋਂ ਫੀਚਰ ਮੌਜੂਦ ਹੈ ਪਰ ਯੂਜ਼ਰ ਹੁਣ ਨਹੀਂ ਕਰ ਸਕਦਾ (ਉਦਾਹਰਣ: Export ਪਲਾਨ ਅੱਪਗ੍ਰੇਡ ਹੋਣ ਤੱਕ, ਰਿਕਾਰਡ ਚੁਣਨ ਤੱਕ, ਜਾਂ ਡੇਟਾ ਲੋਡ ਹੋਣ ਤੱਕ)।
• ਸਪਸ਼ਟੀਕਰਨ ਸਮੇਤ ਦਿਖਾਓ ਜਦੋਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੋਵੇ ਕਿ ਉਹ آگੇ ਕਿਉਂ ਨਹੀਂ ਦੀ ਕਰ ਸਕਦੇ ("ਤੁਸੀਂ ਇਨਵਾਇਸ ਵੇਖ ਸਕਦੇ ਹੋ, ਪਰ ਸਿਰਫ Owners ਹੀ ਭੁਗਤਾਨ ਤਰੀਕੇ ਸੋਧ ਸਕਦੇ ਹਨ")।

"ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਪਰ ਸੋਧ ਨਹੀਂ ਕਰ ਸਕਦੇ" ਆਮ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਮੁਤਾਬਿਕ ਹੈ। ਇਹ ਦੋ ਪਰਮੀਸ਼ਨਾਂ ਵਜੋਂ ਦਿੱਖੋ: ਇੱਕ ਡਾਟਾ ਪੜ੍ਹਨ ਲਈ ਅਤੇ ਇੱਕ ਸੋਧਣ ਲਈ। ਮੈਨੂ ਵਿੱਚ, ਤੁਸੀਂ Customer details ਓਹਨਾਂ ਨੂੰ ਦਿਖਾ ਸਕਦੇ ਹੋ ਜੋ ਪੜ੍ਹ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਉਹੀ Edit customer ਦੇਖਣਗੇ ਜਿਨ੍ਹਾਂ ਕੋਲ write access ਹੈ। ਪੇਜ਼ 'ਤੇ, ਫੀਲਡ read-only ਰੇਂਡਰ ਕਰੋ ਅਤੇ edit ਕੰਟਰੋਲ ਨੂੰ ਗੇਟ ਕਰੋ, ਫਿਰ ਵੀ ਪੇਜ਼ ਨੂੰ ਲੋਡ ਹੋਣ ਦਿਓ।

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ: ਅੰਤਿਮ ਨਤੀਜਾ ਬੈਕਐਂਡ ਤੈਅ ਕਰਦਾ ਹੈ। ਭਾਵੇਂ UI ਹਰ ਐਡਮਿਨ ਐਕਸ਼ਨ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੋਵੇ, ਸਰਵਰ ਨੂੰ ਹਰੇਕ ਸੰਵੇਦਨਸ਼ੀਲ ਬੇਨਤੀ 'ਤੇ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਕਰਨਾ ਤੇ "not allowed" ਸਾਫ ਰਿਸਪਾਂਸ ਦਿੱਤਾਂ ਦੇਣਾ ਲਾਜਮੀ ਹੈ।

ਇੱਕ ਐਸਾ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕੋ

ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੇਨੂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦਾ ਇਹ ਹੈ ਕਿ ਅਜਿਹਾ ਮਾਡਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਹੀ ਨਹੀਂ ਰੱਖੋਗੇ।

ਰੋਲਾਂ ਨੂੰ گروਪ ਕਰਨ ਲਈ ਵਰਤੋ, ਮੈਨਿੰਗ ਲਈ ਨਹੀਂ। Admin ਅਤੇ Support ਵਰਗੇ ਫੰਕਸ਼ਨਲ ਬੱਕਟ ਫਾਇਦੇਮੰਦ ਹਨ। ਪਰ ਜਦੋਂ ਰੋਲ ਵਧ-ਵਧ ਕੇ (Admin-West-Coast-ReadOnly) ਵਾਂਗ ਫੈਲਣ ਲੱਗ ਜਾਂਦੇ ਹਨ, UI ਭਟਕਾਵਾਂ ਵਾਲਾ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬੈਕਐਂਡ ਅਨੁਮਾਨ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।

ਉਮੀਦ ਕਰੋ ਕਿ ਪਰਮੀਸ਼ਨ ਉਹ ਸਰੋਤ-ਸੱਚ ਹਨ ਜੋ ਕਿਸੇ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ ਬਤਾਉਂਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੇ ਅਤੇ ਐਕਸ਼ਨ-ਆਧਾਰਿਤ ਰੱਖੋ, ਜਿਵੇਂ invoice.create ਜਾਂ customer.export। ਇਹ role-sprawl ਨਾਲੋਂ ਬਿਹਤਰ ਸਕੇਲ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਨਵੇਂ ਫੀਚਰ ਆਮ ਤੌਰ 'ਤੇ ਨਵੇਂ ਐਕਸ਼ਨ ਜੋੜਦੇ ਹਨ, ਨਾਂ ਕਿ ਨਵੀਆਂ ਨੌਕਰੀਆਂ।

ਫਿਰ ਸੰਦਰਭ ਲਈ ਪਾਲਿਸੀਆਂ ਜੋੜੋ। ਇੱਥੇ ਤੁਸੀਂ ਹਾਲਤਾਂ ਜਿਵੇਂ "ਕੇਵਲ ਆਪਣਾ ਰਿਕਾਰਡ ਸੋਧ ਸਕਦੇ ਹੋ" ਜਾਂ "$5,000 ਤੋਂ ਘੱਟ ਇਨਵਾਇਸ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹੋ" ਹੱਲ ਕਰਦੇ ਹੋ। ਪਾਲਿਸੀਆਂ ਤੁਹਾਨੂੰ ਲਗਭਗ-ਡੁਪਲਿਕੇਟ ਪਰਮੀਸ਼ਨਾਂ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ ਇੱਕ ਸ਼ਰਤ 'ਤੇ ਅੰਤਰਿਤ ਹੁੰਦੀਆਂ।

ਇੱਕ ਬਣਾਉਣਯੋਗ ਲੇਅਰਿੰਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਖਦੀ ਹੈ:

• Roles permissions ਨੂੰ групп ਕਰਦੇ ਹਨ (ਨੌਕਰੀ ਦੀ ਭੂਮਿਕਾ)
• Permissions ਐਕਸ਼ਨਾਂ ਨੂੰ ਵੇਖਾਉਂਦੇ ਹਨ (ਕੀ)
• Policies ਸੰਦਰਭ ਜੋੜਦੀਆਂ ਹਨ (ਕਦੋਂ, ਕਿਸ ਰਿਕਾਰਡ ਤੇ)

ਨਾਂਕਰਨਕਤਾ ਉਮੀਦ ਤੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਜੇ UI ਕਹਿੰਦਾ ਹੈ Export Customers ਪਰ API download_all_clients_v2 ਵਰਤਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਆਖਿਰਕਾਰ ਗਲਤ ਚੀਜ਼ ਛੁਪ ਸਕਦੀ ਹੈ ਜਾਂ ਸਹੀ ਚੀਜ਼ ਰੋਕੀ ਜਾ ਸਕਦੀ ਹੈ। ਨਾਂ ਮਨੁੱਖੀ, ਲਗਾਤਾਰ ਅਤੇ ਫਰੰਟਏਂਡ/ਬੈਕਐਂਡ ਵਿਚ ਸਾਂਝੇ ਰੱਖੋ:

• ਲਗਾਤਾਰ noun.verb (ਜਾਂ resource.action) ਯੂਜ਼ ਕਰੋ
• UI ਲੇਬਲ ਨੂੰ permission ਦੇ ਇਰਾਦੇ ਨਾਲ ਮਿਲਾਓ, ਨਾਂ ਕਿ ਅੰਦਰੂਨੀ ਕੋਡ ਨਾਂ ਨਾਲ
• ਜਦੋਂ ਫੀਚਰ ਰੀਨੇਮ ਹੋਵੇ ਤਾਂ ਪੁਰਾਣੇ ਪਰਮੀਸ਼ਨ ਨਾਂਆਂ ਨੂੰ ਕੰਮ ਕਰਦੇ ਰੱਖੋ

ਉਦਾਹਰਣ: CRM ਵਿੱਚ Sales ਰੋਲ lead.create ਅਤੇ lead.update ਸ਼ਾਮਿਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਪਾਲਿਸੀ update ਹਦ ਤੱਕ ਸਿਰਫ ਉਹਨਾਂ ਲਈ ਸੀਮਿਤ ਕਰਦੀ ਹੈ ਜੋ ਲੀਡ ਦੇ ਮਾਲਕ ਹਨ। ਇਸ ਨਾਲ ਤੁਹਾਡਾ ਮੈਨੂ ਸਾਫ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਬੈਕਐਂਡ ਕਠੋਰ ਰਹਿੰਦਾ ਹੈ।

ਪੈਲੇ ਪੈਲੇ ਕਦਮ: ਰੋਲ ਅਤੇ ਪਰਮੀਸ਼ਨਾਂ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਲਾਗੂ ਕਰੋ

ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਚੰਗਾ ਅਨੁਭਵ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਗੁੰਜਲ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀ ਨਾਲ ਹੋਣ ਵਾਲੇ ਕਲਿੱਕ ਰੋਕਦੇ ਹਨ। ਪਰ ਉਹ ਤਾਂ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਬੈਕਐਂਡ ਅਧਿਕਾਰ ਵਿਚ ਕਾਰਜਕਾਰੀ ਰਹੇ। UI ਨੂੰ ਇੱਕ ਇਸ਼ਾਰਾ ਸਮਝੋ, ਅਤੇ ਸਰਵਰ ਨੂੰ ਨਿਆਯਧੀਸ਼।

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇਹ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਪਰੋਟੈਕਟ ਕਰ ਰਹੇ ਹੋ—ਪੇਜ਼ਾਂ ਨਹੀਂ, ਪਰ ਐਕਸ਼ਨ। View customer list different ਹੈ export customers ਅਤੇ delete customer ਤੋਂ। ਇਹੀ ਬੈਕਬੋਨ ਹੈ ਉਹਨਾਂ ਮੈਨੂਆਂ ਲਈ ਜੋ ਸੁਰੱਖਿਆ ਥਿਏਟਰ ਵਿੱਚ ਨਹੀਂ ਬਦਲਣੀਆਂ।

ਇੱਕ ਅਮਲੀ ਐਂਡ-ਟੂ-ਐਂਡ ਰੈਸੀਪੀ

1. UI ਅਤੇ API ਵਿੱਚ ਐਕਸ਼ਨਾਂ ਦੀ ਇਨਵੈਂਟਰੀ ਕਰੋ। ਹਰ ਫੀਚਰ ਲਈ konkrete operations ਲਿਸਟ ਕਰੋ: read, create, update, delete, export, invite, change billing, run admin reports.
2. ਪਰਮੀਸ਼ਨਾਂ ਨੂੰ ਸਰਵਰ 'ਤੇ ਸਰੋਤ-ਸੱਚ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। role-to-permission ਮੈਪਿੰਗ ਨੂੰ DB (ਜਾਂ config) ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਹਰ API ਹੈਂਡਲਰ ਇਹ ਪੁੱਛੇ: "ਕੀ ਇਹ ਯੂਜ਼ਰ permission X on resource Y ਰੱਖਦਾ ਹੈ?"
3. UI ਲਈ ਇੱਕ ਛੋਟਾ capabilities payload ਰਿਟਰਨ ਕਰੋ। ਲੌਗਿਨ ਪ੍ਰਕਿਰਿਆ (ਜਾਂ ਸੈਸ਼ਨ ਰੀਫ੍ਰੈਸ਼) ਮਗਰੋਂ booleans ਜਿਵੇਂ canEditCustomers, canDeleteCustomers, canExport ਜਾਂ ਇੱਕ ਸੰਕੁਚਿਤ permission strings ਦੀ ਲਿਸਟ ਰਿਟਰਨ ਕਰੋ। ਇਸਨੂੰ ਮਿਨੀਮਲ ਰੱਖੋ।
4. ਹਰੇਕ write ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ read 'ਤੇ ਚੈੱਕ ਲਗਾਓ। ਸਾਰੇ mutations ਨੂੰ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਕਰਨੇ ਲਾਜ਼ਮੀ ਹਨ। ਕੁਝ reads ਨੂੰ ਵੀ (ਉਦਾਹਰਣ: salaries, audit logs, exports) ਪਰਖੋ।
5. ਕੁਝ role-focused tests ਜੋੜੋ। 2–3 ਮੁੱਖ ਰੋਲ ਚੁਣੋ ਅਤੇ ਉੱਚ-ਖ਼ਤਰੇ ਵਾਲੇ ਐਕਸ਼ਨਾਂ ਲਈ ਟੈਸਟ ਕਰੋ। ਉਦਾਹਰਣ: Sales deals ਬਣਾਉਂ ਸਕਦਾ ਹੈ ਪਰ customers export ਨਹੀਂ ਕਰ ਸਕਦਾ; Admin users invite ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਛੋਟਾ ਪਰ ਮਹੱਤਵਪੂਰਨ ਨਿਯਮ: ਕਦੇ ਵੀ ਕਲਾਇੰਟ-ਪ੍ਰੋਵਾਈਡ ਕੀਤੇ role ਜਾਂ permission flags 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। UI capabilities ਦੇ ਆਧਾਰ 'ਤੇ ਬਟਨਾਂ ਨੂੰ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਪਰ API ਨੂੰ ਫਿਰ ਵੀ unauthorized requests ਨੂੰ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਫਰੰਟਐਂਡ ਪੈਟਰਨ ਜੋ ਸਚੇ ਰਹਿੰਦੇ ਹਨ

ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਨੈਵੀਗੇਸ਼ਨ ਮੈਨੂ ਲੋਕਾਂ ਨੂੰ ਉਹ ਚੀਜ਼ਾਂ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਉਹ ਕਰ ਸਕਦੇ ਹਨ, ਨਾ ਕਿ ਇਹ ਦਿਖਾਉਣਾ ਕਿ ਉਨ੍ਹਾਂ ਕੋਲ ਸੁਰੱਖਿਆ ਹੈ। ਫਰੰਟਐਂਡ ਇੱਕ ਗਾਈਡ ਰੇਲ ਹੈ। ਬੈਕਐਂਡ ਲਾਂਚ ਹੈ।

ਇੱਕ ਹੀ ਸਰੋਤ-ਸੱਚ ਤੋਂ ਮੈਨੂ ਬਣਾਓ

ਹਰ ਬਟਨ 'ਤੇ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਘੁਸਾਉਣ ਦੀ ਬਜਾਏ, ਆਪਣੀ ਨੈਵੀਗੇਸ਼ਨ ਨੂੰ ਇੱਕ config ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਹਰ ਆਈਟਮ ਲਈ ਲੋੜੀਂਦੀ ਪਰਮੀਸ਼ਨ ਦੱਸਦਾ ਹੋਵੇ, ਅਤੇ ਫਿਰ ਉਸ config ਤੋਂ render ਕਰੋ। ਇਸ ਨਾਲ ਨਿਯਮ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੇ ਹਨ ਅਤੇ UI ਦੇ ਅਜਿਹੇ ਕੋਨਾਂ ਵਿੱਚ ਭੁੱਲਣ ਦੀ ਸੰਭਾਵਨਾ ਘਟਦੀ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਪੈਟਰਨ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

const menu = [
  { label: "Contacts", path: "/contacts", requires: "contacts.read" },
  { label: "Export", action: "contacts.export", requires: "contacts.export" },
  { label: "Admin", path: "/admin", requires: "admin.access" },
];

const visibleMenu = menu.filter(item => userPerms.includes(item.requires));

Admin ਵਰਗੀਆਂ ਪੂਰੀਆਂ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਛੁਪਾਉਣਾ ਇੱਕ-ਇਕ ਚੈਕ ਲਗਾਉਣ ਨਾਲੋਂ ਵਧੀਆ ਹੈ। ਇਹ ਗਲਤੀਆਂ ਘੱਟ ਕਰਦਾ ਹੈ।

ਇਮਾਨਦਾਰ ਹਾਲਤਾਂ: ਲੁਕਿਆ ਹੋਇਆ vs ਡਿਸੇਬਲ ਕੀਤਾ

ਉਹ ਆਈਟਮ ਲੁਕਾਓ ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸਨੂੰ ਵਰਤਣ ਦੀ ਆਗਿਆ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਡਿਸੇਬਲ ਕਰੋ ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਲ ਪਰਮੀਸ਼ਨ ਹੈ ਪਰ ਮੌਜੂਦਾ ਸੰਦਰਭ ਘੱਟ ਹੈ।

ਉਦਾਹਰਣ: Delete contact ਉਥੇ ਤੱਕ ਡਿਸੇਬਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦ ਤੱਕ ਕੋਈ contact ਚੁਣਿਆ ਨਾ ਹੋਵੇ। ਉਹੀ ਪਰਮੀਸ਼ਨ, ਸਿਰਫ ਸੰਦਰਭ ਘੱਟ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਡਿਸੇਬਲ ਕਰਦੇ ਹੋ, ਕੰਟਰੋਲ ਕੋਲ ਇੱਕ ਛੋਟਾ “ਕਿਉਂ” ਸੁਨੇਹਾ (tooltip, helper text ਜਾਂ inline note) ਦਿਓ: Select a contact to delete.

ਇਕ ਨਿਯਮ-ਸੈਟ ਜੋ ਟਿਕਦਾ ਹੈ:

• ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਲ ਪਰਮੀਸ਼ਨ ਨਹੀਂ ਹੈ ਤਾਂ ਲੁਕਾਓ।
• ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਲ ਪਰਮੀਸ਼ਨ ਹੈ ਪਰ ਕੋਈ ਆਈਟਮ ਚੁਣਿਆ ਨਹੀਂ ਗਿਆ, ਫਾਰਮ ਗਲਤ ਹੈ, ਜਾਂ ਲੋਡਿੰਗ ਚੱਲ ਰਹੀ ਹੈ ਤਾਂ ਡਿਸੇਬਲ ਕਰੋ।
• ਕਦੇ ਵੀ local storage ਨੂੰ ਪਰਮੀਸ਼ਨਾਂ ਲਈ ਤਥ੍ਯ ਸਮਝ ਕੇ ਨਹੀਂ ਲਓ। ਇਹ ਸਿਰਫ ਕੈਸ਼ ਹੈ।
• ਲੌਗਿਨ, ਰੋਲ ਬਦਲਣ ਜਾਂ ਅਕਾਊਂਟ ਸਵਿੱਚ ਹੋਣ 'ਤੇ ਪਰਮੀਸ਼ਨਾਂ ਨੂੰ ਰੀ-ਚੈੱਕ ਕਰੋ।

ਬੈਕਐਂਡ ਲਾਗੂਅੰਨ ਜੋ ਬਾਈਪਾਸ ਨਾਂ ਕੀਤਾ ਜਾ ਸਕੇ

ਮੈਨੂ ਆਈਟਮ ਲੁਕਾਉਣਾ ਲੋਕਾਂ ਨੂੰ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ। ਬੈਕਐਂਡ ਨੂੰ ਆਖਰੀ ਜਜ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਬੇਨਤੀਆਂ ਨੂੰ ਰੀਪਲੇ, ਸੋਧਿਆ ਜਾਂ UI ਤੋਂ ਬਾਹਰ ਟਰਿੱਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ ਵਧੀਆ ਨਿਯਮ: ਹਰ ਐਕਸ਼ਨ ਜੋ ਡਾਟਾ ਬਦਲਦਾ ਹੈ ਉਸ 'ਤੇ ਇੱਕ authorization check ਹੋਵੇ, ਇਕ ਥਾਂ, ਜੋ ਹਰ ਬੇਨਤੀ ਤੋਂ ਗੁਜ਼ਰਦੀ ਹੈ। ਇਹ middleware, handler wrapper, ਜਾਂ ਇੱਕ policy layer ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਪਹੁੰਚ ਚੁਣੋ ਤੇ ਉਸ 'ਤੇ ਟਿਕੋ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਰਾਹ ਛੱਡ ਦਿਓਗੇ।

ਰਿਕਵੇਸਟ ਪੱਥ 'ਤੇ ਚੈੱਕ ਰੱਖੋ

Authorization ਨੂੰ input validation ਤੋਂ ਵੱਖ ਰਹਿਣ ਦਿਓ। ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ, “ਕੀ ਇਹ ਯੂਜ਼ਰ ਇਹ ਕਰ ਸਕਦਾ ਹੈ?”, ਫਿਰ payload validate ਕਰੋ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ validate ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਵੇਰਵੇ ਲੀਕ ਕਰ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ ਕਿ ਕਿਹੜੇ record IDs ਮੌਜੂਦ ਹਨ) ਕਿਸੇ ਨੂੰ ਜਿਸਨੂੰ ਇਹ ਜਾਣਨਾ ਨਹੀਂ ਚਾਹੀਦਾ।

ਇੱਕ ਪੈਟਰਨ ਜੋ ਸਕੇਲ ਕਰਦਾ ਹੈ:

• ਕਾਲਰ ਦੀ authenticate ਕਰੋ ਅਤੇ ਸਾਫ identity ਬਣਾਓ (user id, org id, roles, permissions).
• authorization ਲਈ ਲੋੜੀਂਦਾ resource context ਲੋਡ ਕਰੋ (ਅਕਸਰ ਕੇਵਲ owner id ਜਾਂ org id).
• ਇੱਕ single policy function ਕਾਲ ਕਰੋ (ਉਦਾਹਰਨ: Can(user, "invoice.delete", invoice)).
• ਜੇ deny ਹੋਇਆ ਤੇ ਤੁਰੰਤ ਰੋਕੋ ਅਤੇ ਸਹੀ ਸਟੈਟਸ ਵਾਪਸ ਕਰੋ।
• ਫਿਰ payload validate ਕਰੋ ਅਤੇ ਬਿਜਨੈਸ ਲੋਜਿਕ ਚਲਾਓ।

ਸਪੱਸ਼ਟ, ਲਗਾਤਾਰ ਰਿਸਪਾਂਸ ਰਿਟਰਨ ਕਰੋ

Status codes ਇਸ ਤਰ੍ਹਾਂ ਵਰਤੋ ਜੋ frontend ਅਤੇ logs ਦੋਹਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋਣ:

• 401 Unauthorized ਜਦੋਂ ਕਾਲਰ ਲੌਗਇਨ ਨਹੀਂ ਹੈ.
• 403 Forbidden ਜਦੋਂ ਲੌਗਇਨ ਹੋ ਚੁੱਕੇ ਪਰ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ.

404 Not Found ਨੂੰ disguise ਵਜੋਂ ਵਰਤਣ ਵਿੱਚ ਸਾਵਧਾਨ ਰਹੋ। ਇਹ ਕਿਸੇ ਰਿਸੋਰਸ ਦੇ ਹੋਣ ਦੀ ਖੁਦਾਈ ਨੂ ਲੋਕਾਂ ਤੋਂ ਛੁਪਾਉਣ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਬੇਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਮਿਲਾਉਂਦੇ ਹੋ ਤਾਂ ਡਿਬੱਗਿੰਗ ਮੁਸ਼ਕਲ ਹੋ ਜਾਦੀ ਹੈ। ਹਰ ਰਿਸੋਰਸ ਟਾਈਪ ਲਈ ਇਕ ਰੋਲ ਨਿਯਮ ਚੁਣੋ।

ਸਭ ਤੋਂ ਅਹਮ: ਇਹ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਜੋ authorization ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਉਹ ਬਟਨ ਕਲਿੱਕ, ਮੋਬਾਈਲ ਐਪ, ਸਕ੍ਰਿਪਟ ਜਾਂ ਡਾਇਰੈਕਟ API ਕਾਲ—ਸਭੇ ਲਈ ਇੱਕੋ ਜਿਹਾ ਚੱਲੇ।

ਅੰਤ ਵਿੱਚ, denied ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਡੀਬੱਗ ਅਤੇ ਆਡਿਟ ਲਈ ਲੌਗ ਕਰੋ, ਪਰ ਲੌਗ ਸੇਫ਼ ਰੱਖੋ। ਕਿਸ ਨੇ, ਕਿਹੜਾ ਐਕਸ਼ਨ, ਅਤੇ ਕਿਹੜਾ ਉੱਚ-ਸਤਰ ਰਿਸੋਰਸ ਟਾਈਪ ਲੌਗ ਕਰੋ। ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡ, ਪੂਰੇ payloads ਜਾਂ secrets ਤੋਂ ਬਚੋ।

ਐਜ ਕੇਸ ਜਿਹੜੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਣਾਉਂਦੇ ਜਾਂ ਤੋੜਦੇ ਹਨ

ਅਧਿਕਤਰ ਪਰਮੀਸ਼ਨ ਬੱਗ ਉਨ੍ਹਾਂ ਰਾਹਾਂ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਤੁਹਾਡੇ ਮੈਨੂ ਨੇ ਕਦੇ ਸੋਚੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਸੀ ਲਈ ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਰਾਹਾਂ ਲਈ ਵੀ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਉਹਨਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹਨ।

ਡੀਪ ਲਿੰਕ ਅਤੇ “ਲੁਕੇ” ਸਕਰੀਨਾਂ

ਜੇ ਮੈਨੂ ਕਿਸੇ ਰੋਲ ਲਈ Billing ਨੂੰ ਲੁਕਾਂਦਾ ਹੈ ਤਾਂ ਵੀ ਯੂਜ਼ਰ ਸੇਵ ਕੀਤੀ URL ਪੇਸਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਬ੍ਰਾਉਜ਼ਰ ਇਤਿਹਾਸ ਤੋਂ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ। ਹਰ ਪੇਜ਼ ਲੋਡ ਨੂੰ ਤਾਜ਼ਾ ਬੇਨਤੀ ਵਾਂਗ ਸੋਚੋ: ਵਰਤਮਾਨ ਯੂਜ਼ਰ ਦੀਆਂ ਪਰਮੀਸ਼ਨਾਂ ਲੋਡ ਕਰੋ, ਅਤੇ ਸਕਰੀਨ ਖ਼ੁਦ ਵੀ ਸਕਾਰਾਤਮਕ ਰੂਪ ਵਿੱਚ ਪ੍ਰੋਟੈਕਟ ਕੀਤੇ ਹੋਏ ਡਾਟੇ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰੇ ਜੇ ਪਰਮੀਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਕ ਦੋਸਤਾਨਾ “ਤੁਹਾਨੂੰ ਪਹੁੰਚ ਨਹੀਂ” ਸੁਨੇਹਾ ਠੀਕ ਹੈ, ਪਰ ਅਸਲ ਰੱਖਿਆ ਇਹ ਹੈ ਕਿ ਬੈਕਐਂਡ ਕੁਝ ਵੀ ਵਾਪਸ ਨਾ ਕਰੇ।

ਡਾਇਰੈਕਟ API ਕਾਲ ਅਤੇ ਬਲਕ ਐਂਡਪੋਇੰਟ

ਕੋਈ ਵੀ ਤੁਹਾਡੀ API ਨੂੰ dev tools, ਸਕ੍ਰਿਪਟ ਜਾਂ ਹੋਰ ਕਲਾਇੰਟ ਤੋਂ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਹਰ ਐਂਡਪੋਇੰਟ 'ਤੇ ਚੈੱਕ ਕਰੋ, ਸਿਰਫ ਐਡਮਿਨ ਸਕਰੀਨਾਂ 'ਤੇ ਨਹੀਂ। ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋਣ ਵਾਲਾ ਖਤਰਾ ਬਲਕ ਐਕਸ਼ਨ ਹੈ: ਇੱਕ /items/bulk-update ਨਾਨ-ਐਡਮਿਨ ਨੂੰ ਉਹ fields ਸੋਧਣ ਦੇ ਸਕਦਾ ਹੈ ਜੋ UI ਵਿੱਚ ਵੀ ਨਹੀਂ ਦਿਖਦੇ।

ਰੋਲ ਮਿਡ-ਸੈਸ਼ਨ ਵੀ ਬਦਲ ਸਕਦੇ ਹਨ। ਜੇ admin ਇੱਕ ਪਰਮੀਸ਼ਨ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਯੂਜ਼ਰ ਕੋਲ ਪੁਰਾਣਾ token ਜਾਂ cached menu state ਹੋ ਸਕਦਾ ਹੈ। ਛੋਟੇ-lived tokens ਜਾਂ ਸਰਵਰ-ਸਾਈਡ permission lookup ਵਰਤੋ, ਅਤੇ 401/403 ਮਿਲਣ 'ਤੇ permissions ਅਪਡੇਟ ਕਰੋ ਅਤੇ UI ਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ।

ਸ਼ੇਅਰ ਕੀਤੇ ਡਿਵਾਈਸ ਵੀ ਇੱਕ ਹੋਰ ਜਾਲ ਹਨ: cached menu state ਖਾਤਿਆਂ ਵਿੱਚ ਲੀਕ ਰੂਪ ਵਿੱਚ ਲੱਗ ਸਕਦਾ ਹੈ। menu visibility ਨੂੰ user ID ਨਾਲ کی ਕੀ ਕਰਕੇ ਸਟੋਰ ਕਰੋ, ਜਾਂ ਪੁਰੀ ਤਰ੍ਹਾਂ persist ਨਾ ਕਰੋ।

ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਾਉਣ ਵਾਲੇ ਪੰਜ ਟੈਸਟ:

• ਸੀਮਿਤ ਰੋਲ ਨਾਲ ਲੌਗ ਇਨ ਹੋ ਕੇ ਲੁਕੇ ਪੇਜ਼ ਦਾ ਡੀਪ ਲਿੰਕ ਖੋਲ੍ਹੋ
• dev tools ਤੋਂ ਨਕਲ ਕੀਤੀ ਗਈ ਬੇਨਤੀ ਨਾਲ ਇਕ ਪ੍ਰੋਟੈਕਟਡ API ਕਾਲ ਕਰੋ
• ਯੂਜ਼ਰ ਦਾ ਰੋਲ active ਦੌਰਾਨ ਬਦਲੋ ਅਤੇ ਫਿਰ ਐਕਸ਼ਨ ਦੋਹਰਾਓ
• ਲੌਗ ਆਊਟ ਕਰੋ, ਹੋਰ ਯੂਜ਼ਰ ਨਾਲ ਲੌਗ ਇਨ ਕਰੋ, ਅਤੇ ਮੈਨੂ ਰੀਸੈੱਟ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
• ਮਿਕਸ ਕੀਤੇ allowed ਅਤੇ disallowed fields ਨਾਲ ਬਲਕ ਐਂਡਪੋਇੰਟ ਟ੍ਰਾਈ ਕਰੋ

ਉਦਾਹਰਣ ਦ੍ਰਿਸ਼: ਇੱਕ ਸਧਾਰਣ CRM ਮੈਨੂ ਜਿਸਦੀ ਅਸਲ ਲਾਗੂਅੰਨ ਹੋਵੇ

ਇੱਕ ਅੰਦਰੂਨੀ CRM ਸੋਚੋ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਰੋਲ ਹਨ: Sales, Support, ਅਤੇ Admin. ਹਰ ਕੋਈ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ ਅਤੇ ਐਪ ਇੱਕ ਬਾਂਏ ਪਾਸੇ ਮੈਨੂ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਮੈਨੂ ਸਿਰਫ ਸੁਵਿਧਾ ਹੈ। ਅਸਲ ਸੁਰੱਖਿਆ ਉਹ ਹੈ ਜੋ ਸਰਵਰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਪਰਮੀਸ਼ਨ ਸੈੱਟ ਹੈ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦਾ ਹੈ:

• Leads: view, create, edit, delete, export
• Tickets: view, create, edit, assign
• Billing: view, edit
• Users: view, manage

UI ਪਹਿਲਾਂ ਬੈਕਐਂਡ ਤੋਂ ਵਰਤਮਾਨ ਯੂਜ਼ਰ ਦੀਆਂ ਆਗਿਆਵਾਂ ਮੰਗਦਾ ਹੈ (ਅਕਸਰ permission strings ਦੀ ਇੱਕ ਲਿਸਟ) ਨਾਲ ਨਾਲ ਬੁਨਿਆਦੀ ਸੰਦਰਭ ਜਿਵੇਂ user id ਅਤੇ team। ਮੈਨੂ ਉਸ ਤੋਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ billing.view ਨਹੀਂ ਹੈ ਤਾਂ ਤੁਸੀਂ Billing ਨਹੀਂ ਦੇਖੋਗੇ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ leads.export ਹੈ ਤਾਂ Leads ਸਕਰੀਨ 'ਤੇ Export ਬਟਨ ਦਿਖੇਗਾ। ਜੇ ਤੁਸੀਂ ਕੇਵਲ ਆਪਣੇ ਹੀ leads ਨੂੰ ਸੋਧ ਸਕਦੇ ਹੋ, Edit ਬਟਨ ਫਿਰ ਵੀ ਆ ਸਕਦਾ ਹੈ ਪਰ ਜਦੋਂ lead ਤੁਹਾਡਾ ਨਹੀਂ ਹੁੰਦਾ ਤਾਂ ਇਹ ਡਿਸੇਬਲ ਹੋਣਾ ਜਾਂ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

ਹੁਣ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ: ਹਰ ਐਕਸ਼ਨ ਐਂਡਪੋਇੰਟ ਉਹੀ ਨਿਯਮ ਲਗਾਉਂਦਾ ਹੈ।

ਉਦਾਹਰਣ: Sales leads ਬਣਾਉ ਸਕਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਪਣੇ leads ਸੋਧ ਸਕਦੇ ਹਨ। Support tickets ਵੇਖ ਸਕਦਾ ਹੈ ਅਤੇ assign ਕਰ ਸਕਦਾ ਹੈ, ਪਰ billing ਨੂੰ ਹਿਲਾ ਨਹੀਂ ਸਕਦਾ। Admin users ਅਤੇ billing ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਕੋਈ lead delete ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਬੈਕਐਂਡ ਜਾਂਚਦਾ ਹੈ:

1. ਕੀ ਯੂਜ਼ਰ ਕੋਲ leads.delete ਹੈ?
2. ਜੇ rule own-only ਹੈ, ਕੀ lead.owner_id == user.id?
3. ਜੇ lead locked ਹੈ (ਉਦਾਹਰਣ: ਪਹਿਲਾਂ ਹੀ invoiced), ਕੀ delete ਸਿਰਫ Admin ਲਈ ਰੋਕਿਆ ਗਿਆ ਹੈ?

ਚਾਹੇ Support ਯੂਜ਼ਰ ਹੱਥੋਂ delete endpoint ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਵੀ ਕਰੇ, ਉਹਨਾਂ ਨੂੰ forbidden response ਮਿਲੇਗਾ। ਲੁਕਿਆ ਹੋਇਆ ਮੈਨੂ ਕਦੇ ਵੀ ਸੁਰੱਖਿਆ ਨਹੀਂ ਸੀ—ਬੈਕਐਂਡ ਫੈਸਲਾ ਸੀ।

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਫੰਦੇ

ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਨਾਲ ਸਭ ਤੋਂ ਵੱਡੀ ਫੰਦੀ ਇਹ ਸੋਚਣਾ ਹੈ ਕਿ ਜਦੋਂ ਮੈਨੂ ਠੀਕ ਲੱਗਣ ਲੱਗਾ ਤਾਂ ਕੰਮ ਮੁਕੰਮਲ ਹੋ ਗਿਆ। ਬਟਨਾਂ ਨੂੰ ਲੁਕਾਉਣਾ ਭਟਕਾਅ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਖ਼ਤਰੇ ਨਹੀਂ ਘਟਾਉਂਦਾ।

ਅਕਸਰ ਆਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ:

• “Not visible” ਦਾ ਮਤਲਬ “not possible.” ਕੋਈ ਵੀ API ਸਿੱਧਾ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਪੁਰਾਣਾ URL ਵਰਤ ਸਕਦਾ ਹੈ, ਜਾਂ dev tools ਨਾਲ ਐਕ్షਨ ਕਰ ਸਕਦਾ ਹੈ। UI hiding ਨੂੰ ਸਹੂਲਤ ਸਮਝੋ, ਨਾ ਕਿ ਰੋਕ।
• ਪਰਮੀਸ਼ਨ ਸਿਰਫ UI ਵਿੱਚ ਚੈੱਕ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਫਰੰਟਐਂਡ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ record delete ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀ ਪਹਿਲਾਂ ਹੀ ਗੁਆ ਚੁਕੇ ਹੋ। ਬੈਕਐਂਡ ਹਰ ਸੰਰੱਖਿਤ ਐਕਸ਼ਨ ਲਈ ਆਖਰੀ ਜਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਸਭ ਕੁਝ "isAdmin" ਇੱਕ ਵੱਡੇ ਫਲੈਗ 'ਤੇ ਦੇਣਾ। ਇਹ ਤੇਜ਼ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਇਹ ਫੈਲਦਾ ਹੈ। ਜਲਦੀ ਹੀ ਹਰ ਛੋਟੀ ਛੋਟੀ ਛੂਟ ਲਈ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਐਕਸੇਸ ਨਿਯਮ ਨਹੀਂ ਸਮਝ ਸਕਦਾ।
• ਕਲਾਇੰਟ ਨੂੰ ਰੋਲ ਦੱਸਣ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ। ਕਦੇ ਵੀ ਬ੍ਰਾਉਜ਼ਰ ਤੋਂ ਆਈ role, isAdmin, ਜਾਂ permissions ਨੂੰ ਸੱਚ ਨਹੀਂ ਮੰਨੋ। ਆਪਣੀ ਪਛਾਣ session ਜਾਂ token ਤੋਂ ਹਾਸਲ ਕਰੋ, ਫਿਰ ਸਰਵਰ-ਸਾਈਡ ਤੇ roles ਅਤੇ permissions ਲੁੱਕਅੱਪ ਕਰੋ।
• ਪੜ੍ਹਨ ਵਾਲੀਆਂ ਪਰਮੀਸ਼ਨਾਂ ਨੂੰ ਭੁੱਲਣਾ। ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ writes (create, update, delete) 'ਤੇ ਧਿਆਨ ਦਿੰਦੀਆਂ ਹਨ, ਪਰ ਡੇਟਾ ਲੀਕ ਆਮ ਤੌਰ 'ਤੇ reads ਤੋਂ ਹੁੰਦੀ ਹੈ। customers listing, invoices ਵੇਖਣਾ, CSV export ਅਤੇ search ਆਮ ਤੌਰ 'ਤੇ ਚੈੱਕ ਲੋੜਦੇ ਹਨ।

ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ: ਤੁਸੀਂ Export leads menu ਆਈਟਮ non-managers ਲਈ ਲੁਕਾਉਂਦੇ ਹੋ। ਜੇ export endpoint ਵੀ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਕੋਈ ਵੀ ਯੂਜ਼ਰ ਜੋ ਬੇਨਤੀ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਕਾਪੀ ਕਰ ਲੈਂਦਾ ਹੈ (ਜਾਂ coworker ਤੋਂ) ਫਾਈਲ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ।

ਪ੍ਰੀ-ਲਾਂਚ ਜਾਂਚ ਸੂਚੀ

ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਲਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਅਖੀਰਲਾ ਪਾਸ ਕਰੋ ਜੋ ਉਹ ਚੀਜ਼ਾਂ ਵਰਤਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਕਰ ਸਕਦੇ ਹਨ, ਨਾਂ ਕਿ ਜੋ ਉਹ ਵੇਖਦੇ ਹਨ।

ਆਪਣੇ ਐਪ ਨੂੰ ਹਰ ਮੁੱਖ ਰੋਲ ਵਜੋਂ ਚਲਾਉ ਅਤੇ ਉਹੀ ਐਕਸ਼ਨਾਂ ਦੀ ਇੱਕੋ ਜਿਹੀ ਸੈੱਟ ਦੋਹਰਾਓ। ਇਹ UI ਵਿੱਚ ਵੀ ਕਰੋ ਅਤੇ API ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰਕੇ (ਜਾਂ browser dev tools) ਇਹ ਚੈੱਕ ਕਰੋ ਕਿ ਸਰਵਰ ਸੱਚ-ਸਰੋਤ ਹੈ।

ਚੈਕਲਿਸਟ:

• ਹਰ ਰਹਿਣ ਵਾਲੇ ਐਕਸ਼ਨ ਲਈ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇੱਕ ਸਰਵਰ-ਸਾਈਡ authorization check ਹੈ (ਮੈਨੂ ਬਣਾਉਂਦੇ ਸਮੇਂ ਹੀ ਨਹੀਂ).
• UI ਨੂੰ server-provided capabilities (ਉਦਾਹਰਣ: session ਤੋਂ can-list ਜਾਂ permission endpoint) ਤੋਂ actions render ਕਰਨ ਦਿਓ, role names ਤੋਂ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਓ।
• ਯਕੀਨੀ ਬਣਾਓ ਕਿ UI forbidden responses ਨੂੰ ਸਧਾਰਨ ਰੂਪ ਵਿੱਚ ਵਰਤਦਾ ਹੈ: ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ, ਪੇਜ਼ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਤੋੜਿਆ ਹੋਇਆ ਸਟੇਟ ਵਿੱਚ ਨਾ ਛੱਡੋ।
• ਰੋਲ ਅਤੇ ਪਰਮੀਸ਼ਨ ਬਦਲਾਅ ਦੀ ਜਾਂਚ ਕਰੋ। ਜਦੋਂ admin access ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਇਹ ਤੇਜ਼ ਅਤੇ ਪੇਚੀਦਗੀ-ਰਹਿਤ ਪ੍ਰਭਾਵ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ (token refresh, session invalidation, ਜਾਂ permission versioning)।
• ਪੈਸੇ, exports, deletes, ਅਤੇ admin ਸੈਟਿੰਗਜ਼ ਤੇ ਟੱਚ ਕਰਨ ਵਾਲੇ ਰੋਲ ਅਤੇ ਐਕਸ਼ਨਾਂ ਲਈ ਕੁਝ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਟੈਸਟ ਚਲਾਓ।

ਗੈਪਾਂ ਨੂੰ ਵੇਖਣ ਦਾ ਇੱਕ ਅਮਲੀ ਤਰੀਕਾ: ਇੱਕ "ਖਤਰਨਾਕ" ਬਟਨ (ਜਿਵੇਂ delete user, export CSV, change billing) ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ end-to-end trace ਕਰੋ। ਮੈਨੂ ਆਈਟਮ ਠੀਕ ਢੰਗ ਨਾਲ ਲੁਕਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, API unauthorized calls ਨੂੰ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ UI ਨੂੰ 403 ਮਿਲਣ 'ਤੇ gracefully recover ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਅਗਲੇ ਕਦਮ: ਬਿਨਾਂ ਸਲੋ ਹੋਏ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰੋ

ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਦਿਨ 1 'ਤੇ perfect access matrix ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹ ਕੁਝ ਐਕਸ਼ਨ ਚੁਣੋ ਜੋ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹਨ (view, create, edit, delete, export, manage users), ਉਨ੍ਹਾਂ ਨੂੰ ਮੌਜੂਦਾ ਰੋਲਾਂ ਨਾਲ ਮੈਪ ਕਰੋ, ਅਤੇ ਅੱਗੇ ਵਧੋ। ਜਦੋਂ ਨਵਾਂ ਫੀਚਰ ਆਵੇ, ਸਿਰਫ ਉਨ੍ਹਾਂ ਨਵੇਂ ਐਕਸ਼ਨਾਂ ਨੂੰ ਜੋੜੋ ਜੋ ਉਹ ਪੈਨਦਾ ਹੈ।

ਸਕਰੀਨਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ planning pass ਕਰੋ ਜੋ pages ਦੀ ਨਹੀਂ, actions ਦੀ ਲਿਸਟ ਬਣਾਵੇ। Invoices ਵਰਗਾ ਇੱਕ ਮੈਨੂ ਆਈਟਮ ਕਈ ਐਕਸ਼ਨਾਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ: view list, view details, create, refund, export. ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਲਿਖ ਕੇ ਰੱਖਣਾ UI ਅਤੇ ਬੈਕਐਂਡ ਦੋਹਾਂ ਨੂੰ ਸਾਫ ਕਰਦਾ ਹੈ ਅਤੇ ਆਮ ਗਲਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਕਿ ਪੂਰੇ ਪੇਜ਼ ਨੂੰ ਗੇਟ ਕੀਤਾ ਗਿਆ ਹੈ ਪਰ ਇਕ ਖ਼ਤਰਨਾਕ ਐਂਡਪੋਇੰਟ ਅਣਰੱਖਿਆਤ ਰਹਿੰਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ access rules ਨੂੰ refactor ਕਰੋ, ਇਸ ਨੂੰ ਕਿਸੇ ਹੋਰ risky ਚੇਂਜ ਵਾਂਗ treat ਕਰੋ: ਇੱਕ safety net ਰੱਖੋ। snapshots ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦਾ ਵੈਵਹਾਰ ਤੁਲਨਾ ਕਰਨ ਦੇਣਗੇ। ਜੇ ਕਿਸੇ ਰੋਲ ਨੇ ਥੱਪੜ-ਝੱਪੜ ਕਰਕੇ ਲੋੜੀਂਦੀ ਪਹੁੰਚ ਘਟਾ ਲਈ ਤਾਂ rollback production ਵਿੱਚ hot-fixing ਨਾਲੋਂ ਤੇਜ਼ ਹੈ।

ਸਧਾਰਨ release routine ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ:

• ਫੀਚਰ ਲਈ actions ਦੀ ਲਿਸਟ ਲਿਖੋ ਅਤੇ ਹਰ permission ਦਾ ਨਾਮ ਰੱਖੋ।
• ਪਹਿਲਾਂ ਬੈਕਐਂਡ ਚੈਕ ਜੋੜੋ, ਫਿਰ UI visibility ਨੂੰ ਉਹੀ permissions ਨਾਲ ਵਾਇਰ ਕਰੋ।
• ਹਰ risky action ਲਈ ਇੱਕ allowed role ਅਤੇ ਇੱਕ denied role ਦੀ ਜਾਂਚ ਕਰੋ।
• denied attempts ਨੂੰ ਲੌਗ ਕਰੋ (ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਛੱਡ ਕੇ) ਤਾਂ ਕਿ ਤੁਸੀਂ ਗੈਪ ਪਛਾਣ ਸਕੋ।
• ਰੋਲਆਊਟ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲਓ ਤਾਂ ਕਿ ਜੇ ਲੋੜ ਹੋਵੇ ਤੁਸੀਂ ਤੁਰੰਤ rollback ਕਰ ਸਕੋ।

ਜੇ ਤੁਸੀਂ ਕੁਝ ਐਪ ਚੈਟ-ਅਧਾਰਿਤ ਪਲੇਟਫਾਰਮ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai (koder.ai), ਇਹੀ ਢਾਂਚਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: permissions ਅਤੇ policies ਨੂੰ ਇੱਕ ਵਾਰ ਪਰਿਭਾਸ਼ਿਤ ਰੱਖੋ, UI ਨੂੰ ਸਰਵਰ ਤੋਂ capabilities ਪੜ੍ਹਨ ਦਿਓ, ਅਤੇ ਬੈਕਐਂਡ ਚੈੱਕ ਹਰ ਹੈਂਡਲਰ ਵਿੱਚ non-optional ਰੱਖੋ।