ਸੌਂਪੀ ਗਈ ਪਹੁੰਚ
ਕਿਸੇ ਡਿਵੈਲਪਰ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ, ਬਿਲਿੰਗ ਆਪਣੇ ਲੇਖਾਕਾਰ ਨੂੰ ਸੌਂਪੋ, ਕਿਸੇ ਗਾਹਕ ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਸਾਈਟਾਂ ਲਈ ਸਿਰਫ਼-ਦੇਖਣ (read-only) ਦੀ ਪਹੁੰਚ ਦਿਓ, ਜਾਂ ਸਾਡੀ ਸਹਾਇਤਾ ਟੀਮ ਨੂੰ ਕਿਸੇ ਸਮੱਸਿਆ ਦੀ ਜਾਂਚ ਕਰਨ ਦਿਓ। ਹਰੇਕ ਮਨਜ਼ੂਰੀ ਪਰਿਭਾਸ਼ਿਤ ਇਜਾਜ਼ਤਾਂ ਵਾਲੀ ਇੱਕ ਭੂਮਿਕਾ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿਸੇ ਸੰਸਥਾ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ, ਡਾਟਾਬੇਸ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਿਰਫ਼-ਜੋੜਨ ਵਾਲੇ (append-only) ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਦਰਜ ਹੁੰਦੀ ਹੈ।
ਇੱਕੋ ਲੌਗਇਨ ਸਾਂਝਾ ਕਰਨ ਨਾਲ ਖਾਤੇ ਦੀ ਪਹੁੰਚ ਵਿੱਚ ਗੜਬੜ ਹੁੰਦੀ ਹੈ। Zinn Digital® 'ਤੇ ਹਰੇਕ ਵਿਅਕਤੀ ਦੀ ਆਪਣੀ ਪਛਾਣ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਪਹੁੰਚ ਇੱਕ ਮੈਂਬਰਸ਼ਿਪ ਹੈ — ਇੱਕ ਉਪਭੋਗਤਾ, ਇੱਕ ਸੰਸਥਾ, ਅਤੇ ਇੱਕ ਭੂਮਿਕਾ — ਜਿਸਨੂੰ ਤੁਸੀਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਦੇ ਸਕਦੇ ਹੋ, ਬਦਲ ਸਕਦੇ ਹੋ ਜਾਂ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ।
ਹਰੇਕ ਸਹਿਯੋਗੀ ਸਾਡੀ ਪਛਾਣ ਪਰਤ, Keycloak ਰਾਹੀਂ ਆਪਣੇ ਵਜੋਂ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਤੁਹਾਡਾ ਪਾਸਵਰਡ ਟਾਈਪ ਨਹੀਂ ਕਰਦਾ, ਕੋਈ ਵੀ ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਸਾਂਝਾ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਹਟਾਉਣਾ ਪਾਸਵਰਡ ਰੋਟੇਸ਼ਨ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਭੱਜ-ਦੌੜ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਇੱਕ ਕਾਰਵਾਈ ਹੈ ਕਿ ਇਸਨੂੰ ਹੋਰ ਕੌਣ ਜਾਣਦਾ ਸੀ।
ਖਾਤੇ ਲੜੀਵਾਰ ਹੁੰਦੇ ਹਨ — ਇੱਕ ਰੀਸੈਲਰ ਸੰਸਥਾ ਕਲਾਇੰਟ ਸੰਸਥਾਵਾਂ ਨੂੰ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਸੰਸਥਾਵਾਂ ਸਾਈਟਾਂ ਨੂੰ ਰੱਖਦੀਆਂ ਹਨ। ਇੱਕ ਮੈਂਬਰਸ਼ਿਪ ਇੱਕ ਸੰਸਥਾ ਅਤੇ ਇਸਦੇ ਅਧੀਨ ਸਭ ਕੁਝ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਆਪਣੇ ਦੂਜੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਕਦੇ ਵੀ ਪ੍ਰਗਟ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਏਜੰਸੀ ਕਲਾਇੰਟ ਨੂੰ ਉਹਨਾਂ ਦੀ ਆਪਣੀ ਸੰਸਥਾ ਦਾ ਕੰਟਰੋਲ ਸੌਂਪ ਸਕਦੇ ਹੋ।
ਟੈਨੈਂਟ ਵੱਖਰੇਵਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਕੋਈ ਅਜਿਹਾ ਫਿਲਟਰ ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਬੱਗ ਛੱਡ ਸਕੇ। Postgres ਰੋਅ-ਲੈਵਲ ਸੁਰੱਖਿਆ (Row-Level Security) ਹਰੇਕ ਪੁੱਛਗਿੱਛ ਨੂੰ ਕਾਲਰ ਦੇ ਸੰਗਠਨ ਸਬ-ਟ੍ਰੀ ਤੱਕ ਸੀਮਤ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰਲੀ ਬੇਨਤੀ ਕੋਲ ਵਾਪਸ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ।
ਆਪਣੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਕਿਸੇ ਸੰਸਥਾ ਜਾਂ ਸਾਈਟ ਲਈ ਬੇਨਤੀ ਕਰੋ ਅਤੇ API ਇਜਾਜ਼ਤ ਸੰਬੰਧੀ ਗਲਤੀ ਦੀ ਬਜਾਏ ਇੱਕ ਸਧਾਰਨ 'ਨਹੀਂ ਮਿਲਿਆ' (not-found) ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਜਾਜ਼ਤ ਦੀ ਗਲਤੀ ਇਹ ਪੁਸ਼ਟੀ ਕਰੇਗੀ ਕਿ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹੈ; 'ਨਹੀਂ ਮਿਲਿਆ' ਬਾਹਰਲੇ ਵਿਅਕਤੀ ਨੂੰ ਕੁਝ ਵੀ ਨਹੀਂ ਦੱਸਦਾ।
ਇਜਾਜ਼ਤਾਂ ਬਾਰੀਕ ਕੁੰਜੀਆਂ ਹਨ — ਮੌਡਿਊਲ ਅਤੇ ਕਾਰਵਾਈ, ਜਿਵੇਂ sites.restart ਜਾਂ billing.refund — ਅਤੇ ਭੂਮਿਕਾਵਾਂ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦੀਆਂ ਹਨ। ਚਾਰ ਭੂਮਿਕਾਵਾਂ ਉਹਨਾਂ ਢਾਂਚਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਅਸਲ ਟੀਮਾਂ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਸਾਡੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਡੇਟਾ ਹੈ, ਕੋਡ ਵਿੱਚ ਦੱਬਿਆ ਤਰਕ ਨਹੀਂ।
ਪੂਰਾ ਨਿਯੰਤਰਣ: ਅਧੀਨ ਸੰਸਥਾਵਾਂ ਬਣਾਓ, ਮੈਂਬਰਾਂ ਨੂੰ ਸੱਦਾ ਦਿਓ ਅਤੇ ਹਟਾਓ, ਭੂਮਿਕਾਵਾਂ ਬਦਲੋ, API ਕੁੰਜੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ, ਸਾਈਟਾਂ ਬਣਾਓ, ਮੁੜ ਚਾਲੂ ਕਰੋ, ਪਰਜ ਕਰੋ, ਮੁਅੱਤਲ ਕਰੋ ਅਤੇ ਮਿਟਾਓ, ਬਿਲਿੰਗ ਅਤੇ ਚਲਾਨ ਚਲਾਓ, ਟਿਕਟਾਂ ਦਰਜ ਕਰੋ ਅਤੇ ਆਡਿਟ ਲੌਗ ਪੜ੍ਹੋ। ਉਹ ਭੂਮਿਕਾ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਲਈ ਰੱਖਦੇ ਹੋ।
ਸੰਸਥਾ, ਇਸਦੇ ਮੈਂਬਰਾਂ ਅਤੇ ਪਲਾਨ ਕੈਟਾਲਾਗ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਇਨਵੌਇਸਾਂ, ਭੁਗਤਾਨ ਵਿਧੀਆਂ ਅਤੇ ਖਰਚਿਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਇੱਕ ਵੀ ਸਾਈਟ ਨੂੰ ਬਣਾਉਣ, ਬਦਲਣ ਜਾਂ ਮਿਟਾਉਣ ਦੀ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ — ਬਿਲਕੁਲ ਉਹੀ ਰੂਪ ਜੋ ਇੱਕ ਬਾਹਰੀ ਬੁੱਕਕੀਪਰ ਕੋਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਾਈਟਾਂ ਦੇਖਦਾ ਅਤੇ ਬਣਾਉਂਦਾ ਹੈ, ਸੇਵਾਵਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਕੈਸ਼ੇ ਸਾਫ਼ ਕਰਦਾ ਹੈ, API ਕੁੰਜੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ ਅਤੇ ਟਿਕਟਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਾਣਬੁੱਝ ਕੇ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ: ਬਿਲਿੰਗ, ਇਨਵੌਇਸ, ਭੁਗਤਾਨ ਵਿਧੀਆਂ, ਮੈਂਬਰ ਪ੍ਰਬੰਧਨ, ਸਾਈਟ ਮੁਅੱਤਲੀ ਅਤੇ ਸਾਈਟ ਮਿਟਾਉਣਾ। ਕੋਈ ਠੇਕੇਦਾਰ ਤੁਹਾਡੇ ਤੋਂ ਬਿਲ ਲਏ ਬਿਨਾਂ ਜਾਂ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਨਸ਼ਟ ਕੀਤੇ ਬਿਨਾਂ ਨਿਰਮਾਣ ਕਰ ਸਕਦਾ ਹੈ।
ਸੰਸਥਾ, ਇਸਦੇ ਮੈਂਬਰਾਂ, ਇਸਦੀਆਂ ਸਾਈਟਾਂ, ਇਸਦੇ ਬਿਲਿੰਗ, ਪਲਾਨ ਕੈਟਾਲਾਗ, ਟਿਕਟਾਂ, ਅਨੁਵਾਦ ਸਥਿਤੀ ਅਤੇ ਆਡਿਟ ਲੌਗ ਨੂੰ ਵੇਖ ਸਕਦਾ ਹੈ — ਅਤੇ ਇਸ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਬਦਲ ਨਹੀਂ ਸਕਦਾ। ਅਜਿਹੇ ਗਾਹਕ ਲਈ ਸਹੀ ਅਧਿਕਾਰ ਜੋ ਦਿੱਖ ਚਾਹੁੰਦਾ ਹੈ, ਕੋਈ ਆਡੀਟਰ, ਜਾਂ ਕੋਈ ਹਿੱਸੇਦਾਰ ਜਿਸਨੂੰ ਸਿਰਫ਼ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ।
ਪਹੁੰਚ ਸੌਂਪਣਾ ਉਦੋਂ ਹੀ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਉਹ ਖਾਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸੌਂਪਦੇ ਹੋ, ਉਹਨਾਂ 'ਤੇ ਕਬਜ਼ਾ ਕਰਨਾ ਔਖਾ ਹੋਵੇ। ਖਾਤੇ 'ਤੇ ਹਰੇਕ ਵਿਅਕਤੀ ਲਈ, ਹਰ ਸਤ੍ਹਾ 'ਤੇ Keycloak ਰਾਹੀਂ ਪ੍ਰਮਾਣੀਕਰਨ ਚੱਲਦਾ ਹੈ।
ਸਹਾਇਤਾ ਕਾਰਜ ਲਈ ਕਈ ਵਾਰ ਤੁਹਾਡੇ ਖਾਤੇ ਦੇ ਅੰਦਰ ਦੇਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਹ ਪਹੁੰਚ ਹੋਰ ਸਭ ਕੁਝ ਵਾਂਗ ਉਸੇ ਇਜਾਜ਼ਤ ਮਾਡਲ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਹੁੰਦੀ ਹੈ — ਕਰਮਚਾਰੀ ਸਿਰਫ਼ ਇੱਕ ਕਰਮਚਾਰੀ ਸੰਸਥਾ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਜੋ ਸੀਮਤ ਇਜਾਜ਼ਤਾਂ ਵਾਲੇ ਵਿਭਾਗਾਂ ਵਿੱਚ ਸੰਗਠਿਤ ਹੁੰਦੇ ਹਨ।
ਸਟਾਫ਼ ਨੂੰ ਸਪੋਰਟ, ਬਿਲਿੰਗ ਅਤੇ ਫਾਇਨਾਂਸ, ਅਬਿਊਜ਼ ਅਤੇ ਟਰੱਸਟ-ਐਂਡ-ਸੇਫਟੀ, ਸੇਲਜ਼, ਆਨਬੋਰਡਿੰਗ, ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਓਪਸ, ਮਾਰਕੀਟਿੰਗ, ਅਤੇ ਮੈਨੇਜਮੈਂਟ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਹਰੇਕ ਭੂਮਿਕਾ ਖਾਸ ਮੌਡਿਊਲ ਅਤੇ ਕਾਰਵਾਈਆਂ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਇੱਕ ਏਜੰਟ ਐਡਮਿਨ ਕੰਸੋਲ ਦਾ ਉਹ ਹਿੱਸਾ ਵੇਖੇ ਜਿਸਦੀ ਉਸਦੇ ਕੰਮ ਲਈ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਦਾ ਨਹੀਂ।
Support Agent ਭੂਮਿਕਾ ਬਿਲਕੁਲ ਇਹ ਅਧਿਕਾਰ ਦਿੰਦੀ ਹੈ: ਗਾਹਕਾਂ ਨੂੰ ਦੇਖਣਾ, ਟਿਕਟਾਂ ਨੂੰ ਦੇਖਣਾ ਅਤੇ ਜਵਾਬ ਦੇਣਾ, ਸਾਈਟਾਂ ਨੂੰ ਦੇਖਣਾ, ਸਾਈਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਅਤੇ ਇਸਦੇ ਕੈਸ਼ੇ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ। ਇਸ ਵਿੱਚ ਕੋਈ ਬਿਲਿੰਗ ਕੌਨਫਿਗਰੇਸ਼ਨ, ਰਿਫੰਡ, ਪਲਾਨ ਸੰਪਾਦਨ ਅਤੇ ਫਲੀਟ ਪ੍ਰਬੰਧਨ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ। ਇੱਕ ਏਜੰਟ ਵੱਲੋਂ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਸੁਧਾਰਾਤਮਕ ਕਾਰਵਾਈ ਭੂਮਿਕਾ ਦੁਆਰਾ ਸੀਮਤ ਹੁੰਦੀ ਹੈ, ਨੇਕ ਇਰਾਦਿਆਂ ਦੁਆਰਾ ਨਹੀਂ।
customer.impersonate ਇਜਾਜ਼ਤ Manager ਭੂਮਿਕਾ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ — ਇਹ ਸਿਰਫ਼ Super Admin ਕੋਲ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਸੈਸ਼ਨ ਤੁਹਾਡੇ ਵੱਲੋਂ ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਇੱਕ ਲਗਾਤਾਰ ਰਹਿਣ ਵਾਲਾ ਇਮਪਰਸਨੇਸ਼ਨ ਬੈਨਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਕਦੇ ਵੀ ਅਸਪਸ਼ਟ ਨਾ ਰਹੇ ਕਿ ਕਾਰਵਾਈ ਕੌਣ ਕਰ ਰਿਹਾ ਹੈ।
ਹਰੇਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਕਾਰਵਾਈ ਇੱਕ ਸਿਰਫ਼-ਜੋੜਨ ਵਾਲੇ (append-only) ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਜੋ ਕਰਤਾ, ਕਾਰਵਾਈ, ਟੀਚਾ, ਸਹਾਇਕ ਮੈਟਾਡੇਟਾ, IP ਪਤਾ ਅਤੇ ਸਮਾਂ-ਮੋਹਰ ਦਰਜ ਕਰਦੀ ਹੈ — ਜੋ ਉਤਪਾਦਨ ਵਿੱਚ ਸਮੇਂ ਅਨੁਸਾਰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਮਾਲਕ ਅਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਮੈਂਬਰ ਆਪਣੀ ਸੰਸਥਾ ਦਾ ਲੌਗ ਖ਼ੁਦ ਪੜ੍ਹ ਸਕਦੇ ਹਨ।
ਸਟਾਫ਼ ਦੀਆਂ ਸੰਵੇਦਨਸ਼ੀਲ ਅਤੇ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਵਧੇਰੇ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਦੋ ਵਿਅਕਤੀਆਂ ਦੀ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਨਵੇਂ ਵਿਭਾਗ ਅਤੇ ਭੂਮਿਕਾਵਾਂ ਕੋਡ ਬਦਲਾਅ ਦੀ ਬਜਾਏ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦਾ ਮਾਮਲਾ ਹਨ।
ਸਕ੍ਰਿਪਟਾਂ, CI ਪਾਈਪਲਾਈਨਾਂ, CLI, Terraform ਪ੍ਰਦਾਤਾ ਅਤੇ AI ਏਜੰਟ ਸਾਰੇ ਲੋਕਾਂ ਵਾਂਗ ਹੀ ਉਸੇ ਅਨੁਮਤੀ ਮਾਡਲ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੇ ਹਨ — ਕੋਈ ਸਾਂਝੇ ਕੀਤੇ ਮਨੁੱਖੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਹੀਂ, ਬਿਲਡ ਵਿੱਚ ਚਿਪਕਾਏ ਗਏ ਕੋਈ ਲੰਬੇ ਸਮੇਂ ਦੇ ਭੇਤ ਨਹੀਂ।
ਕੁੰਜੀਆਂ ਕਿਸੇ ਸੰਸਥਾ ਨਾਲ ਸਬੰਧਤ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕੋ ਜਿਹੀਆਂ RBAC ਇਜਾਜ਼ਤਾਂ ਨਾਲ ਜੁੜੇ ਵਿਸਤ੍ਰਿਤ ਦਾਇਰੇ ਰੱਖਦੀਆਂ ਹਨ — ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ, ਬਿਲਿੰਗ, ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ। ਕਿਸੇ ਮੈਂਬਰ ਦੇ ਪੂਰੇ ਖਾਤੇ ਦੀ ਬਜਾਏ ਪਾਈਪਲਾਈਨ ਨੂੰ ਲੋੜੀਂਦਾ ਸੀਮਤ ਦਾਇਰਾ ਪ੍ਰਦਾਨ ਕਰੋ।
ਟੈਸਟ-ਮੋਡ ਅਤੇ ਲਾਈਵ-ਮੋਡ ਕੁੰਜੀਆਂ ਵੱਖਰੀਆਂ ਹਨ, ਇਸ ਲਈ ਵਿਕਾਸ ਅਧੀਨ ਕੋਈ ਏਕੀਕਰਨ ਗਲਤੀ ਨਾਲ ਜਾਂ ਕਾਪੀ ਕੀਤੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੁਆਰਾ ਉਤਪਾਦਨ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਅਸੀਂ ਗੁਪਤ ਜਾਣਕਾਰੀ ਦਾ ਇੱਕ SHA-256 ਹੈਸ਼ ਅਤੇ ਇੱਕ ਲੁੱਕਅੱਪ ਅਗੇਤਰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ — ਕਦੇ ਵੀ ਮੂਲ ਕੁੰਜੀ ਨੂੰ ਨਹੀਂ। ਤੁਸੀਂ ਕੁੰਜੀ ਨੂੰ ਇਸਦੀ ਸਿਰਜਣਾ ਦੇ ਸਮੇਂ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਦੇਖਦੇ ਹੋ। ਹਰੇਕ ਕੁੰਜੀ ਇਹ ਟਰੈਕ ਕਰਦੀ ਹੈ ਕਿ ਇਸਨੂੰ ਆਖਰੀ ਵਾਰ ਕਦੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ ਅਤੇ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਵਿੱਚ ਵਿਘਨ ਪਾਏ ਬਿਨਾਂ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਸਾਡਾ MCP ਸਰਵਰ ਕਿਸੇ ਵੀ MCP-ਸਮਰੱਥ ਏਜੰਟ ਨੂੰ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਵਿੱਚ ਤੁਹਾਡੀ ਹੋਸਟਿੰਗ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ OAuth 2.1 ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸੰਸਥਾ ਅਤੇ RBAC ਭੂਮਿਕਾ ਤੱਕ ਸੀਮਿਤ ਹੈ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਤੀ-ਟੂਲ ਰੱਦ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਟੋਕਨ, ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ 'ਤੇ ਪੁਸ਼ਟੀਕਰਨ, ਖਰਚ ਸੀਮਾਵਾਂ ਅਤੇ ਪੂਰੀ ਆਡਿਟ ਲੌਗਿੰਗ ਸ਼ਾਮਲ ਹਨ।
ਖਾਤਾ ਪਹੁੰਚ ਅਤੇ ਸਰਵਰ ਪਹੁੰਚ ਵੱਖ-ਵੱਖ ਮਸਲੇ ਹਨ। ਸਾਈਟ-ਪੱਧਰੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਘੱਟੋ-ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਨਾਲ ਜਾਰੀ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਵੱਖਰੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਇੱਕ ਸਹਿਯੋਗੀ ਦਾ ਸ਼ੈੱਲ ਸਿਰਫ਼ ਇੱਕ ਸਾਈਟ ਦਾ ਸ਼ੈੱਲ ਹੋਵੇ।
ਇੱਕ ਇਕੱਲਾ ਓਪਰੇਟਰ ਇੱਕ ਸਿੰਗਲ ਸੰਸਥਾ ਅਤੇ ਇੱਕ ਮਾਲਕ ਮੈਂਬਰਸ਼ਿਪ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕੋਈ ਠੇਕੇਦਾਰ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਆਉਂਦਾ ਹੈ ਤਾਂ ਉਹ ਇੱਕ ਡਿਵੈਲਪਰ ਭੂਮਿਕਾ ਜੋੜਦਾ ਹੈ। ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਮੈਂਬਰਸ਼ਿਪ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦਾ ਸਾਈਨ-ਇਨ ਤੁਰੰਤ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ — ਬਦਲਣ ਲਈ ਕੋਈ ਸਾਂਝਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪਿੱਛੇ ਨਹੀਂ ਬਚਦਾ।
ਇੱਕ ਏਜੰਸੀ ਸੰਗਠਨ ਟ੍ਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਕਲਾਇੰਟ ਨੂੰ ਆਪਣੀ ਚਾਈਲਡ ਸੰਸਥਾ ਮਿਲਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਸ ਕਲਾਇੰਟ ਦੀਆਂ ਸਾਈਟਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਲੋਕਾਂ ਨੂੰ ਉੱਥੇ ਮੈਂਬਰਸ਼ਿਪ ਮਿਲਦੀ ਹੈ — ਦਿੱਖ ਚਾਹੁਣ ਵਾਲੇ ਹਿੱਸੇਦਾਰ ਲਈ ਕੇਵਲ-ਪੜ੍ਹਨਯੋਗ, ਸਵੈ-ਸੇਵਾ ਚਾਹੁਣ ਵਾਲੇ ਕਲਾਇੰਟ ਲਈ ਮਾਲਕ ਦਾ ਦਰਜਾ। ਤੁਹਾਡੇ ਕਰਮਚਾਰੀ ਟ੍ਰੀ ਵਿੱਚ ਉੱਚੇ ਪੱਧਰ 'ਤੇ ਮੈਂਬਰਸ਼ਿਪ ਰੱਖਦੇ ਹਨ ਅਤੇ ਪੋਰਟਫੋਲੀਓ ਦੇਖਦੇ ਹਨ; ਕਲਾਇੰਟ ਕੇਵਲ ਆਪਣੀ ਹੀ ਸ਼ਾਖਾ ਵੇਖਦਾ ਹੈ, ਅਤੇ Row-Level Security ਉਹ ਹੈ ਜੋ ਇਸਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਵਾਅਦੇ ਦੀ ਬਜਾਏ ਹਕੀਕਤ ਬਣਾਉਂਦੀ ਹੈ।
ਇੱਕ ਰੀਸੈਲਰ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇੱਕ ਪੱਧਰ ਹੋਰ ਉੱਪਰ: ਇੱਕ ਰੀਸੈਲਰ ਸੰਸਥਾ ਗਾਹਕ ਸੰਸਥਾਵਾਂ ਨੂੰ ਰੱਖਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਦੇ ਆਪਣੇ ਮੈਂਬਰ, ਬਿਲਿੰਗ ਵਿਊ ਅਤੇ ਸਾਈਟਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਹੀ ਮੂਲ ਢਾਂਚਾ ਸਬ-ਖਾਤਿਆਂ, ਏਜੰਸੀ ਟੀਮਾਂ ਅਤੇ ਰੀਸੈਲਰ ਲੜੀਵਾਰ ਪ੍ਰਬੰਧਾਂ ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਦਾ ਹੈ — ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਲਈ ਵੀ ਕੋਈ ਵੱਖਰਾ ਜਾਂ ਕਮਜ਼ੋਰ ਤੰਤਰ ਨਹੀਂ ਹੈ।
ਬਿਨਾਂ ਕਾਰਡ ਦੇ 14-ਦਿਨਾਂ ਦੇ ਟ੍ਰਾਇਲ 'ਤੇ ਸਭ ਕੁਝ ਉਪਲਬਧ ਹੈ। ਭੁਗਤਾਨ ਵੇਰਵਿਆਂ ਤੋਂ ਬਿਨਾਂ ਸਾਈਨ ਅੱਪ ਕਰੋ, ਕਿਸੇ ਸਹਿਕਰਮੀ ਨੂੰ ਸੱਦਾ ਦਿਓ, ਦੇਖੋ ਕਿ ਹਰੇਕ ਭੂਮਿਕਾ ਕੀ ਐਕਸੈਸ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਅਤੇ ਆਪਣਾ ਆਡਿਟ ਲੌਗ ਦੁਬਾਰਾ ਪੜ੍ਹੋ।
ਅੱਜ ਇੱਕ ਮੈਂਬਰਸ਼ਿਪ ਕਿਸੇ ਸੰਸਥਾ ਅਤੇ ਟ੍ਰੀ ਵਿੱਚ ਇਸਦੇ ਅਧੀਨ ਸਭ ਕੁਝ ਵਿੱਚ ਆਪਣੀ ਭੂਮਿਕਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਸਾਈਟ ਸੈੱਟਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸੰਸਥਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਹੈ — ਉਹਨਾਂ ਸਾਈਟਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਆਪਣੀ ਅਧੀਨ ਸੰਸਥਾ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਉੱਥੇ ਪ੍ਰਦਾਨ ਕਰੋ। ਇਹ ਏਜੰਸੀਆਂ ਅਤੇ ਮੁੜ-ਵਿਕਰੇਤਾਵਾਂ ਲਈ ਇੱਕ ਸਾਫ਼ ਮਾਡਲ ਹੈ, ਜਿੱਥੇ ਹਰੇਕ ਗਾਹਕ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀ ਵੱਖਰੀ ਹੱਦ ਚਾਹੁੰਦਾ ਹੈ। ਪ੍ਰਤੀ-ਮੈਂਬਰਸ਼ਿਪ ਸਰੋਤ ਸਕੋਪਿੰਗ, ਇੱਕ ਸੰਸਥਾ ਦੇ ਅੰਦਰ ਨਿਰਧਾਰਤ ਸਾਈਟਾਂ ਲਈ ਇੱਕ ਸਿੰਗਲ ਮੈਂਬਰਸ਼ਿਪ ਨੂੰ ਪਿੰਨ ਕਰਨਾ, ਇੱਕ ਯੋਜਨਾਬੱਧ ਸੁਧਾਰ ਹੈ ਨਾ ਕਿ ਕੁਝ ਅਜਿਹਾ ਜੋ ਹੁਣ ਉਪਲਬਧ ਹੈ।
Developer ਭੂਮਿਕਾ ਕੋਲ ਸਾਈਟ ਮਿਟਾਉਣ ਜਾਂ ਸਾਈਟ ਮੁਅੱਤਲ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਹੁੰਦਾ — ਉਹ ਕੁੰਜੀਆਂ Owner ਭੂਮਿਕਾ ਕੋਲ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਸਾਈਟਾਂ ਦੇਖਣ ਅਤੇ ਬਣਾਉਣ, ਸੇਵਾਵਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ, ਕੈਸ਼ ਸਾਫ਼ ਕਰਨ, API ਕੁੰਜੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਅਤੇ ਟਿਕਟਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ push-to-live ਇਜਾਜ਼ਤਾਂ ਵੀ Developer ਗ੍ਰਾਂਟ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਉਤਪਾਦਨ (ਪ੍ਰੋਡਕਸ਼ਨ) ਵਿੱਚ ਭੇਜਣ ਦਾ ਅਧਿਕਾਰ ਖਾਤਾ ਮਾਲਕ ਕੋਲ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਸਟੇਜਿੰਗ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਨਿਰਮਾਣ ਕਾਰਜ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਲਾਈਵ ਸਾਈਟ ਤੋਂ ਬਾਹਰ ਹੋਵੇ।
ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਟਾਫ ਦੀ ਭੂਮਿਕਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰੇਕ ਭੂਮਿਕਾ ਇਜਾਜ਼ਤ ਕੁੰਜੀਆਂ ਦਾ ਇੱਕ ਸੀਮਤ ਸਮੂਹ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ Support Agent ਤੁਹਾਡੇ ਖਾਤੇ ਅਤੇ ਸਾਈਟਾਂ ਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੀਆਂ ਟਿਕਟਾਂ ਨੂੰ ਦੇਖ ਅਤੇ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਇੱਕ ਸਾਈਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਦੇ ਕੈਸ਼ੇ ਨੂੰ ਸਾਫ਼ ਕਰ ਸਕਦਾ ਹੈ — ਅਤੇ ਬਿਲਿੰਗ ਸੰਰਚਨਾ, ਰਿਫੰਡ, ਪਲਾਨ ਜਾਂ ਫਲੀਟ ਨੂੰ ਛੂਹ ਨਹੀਂ ਸਕਦਾ। ਇੱਕ ਗਾਹਕ ਵਜੋਂ ਸਾਈਨ ਇਨ ਕਰਨਾ ਇੱਕ ਵੱਖਰੀ ਇਜਾਜ਼ਤ ਹੈ ਜੋ ਸਿਰਫ਼ Super Admin ਕੋਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਡੈਸ਼ਬੋਰਡ ਇੱਕ ਨਿਰੰਤਰ ਰੂਪ ਧਾਰਨ (impersonation) ਬੈਨਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਹਰੇਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਾਰਵਾਈ ਨੂੰ ਆਡੀਟਰ, ਕਾਰਵਾਈ, ਨਿਸ਼ਾਨਾ, IP ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਦੇ ਨਾਲ ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਆਪਣੀ ਸੰਸਥਾ ਦਾ ਲੌਗ ਖੁਦ ਪੜ੍ਹ ਸਕਦੇ ਹੋ।
ਮੈਂਬਰਸ਼ਿਪ ਹਟਾਓ ਅਤੇ ਉਸ ਸੰਸਥਾ ਤੱਕ ਉਹਨਾਂ ਦੀ ਪਹੁੰਚ ਖ਼ਤਮ ਹੋ ਜਾਵੇਗੀ — ਉਹਨਾਂ ਕੋਲ ਅਜੇ ਵੀ ਆਪਣੀ ਪਛਾਣ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਖਾਤੇ ਵਿੱਚ ਕੋਈ ਭੂਮਿਕਾ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਲਈ ਕੋਈ ਅਧਿਕਾਰ ਨਹੀਂ ਹਨ। API ਕੁੰਜੀਆਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਵਿੱਚ ਵਿਘਨ ਪਾਏ ਬਿਨਾਂ ਇੱਕ ਪਾਈਪਲਾਈਨ ਕੁੰਜੀ ਨੂੰ ਕੱਟਿਆ ਜਾ ਸਕੇ। ਜੇਕਰ ਤੁਸੀਂ SAML ਸਿੰਗਲ ਸਾਈਨ-ਆਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਡੀਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਸਾਈਨ-ਇਨ ਨੂੰ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਸੰਭਾਲਦੀ ਹੈ। ਸਾਈਟ-ਪੱਧਰ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਿਵੇਂ ਕਿ SSH ਕੁੰਜੀਆਂ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਰੱਦ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਹਟਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਖ਼ੁਦ ਆਡਿਟ-ਲੌਗ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਨਹੀਂ — ਪਰ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਕਿਉਂ। API ਕੁੰਜੀਆਂ ਸੰਸਥਾ ਨਾਲ ਸਬੰਧਤ ਹੁੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਕਿਸੇ ਵਿਅਕਤੀਗਤ ਮੈਂਬਰ ਨਾਲ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਵਿਸ਼ੇਸ਼ ਦਾਇਰੇ ਹੁੰਦੇ ਹਨ ਜੋ ਇੱਕੋ ਇਜਾਜ਼ਤ ਸੂਚੀ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਲਈ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਕੁੰਜੀ ਸੌਂਪਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਉਸ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਸੀਮਤ ਦਾਇਰੇ ਵਾਲੀ ਕੁੰਜੀ ਬਣਾਉਂਦੇ ਹੋ ਜਿਸਦੀ ਉਸ ਕੰਮ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕੰਮ ਖ਼ਤਮ ਹੋਣ 'ਤੇ ਉਸ ਕੁੰਜੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦੇ ਹੋ। ਗੁਪਤ ਜਾਣਕਾਰੀ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਹੈਸ਼ ਹੀ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰੇਕ ਕੁੰਜੀ ਇਹ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ ਕਿ ਇਸਦੀ ਆਖਰੀ ਵਾਰ ਵਰਤੋਂ ਕਦੋਂ ਕੀਤੀ ਗਈ ਸੀ ਤਾਂ ਜੋ ਨਾ ਵਰਤੀਆਂ ਗਈਆਂ ਕੁੰਜੀਆਂ ਨੂੰ ਲੱਭਣਾ ਅਤੇ ਹਟਾਉਣਾ ਆਸਾਨ ਹੋਵੇ।
ਹਾਂ। ਸਾਡਾ MCP ਸਰਵਰ OAuth 2.1 ਨਾਲ ਏਜੰਟਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੀ ਸੰਸਥਾ ਅਤੇ ਤੁਹਾਡੀ RBAC ਭੂਮਿਕਾ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ, ਪ੍ਰਤੀ-ਟੂਲ ਰੱਦ ਕਰਨ ਯੋਗ ਟੋਕਨਾਂ ਦੇ ਨਾਲ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਪੂਰੀ ਪਹੁੰਚ ਦੇਣ ਦੀ ਬਜਾਏ ਇੱਕ ਖਾਸ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰੋ। ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਖਰਚ ਦੀਆਂ ਸੀਮਾਵਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਹਰੇਕ ਕਾਰਵਾਈ ਮਨੁੱਖੀ ਗਤੀਵਿਧੀ ਵਾਂਗ ਹੀ ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਦਰਜ ਹੁੰਦੀ ਹੈ।
Postgres Row-Level Security ਡਾਟਾਬੇਸ ਵਿੱਚ ਹੀ ਕਾਲਰ ਦੇ ਸੰਗਠਨ ਸਬ-ਟ੍ਰੀ ਤੱਕ ਪੁੱਛਗਿੱਛਾਂ ਦਾ ਦਾਇਰਾ ਸੀਮਤ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰੀ ਫਿਲਟਰ ਇਕੱਲੀ ਰੱਖਿਆ ਲਾਈਨ ਦੀ ਬਜਾਏ ਡੂੰਘਾਈ ਨਾਲ ਰੱਖਿਆ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਦਾਇਰੇ ਤੋਂ ਬਾਹਰਲੇ ਰਿਕਾਰਡਾਂ ਲਈ ਬੇਨਤੀਆਂ ਇਜਾਜ਼ਤ ਗਲਤੀ ਦੀ ਬਜਾਏ ਨਾ-ਮਿਲਣ ਦਾ ਨਤੀਜਾ ਦਿੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਕੀ ਮੌਜੂਦ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਵੀ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦਾ। ਸਰਵਰ ਵਾਲੇ ਪਾਸੇ, CageFS ਰਾਹੀਂ ਪ੍ਰਤੀ-ਸਾਈਟ ਵੱਖਰਾਪਣ ਹਰੇਕ ਕਿਰਾਏਦਾਰ ਦੇ ਸ਼ੈੱਲ ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਆਪਣੀ ਸਾਈਟ ਤੱਕ ਹੀ ਰੱਖਦਾ ਹੈ।
ਹਾਂ। 14-ਦਿਨਾਂ ਦਾ ਟ੍ਰਾਇਲ ਬਿਨਾਂ ਕਾਰਡ ਦੇ ਹੈ — ਕੋਈ ਭੁਗਤਾਨ ਵੇਰਵੇ ਨਹੀਂ, ਕੋਈ ਵਚਨਬੱਧਤਾ ਨਹੀਂ — ਅਤੇ ਇਸ ਵਿੱਚ ਪੰਜ ਸਾਈਟਾਂ ਤੱਕ Footprint-Free ਹੋਸਟਿੰਗ ਸ਼ਾਮਲ ਹੈ। ਵਚਨਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਸਹਿਯੋਗੀ ਨੂੰ ਸੱਦਾ ਦੇਣ, ਕੋਈ ਭੂਮਿਕਾ ਨਿਰਧਾਰਤ ਕਰਨ, ਅਤੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ ਕਿ ਸੀਮਾਵਾਂ ਤੁਹਾਡੀ ਲੋੜ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
ਕਾਰਡ-ਮੁਕਤ 14-ਦਿਨਾਂ ਦੇ ਟ੍ਰਾਇਲ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ, ਕਿਸੇ ਨੂੰ ਸੱਦਾ ਦਿਓ, ਅਤੇ ਇਜਾਜ਼ਤ ਮਾਡਲ ਨੂੰ ਆਪਣਾ ਕੰਮ ਕਰਦੇ ਦੇਖੋ — ਅਜਿਹੀਆਂ ਭੂਮਿਕਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ, ਅਜਿਹੇ ਦਾਇਰੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਆਡਿਟ ਲੌਗ ਜੋ ਬਿਲਕੁਲ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਕੀ ਕੀਤਾ ਹੈ।
ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ