06 ਅਕਤੂ 2025·8 ਮਿੰਟ
ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਅੱਪਲੋਡ: ਸਾਈਂਡ URLs ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ
ਸਾਈਂਡ URLs, ਸਖਤ ਟਾਈਪ ਅਤੇ ਸਾਈਜ਼ ਚੈੱਕ, ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਅਤੇ ਪਰਮੀਸ਼ਨ ਨਿਯਮਾਂ ਨਾਲ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਅੱਪਲੋਡ — ਟ੍ਰੈਫਿਕ ਵਧਣ 'ਤੇ ਵੀ ਤੇਜ਼ ਰਹਿਣ ਵਾਲਾ।
ਸਾਈਂਡ URLs, ਸਖਤ ਟਾਈਪ ਅਤੇ ਸਾਈਜ਼ ਚੈੱਕ, ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਅਤੇ ਪਰਮੀਸ਼ਨ ਨਿਯਮਾਂ ਨਾਲ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਅੱਪਲੋਡ — ਟ੍ਰੈਫਿਕ ਵਧਣ 'ਤੇ ਵੀ ਤੇਜ਼ ਰਹਿਣ ਵਾਲਾ।
ਫਾਈਲ ਅੱਪਲੋਡ ਸਧਾਰਣ ਵੱਜੋਂ ਲੱਗਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਸੱਚੇ ਯੂਜ਼ਰ ਆਉਂਦੇ ਹਨ ਤਾਂ ਚੀਜ਼ਾਂ ਜਟਿਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਵਿਅਕਤੀ ਪ੍ਰੋਫਾਇਲ ਫੋਟੋ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ। ਫਿਰ ਦਸ ਹਜ਼ਾਰ ਲੋਕ ਇੱਕੋ ਸਮੇਂ PDF, ਵੀਡੀਓਜ਼ ਅਤੇ ਸਪਰੇਡਸ਼ੀਟ ਅੱਪਲੋਡ ਕਰਦੇ ਹਨ। ਇੱਕਦੇਰ ਤੁਹਾਡੀ ਐਪ ਸੁਸਤ ਮਹਿਸੂਸ ਹੋਣ ਲੱਗਦੀ ਹੈ, ਸਟੋਰੇਜ ਖਰਚ ਵੱਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸਪੋਰਟ ਟਿਕਟ ਲੱਗਦੇ ਹਨ।
ਆਮ ਫੇਲ ਹੋਣ ਵਾਲੇ ਮੋਡ ਅਨੁਮਾਨਿਤ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ ਸਰਵਰ ਪੂਰੇ ਫਾਈਲ ਨੂੰ ਹੈਂਡਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਅੱਪਲੋਡ ਪੰਨੇ ਹੰਗ ਜਾਂ ਟਾਈਮਆਉਟ ਹੋ ਜਾਂਦੇ ਹਨ — ਇਸਦੀ ਬਜਾਏ ਕਿ ਓਬਜੇਕਟ ਸਟੋਰੇਜ ਭਾਰੀ ਕੰਮ ਕਰੇ। ਪਰਮੀਸ਼ਨ ਸਮੇਂ ਦੇ ਨਾਲ ਡਿ੍ਰਫਟ ਹੋ ਸਕਦੇ ਹਨ, ਤਾਂ ਕੋਈ ਫਾਈਲ URL ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਕੁਝ ਵੇਖ ਸਕਦਾ ਹੈ ਜੋ ਉਹ ਨਹੀਂ ਵੇਖਣਾ ਚਾਹੀਦਾ। “ਨਿਰਦੋਸ਼” ਫਾਈਲਾਂ ਮਾਲਵੇਅਰ ਲੈ ਕੇ ਆ ਸਕਦੀਆਂ ਨੇ ਜਾਂ ਐਸੀਆਂ ਫਾਰਮੈਟਾਂ ਰੱਖਦੀਆਂ ਨੇ ਜੋ ਡਾਊਨਸਟਰੀਮ ਟੂਲਾਂ ਨੂੰ ਕਰੈਸ਼ ਕਰ ਦੇਂਦੀਆਂ ਹਨ। ਅਤੇ ਲੌਗ ਅਪੂਰਨ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ ਕਿ ਕਿਸ ਨੇ ਕਿਹੜੀ ਫਾਈਲ ਕਦੋਂ ਅੱਪਲੋਡ ਕੀਤੀ।
ਤੁਹਾਨੂੰ ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਹ ਬੋਰਿੰਗ ਪਰ ਭਰੋਸੇਮੰਦ ਹੈ: ਤੇਜ਼ ਅੱਪਲੋਡ, ਸਾਫ਼ ਨਿਯਮ (ਕਿਹੜੀਆਂ ਕਿਸਮਾਂ ਅਤੇ ਅਕਾਰ ਦੀਆਂ ਆਗਿਆਤ), ਅਤੇ ਇੱਕ ਆਡਿਟ ਟ੍ਰੇਲ ਜੋ ਘਟਨਾਵਾਂ ਦੀ ਜਾਂਚ ਅਸਾਨ ਬਣਾਏ।
ਸਭ ਤੋਂ ਮੁਸ਼ਕਿਲ ਟਰੇਡਆਫ਼ ਗਤੀ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਇੱਕ ਚੈਕ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਖਤਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਉਹ ਉਡੀਕਾਂਗੇ ਅਤੇ ਰੀਟ੍ਰਾਈ ਕਰਨਗੇ, ਜਿਸ ਨਾਲ ਲੋਡ ਵਧੇਗਾ। ਜੇ ਤੁਸੀਂ ਚੈਕ ਬਹੁਤ ਦੇਰ ਨਾਲ ਕਰਦੇ ਹੋ ਤਾਂ ਅਣਸੁਰੱਖਿਅਤ ਜਾਂ ਅਣਅਧਿਕ੍ਰਿਤ ਫਾਈਲਾਂ ਫੈਲ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਅਪ੍ਰੋਚ ਹੈ ਅੱਪਲੋਡ ਨੂੰ ਚੈਕ ਤੋਂ ਅਲੱਗ ਕਰਨਾ ਅਤੇ ਹਰ ਕਦਮ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਮਾਪਯੋਗ ਰੱਖਣਾ।
“ਸਕੇਲ” ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਹੋਵੋ — ਦਿਨ ਵਿੱਚ ਫਾਈਲਾਂ ਦੀ ਗਿਣਤੀ, ਪੀਕ ਅੱਪਲੋਡ ਪ੍ਰਤੀ ਮਿੰਟ, ਮੈਕਸ ਫਾਈਲ ਸਾਈਜ਼ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਭੂਮਿਕਾ ਲਿਖੋ। ਖੇਤਰ (regions) ਲੈਟੈਂਸੀ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਨਿਯਮਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਐਪ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਸੀਮਾਵਾਂ ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰਨਾ ਫਾਇਦੇਮੰਦ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਪੇਰਮਿਸ਼ਨ, ਸਟੋਰੇਜ ਅਤੇ ਬੈਕਗਰਾਊਂਡ ਸਕੈਨਿੰਗ ਵਰਕਫਲੋ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ 'ਚ ਰੂਪ ਦਿੰਦੇ ਹਨ।
ਟੂਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਫ਼ ਹੋ ਜਾਓ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਖਤਰਾ ਮਾਡਲ ਵੱਡੀ ਡਾਕੀੂਮੈਂਟ ਦੀ ਲੋੜ ਨਹੀਂ — ਇਹ ਉਹ ਛੋਟਾ, ਸਾਂਝਾ ਸਮਝੌਤਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਰੋਕਣਾ ਹੈ, ਕੀ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਕਿਹੜੇ ਟਰੇਡਆਫ਼ ਤੁਸੀਂ ਸਵੀਕਾਰੋਗੇ।
ਹੁਲਾਰੇ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਅਨੁਮਾਨਿਤ ਥਾਵਾਂ 'ਤੇ ਦੱਖਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ: ਕਲਾਇੰਟ (ਮੇਟਾ ਡੇਟਾ ਬਦਲਣਾ ਜਾਂ MIME ਕਿਸਮ ਨਕਲੀ ਕਰਨਾ), ਨੈੱਟਵਰਕ ਐਜ (ਰਿਪਲੇਅ ਅਤੇ ਰੇਟ-ਲਿਮਿਟ ਜ਼ਿਆਦਾ ਵਰਤੋ), ਸਟੋਰੇਜ (ਆਬਜੈਕਟ ਨਾਮ ਅਨੁਮਾਨ ਲਾਉਣਾ, ਓਵਰਰਾਈਟ), ਅਤੇ ਡਾਊਨਲੋਡ/ਪ੍ਰੀਵਿью (ਖ਼ਤਰਨਾਕ ਰੇਂਡਰਿੰਗ ਟਰਿਗਰ ਕਰਨਾ ਜਾਂ ਸਾਂਝੇ ਐਕਸੈਸ ਰਾਹੀਂ ਫਾਈਲ ਚੋਰੀ ਕਰਨਾ)।
ਇਥੋਂ ਤੋਂ, ਖਤਰਿਆਂ ਨੂੰ ਸਧਾਰਨ ਨਿਯੰਤਰਣਾਂ ਨਾਲ ਮਿਲਾਓ:
ਅਤਿ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਸਭ ਤੋਂ ਆਸਾਨ ਗਲਤ ਵਰਤੋਂ ਹਨ — ਇਹ ਖਰਚ ਵਧਾ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸੁਸਤ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤ 'ਚ ਹੀ ਰੋਕੋ: ਕਠੋਰ ਬਾਈਟ ਸੀਮਾ ਅਤੇ ਤੇਜ਼ ਰਿਜੈਕਸ਼ਨ।
ਨਕਲੀ ਫਾਈਲ ਕਿਸਮਾਂ ਆਉਂਦੀਆਂ ਹਨ। invoice.pdf ਨਾਂ ਵਾਲੀ ਫਾਈਲ ਕੋਈ ਹੋਰ ਹੋ ਸਕਦੀ ਹੈ। ਐਕਸਟੇੰਸ਼ਨ ਜਾਂ UI ਚੈੱਕਾਂ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਅੱਪਲੋਡ ਤੋਂ ਬਾਅਦ ਅਸਲੀ ਬਾਈਟਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵੇਰੀਫਾਈ ਕਰੋ।
ਮਾਲਵੇਅਰ ਵਖਰਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਸਾਰਿਆਂ ਨੂੰ ਅੱਪਲੋਡ ਪੂਰਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਕੈਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਬਿਨਾਂ ਅਨੁਭਵ ਨੁਕਸਾਨ ਕੀਤੇ। ਆਮ ਪੈਟਰਨ ਹੈ: ਅਸਿੰਕ੍ਰੋਨਸ ਦਾਅਵਾ, ਸ਼ੱਕੀ ਆਈਟਮਾਂ ਨੂੰ ਕਵਾਰੰਟੀਨ ਕਰਨਾ, ਅਤੇ ਸਕੈਨ ਪਾਸ ਹੋਣ ਤੱਕ ਐਕਸੈਸ ਰੋਕਣਾ।
ਅਣਅਧਿਕ੍ਰਿਤ ਐਕਸੈਸ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦੇਹ ਹੋ ਸਕਦਾ ਹੈ। ਹਰ ਅੱਪਲੋਡ ਅਤੇ ਹਰ ਡਾਊਨਲੋਡ ਨੂੰ ਪਰਮੀਸ਼ਨ ਫੈਸਲੇ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ। ਇੱਕ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਉਸੇ ਥਾਂ 'ਤੇ ਅੱਪਲੋਡ ਕਰ ਸਕੇ ਜੋ ਉਹ ਮਾਲਿਕ ਹੈ ਜਾਂ ਜਿਸ 'ਤੇ ਉਹ ਲਿਖਣ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਫਾਈਲ ਡਾਊਨਲੋਡ ਕਰ ਸਕੇ ਜੋ ਉਹ ਵੇਖਣ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੀਆਂ ਐਪ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ v1 ਨੀਤੀ ਹੋ ਸਕਦੀ ਹੈ:
ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਐਪ ਸਰਵਰ "ਬਾਈਟਸ ਕਾਰੋਬਾਰ" ਤੋਂ ਬਾਹਰ ਰਹੇ। ਹਰ ਫਾਈਲ ਨੂੰ ਬੈਕਐਂਡ ਰਾਹੀਂ ਭੇਜਣ ਦੀ ਬਜਾਏ, ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ ਸਾਈਂਡ URL ਦੇ ਕੇ ਸੀਧਾ ਓਬਜੇਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰਨ ਦਿਓ। ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਫੈਸਲਿਆਂ ਅਤੇ ਰਿਕਾਰਡਾਂ 'ਤੇ ਧਿਆਨ ਰੱਖੇ, ਨਾ ਕਿ ਗਿਗਾਬਾਈਟ ਧੱਕਣ 'ਤੇ।
ਇਹ ਵੰਡ ਸਧਾਰਣ ਹੈ: ਬੈਕਐਂਡ ਜਵਾਬ ਦਿੰਦਾ ਹੈ "ਕੌਣ ਕਿਹੜੀ ਚੀਜ਼ ਅੱਪਲੋਡ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ," ਜਦਕਿ ਸਟੋਰੇਜ ਫਾਈਲ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ। ਇਹ ਇੱਕ ਆਮ ਬੋਤਲਨੇਕ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ: ਐਪ ਸਰਵਰ ਦੋਹਰਾ ਕੰਮ (auth ਅਤੇ ਫਾਈਲ ਪ੍ਰੋਕਸੀ) ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਲੋਡ 'ਤੇ CPU, ਮੈਮਰੀ ਜਾਂ ਨੈੱਟਵਰਕ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ।
ਹਰ ਫਾਈਲ ਲਈ ਇੱਕ ਛੋਟਾ ਅੱਪਲੋਡ ਰਿਕਾਰਡ ਆਪਣੇ ਡੇਟਾਬੇਸ (ਉਦਾਹਰਨ ਲਈ PostgreSQL) ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਹਰ ਫਾਈਲ ਦਾ ਮਾਲਿਕ ਅਤੇ ਲਾਈਫਸਾਇਕਲ ਸਪਸ਼ਟ ਹੋਵੇ। ਇਸ ਰਿਕਾਰਡ ਨੂੰ ਅੱਪਲੋਡ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਓ ਅਤੇ ਘਟਨਾਵਾਂ ਦੇ ਮੁਤਾਬਕ ਅਪਡੇਟ ਕਰੋ।
ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੋਂ ਵਾਲੇ ਫੀਲਡਾਂ ਵਿੱਚ ਮਾਲਿਕ ਅਤੇ ਟੈਨੈਂਟ/ਵਰਕਸਪੇਸ ਆਈਡੀ, ਸਟੋਰੇਜ ਆਬਜੈਕਟ ਕੀ, ਸਥਿਤੀ, ਦਾਅਵਾ ਕੀਤਾ ਆਕਾਰ ਅਤੇ MIME ਕਿਸਮ, ਅਤੇ ਇੱਕ ਚੈਕਸਮ ਸ਼ਾਮِل ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਵੇਰਿਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਅੱਪਲੋਡਾਂ ਨੂੰ ਇੱਕ ਸਟੇਟ ਮਸ਼ੀਨ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ ਤਾਂ ਜੋ ਰੀਟ੍ਰਾਈ ਹੋਣ 'ਤੇ ਵੀ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਸਹੀ ਰਹਿਣ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੈ:
ਕੇਵਲ ਬੈਕਐਂਡ ਦੇ requested ਰਿਕਾਰਡ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਨੂੰ ਸਾਈਂਡ URL ਵਰਤਣ ਦੀ ਆਗਿਆ ਦਿਓ। ਜਦੋਂ ਸਟੋਰੇਜ ਅੱਪਲੋਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ, ਉਸੇ ਨੂੰ uploaded ਤੇ ਲੈ ਜਾਓ, ਬੈਕਗਰਾਊਂਡ ਵਿੱਚ ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਚਲਾਓ, ਅਤੇ ਕੇਵਲ approved ਹੋਣ 'ਤੇ ਫਾਈਲ ਨੂੰ ਐਕਸਪੋਜ਼ ਕਰੋ।
ਜਦੋਂ ਯੂਜ਼ਰ Upload 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਤਾਂ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਹਾਡੀ ਐਪ ਬੈਕਐਂਡ ਨੂੰ ਫਾਈਲ ਨਾਂ, ਫਾਈਲ ਸਾਈਜ਼ ਅਤੇ ਇਰਾਦਾ ਵਰਤੋਂ (avatar, invoice, attachment) ਵਰਗੀਆਂ ਮੂਲ ਜਾਣਕਾਰੀਆਂ ਭੇਜਦੀ ਹੈ। ਬੈਕਐਂਡ ਉਸ ਖਾਸ ਟਾਰਗਟ ਲਈ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਇੱਕ ਅੱਪਲੋਡ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ ਸਾਈਂਡ URL ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਸਾਈਂਡ URL ਨੂੰ ਤੰਗ ਸਕੋਪ ਦਾ ਰੱਖੋ। ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ ਆਬਜੈਕਟ ਕੀ ਲਈ ਇਕੱਲੀ ਅੱਪਲੋਡ ਦੀ ਆਗਿਆ ਦੇਵੇ, ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ ਹੋਵੇ, ਅਤੇ ਸਪਸ਼ਟ ਸ਼ਰਤਾਂ (ਸਾਈਜ਼ ਲਿਮਿਟ, ਮਨਜ਼ੂਰ ਕੀਤੀ ਸਮੱਗਰੀ ਕਿਸਮ, ਵਿਕਲਪਿਕ ਚੈਕਸਮ) ਹੋਣ।
ਬ੍ਰਾਊਜ਼ਰ ਉਸ URL ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਿੱਧਾ ਸਟੋਰੇਜ ਨੂੰ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦੁਬਾਰਾ ਬੈਕਐਂਡ ਨੂੰ finalize ਕਰਨ ਲਈ ਕਾਲ ਕਰਦਾ ਹੈ। finalize 'ਤੇ ਪਰਮੀਸ਼ਨ ਦੀ ਦੁਬਾਰਹ ਜਾਂਚ ਕਰੋ (ਯੂਜ਼ਰ ਦੀ ਪਹੁੰਚ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ), ਅਤੇ ਜੋ ਅਸਲ ਵਿੱਚ ਸਟੋਰੇਜ ਵਿੱਚ ਪੁੱਜਿਆ ਹੈ ਉਹ ਪ੍ਰਮਾਣਿਤ ਕਰੋ: ਸਾਈਜ਼, ਡਿਟੈਕਟ ਕੀਤੀ ਸਮੱਗਰੀ ਕਿਸਮ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਚੈਕਸਮ ਵਰਤਦੇ ਹੋ ਤਾਂ ਉਹ ਵੀ। finalize ਨੂੰ idempotent ਬਣਾਓ ਤਾਂ ਜੋ ਰੀਟ੍ਰਾਈ ਦੌਰਾਨ ਡੁਪਲੀਕੇਟ ਨਾ ਬਣਨ।
ਫਿਰ ਰਿਕਾਰਡ ਨੂੰ uploaded ਮਾਰਕ ਕਰੋ ਅਤੇ ਪਿਛੋਕੜ ਵਿੱਚ ਸਕੈਨਿੰਗ ਟ੍ਰਿਗਰ ਕਰੋ (queue/job)। UI ਸਕੈਨ ਹੋਣ ਤੱਕ "Processing" ਦਿਖਾ ਸਕਦੀ ਹੈ।
ਇਕਸਟੇੰਸ਼ਨ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਉਹੀ ਕਾਰਨ ਹੈ ਜਿਸ ਨਾਲ invoice.pdf.exe ਤੁਹਾਡੇ ਬੱਕੇਟ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਚੈੱਕਸ ਦੇ ਤੌਰ 'ਤੇ ਰੱਖੋ ਜੋ ਕਈ ਥਾਂ ਤੇ ਹੁੰਦੇ ਹਨ।
ਸਾਈਜ਼ ਸੀਮਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਤੱਕ਼ਰੀਬਨ ਮੈਕਸ ਸਾਈਜ਼ ਨੂੰ ਸਾਈਂਡ URL ਨੀਤੀ (ਯਾ ਪ੍ਰੀ-ਸਾਈਂਡ POST ਸ਼ਰਤਾਂ) ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਸਟੋਰੇਜ ਪਹਿਲਾਂ ਹੀ ਅਤਿ ਵੱਡੇ ਅੱਪਲੋਡ ਰਿਜੈਕਟ ਕਰ ਦੇਵੇ। ਉਸੇ ਸੀਮਾ ਨੂੰ ਦੂਜੇ ਵਾਰੀ ਬੈਕਐਂਡ ਵੱਲੋਂ ਮੈਟਾਡੇਟਾ ਰਿਕਾਰਡ ਕਰਦੇ ਸਮੇਂ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਹਾਲੇ ਵੀ UI ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਟਾਈਪ ਚੈੱਕਸ ਨੂੰ ਫਾਈਲ ਨਾਮ ਦੇ ਆਧਾਰ 'ਤੇ ਨਾ ਕਰੋ। ਫਾਈਲ ਦੇ ਪਹਿਲੇ ਬਾਈਟ (ਮੈਜਿਕ ਬਾਇਟ) ਦੀ ਜਾਂਚ ਕਰੋ ਕਿ ਇਹ ਤੁਹਾਡੇ ਅਨੁਮਾਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਇਕ ਅਸਲ PDF %PDF ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ PNG ਫਾਈਲਾਂ ਇੱਕ ਨਿਰਧਾਰਤ ਸਿਗਨੇਚਰ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਸਮੱਗਰੀ ਤੁਹਾਡੇ allowlist ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਤਾਂ ਰਿਜੈਕਟ ਕਰੋ, ਭਾਵੇਂ ਐਕਸਟੇੰਸ਼ਨ ਠੀਕ ਦਿੱਸਦੀ ਹੋਵੇ।
ਹਰ ਫੀਚਰ ਲਈ allowlists ਨੂੰ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ। ਇੱਕ avatar ਅੱਪਲੋਡ ਸਿਰਫ਼ JPEG ਅਤੇ PNG ਦੀ ਹੀ ਆਗਿਆ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ documents ਫੀਚਰ PDF ਅਤੇ DOCX ਦੀ ਆਗਿਆ ਦੇ ਸਕਦਾ ਹੈ। ਇਹ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਨਿਯਮ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ।
ਮੂਲ ਫਾਈਲ ਨਾਂ ਨੂੰ ਕਦੇ ਵੀ ਸਟੋਰੇਜ ਕੀ ਵਜੋਂ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਡਿਸਪਲੇਅ ਲਈ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ (ਅਜੀਬ ਅੱਖਰ ਹਟਾਉ, ਲੈਂਥ ਘਟਾਓ), ਪਰ ਆਪਣਾ ਸੁਰੱਖਿਅਤ ਆਬਜੈਕਟ ਕੀ ਸਟੋਰ ਕਰੋ, ਜਿਵੇਂ UUID + ਆਵਸ਼ਯਕ ਐਕਸਟੇੰਸ਼ਨ ਜੋ ਤੁਸੀਂ type detection ਦੇ ਬਾਅਦ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਆਪਣੇ ਡੇਟਾਬੇਸ 'ਚ ਇੱਕ ਚੈਕਸਮ (ਜਿਵੇਂ SHA-256) ਸਟੋਰ ਕਰੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰੋਸੈਸਿੰਗ ਜਾਂ ਸਕੈਨਿੰਗ ਦੌਰਾਨ ਇਸ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਇਹ ਕਰਪਸ਼ਨ, ਅਰਧ-ਅੱਪਲੋਡ ਜਾਂ ਟੈਂਪਰਿੰਗ ਨੂੰ ਉਲਝਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਅੱਪਲੋਡ ਰੀਟ੍ਰਾਈ ਹੋ ਰਹੇ ਹਨ।
ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਇਹ ਸੰਕਟਮਾਰਗ ਵਿੱਚ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਅੱਪਲੋਡ ਨੂੰ ਤੁਰੰਤ ਸਵੀਕਾਰ ਕਰੋ, ਫਿਰ ਫਾਈਲ ਨੂੰ ਬਲੌਕ ਸਮਝੋ ਜਦ ਤੱਕ ਸਕੈਨ ਪਾਸ ਨਾ ਹੋਵੇ।
pending_scan ਵਰਗਾ ਇੱਕ ਅੱਪਲੋਡ ਰਿਕਾਰਡ ਬਣਾਉ। UI ਫਾਈਲ ਦਿਖਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਵਰਤਣਯੋਗ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਸਕੈਨ ਆਮ ਤੌਰ 'ਤੇ ਸਟੋਰੇਜ ਇਵੈਂਟ ਦੁਆਰਾ ਟ੍ਰਿਗਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਆਬਜੈਕਟ ਬਣਦਾ ਹੈ, ਜਾਂ ਅੱਪਲੋਡ ਪੂਰਾ ਹੋਣ 'ਤੇ ਇੱਕ ਜੋਬ ਨੂੰ ਕਿਊ 'ਚ ਪਬਲਿਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਦੋਹਾਂ (ਬੈਕਅਪ ਵਜੋਂ) ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਸਕੈਨ ਵਰਕਰ ਆਬਜੈਕਟ ਨੂੰ ਡਾਊਨਲੋਡ ਜਾਂ ਸਟ੍ਰੀਮ ਕਰਦਾ ਹੈ, ਸਕੈਨਰ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ 'ਚ ਲਿਖਦਾ ਹੈ। ਆਉਟਪੁੱਟ ਵਿੱਚ ਮੁੱਖ ਚੀਜ਼ਾਂ ਰੱਖੋ: ਸਕੈਨ ਸਥਿਤੀ, ਸਕੈਨਰ ਵਰਜਨ, ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਜਿਸ ਨੇ ਅੱਪਲੋਡ ਕੀਤਾ ਉਹ। ਇਹ ਆਡਿਟ ਟ੍ਰੇਲ ਸਪੋਰਟ ਲਈ ਬਹੁਤ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਪੁੱਛਦਾ ਹੈ "ਮੇਰੀ ਫਾਈਲ ਕਿਉਂ ਰੋਕੀ ਗਈ?"।
ਫੇਲ ਹੋਈਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਾਫ਼ ਫਾਈਲਾਂ ਨਾਲ ਮਿਲੇ-ਝੁਲੇ ਨਾ ਛੱਡੋ। ਇੱਕ ਨੀਤੀ ਚੁਣੋ ਅਤੇ ਲਗਾਤਾਰ ਲਾਗੂ ਕਰੋ: ਕਵਾਰੰਟੀਨ ਅਤੇ ਐਕਸੈਸ ਹਟਾਓ, ਜਾਂ ਜੇ ਤਜਵੀਜ਼ ਲਈ ਲੋੜ ਨਹੀਂ ਤਾਂ ਮਿਟਾ ਦਿਓ।
ਜੋ ਵੀ ਨੀਤੀ ਤੁਸੀਂ ਚੁਣੋ, ਯੂਜ਼ਰ ਸੰਦੇਸ਼ ਸ਼ਾਂਤ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਹੋਵੇ. ਉਨ੍ਹਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਅਗਲਾ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਰੀ-ਅੱਪਲੋਡ, ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ)। ਜੇ ਇੱਕ ਛੋਟੀ ਸਮੇਂ ਵਿੱਚ ਕਈ ਫੇਲ ਹੋ ਰਹੇ ਹਨ ਤਾਂ ਆਪਣੀ ਟੀਮ ਨੂੰ ਅਲਰਟ ਕਰੋ।
ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਗੱਲ: ਡਾਊਨਲੋਡ ਅਤੇ ਪ੍ਰੀਵਿью ਲਈ ਇੱਕ ਕਠੋਰ ਨਿਯਮ ਰੱਖੋ — ਸਿਰਫ਼ approved ਮਾਰਕ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਹੀ ਸਰਵ ਕੀਤਾ ਜਾਵੇ। ਬਾਕੀ ਸਾਰੀਆਂ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਜਵਾਬ ਦਿੱਤਾ ਜਾਵੇ ਜਿਵੇਂ "File is still being checked."।
ਤੇਜ਼ ਅੱਪਲੋਡ ਚੰਗੇ ਹਨ, ਪਰ ਜੇ ਗਲਤ ਵਿਅਕਤੀ ਇੱਕ ਫਾਈਲ ਨੂੰ ਗਲਤ ਵਰਕਸਪੇਸ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਧੀਮੀ ਰਿਕਵੇਸਟਾਂ ਨਾਲੋਂ ਵੱਡੀ ਸਮੱਸਿਆ ਹੈ। ਸਭ ਤੋਂ ਸਧਾਰਣ ਨਿਯਮ ਵੀ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਹੈ: ਹਰ ਫਾਈਲ ਰਿਕਾਰਡ ਇੱਕ ਸਪਸ਼ਟ ਟੈਨੈਂਟ (ਵਰਕਸਪੇਸ/ਆਰਗ/ਪ੍ਰੋਜੈਕਟ) ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ ਅਤੇ ਉਸਦਾ ਇੱਕ ਸਪਸ਼ਟ ਮਾਲਿਕ ਜਾਂ ਬਣਾਉਣ ਵਾਲਾ ਹੋਵੇ।
ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਦੋ ਵਾਰੀ ਕਰੋ: ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਾਈਂਡ ਅੱਪਲੋਡ URL ਜਾਰੀ ਕਰਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਜਦੋਂ ਕੋਈ ਡਾਊਨਲੋਡ ਜਾਂ ਵੇਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਪਹਿਲੀ ਜਾਂਚ ਗੈਰਅਧਿਕ੍ਰਿਤ ਅੱਪਲੋਡ ਨੂੰ ਰੋਕਦੀ ਹੈ। ਦੂਜੀ ਜਾਂਚ ਤੁਹਾਨੂੰ ਬਚਾਉਂਦੀ ਹੈ ਜੇਕਰ ਪਹੁੰਚ ਰੱਦ ਕਰ ਦਿੱਤੀ ਗਈ ਹੋਵੇ, URL ਲਿਕ ਹੋ ਗਿਆ ਹੋਵੇ, ਜਾਂ ਯੂਜ਼ਰ ਦੀ ਭੂਮਿਕਾ ਅੱਪਲੋਡ ਤੋਂ ਬਾਅਦ ਬਦਲ ਗਈ ਹੋਵੇ।
ਲੀਸਟ ਪ੍ਰਿਵਿਲੇਜ ਦੋਹਾਂ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਨੁਮੋਦਿਤ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਵੱਡੇ "files" ਪਰਮੀਸ਼ਨ ਦੀ ਬਜਾਏ, ਅਲੱਗ ਅਧਿਕਾਰ ਰੱਖੋ ਜਿਵੇਂ "can upload", "can view", ਅਤੇ "can manage (delete/share)"। ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਕਵੇਸਟਾਂ ਫਿਰ ਤੇਜ਼ ਲੁੱਕਅੱਪ ਬਣ ਜਾਂਦੀਆਂ ਹਨ (ਯੂਜ਼ਰ, ਟੈਨੈਂਟ, ਐਕਸ਼ਨ) ਨਾ ਕਿ ਮਹਿੰਗੀ ਕਸਟਮ ਲਾਜ਼ਿਕ।
ID ਅਨੁਮਾਨ ਨੂੰ ਰੋਕਣ ਲਈ, URLs ਅਤੇ APIs ਵਿੱਚ ਲਗਤਾਰ ਫਾਈਲ IDs ਵਰਤੋਂ ਨਾ ਕਰੋ। ਓਪੈਕ ਆਈਡੀਜ਼ ਅਤੇ ਅਣਅਨੁਮਾਨਯੋਗ ਸਟੋਰੇਜ ਕੀ ਰੱਖੋ। ਸਾਈਂਡ URLs ਟ੍ਰਾਂਸਪੋਰਟ ਹਨ, ਤੁਹਾਡੀ ਪਰਮੀਸ਼ਨ ਪ੍ਰਣਾਲੀ ਨਹੀਂ।
ਸਾਂਝੀ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਅਕਸਰ ਸਿਸਟਮਾਂ ਨੂੰ ਧੀਮਾ ਅਤੇ ਗੁੰਝਲਦਾਰ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਸਾਂਝਾ ਕਰਨ ਨੂੰ ਸਪਸ਼ਟ ਡੇਟਾ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਨਾਂ ਕਿ ਨਿਰਾਕਸ਼ਿਤ ਐਕਸੈਸ। ਇੱਕ ਸਾਦਾ ਅਪ੍ਰੋਚ ਹੈ ਕਿ ਇੱਕ ਵੱਖਰਾ ਸ਼ੇਅਰਿੰਗ ਰਿਕਾਰਡ ਰੱਖੋ ਜੋ ਇੱਕ ਯੂਜ਼ਰ ਜਾਂ ਗਰੁੱਪ ਨੂੰ ਇੱਕ ਫਾਈਲ ਲਈ ਅਧਿਕਾਰ ਦਿੰਦਾ ਹੋਵੇ, ਵਿਕਲਪਿਕ ਸਮਾਪਤੀ ਸਮੇਂ ਦੇ ਨਾਲ।
ਜਦੋਂ ਲੋਕ ਸੁਰੱਖਿਅਤ ਅੱਪਲੋਡਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਸੁਰੱਖਿਆ ਚੈਕਸ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਅਤੇ ਮੂਲ ਗੱਲਾਂ ਭੁੱਲ ਜਾਂਦੇ ਹਨ: ਬਾਈਟਸ ਨੂੰ ਹਿਲਾਉਣਾ ਹੀ ਸਭ ਤੋਂ ਧੀਮਾ ਹੈ। ਲਕਸ਼ਯ ਇਹ ਹੈ ਕਿ ਵੱਡੀਆਂ ਫਾਈਲ ਟਰੈਫਿਕ ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਸਰਵਰਾਂ ਤੋਂ ਦੂਰ ਰੱਖਿਆ ਜਾਵੇ, ਰੀਟ੍ਰਾਈਜ਼ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਸੁਰੱਖਿਆ ਚੈਕਸ ਨੂੰ ਅਜਿਹਾ ਨਾ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਉਹ ਅਨੰਤ ਕਿਊ ਬਣ ਜਾਣ।
ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਲਈ multipart ਜਾਂ chunked ਅੱਪਲੋਡ ਵਰਤੋਂ ਤਾਂ ਜੋ ਇੱਕ ਢਿੱਲੀ ਕਨੈਕਸ਼ਨ ਯੂਜ਼ਰ ਨੂੰ ਨਿੱਲੇ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਾ ਕਰੇ। ਚੰਕਸ ਤੁਹਾਨੂੰ ਸਾਫ਼ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ: ਕੁੱਲ ਮੈਕਸ ਸਾਈਜ਼, ਮੈਕਸ ਚੰਕ ਸਾਈਜ਼, ਅਤੇ ਮੈਕਸ ਅੱਪਲੋਡ ਸਮਾਂ।
ਕਲਾਇੰਟ ਟਾਈਮਆਉਟ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਜਾਣਬੂਝ ਕੇ ਸੈੱਟ ਕਰੋ। ਕੁਝ ਰੀਟ੍ਰਾਈਜ਼ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬਚਾ ਸਕਦੇ ਹਨ; ਅਸੀਮਤ ਰੀਟ੍ਰਾਈਜ਼ ਖਰਚ ਬੜ੍ਹਾ ਸਕਦੇ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਇਲ ਨੈੱਟਵਰਕ 'ਤੇ। ਪ੍ਰਤੀ-ਚੰਕ ਛੋਟੇ ਟਾਈਮਆਉਟ, ਛੋਟਾ ਰੀਟ੍ਰਾਈ ਕੈਪ, ਅਤੇ ਪੂਰੇ ਅੱਪਲੋਡ ਲਈ ਕਠੋਰ ਡੈਡਲਾਈਨ ਰੱਖੋ।
ਸਾਈਂਡ URLs ਭਾਰੀ ਡੇਟਾ ਪਾਥ ਨੂੰ ਤੇਜ਼ ਰੱਖਦੇ ਹਨ, ਪਰ ਉਹ ਪ੍ਰਦਾਤਾ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਬਣਾਉਂਦਾ ਹੈ ਉਹ ਵੀ ਹਾਟ ਸਪੌਟ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਬਚਾਓ ਤਾਂ ਜੋ ਇਹ ਜਵਾਬਦੀਹ ਰਹੇ:
ਲੈਟੈਂਸੀ ਦਾ ਨਿਰਭਰ ਭੂਗੋਲ 'ਤੇ ਵੀ ਹੁੰਦਾ ਹੈ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, اپنے ਐਪ, ਸਟੋਰੇਜ, ਅਤੇ ਸਕੈਨਿੰਗ ਵਰਕਰਸ ਨੂੰ ਇੱਕੋ ਖੇਤਰ ਵਿੱਚ ਰੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ ਕੰਪਲਾਇੰਸ ਲਈ ਦੇਸ਼-ਖ਼ਾਸ ਹੋਸਟਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਰੂਟਿੰਗ ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ ਤਾਂ ਜੋ ਅੱਪਲੋਡ ਮਹাদেশਾਂ ਦੇ ਪਾਰ ਨਹੀਂ ਜਾਏ। AWS 'ਤੇ ਗਲੋਬਲ ਅਭਿਆਸ ਵਾਲੇ ਪਲੇਟਫਾਰਮ (ਜਿਵੇਂ Koder.ai) ਵਰਕਲੋਡز ਨੂੰ ਯੂਜ਼ਰਾਂ ਦੇ ਨੇੜੇ ਰੱਖ ਸਕਦੇ ਹਨ ਜਦੋਂ ਡੇਟਾ ਰਿਹਾਇਸ਼ੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ।
ਅਖੀਰ ਵਿੱਚ, ਡਾਊਨਲੋਡ ਦੀ ਯੋਜਨਾ ਵੀ ਕਰੋ, ਸਿਰਫ਼ ਅੱਪਲੋਡ ਹੀ ਨਹੀਂ। ਸਾਈਂਡ ਡਾਊਨਲੋਡ URLs ਨਾਲ ਫਾਈਲਾਂ ਸਰਵ ਕਰੋ ਅਤੇ ਫਾਈਲ ਕਿਸਮ ਅਤੇ ਪਰਾਈਵੇਸੀ ਲੈਵਲ ਦੇ ਆਧਾਰ 'ਤੇ ਕੈਸ਼ ਨੀਤੀਆਂ ਸੈੱਟ ਕਰੋ। ਸਰਵਜਨਿਕ ਐਸੈਟ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ; ਨਿੱਜੀ ਰੀਸੀਟ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਅਤੇ ਪਰਮੀਸ਼ਨ-ਚੈੱਕ ਕੀਤੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇਕ ਛੋਟੀ ਬਿਜ਼ਨਸ ਐਪ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿੱਥੇ ਕਰਮਚਾਰੀ ਇਨਵੌਇਸ ਅਤੇ ਰਸੀਦਾਂ ਦੀਆਂ ਤਸਵੀਰਾਂ ਅੱਪਲੋਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਮੈਨੇਜਰ ਉਨ੍ਹਾਂ ਨੂੰ ਰੀਅਬਰਸਮੈਂਟ ਲਈ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਅੱਪਲੋਡ ਡਿਜ਼ਾਈਨ ਅਕਾਨੂੰਨੀ ਨਹੀਂ ਰਹਿੰਦਾ: ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ, ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ, ਅਤੇ ਅਸਲ ਪੈਸਾ ਲੱਗਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਫਲੋ ਸਪਸ਼ਟ ਸਥਿਤੀਆਂ ਵਰਤਦਾ ਹੈ ਤਾਂ ਜੋ ਹਰ ਕੋਈ ਜਾਣੇ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਬੋਰੀ ਕੰਮ ਨੂੰ ਆਟੋਮੇਟ ਕਰ ਸਕੋ: ਫਾਈਲ ਓਬਜੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਰਿਕਾਰਡ ਸੇਵ ਕਰਦੇ ਹੋ ਜੋ ਯੂਜ਼ਰ/ਵਰਕਸਪੇਸ/ਖਰਚ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ; ਇੱਕ ਬੈਕਗਰਾਊਂਡ ਜੋਬ ਫਾਈਲ ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ ਅਤੇ ਮੁਢਲੀ ਮੈਟਾ ਡੇਟਾ ਨਿਕਾਲਦਾ ਹੈ (ਜਿਵੇਂ ਅਸਲੀ MIME ਕਿਸਮ); ਫਿਰ ਆਈਟਮ ਮਨਜ਼ੂਰ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਰਿਜੈਕਟ ਹੋ ਕੇ ਬਲੌਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਨਿਰਧਾਰਤ ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਫਾਈਲ ਬਹੁਤ ਵੱਡੀ ਹੈ, ਤਾਂ ਸੀਮਾ ਅਤੇ ਮੌਜੂਦਾ ਸਾਈਜ਼ ਦਿਖਾਓ (ਉਦਾਹਰਨ: "File is 18 MB. Max is 10 MB."). ਜੇ ਕਿਸਮ ਗਲਤ ਹੈ, ਤਾਂ ਦੱਸੋ ਕਿ ਕੀ ਮਨਜ਼ੂਰ ਹੈ ("Upload a PDF, JPG, or PNG"). ਜੇ ਸਕੈਨ ਫੇਲ ਹੈ, ਸੁਖਾਅ ਅਤੇ ਕਾਰਵਾਈਯੋਗ ਸੁਨੇਹਾ ਦਿਓ ("This file could be unsafe. Please upload a new copy.").
ਸਪੋਰਟ ਟੀਮਾਂ ਨੂੰ ਐਸਾ ਟ੍ਰੇਲ ਚਾਹੀਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਫਾਈਲ ਖੋਲ੍ਹਣ ਬਿਨਾਂ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ: upload ID, user ID, workspace ID, created/uploaded/scan started/scan finished ਦੇ timestamps, ਨਤੀਜੇ ਕੋਡ (too large, type mismatch, scan failed, permission denied), ਨਾਲ ਨਾਲ ਸਟੋਰੇਜ ਕੀ ਅਤੇ ਚੈਕਸਮ।
ਰੀ-ਅੱਪਲੋਡ ਅਤੇ ਬਦਲਵ обычай ਹਨ। ਉਹਨਾਂ ਨੂੰ ਨਵੇਂ ਅੱਪਲੋਡ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ, ਉਹਨਾਂ ਨੂੰ ਉਹੀ ਖਰਚ ਨਾਲ ਜੁੜੋ ਪਰ ਨਵੀਂ ਵਰਜ਼ਨ ਦੇ ਤੌਰ 'ਤੇ, ਇਤਿਹਾਸ ਰੱਖੋ (ਕਿਸ ਨੇ ਕਦੋਂ ਬਦਲਿਆ), ਅਤੇ ਸਿਰਫ਼ ਨਵੀਂ ਵਰਜ਼ਨ ਨੂੰ ਐਕਟਿਵ ਮਾਰਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਐਪ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਇੱਕ uploads ਟੇਬਲ ਅਤੇ expense_attachments ਟੇਬਲ ਨਾਲ ਵਰਜ਼ਨ ਫੀਲਡ ਦੇ ਰੂਪ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਾਪ ਖਾਂਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਅੱਪਲੋਡ ਬੱਗ ਜ਼ਿਆਦਾ ਖਾਸ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਛੋਟੀਆਂ ਸ਼ੌਰਟਕੱਟਸ ਹੁੰਦੇ ਹਨ ਜੋ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਵਧਦਾ ਹੈ ਤਾਂ ਅਸਲ ਜੋਖਮ ਬਣ ਜਾਂਦੇ ਹਨ।
ਜ਼ਿਆਦਾ ਚੈException use not allowed -- continue:checks ਹਮੇਸ਼ਾ ਅੱਪਲੋਡ ਨੂੰ ਧੀਮਾ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਫਾਸਟ ਪਾਥ ਨੂੰ ਭਾਰੀ ਪਾਥ ਤੋਂ ਅਲੱਗ ਕਰੋ।
ਤੇਜ਼ ਚੈੱਕ ਸਿੰਕ੍ਰੋਨਸਲੀ ਕਰੋ (auth, size, allowed type, rate limits), ਫਿਰ ਸਕੈਨਿੰਗ ਅਤੇ ਡੂੰਘੀ ਜਾਂਚ ਨੂੰ ਬੈਕਗਰਾਊਂਡ ਵਰਕਰ ਨੂੰ ਸੌਂਪ ਦਿਓ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਫਾਈਲ "uploaded" ਤੋਂ "ready" ਹੋਣ ਦੌਰਾਨ ਕੰਮ ਜਾਰੀ ਰੱਖਣ ਦਿਓ। ਜੇ ਤੁਸੀਂ chat-based builder ਵਰਗਾ Koder.ai ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਉਸੇ ਮਨੋਭਾਵ ਨਾਲ ਚਲੋ: ਅੱਪਲੋਡ ਐਂਡਪੋਇੰਟ ਨੂੰ ਛੋਟਾ ਅਤੇ ਕਠੋਰ ਰੱਖੋ, ਅਤੇ ਸਕੈਨਿੰਗ/ਪੋਸਟ-ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਜੋਬਜ਼ ਵਿੱਚ ਧੱਕੋ।
ਅੱਪਲੋਡਸ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ v1 ਲਈ "ਪ੍ਰਯਾਪਤ ਸੁਰੱਖਿਅਤ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਟੀਮਾਂ ਆਮਤੌਰ 'ਤੇ ਪਾਬੰਦੀ ਵਾਲੇ ਨਿਯਮ (ਜੋ ਹਕੀਕਤ ਵਿੱਚ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ) ਅਤੇ ਗੁੰਮ ਨਿਯਮ (ਜੋ ਦੁਸ਼ਮਣੀ ਨੂੰ ਬੁਲਾਉਂਦੇ ਹਨ) ਨੂੰ ਮਿਲਾ ਦੇ ਕੇ ਮੁਸੀਬਤ ਵਿੱਚ ਪੈਂਦੀਆਂ ਹਨ। ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਪਰ ਹਰ ਅੱਪਲੋਡ ਲਈ "ਲੈਣ-ਦੇਣ" ਦਾ ਸਪਸ਼ਟ ਰਾਹ ਹੋਵੇ: "received" ਤੋਂ "allowed to download" ਤੱਕ।
ਪ੍ਰੀ-ਲਾਂਚ ਚੈੱਕਲਿਸਟ:
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਨਿਯੂਨ ਪੱਧਰੀ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਸਧਾਰਨ ਰੱਖੋ: ਸਾਈਜ਼ ਲਿਮਿਟ, ਤੰਗ ਟਾਈਪ allowlist, ਸਾਈਂਡ URL ਅੱਪਲੋਡ, ਅਤੇ "quarantine until scan passes"। ਫਿਰ ਵਧੀਆ ਫੀਚਰ (previews, ਹੋਰ ਕਿਸਮਾਂ, ਬੈਕਗਰਾਊਂਡ ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ) ਜ਼ਿਆਦਾ ਸਥਿਰ ਕੋਰ ਪਾਥ ਹੋਣ 'ਤੇ ਸ਼ਾਮِل ਕਰੋ।
ਮਾਨੀਟਰਿੰਗ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੇਜ਼ ਨੂੰ ਵੱਡੇ ਹੋਣ 'ਤੇ "ਅਚਾਨਕ ਧੀਮਾ" ਵਿੱਚੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਅੱਪਲੋਡ ਫੇਲ੍ਹ ਦਰ (ਕਲਾਇੰਟ vs ਸਰਵਰ/ਸਟੋਰੇਜ), ਸਕੈਨ ਫੇਲ ਦਰ ਅਤੇ ਸਕੈਨ ਲੈਟੈਂਸੀ, ਫਾਈਲ-ਸਾਈਜ਼ ਬਕਟ ਦੁਆਰਾ ਔਸਤ ਅੱਪਲੋਡ ਸਮਾਂ, ਡਾਊਨਲੋਡ 'ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਰਦ ਕਰਨ, ਅਤੇ ਸਟੋਰੇਜ ਐਕਸਿਗੈਰ ਪੈਟਰਨ ਟਰੈਕ ਕਰੋ।
ਅਸਲੀ ਦੁਨੀਆ ਵਾਲੀਆਂ ਫਾਈਲ ਸਾਈਜ਼ਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਨਾਲ ਛੋਟਾ ਲੋਡ ਟੈਸਟ ਚਲਾਓ (ਮੋਬਾਇਲ ਡੇਟਾ ਵੱਖਰਾ ਚਲਦਾ ਹੈ)। ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਟਾਈਮਆਉਟ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਠੀਕ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai 'ਤੇ ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ (koder.ai), ਤਾਂ Planning Mode ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਥਾਂ ਹੈ ਆਪਣੇ ਅੱਪਲੋਡ ਸਟੇਟ ਅਤੇ ਐਂਡਪੋਇੰਟ ਪਹਿਲਾਂ ਨਕਸ਼ਾ ਕਰਨ ਲਈ, ਫਿਰ ਉਸ ਫਲੋ ਦੇ ਆਲੇ ਦੁਆਲੇ ਬੈਕਐਂਡ ਅਤੇ UI ਜਨਰੇਟ ਕਰਨ ਲਈ। Snapshots ਅਤੇ rollback ਵੀ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸੀਮਾਵਾਂ ਜਾਂ ਸਕੈਨ ਨਿਯਮ ਟਿਊਨ ਕਰ ਰਹੇ ਹੋ।
Use direct-to-object-storage uploads with short-lived signed URLs so your app servers don’t stream file bytes. Keep your backend focused on authorization decisions and recording upload state, not moving gigabytes.
Check twice: once when you create the upload and issue a signed URL, and again when you finalize and when you serve a download. Signed URLs are just a transport tool; your app still needs permission checks tied to the file record and its tenant/workspace.
Treat it as a state machine so retries and partial failures don’t create security gaps. A common flow is requested, uploaded, scanned, approved, rejected, and you only allow downloads when the status is approved.
Put a hard byte limit into the signed URL policy (or pre-signed POST conditions) so storage rejects oversized files early. Enforce the same limit again during finalize using storage-reported metadata so clients can’t bypass it.
Don’t trust the filename extension or browser MIME type. Detect type from the file’s actual bytes after upload (for example, magic bytes) and compare it to a tight allowlist for that specific feature.
Don’t block the user on scanning. Accept the upload quickly, quarantine it, run scanning in the background, and only allow download/preview after a clean result is recorded.
Pick a consistent policy: quarantine and remove access, or delete if you don’t need it for investigation. Give the user a calm, specific message and keep audit data so support can explain what happened without opening the file.
Never use the user-provided filename or path as the storage key. Generate an unguessable object key (like a UUID) and store the original name only as display metadata after normalizing it.
Use multipart or chunked uploads so unstable connections don’t restart from zero. Keep retries capped, set timeouts intentionally, and add a hard deadline for the whole upload so one client can’t tie up resources indefinitely.
Use a small upload record with owner, tenant/workspace, object key, status, timestamps, detected type, size, and checksum if you use one. If you build on Koder.ai, this fits well with a Go backend, PostgreSQL tables for uploads, and background jobs for scanning while keeping the UI responsive.