ਪੁਰਾਣਾ VPN ਫਾਈਲ ਪੋਰਟਲ ਬਦਲਣਾ: ਨਿਯੰਤਰਣ ਕਾਇਮ ਰੱਖੋ
ਨੇਟਿਵ ਫਾਈਲ ਕਲਾਇੰਟ ਅਤੇ ਪ੍ਰੌਕਸੀ ਪੋਰਟਲ ਇਜਾਜ਼ਤਾਂ, ਰਿਕਵਰੀ ਅਤੇ ਪਛਾਣ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਚਾਰ ਕੰਮਾਂ 'ਤੇ ਦੋਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਕਲਾਇੰਟ ਤੋਂ ਬਿਨਾਂ ਪੁਰਾਣੇ ਪੋਰਟਲ ਵਿੱਚ ਇੱਕ ਡਿਲੀਟ ਬਟਨ, ਇੱਕ ਪਸੰਦੀਦਾ ਤਾਰਾ ਅਤੇ ਈਮੇਲ ਵਿੱਚ ਚਿਪਕਾਇਆ ਸ਼ੇਅਰ ਪਾਥ ਸੀ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨਿਯੰਤਰਣ ਹੈ। ਪੋਰਟਲ ਬਦਲਣ ਦਾ ਮਤਲਬ ਹੈ ਇਹ ਤੈਅ ਕਰਨਾ ਕਿ ਦੂਰ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਹਾਲੇ ਕਿਹੜੇ ਕੰਮ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਕਿੱਥੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਸੇ ਅਜਿਹੇ ਪੰਨੇ ਦਾ ਲੇਆਉਟ ਦੁਹਰਾਉਣਾ ਜੋ ਸੰਜੋਗ ਨਾਲ ਕੰਮ ਕਰ ਗਿਆ ਸੀ। ਦੋ ਬਦਲਣ ਵਾਲੇ ਰੂਪ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ।
ਬਟਨ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ
ਕੰਮਾਂ ਦੀ ਸੂਚੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਪੜ੍ਹਨਾ, ਅੱਪਲੋਡ, ਨਾਮ ਬਦਲਣਾ, ਡਿਲੀਟ। ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ, ਫਿਰ ਉਹ ਫੈਸਲਾ ਇੰਟਰਫੇਸ ਵਿੱਚ ਨਹੀਂ ਬਲਕਿ ਫਾਈਲ ਸੇਵਾ ਵਿੱਚ ਲਾਗੂ ਕਰੋ। ਨਵੇਂ ਪੋਰਟਲ ਵਿੱਚ ਡਿਲੀਟ ਨਿਯੰਤਰਣ ਲੁਕਾਉਣ ਨਾਲ ਬੈਕਐਂਡ ਇਜਾਜ਼ਤ ਬਰਕਰਾਰ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਜਿਸ ਕੋਲ ਨੇਟਿਵ ਕਲਾਇੰਟ ਅਤੇ ਉਹੀ ਖਾਤਾ ਹੈ ਉਹ ਅਜੇ ਵੀ ਫਾਈਲ ਹਟਾ ਸਕਦਾ ਹੈ।
ਡਿਲੀਟ ਲਈ ਵੱਖਰਾ ਫੈਸਲਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹੀ ਉਹ ਕੰਮ ਹੈ ਜਿਸਦਾ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪਛਤਾਵਾ ਹੁੰਦਾ ਹੈ। ਪੁੱਛੋ ਕਿ ਡਿਲੀਟ ਕੀਤੀ ਵਸਤੂ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਰਿਕਵਰ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਜਵਾਬ ਲੈਪਟਾਪ ਦੀ ਰੀਸਾਈਕਲ ਬਿਨ ਜਾਂ ਪੋਰਟਲ ਦੀ ਆਪਣੀ ਰੱਦੀ ਹੈ। ਨੈੱਟਵਰਕ ਸ਼ੇਅਰ ਆਮ ਤੌਰ 'ਤੇ ਡਿਲੀਟ ਨੂੰ ਸਥਾਨਕ ਰੀਸਾਈਕਲ ਬਿਨ ਰਾਹੀਂ ਨਹੀਂ ਲੰਘਾਉਂਦਾ।
Windows-ਅਧਾਰਿਤ ਸ਼ੇਅਰ 'ਤੇ, Volume Shadow Copy ਸਨੈਪਸ਼ਾਟ ਮਸ਼ੀਨਰੀ ਅਤੇ ਉਹ ਤਾਲਮੇਲ ਦਿੰਦਾ ਹੈ ਜੋ ਬੈਕਅੱਪ ਸੌਫਟਵੇਅਰ ਵਰਤਦਾ ਹੈ, ਪਰ ਇਸਦੀ ਮੌਜੂਦਗੀ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਇਹ ਸ਼ੇਅਰ ਰੀਸਟੋਰ ਕਰਨ ਯੋਗ ਵਰਜ਼ਨ ਰੱਖਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਫਾਈਲ ਸੇਵਾ ਦੇ ਮਾਲਕ ਨੂੰ ਵਰਜ਼ਨ ਨੀਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਅਤੇ ਪੋਰਟਲ ਰਿਟਾਇਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਰੀਸਟੋਰ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਵਿਕਲਪ A: ਸੁਰੰਗ ਰਾਹੀਂ ਨੇਟਿਵ ਫਾਈਲ ਕਲਾਇੰਟ
ਮੈਪ ਕੀਤੀ ਡਰਾਈਵ ਜਾਂ SMB ਕਲਾਇੰਟ ਉਹ ਕੰਮ ਕਾਇਮ ਰੱਖਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਨ, ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਹਰ ਬੇਨਤੀ 'ਤੇ ਫਾਈਲ ਸਰਵਰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਪਛਾਣ ਫਾਈਲ ਸੇਵਾ ਦੀ ਪਛਾਣ ਹੈ, ਇਸ ਲਈ ਪਹੁੰਚ VPN ਉਤਪਾਦ ਬਦਲਣ 'ਤੇ ਵੀ ਬਚੀ ਰਹਿੰਦੀ ਹੈ, ਜਿੰਨਾ ਚਿਰ ਸੁਰੰਗ ਟ੍ਰੈਫਿਕ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ ਅਤੇ ਖਾਤਾ ਮੌਜੂਦ ਹੈ।
ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਸੇਵਾ ਤੱਕ ਸਿੱਧਾ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ। ਨਾਮ ਹੱਲ, ਪੋਰਟ ਪਹੁੰਚ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਢੰਗ ਸਾਰੇ ਦੂਰ-ਪਹੁੰਚ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜੋ ਪੋਰਟਲ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਦਾ ਪ੍ਰੌਕਸੀ ਕਰਦਾ ਸੀ ਉਹ ਇਹ ਸਾਰੀਆਂ ਲੋੜਾਂ ਲੁਕਾਉਂਦਾ ਸੀ। ਗੈਰ-ਪ੍ਰਬੰਧਿਤ ਡਿਵਾਈਸਾਂ 'ਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਪਣੇ ਫਾਈਲ ਮੈਨੇਜਰ ਵਿੱਚ ਮਾਊਂਟ ਕੀਤਾ ਸ਼ੇਅਰ ਵੀ ਮਿਲਦਾ ਹੈ, ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਨਾਲੋਂ ਵੱਡੀ ਸਤਹ ਹੈ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਸਹਾਇਤਾ ਭਾਰ ਲਈ ਬਜਟ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹ ਪਹਿਲੇ ਹੀ ਦਿਨ ਆਉਂਦਾ ਹੈ, ਰਿਆਇਤ ਅਵਧੀ ਤੋਂ ਬਾਅਦ ਨਹੀਂ।
ਰਿਕਵਰੀ ਇਸ ਰੂਪ ਦੇ ਪੱਖ ਵਿੱਚ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਦਲੀਲ ਹੈ: ਪਿਛਲੇ ਵਰਜ਼ਨ ਅਤੇ ਰੀਸਟੋਰ ਇਜਾਜ਼ਤਾਂ ਪਲੇਟਫਾਰਮ ਦੇ ਮੂਲ ਹਨ, ਅਤੇ ਹੈਲਪ ਡੈਸਕ ਉਹੀ ਪ੍ਰਕਿਰਿਆ ਵਰਤ ਸਕਦਾ ਹੈ ਜੋ ਸਾਈਟ 'ਤੇ ਵਰਤਦਾ ਹੈ।
ਵਿਕਲਪ B: ਪ੍ਰੌਕਸੀ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਗੇਟਵੇ
ਫਾਈਲ ਲਿਆ ਕੇ ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਸਟ੍ਰੀਮ ਕਰਨ ਵਾਲਾ ਪੋਰਟਲ ਫਾਈਲ ਸੇਵਾ ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਨੈੱਟਵਰਕ ਪਾਥ ਤੋਂ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਇਹ ਤਦ ਲਾਹੇਵੰਦ ਹੈ ਜਦੋਂ ਡਿਵਾਈਸ ਸੁਰੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋ ਸਕਦੀ ਜਾਂ ਜਦੋਂ ਸੰਸਥਾ ਚਾਹੁੰਦੀ ਹੈ ਕਿ ਹਰ ਬੇਨਤੀ ਇੱਕ ਹੀ ਸੰਕੀਰਣ ਬਿੰਦੂ 'ਤੇ ਲੌਗ ਹੋਵੇ। ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਹਰ ਕੰਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ ਆਪਣਾ ਸੇਵਾ ਖਾਤਾ ਵਰਤਣ ਦੀ ਬਜਾਏ ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਫਾਈਲ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਾਉਣੀ ਪੈਂਦੀ ਹੈ।
ਡਿਲੀਟ ਅਤੇ ਨਾਮ ਬਦਲਣ ਦਾ ਵਿਵਹਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ, ਲਾਗੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਪ੍ਰੌਕਸੀ ਡਿਲੀਟ ਕਾਰਵਾਈ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਕਾਰਵਾਈ ਕਿਸੇ ਪਛਾਣ ਨਾਲ ਬੈਕਐਂਡ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਅਤੇ ਆਡਿਟ ਟ੍ਰੇਲ ਵਿੱਚ ਗੇਟਵੇ ਨਹੀਂ, ਉਪਭੋਗਤਾ ਦਾ ਨਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਪ੍ਰੌਕਸੀ ਨਾਮ ਨਹੀਂ ਬਦਲ ਸਕਦਾ, ਤਾਂ ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਵਿਚਕਾਰ ਪਤਾ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ ਦੱਸ ਦਿਓ।
ਲਿੰਕ ਮੁੜ-ਲਿਖਣਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਹ ਰੂਪ ਚੁੱਪਚਾਪ ਅਰਥ ਬਦਲਦਾ ਹੈ। ਪੋਰਟਲ ਜਿਸ URL ਦਾ ਪ੍ਰੌਕਸੀ ਕਰਦਾ ਹੈ ਉਹ ਉਸ URL ਵਰਗੀ ਵਸਤੂ ਨਹੀਂ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਸਿੱਧਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਨੂੰ ਦੂਜੇ ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਉਹ ਪ੍ਰਮਾਣੀਕਰਨ ਸੰਦਰਭ ਹਟ ਸਕਦਾ ਹੈ ਜਿਸਨੇ ਇਸਨੂੰ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਇਆ ਸੀ।
ਨਾਮ, ਪਛਾਣਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਦੇ ਲਿੰਕ
ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸਰਵਰ ਅਤੇ ਸ਼ੇਅਰ ਪਾਥ ਵੰਡੋ, ਡੋਮੇਨ ਬ੍ਰਾਊਜ਼ਿੰਗ ਸੂਚੀ ਨਹੀਂ। ਬ੍ਰਾਊਜ਼ਿੰਗ ਖੋਜ ਸੇਵਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਸੁਰੰਗ ਪਾਰ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ, ਅਤੇ ਜੋ ਪਾਥ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਦਾ ਲੈਪਟਾਪ ਡੋਮੇਨ ਗਿਣ ਸਕਦਾ ਹੈ, ਉਹ ਅਗਲੀ ਗੈਰ-ਪ੍ਰਬੰਧਿਤ ਡਿਵਾਈਸ 'ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਸਿੰਗਲ ਸਾਈਨ-ਆਨ ਦੀ ਸਮੀਖਿਆ ਐਪਲੀਕੇਸ਼ਨ ਦਰ ਐਪਲੀਕੇਸ਼ਨ ਕਰੋ। ਪੋਰਟਲ ਲਈ ਜਾਰੀ ਟੋਕਨ ਉਸ ਫਾਈਲ ਸੇਵਾ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਭੇਜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਜਿਸਨੇ ਇਸਨੂੰ ਕਦੇ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਪਛਾਣਕਰਤਾ ਲੈ ਕੇ ਜਾਣ ਵਾਲੇ ਕਵੈਰੀ ਪੈਰਾਮੀਟਰ ਸਿਰਫ਼ ਇਸ ਲਈ ਜਨਤਕ ਲਿੰਕ ਵਿੱਚ ਕਾਪੀ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਕਿ ਉਹ ਪੁਰਾਣੇ ਬੁੱਕਮਾਰਕ ਵਿੱਚ ਦਿਖੇ ਸਨ। ਹਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਆਪਣੀ ਵੱਖਰੀ ਭਰੋਸਾ ਸੀਮਾ ਮੰਨੋ।
| Requirement | Native client | Proxy portal |
|---|---|---|
| Permission enforcement | File service, per request | Proxy identity, then file service |
| Restore path | Platform versions and backups | Proxy trash plus backend restore |
| Device requirements | Tunnel and client | Browser only |
| Audit identity | File server logs | Proxy logs, if it forwards the user |
ਲੋੜਾਂ ਦੀ ਸੂਚੀ ਦੇ ਵਿਰੁੱਧ ਚੁਣੋ
ਕੋਈ ਵੀ ਰੂਪ ਸਿੱਧਾ ਨਹੀਂ ਜਿੱਤਦਾ। ਕੰਮ ਕਰਨ ਵਾਲੀ ਸੁਰੰਗ ਵਾਲੇ ਪ੍ਰਬੰਧਿਤ ਲੈਪਟਾਪਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕਰਮਚਾਰੀ ਨੇਟਿਵ ਕਲਾਇੰਟ ਤੋਂ ਵੱਧ ਪਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਰਿਕਵਰੀ ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਮੁੜ-ਲਾਗੂਕਰਨ ਤੋਂ ਨਹੀਂ, ਪਲੇਟਫਾਰਮ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਠੇਕੇਦਾਰਾਂ ਅਤੇ ਨਿੱਜੀ ਡਿਵਾਈਸਾਂ ਦੀ ਮਿਲੀ-ਜੁਲੀ ਆਬਾਦੀ ਪ੍ਰੌਕਸੀ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾ ਸਕਦੀ ਹੈ, ਬਸ਼ਰਤੇ ਪਛਾਣ ਦੀ ਪਾਈਪਲਾਈਨ ਅਸਲੀ ਹੋਵੇ ਅਤੇ ਸਾਂਝਾ ਸੇਵਾ ਖਾਤਾ ਨਾ ਹੋਵੇ।
ਚਾਰ ਕੰਮਾਂ ਅਤੇ ਰਿਕਵਰੀ ਦੇ ਜਵਾਬ ਦੇ ਸਾਮ੍ਹਣੇ ਤੁਲਨਾ ਲਿਖੋ, ਫਿਰ ਨਵੇਂ ਪਾਥ ਰਾਹੀਂ ਇੱਕ ਰੀਸਟੋਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਪੁਰਾਣਾ ਪੋਰਟਲ ਰਿਟਾਇਰ ਕਰੋ। ਉਹ ਟੈਸਟ ਡਿਜ਼ਾਈਨ ਦੇ ਉਹ ਹਿੱਸੇ ਚਲਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਫਲ ਲੌਗਇਨ ਕਦੇ ਨਹੀਂ ਛੂਹਦਾ।