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