13 ਸਤੰ 2025·8 ਮਿੰਟ
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਨੈਵੀਗੇਸ਼ਨ ਮੈਨੂ ਜੋ ਫਿਰ ਵੀ ਐਕਸੈਸ ਲਾਗੂ ਕਰਦੇ ਹਨ
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ UX ਲਈ ਸਾਫ਼ਤਾ ਲਿਆਉਂਦੇ ਹਨ, ਪਰ ਸੁਰੱਖਿਆ ਹਮੇਸ਼ਾਂ ਬੈਕਐਂਡ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਰੋਲ, ਪਾਲਿਸੀਆਂ ਅਤੇ ਸੁਰੱਖਿਅਤ UI ਛੁਪਾਉਣ ਲਈ ਸਧਾਰਨ ਰੁਝਾਨ ਵੇਖੋ।
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ UX ਲਈ ਸਾਫ਼ਤਾ ਲਿਆਉਂਦੇ ਹਨ, ਪਰ ਸੁਰੱਖਿਆ ਹਮੇਸ਼ਾਂ ਬੈਕਐਂਡ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਰੋਲ, ਪਾਲਿਸੀਆਂ ਅਤੇ ਸੁਰੱਖਿਅਤ UI ਛੁਪਾਉਣ ਲਈ ਸਧਾਰਨ ਰੁਝਾਨ ਵੇਖੋ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “ਬਟਨ ਲੁਕਾ ਦਿਓ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਮਤਲਬ ਹੁੰਦੇ ਹਨ: ਉਹਨਾਂ ਉਪਭੋਗਤਿਆਂ ਲਈ ਗੁੰਝਲ ਘਟਾਉਣਾ ਜੋ ਫੀਚਰ ਵਰਤ ਨਹੀਂ ਸਕਦੇ, ਜਾਂ ਗਲਤ ਵਰਤੋਂ ਰੋਕਣਾ। ਫਰੰਟਐਂਡ 'ਤੇ ਸਿਰਫ ਪਹਿਲਾ ਮਕਸਦ ਹਕੀਕਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ।
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਨੈਵੀਗੇਸ਼ਨ ਮੇਨੂ ਮੁੱਖ ਤੌਰ ਤੇ ਇੱਕ UX ਟੂਲ ਹਨ। ਉਹ ਕਿਸੇ ਨੂੰ ਐਪ ਖੋਲ੍ਹਣ ਤੇ ਤੁਰੰਤ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਹਰ ਦੂਜੇ ਕਲਿੱਕ 'ਤੇ “Access denied” ਸਕਰਿਨ ਦੇ ਸਾਹਮਣੇ ਆਉਣ ਦੇ। ਇਹ ਸਮਝ ਨੂੰ ਵੀ ਘਟਾਉਂਦੇ ਹਨ ਜਿਵੇਂ “ਮੈਂ ਇਨਵਾਇਸ ਕਿੱਥੇ ਅਨੁਮੋਦਿਤ ਕਰਾਂ?” ਜਾਂ “ਇਹ ਪੇਜ਼ ਕਿਉਂ ਐਰਰ ਕਰ ਰਿਹਾ ਹੈ?”
UI ਨੂੰ ਲੁਕਾਉਣਾ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹੈ। ਇਹ ਸਪਸ਼ਟਤਾ ਹੈ।
ਇੱਕ ਜਿਗਿਆਸੂ ਸਹਿਕਰਮੀ ਫਿਰ ਵੀ ਕਰ ਸਕਦਾ ਹੈ:
ਸੋ ਅਸਲ ਸਮੱਸਿਆ ਜੋ ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੇਨੂ ਹੱਲ ਕਰਦੇ ਹਨ ਉਹ ਇਮਾਨਦਾਰ ਮਾਰਗਦਰਸ਼ਨ ਹੈ। ਇਹ ਇੰਟਰਫੇਸ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਕੰਮ, ਰੋਲ ਅਤੇ ਸੰਦਰਭ ਨਾਲ ਸੰਗਤ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕੁਝ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।
ਇੱਕ ਵਧੀਆ ਅੰਤਿਮ ਹਾਲਤ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ:
ਉਦਾਹਰਣ: ਇੱਕ ਛੋਟੇ CRM ਵਿੱਚ, Sales Rep ਨੂੰ Leads ਅਤੇ Tasks ਵੇਖਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ User Management ਨਹੀਂ. ਜੇ ਉਹ ਫਿਰ ਵੀ user management URL ਪੇਸਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਪੇਜ਼ ਨੂੰ fail closed ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਕਿਸੇ ਵੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਯੂਜ਼ਰਾਂ ਦੀ ਸੂਚੀ ਦਿਖਾਉਣ ਜਾਂ ਰੋਲ ਬਦਲਣ ਤੋਂ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ।
ਵਿਜ਼ਿਬਿਲਟੀ ਉਹ ਹੈ ਜੋ ਇੰਟਰਫੇਸ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਥਰਾਈਜ਼ੇਸ਼ਨ ਉਹ ਹੈ ਜੋ ਸਿਸਟਮ ਸੱਚ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕਰੇਗਾ ਜਦੋਂ ਬੇਨਤੀ ਸਰਵਰ ਤੇ ਪਹੁੰਚੇਗੀ।
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੇਨੂ ਨੂੰਨੂੰ ਭੁਲਾਵਟ ਘਟਾਉਂਦੇ ਹਨ। ਜੇ ਕਿਸੇ ਨੂੰ ਕਦੇ ਵੀ Billing ਜਾਂ Admin ਦੇਖਣ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੈ, ਉਹਨਾਂ ਆਈਟਮਾਂ ਨੂੰ ਲੁਕਾਉਣਾ ਐਪ ਨੂੰ ਸਾਫ ਰੱਖਦਾ ਹੈ ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਘਟਾਉਂਦਾ ਹੈ। ਪਰ ਬਟਨ ਨੂੰ ਲੁਕਾਉਣਾ ਲੌਕ ਨਹੀਂ ਹੈ। ਲੋਕ ਫਿਰ ਵੀ dev tools, ਪੁਰਾਣੇ ਬੁੱਕਮਾਰਕ ਜਾਂ ਨਕਲ ਕੀਤੀ ਗਈ ਬੇਨਤੀ ਨਾਲ underlying endpoint ਨੂੰ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਨ।
ਇੱਕ ਵਿਹਾਰਕ ਨਿਯਮ: ਇਹ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤਜੁਰਬੇ ਦੀ ਇਛਾ ਰੱਖਦੇ ਹੋ, ਫਿਰ ਨਿਯਮ ਨੂੰ ਬੈਕਐਂਡ 'ਤੇ ਲਾਗੂ ਕਰੋ ਭਾਵੇਂ UI ਕੁਝ ਵੀ ਕਰੇ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਐਕਸ਼ਨ ਨੂੰ ਪ੍ਰਸਤੁਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੋ, ਤਿੰਨ ਪੈਟਰਨ ਵੱਧਤਰ ਕੇਸ ਕਵਰ ਕਰਦੇ ਹਨ:
"ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਪਰ ਸੋਧ ਨਹੀਂ ਕਰ ਸਕਦੇ" ਆਮ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਮੁਤਾਬਿਕ ਹੈ। ਇਹ ਦੋ ਪਰਮੀਸ਼ਨਾਂ ਵਜੋਂ ਦਿੱਖੋ: ਇੱਕ ਡਾਟਾ ਪੜ੍ਹਨ ਲਈ ਅਤੇ ਇੱਕ ਸੋਧਣ ਲਈ। ਮੈਨੂ ਵਿੱਚ, ਤੁਸੀਂ 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 ਤੋਂ ਘੱਟ ਇਨਵਾਇਸ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹੋ" ਹੱਲ ਕਰਦੇ ਹੋ। ਪਾਲਿਸੀਆਂ ਤੁਹਾਨੂੰ ਲਗਭਗ-ਡੁਪਲਿਕੇਟ ਪਰਮੀਸ਼ਨਾਂ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ ਇੱਕ ਸ਼ਰਤ 'ਤੇ ਅੰਤਰਿਤ ਹੁੰਦੀਆਂ।
ਇੱਕ ਬਣਾਉਣਯੋਗ ਲੇਅਰਿੰਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਖਦੀ ਹੈ:
ਨਾਂਕਰਨਕਤਾ ਉਮੀਦ ਤੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਜੇ UI ਕਹਿੰਦਾ ਹੈ Export Customers ਪਰ API download_all_clients_v2 ਵਰਤਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਆਖਿਰਕਾਰ ਗਲਤ ਚੀਜ਼ ਛੁਪ ਸਕਦੀ ਹੈ ਜਾਂ ਸਹੀ ਚੀਜ਼ ਰੋਕੀ ਜਾ ਸਕਦੀ ਹੈ। ਨਾਂ ਮਨੁੱਖੀ, ਲਗਾਤਾਰ ਅਤੇ ਫਰੰਟਏਂਡ/ਬੈਕਐਂਡ ਵਿਚ ਸਾਂਝੇ ਰੱਖੋ:
noun.verb (ਜਾਂ resource.action) ਯੂਜ਼ ਕਰੋਉਦਾਹਰਣ: CRM ਵਿੱਚ Sales ਰੋਲ lead.create ਅਤੇ lead.update ਸ਼ਾਮਿਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਪਾਲਿਸੀ update ਹਦ ਤੱਕ ਸਿਰਫ ਉਹਨਾਂ ਲਈ ਸੀਮਿਤ ਕਰਦੀ ਹੈ ਜੋ ਲੀਡ ਦੇ ਮਾਲਕ ਹਨ। ਇਸ ਨਾਲ ਤੁਹਾਡਾ ਮੈਨੂ ਸਾਫ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਬੈਕਐਂਡ ਕਠੋਰ ਰਹਿੰਦਾ ਹੈ।
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਚੰਗਾ ਅਨੁਭਵ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਗੁੰਜਲ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀ ਨਾਲ ਹੋਣ ਵਾਲੇ ਕਲਿੱਕ ਰੋਕਦੇ ਹਨ। ਪਰ ਉਹ ਤਾਂ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਬੈਕਐਂਡ ਅਧਿਕਾਰ ਵਿਚ ਕਾਰਜਕਾਰੀ ਰਹੇ। UI ਨੂੰ ਇੱਕ ਇਸ਼ਾਰਾ ਸਮਝੋ, ਅਤੇ ਸਰਵਰ ਨੂੰ ਨਿਆਯਧੀਸ਼।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇਹ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਪਰੋਟੈਕਟ ਕਰ ਰਹੇ ਹੋ—ਪੇਜ਼ਾਂ ਨਹੀਂ, ਪਰ ਐਕਸ਼ਨ। View customer list different ਹੈ export customers ਅਤੇ delete customer ਤੋਂ। ਇਹੀ ਬੈਕਬੋਨ ਹੈ ਉਹਨਾਂ ਮੈਨੂਆਂ ਲਈ ਜੋ ਸੁਰੱਖਿਆ ਥਿਏਟਰ ਵਿੱਚ ਨਹੀਂ ਬਦਲਣੀਆਂ।
canEditCustomers, canDeleteCustomers, canExport ਜਾਂ ਇੱਕ ਸੰਕੁਚਿਤ permission strings ਦੀ ਲਿਸਟ ਰਿਟਰਨ ਕਰੋ। ਇਸਨੂੰ ਮਿਨੀਮਲ ਰੱਖੋ।ਇੱਕ ਛੋਟਾ ਪਰ ਮਹੱਤਵਪੂਰਨ ਨਿਯਮ: ਕਦੇ ਵੀ ਕਲਾਇੰਟ-ਪ੍ਰੋਵਾਈਡ ਕੀਤੇ 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 ਵਰਗੀਆਂ ਪੂਰੀਆਂ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਛੁਪਾਉਣਾ ਇੱਕ-ਇਕ ਚੈਕ ਲਗਾਉਣ ਨਾਲੋਂ ਵਧੀਆ ਹੈ। ਇਹ ਗਲਤੀਆਂ ਘੱਟ ਕਰਦਾ ਹੈ।
ਉਹ ਆਈਟਮ ਲੁਕਾਓ ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸਨੂੰ ਵਰਤਣ ਦੀ ਆਗਿਆ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਡਿਸੇਬਲ ਕਰੋ ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਲ ਪਰਮੀਸ਼ਨ ਹੈ ਪਰ ਮੌਜੂਦਾ ਸੰਦਰਭ ਘੱਟ ਹੈ।
ਉਦਾਹਰਣ: Delete contact ਉਥੇ ਤੱਕ ਡਿਸੇਬਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦ ਤੱਕ ਕੋਈ contact ਚੁਣਿਆ ਨਾ ਹੋਵੇ। ਉਹੀ ਪਰਮੀਸ਼ਨ, ਸਿਰਫ ਸੰਦਰਭ ਘੱਟ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਡਿਸੇਬਲ ਕਰਦੇ ਹੋ, ਕੰਟਰੋਲ ਕੋਲ ਇੱਕ ਛੋਟਾ “ਕਿਉਂ” ਸੁਨੇਹਾ (tooltip, helper text ਜਾਂ inline note) ਦਿਓ: Select a contact to delete.
ਇਕ ਨਿਯਮ-ਸੈਟ ਜੋ ਟਿਕਦਾ ਹੈ:
ਮੈਨੂ ਆਈਟਮ ਲੁਕਾਉਣਾ ਲੋਕਾਂ ਨੂੰ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ। ਬੈਕਐਂਡ ਨੂੰ ਆਖਰੀ ਜਜ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਬੇਨਤੀਆਂ ਨੂੰ ਰੀਪਲੇ, ਸੋਧਿਆ ਜਾਂ UI ਤੋਂ ਬਾਹਰ ਟਰਿੱਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵਧੀਆ ਨਿਯਮ: ਹਰ ਐਕਸ਼ਨ ਜੋ ਡਾਟਾ ਬਦਲਦਾ ਹੈ ਉਸ 'ਤੇ ਇੱਕ authorization check ਹੋਵੇ, ਇਕ ਥਾਂ, ਜੋ ਹਰ ਬੇਨਤੀ ਤੋਂ ਗੁਜ਼ਰਦੀ ਹੈ। ਇਹ middleware, handler wrapper, ਜਾਂ ਇੱਕ policy layer ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਪਹੁੰਚ ਚੁਣੋ ਤੇ ਉਸ 'ਤੇ ਟਿਕੋ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਰਾਹ ਛੱਡ ਦਿਓਗੇ।
Authorization ਨੂੰ input validation ਤੋਂ ਵੱਖ ਰਹਿਣ ਦਿਓ। ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ, “ਕੀ ਇਹ ਯੂਜ਼ਰ ਇਹ ਕਰ ਸਕਦਾ ਹੈ?”, ਫਿਰ payload validate ਕਰੋ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ validate ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਵੇਰਵੇ ਲੀਕ ਕਰ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ ਕਿ ਕਿਹੜੇ record IDs ਮੌਜੂਦ ਹਨ) ਕਿਸੇ ਨੂੰ ਜਿਸਨੂੰ ਇਹ ਜਾਣਨਾ ਨਹੀਂ ਚਾਹੀਦਾ।
ਇੱਕ ਪੈਟਰਨ ਜੋ ਸਕੇਲ ਕਰਦਾ ਹੈ:
Can(user, "invoice.delete", invoice)).Status codes ਇਸ ਤਰ੍ਹਾਂ ਵਰਤੋ ਜੋ frontend ਅਤੇ logs ਦੋਹਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋਣ:
401 Unauthorized ਜਦੋਂ ਕਾਲਰ ਲੌਗਇਨ ਨਹੀਂ ਹੈ.403 Forbidden ਜਦੋਂ ਲੌਗਇਨ ਹੋ ਚੁੱਕੇ ਪਰ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ.404 Not Found ਨੂੰ disguise ਵਜੋਂ ਵਰਤਣ ਵਿੱਚ ਸਾਵਧਾਨ ਰਹੋ। ਇਹ ਕਿਸੇ ਰਿਸੋਰਸ ਦੇ ਹੋਣ ਦੀ ਖੁਦਾਈ ਨੂ ਲੋਕਾਂ ਤੋਂ ਛੁਪਾਉਣ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਬੇਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਮਿਲਾਉਂਦੇ ਹੋ ਤਾਂ ਡਿਬੱਗਿੰਗ ਮੁਸ਼ਕਲ ਹੋ ਜਾਦੀ ਹੈ। ਹਰ ਰਿਸੋਰਸ ਟਾਈਪ ਲਈ ਇਕ ਰੋਲ ਨਿਯਮ ਚੁਣੋ।
ਸਭ ਤੋਂ ਅਹਮ: ਇਹ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਜੋ authorization ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਉਹ ਬਟਨ ਕਲਿੱਕ, ਮੋਬਾਈਲ ਐਪ, ਸਕ੍ਰਿਪਟ ਜਾਂ ਡਾਇਰੈਕਟ API ਕਾਲ—ਸਭੇ ਲਈ ਇੱਕੋ ਜਿਹਾ ਚੱਲੇ।
ਅੰਤ ਵਿੱਚ, denied ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਡੀਬੱਗ ਅਤੇ ਆਡਿਟ ਲਈ ਲੌਗ ਕਰੋ, ਪਰ ਲੌਗ ਸੇਫ਼ ਰੱਖੋ। ਕਿਸ ਨੇ, ਕਿਹੜਾ ਐਕਸ਼ਨ, ਅਤੇ ਕਿਹੜਾ ਉੱਚ-ਸਤਰ ਰਿਸੋਰਸ ਟਾਈਪ ਲੌਗ ਕਰੋ। ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡ, ਪੂਰੇ payloads ਜਾਂ secrets ਤੋਂ ਬਚੋ।
ਅਧਿਕਤਰ ਪਰਮੀਸ਼ਨ ਬੱਗ ਉਨ੍ਹਾਂ ਰਾਹਾਂ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਤੁਹਾਡੇ ਮੈਨੂ ਨੇ ਕਦੇ ਸੋਚੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਸੀ ਲਈ ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਰਾਹਾਂ ਲਈ ਵੀ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਉਹਨਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹਨ।
ਜੇ ਮੈਨੂ ਕਿਸੇ ਰੋਲ ਲਈ Billing ਨੂੰ ਲੁਕਾਂਦਾ ਹੈ ਤਾਂ ਵੀ ਯੂਜ਼ਰ ਸੇਵ ਕੀਤੀ URL ਪੇਸਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਬ੍ਰਾਉਜ਼ਰ ਇਤਿਹਾਸ ਤੋਂ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ। ਹਰ ਪੇਜ਼ ਲੋਡ ਨੂੰ ਤਾਜ਼ਾ ਬੇਨਤੀ ਵਾਂਗ ਸੋਚੋ: ਵਰਤਮਾਨ ਯੂਜ਼ਰ ਦੀਆਂ ਪਰਮੀਸ਼ਨਾਂ ਲੋਡ ਕਰੋ, ਅਤੇ ਸਕਰੀਨ ਖ਼ੁਦ ਵੀ ਸਕਾਰਾਤਮਕ ਰੂਪ ਵਿੱਚ ਪ੍ਰੋਟੈਕਟ ਕੀਤੇ ਹੋਏ ਡਾਟੇ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰੇ ਜੇ ਪਰਮੀਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਕ ਦੋਸਤਾਨਾ “ਤੁਹਾਨੂੰ ਪਹੁੰਚ ਨਹੀਂ” ਸੁਨੇਹਾ ਠੀਕ ਹੈ, ਪਰ ਅਸਲ ਰੱਖਿਆ ਇਹ ਹੈ ਕਿ ਬੈਕਐਂਡ ਕੁਝ ਵੀ ਵਾਪਸ ਨਾ ਕਰੇ।
ਕੋਈ ਵੀ ਤੁਹਾਡੀ 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 ਨਾ ਕਰੋ।
ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਾਉਣ ਵਾਲੇ ਪੰਜ ਟੈਸਟ:
ਇੱਕ ਅੰਦਰੂਨੀ CRM ਸੋਚੋ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਰੋਲ ਹਨ: Sales, Support, ਅਤੇ Admin. ਹਰ ਕੋਈ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ ਅਤੇ ਐਪ ਇੱਕ ਬਾਂਏ ਪਾਸੇ ਮੈਨੂ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਮੈਨੂ ਸਿਰਫ ਸੁਵਿਧਾ ਹੈ। ਅਸਲ ਸੁਰੱਖਿਆ ਉਹ ਹੈ ਜੋ ਸਰਵਰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ।
ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਪਰਮੀਸ਼ਨ ਸੈੱਟ ਹੈ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦਾ ਹੈ:
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 ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਬੈਕਐਂਡ ਜਾਂਚਦਾ ਹੈ:
leads.delete ਹੈ?lead.owner_id == user.id?ਚਾਹੇ Support ਯੂਜ਼ਰ ਹੱਥੋਂ delete endpoint ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਵੀ ਕਰੇ, ਉਹਨਾਂ ਨੂੰ forbidden response ਮਿਲੇਗਾ। ਲੁਕਿਆ ਹੋਇਆ ਮੈਨੂ ਕਦੇ ਵੀ ਸੁਰੱਖਿਆ ਨਹੀਂ ਸੀ—ਬੈਕਐਂਡ ਫੈਸਲਾ ਸੀ।
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਨਾਲ ਸਭ ਤੋਂ ਵੱਡੀ ਫੰਦੀ ਇਹ ਸੋਚਣਾ ਹੈ ਕਿ ਜਦੋਂ ਮੈਨੂ ਠੀਕ ਲੱਗਣ ਲੱਗਾ ਤਾਂ ਕੰਮ ਮੁਕੰਮਲ ਹੋ ਗਿਆ। ਬਟਨਾਂ ਨੂੰ ਲੁਕਾਉਣਾ ਭਟਕਾਅ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਖ਼ਤਰੇ ਨਹੀਂ ਘਟਾਉਂਦਾ।
ਅਕਸਰ ਆਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ:
role, isAdmin, ਜਾਂ permissions ਨੂੰ ਸੱਚ ਨਹੀਂ ਮੰਨੋ। ਆਪਣੀ ਪਛਾਣ session ਜਾਂ token ਤੋਂ ਹਾਸਲ ਕਰੋ, ਫਿਰ ਸਰਵਰ-ਸਾਈਡ ਤੇ roles ਅਤੇ permissions ਲੁੱਕਅੱਪ ਕਰੋ।ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ: ਤੁਸੀਂ Export leads menu ਆਈਟਮ non-managers ਲਈ ਲੁਕਾਉਂਦੇ ਹੋ। ਜੇ export endpoint ਵੀ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਕੋਈ ਵੀ ਯੂਜ਼ਰ ਜੋ ਬੇਨਤੀ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਕਾਪੀ ਕਰ ਲੈਂਦਾ ਹੈ (ਜਾਂ coworker ਤੋਂ) ਫਾਈਲ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ।
ਪਰਮੀਸ਼ਨ-ਅਨੁਕੂਲ ਮੈਨੂ ਲਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਅਖੀਰਲਾ ਪਾਸ ਕਰੋ ਜੋ ਉਹ ਚੀਜ਼ਾਂ ਵਰਤਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਕਰ ਸਕਦੇ ਹਨ, ਨਾਂ ਕਿ ਜੋ ਉਹ ਵੇਖਦੇ ਹਨ।
ਆਪਣੇ ਐਪ ਨੂੰ ਹਰ ਮੁੱਖ ਰੋਲ ਵਜੋਂ ਚਲਾਉ ਅਤੇ ਉਹੀ ਐਕਸ਼ਨਾਂ ਦੀ ਇੱਕੋ ਜਿਹੀ ਸੈੱਟ ਦੋਹਰਾਓ। ਇਹ UI ਵਿੱਚ ਵੀ ਕਰੋ ਅਤੇ API ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰਕੇ (ਜਾਂ browser dev tools) ਇਹ ਚੈੱਕ ਕਰੋ ਕਿ ਸਰਵਰ ਸੱਚ-ਸਰੋਤ ਹੈ।
ਚੈਕਲਿਸਟ:
ਗੈਪਾਂ ਨੂੰ ਵੇਖਣ ਦਾ ਇੱਕ ਅਮਲੀ ਤਰੀਕਾ: ਇੱਕ "ਖਤਰਨਾਕ" ਬਟਨ (ਜਿਵੇਂ 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 ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ:
ਜੇ ਤੁਸੀਂ ਕੁਝ ਐਪ ਚੈਟ-ਅਧਾਰਿਤ ਪਲੇਟਫਾਰਮ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai (koder.ai), ਇਹੀ ਢਾਂਚਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: permissions ਅਤੇ policies ਨੂੰ ਇੱਕ ਵਾਰ ਪਰਿਭਾਸ਼ਿਤ ਰੱਖੋ, UI ਨੂੰ ਸਰਵਰ ਤੋਂ capabilities ਪੜ੍ਹਨ ਦਿਓ, ਅਤੇ ਬੈਕਐਂਡ ਚੈੱਕ ਹਰ ਹੈਂਡਲਰ ਵਿੱਚ non-optional ਰੱਖੋ।
Permission-aware menus ਇੱਕ ਵੱਡੇ ਹਿੱਸੇ ਲਈ ਸਪਸ਼ਟਤਾ ਦਿੰਦੀਆਂ ਹਨ, ਸੁਰੱਖਿਆ ਨਹੀਂ। ਉਹ ਯੂਜ਼ਰਾਂ ਨੂੰ ਇਹ ਵੇਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦੇ ਹਨ, ਬੇਕਾਰ ਕਲਿੱਕ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ “ਮੈਨੂੰ ਇਹ ਕਿਉਂ ਦਿਖ ਰਿਹਾ ਹੈ?” ਵਾਲੇ ਸਹਾਇਤਾ ਸਵਾਲਾਂ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਸੁਰੱਖਿਆ ਨੂੰ ਹਮੇਸ਼ਾ ਬੈਕਐਂਡ ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਡੀਪ ਲਿੰਕ, ਪੁਰਾਣੀ ਬੁੱਕਮਾਰਕ ਜਾਂ API ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ ਭਾਵੇਂ UI ਕੀ ਦਿਖਾ ਰਿਹਾ ਹੋਵੇ।
ਜਦੋਂ ਕੋਈ ਫੀਚਰ ਕਿਸੇ ਰੋਲ ਲਈ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਅਣਖੋਜਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਉਸ ਨੂੰ ਛੁਪਾਓ।
ਆਪਣੇ ਸੰਦਰਭ ਵਿੱਚ ਯੂਜ਼ਰ ਕੋਲ ਜੇ ਹਾਲੇ ਅਧਿਕਾਰ ਹਨ ਪਰ ਉਹ ਕੁਝ ਕਰ ਨਹੀਂ ਸਕਦੇ (ਜਿਵੇਂ ਕਿ ਕੋਈ ਰਿਕਾਰਡ ਚੁਣਿਆ ਨਹੀਂ ਗਿਆ ਜਾਂ ਡੇਟਾ ਲੋਡ ਹੋ ਰਿਹਾ ਹੈ), ਤਾਂ ਡਿਸੇਬਲ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਡਿਸੇਬਲ ਕਰਦੇ ਹੋ ਤਾਂ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਕਾਰਨ ਦਿਖਾਓ ਤਾਂ ਜੋ ਇਹ ਵਿਗੜਿਆ ਹੋਇਆ ਨਾ ਲੱਗੇ।
ਕਿਉਂਕਿ ਵਿਜਿਬਿਲਟੀ = Authorization ਨਹੀਂ। ਇੱਕ ਯੂਜ਼ਰ URL ਪੇਸਟ ਕਰ ਸਕਦਾ ਹੈ, ਬੁੱਕਮਾਰਕ ਰੀ-ਯੂਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਤੁਹਾਡੀ API ਨੂੰ UI ਬਾਹਰੋਂ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
UI ਨੂੰ ਰਾਹ-ਦਿਖਾਉਣ ਵਜੋਂ ਦਾ ਸਮਝੋ। ਹਰ ਸੰਵੇਦਨਸ਼ੀਲ ਬੇਨਤੀ ਲਈ ਅੰਤਿਮ ਫੈਸਲਾ ਬੈਕਐਂਡ ਕਰਦਾ ਹੈ।
ਸਰਵਰ-ਸਾਈਡ ਤੋਂ ਲੋੜੀਂਦੇ "capabilities" ਜਿਵੇਂ ਕਿ ਛੋਟੇ boolean ਫਲੈਟ (ਉਦਾਹਰਣ: canEditCustomers, canDeleteCustomers) ਜਾਂ ਪਰਮੀਸ਼ਨ ਸਟਰਿੰਗਜ਼ ਲੌਗਿਨ ਜਾਂ ਸੈਸ਼ਨ ਰੀਫ੍ਰੈਸ਼ ਮਗਰੋਂ ਰਿਟਰਨ ਕਰੋ।
UI ਨੂੰ ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ ਮੈਨੂ ਅਤੇ ਬਟਨ ਰੇਂਡਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਕਦੇ ਵੀ ਬ੍ਰਾਉਜ਼ਰ ਤੋਂ ਆ ਰਹੇ isAdmin ਵਰਗੇ ਕਲਾਇਂਟ-ਪ੍ਰੋਵਾਈਡ ਕੀਤੇ ਹੋਏ ਫਲੈਗਾਂ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ; ਪਰਮੀਸ਼ਨਾਂ ਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਪਰਖੋ।
ਕਿਰਿਆਵਾਂ (actions) ਦੀ ਇੱਕ ਇਨਵੈਂਟਰੀ ਬਣਾਓ—ਪੇਜ਼ਾਂ ਦੀ ਨਹੀਂ। ਹਰ ਫੀਚਰ ਲਈ read, create, update, delete, export, invite ਆਦਿ ਵੱਖ-ਵੱਖ ਕਰੋ।
ਫਿਰ ਹਰ ਐਕਸ਼ਨ ਨੂੰ ਬੈਕਐਂਡ ਹੈਂਡਲਰ (ਜਾਂ ਮਿਡਲਵੇਅਰ) ਵਿੱਚ ਲਾਗੂ ਕਰੋ ਅਤੇ ਉਹੀ ਨਾਂਮ UI ਨਾਲ ਸਾਂਝਾ ਕਰੋ ਤਾਂ ਕਿ ਦੋਹਾਂ ਸਿੱਧੇ ਰਹਿਣ।
ਅਮਲੀ ਤੌਰ 'ਤੇ: ਰੋਲ ਬੱਕਟ ਹਨ, ਪਰਮੀਸ਼ਨ ਹੀ ਸੱਚ ਦਾ ਸਰੋਤ। ਛੋਟੀਆਂ, ਐਕਸ਼ਨ-ਆਧਾਰਿਤ ਪਰਮੀਸ਼ਨਾਂ (ਉਦਾਹਰਣ: invoice.create) ਨੂੰ ਰੋਲਾਂ ਨਾਲ ਜੋੜੋ।
ਜੇ ਰੋਲ ਬਹੁਤ ਜਿਆਦਾ ਵਭਿੰਨ ਹੋ ਰਹੇ ਹਨ ਤਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਪਾਲਿਸੀਆਂ ਵਿੱਚ ਰੱਖੋ (ਉਦਾਹਰਣ: ਹੀਟ-ਕਿਸੇ-ਰਿਕਾਰਡ-ਮਾਤਰ), ਨਾ ਕਿ ਨਵੇਂ ਰੋਲ ਬਣਾਉ।
ਸੰਦੇਸ਼ਾਤਮਕ ਨਿਯਮਾਂ ਜਿਵੇਂ “ਆਪਣੇ ਹੀ ਰਿਕਾਰਡ ਸੋਧ ਸਕਦੇ ਹੋ” ਜਾਂ “$5,000 ਤੱਕ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹੋ” ਲਈ ਪਾਲਿਸੀਆਂ ਵਰਤੋ। ਇਹ ਪਰਮੀਸ਼ਨ ਲਿਸਟ ਨੂੰ ਸਥਿਰ ਰੱਖਦੀਆਂ ਹਨ ਤੇ ਹਕੀਕਤੀ ਰੁਕਾਵਟਾਂ ਨੂੰ ਪ੍ਰਕਟ ਕਰਦੀਆਂ ਹਨ।
ਪਾਲਿਸੀ ਨੂੰ ਬੈਕਐਂਡ ਤੇ ਸਰੋਤ ਸੰਦਰਭ (owner ID, org ID) ਦੇ ਨਾਲ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਭ ਨਹੀਂ। ਜਦੋਂ ਰੀਡ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦਿੰਦੇ ਹਨ ਜਾਂ ਨਾਰਮਲ ਫਿਲਟਰਿੰਗ ਨੂੰ ਬਾਇਪਾਸ ਕਰਦੇ ਹਨ (ਜਿਵੇਂ exports, audit logs, salary data), ਉਹਨਾਂ ਨੂੰ ਵੀ ਚੈੱਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਛੋਟਾ ਬੇਸਲਾਈਨ: ਸਾਰੇ writes ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਚੈੱਕ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ; ਸੰਵੇਦਨਸ਼ੀਲ reads ਨੂੰ ਵੀ ਚੈੱਕ ਕਰੋ।
Bulk endpoints अक्सर ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇੱਕ ਕਾਲ ਨਾਲ ਕਈ ਰਿਕਾਰਡ ਬਦਲੇ ਜਾਂਦੇ ਹਨ।
ਬਲਕ ਐਕਸ਼ਨ ਖੁਦ ਚੈੱਕ ਕਰੋ ਅਤੇ ਇਹ ਵੀ ਵੈਰੀਫਾਈ ਕਰੋ ਕਿ ਕਿਸ ਰੋਲ ਲਈ ਕਿਹੜੇ fields ਨੂੰ ਸੋਧਣ ਦੀ ਆਗਿਆ ਹੈ, ਤਾਂ ਕਿ ਛੁਪੇ ਹੋਏ ਫੀਲਡਾਂ ਨੂੰ ਅਣਚਾਹੇ ਤੌਰ 'ਤੇ ਸੋਧਿਆ ਨਾ ਜਾ ਸਕੇ।
ਮੰਨੋ ਕਿ ਪਰਮੀਸ਼ਨ ਸੈਸ਼ਨ ਦੌਰਾਨ ਵੀ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਜਦੋਂ API 401 ਜਾਂ 403 ਵਾਪਸ ਕਰੇ, UI ਨੂੰ capabilities ਰੀਫ੍ਰੈਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਮੈਨੂ ਅਪਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਾਫ ਸੁਨੇਹਾ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਮੈਨੂ ਨੂੰ ਅਜਿਹੇ ਢੰਗ ਨਾਲ ਕੈਸ਼ ਨਾ ਕਰੋ ਜੋ ਸ਼ੇਅਰ ਕੀਤੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਲੀਕ ਕਰ ਸਕੇ; ਜੇ ਕੈਸ਼ ਕਰੋ ਤਾਂ ਉਹਨੂੰ user ID ਨਾਲ ਕੀ ਕੀਤੇ ਰੱਖੋ।