ਜਨਤਕ ਫਾਰਮ ਜਮ੍ਹਾਂ ਕੀਤੀਆਂ ਸਮੱਗਰੀਆਂ ਨੂੰ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਵਿੱਚ ਕਿਵੇਂ ਆਯਾਤ ਕਰੀਏ

ਜਨਤਕ ਫਾਰਮ ਜੋ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਨਾਲ ਕਦੇ ਗੱਲ ਨਹੀਂ ਕਰਦਾ, ਫਿਰ ਵੀ ਉਹ ਡੇਟਾ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਸਦਾ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਨੂੰ ਮੁਲਾਂਕਣ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਟਨਲ ਸਿਰਫ਼ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕੌਣ ਕਿਸ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਡਾਊਨਲੋਡ ਤੋਂ ਬਾਅਦ ਦੀ ਹਰ ਚੀਜ਼ ਇੱਕ ਆਯਾਤ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਉਹ ਨਿੱਜੀ ਪਾਸੇ ਦੀ ਹੈ। ਇਹ ਗਾਈਡ ਇੱਕ ਜਮ੍ਹਾਂ ਕਰਨ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਰਿਕਾਰਡ ਕੀਤੇ ਅੰਦਰੂਨੀ ਰਿਕਾਰਡ ਤੱਕ ਫਾਲੋ ਕਰਦੀ ਹੈ।

ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿੱਥੇ ਜਮ੍ਹਾਂ ਕਰਨ ਆਉਂਦਾ ਹੈ

ਬ੍ਰਾਊਜ਼ਰ ਜਨਤਕ ਐਂਡਪੁਆਇੰਟ 'ਤੇ ਭੇਜਦਾ ਹੈ, ਜੋ ਨਿਯੰਤਰਿਤ ਪ੍ਰਾਪਤੀ ਭੰਡਾਰ ਵਿੱਚ ਇੱਕ ਕਤਾਰ ਲਿਖਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ। ਉਹ ਭੰਡਾਰ ਹੀ ਹੈਂਡਓਵਰ ਬਿੰਦੂ ਹੈ, ਅਤੇ ਜਨਤਕ ਪੱਧਰ ਸਿਰਫ਼ ਉਸੇ ਵਿੱਚ ਲਿਖ ਸਕਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੱਚਾ ਡੇਟਾ ਉੱਥੇ ਹੀ ਬਿਨਾਂ ਬਦਲੇ ਰੱਖੋ, ਉਸਦੇ ਆਉਣ ਦੇ ਸਮੇਂ ਅਤੇ ਸਥਿਰ ਰਿਕਾਰਡ ਪਹਿਚਾਣਕਰਤਾ ਸਮੇਤ।

ਫਿਰ ਨਿੱਜੀ ਕਰਮਚਾਰੀ ਟਨਲ ਰਾਹੀਂ ਬਕਾਇਆ ਕਤਾਰਾਂ ਖਿੱਚਦਾ ਹੈ ਅਤੇ ਹਰ ਇੱਕ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ। ਉਹ ਆਪਣੀ ਹੀ ਪਹਿਚਾਣ ਹੇਠ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਗਲੇ ਭਾਗ ਦਾ ਵਿਸ਼ਾ ਹੈ।

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

ਆਯਾਤਕਰਤਾ ਨੂੰ ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਅਧਿਕਾਰ ਦਿਓ

ਜਨਤਕ ਵੈੱਬ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਲਿਖਣ ਵਾਲੀ ਪਹਿਚਾਣ ਦੋ ਵੱਖਰੇ ਪ੍ਰਿੰਸੀਪਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜਨਤਕ ਸਰਵਰ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਪ੍ਰਬੰਧ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਉਸਨੂੰ ਫਾਰਮ ਡੇਟਾ ਪਹੁੰਚਾਉਣਾ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਪਾਸਿਆਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਖਾਤਾ ਕਿਸੇ ਵੀ ਵੈੱਬ ਬੱਗ ਨੂੰ ਅੰਦਰੂਨੀ ਲਿਖਤ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਕਰਮਚਾਰੀ ਨੂੰ ਆਪਣੇ ਪਹਿਚਾਣ ਪੱਤਰ ਜਾਰੀ ਕਰੋ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਆਯਾਤ ਕਾਰਵਾਈ ਤੱਕ ਸੀਮਿਤ ਕਰੋ, ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਹਰ ਆਯਾਤ ਕਿਸ ਪ੍ਰਿੰਸੀਪਲ ਨੇ ਕੀਤਾ। ਇਹੀ ਵੱਖਰਾਵ ਟਨਲ ਸੀਮਾ ਨੂੰ ਸਜਾਵਟੀ ਨਹੀਂ ਬਲਕਿ ਅਰਥਪੂਰਨ ਬਣਾਉਂਦਾ ਹੈ।

ਇਹ ਵੀ ਸੀਮਿਤ ਕਰੋ ਕਿ ਕਰਮਚਾਰੀ ਕਿਹੜੇ ਸਰੋਤ ਤੋਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਜੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਕਿਊ ਜਾਂ ਟ੍ਰਾਂਸਫਰ ਸੇਵਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਹ ਸੇਵਾ ਆਪਣੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਰੱਖਦੀ ਹੈ, ਕਿਉਂਕਿ VPN ਪੇਲੋਡ ਦੇ ਅੰਦਰ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਕਰਦਾ।

ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲਾ ਫੰਕਸ਼ਨ ਵੀ ਉਸੇ ਸਮੀਖਿਆ ਤੋਂ ਛੋਟ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਤੱਕ ਇਹ ਚੱਲਦਾ ਹੈ, ਇਸਦੀ ਨੈੱਟਵਰਕ ਸਥਿਤੀ ਅਤੇ ਪਹਿਚਾਣ ਪੱਤਰ ਅਜੇ ਵੀ ਅਧਿਕਾਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਛੋਟਾ ਜੀਵਨ ਸਿਰਫ਼ ਵਿੰਡੋ ਨੂੰ ਤੰਗ ਕਰਦਾ ਹੈ। ਜੀਵਨ ਕਾਲ ਇਹ ਤੈਅ ਕਰਨ ਦਾ ਬਦਲ ਨਹੀਂ ਕਿ ਪਹਿਚਾਣ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦੀ ਹੈ।

ਅੰਦਰੂਨੀ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਜਨਤਕ ਫਾਰਮ ਖੇਤਰ ਉਲਟਾ ਸਾਬਤ ਹੋਣ ਤੱਕ ਹਮਲਾਵਰ ਦੇ ਕਾਬੂ ਵਾਲਾ ਟੈਕਸਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ OWASP ਦੀ ਇਨਪੁਟ ਪ੍ਰਮਾਣਿਕਤਾ ਗਾਈਡ ਠੀਕ ਇਸੇ ਕਾਰਨ ਬੈਕਐਂਡ ਫੀਡਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੇ ਸਰੋਤਾਂ ਵਿੱਚ ਗਿਣਦੀ ਹੈ। ਇਨਕ੍ਰਿਪਟਿਡ ਟ੍ਰਾਂਸਫਰ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਾਈਟਸ ਸਹੀ ਸਲਾਮਤ ਪਹੁੰਚੇ, ਇਹ ਨਹੀਂ ਕਿ ਉਹ ਕੋਈ ਮਨਜ਼ੂਰ ਬੇਨਤੀ ਦਰਸਾਉਂਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਕਦਮ ਤੋਂ ਪਹਿਲਾਂ ਪਾਰਸ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਤਾਂ ਜੋ ਮਾੜੀ ਕਤਾਰ ਕਦੇ ਵੀ ਕਾਰਵਾਈ ਕਰ ਸਕਣ ਵਾਲੇ ਕੋਡ ਰਸਤੇ ਤੱਕ ਨਾ ਪਹੁੰਚੇ।

ਮਨਜ਼ੂਰ ਖੇਤਰ, ਉਹਨਾਂ ਦੇ ਫਾਰਮੈਟ, ਉਹਨਾਂ ਦੇ ਆਕਾਰ ਅਤੇ ਪਾਲਣਾ ਕਰਨ ਵਾਲੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਤਾਰੀਖ਼ ਸਹੀ ਢੰਗ ਨਾਲ ਬਣੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਮੰਗੀ ਕਾਰਵਾਈ ਲਈ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਅੰਦਰੂਨੀ ਖਾਤਾ ਜਾਂ ਮਨਜ਼ੂਰੀ ਸਥਿਤੀ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਪੇਲੋਡ ਆਪਣੇ ਆਪ ਨੂੰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਦੇ ਸਕਣਾ ਚਾਹੀਦਾ।

ਰੱਦ ਕੀਤੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਸੁਧਾਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਸਮੀਖਿਆ ਨਤੀਜੇ ਵੱਲ ਭੇਜੋ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਸ਼ੈੱਲ ਜਾਂ ਕੱਚੇ ਡੇਟਾਬੇਸ ਇੰਟਰਫੇਸ ਵੱਲ ਨਾ ਭੇਜੋ। ਰਿਕਾਰਡ ਪਹਿਚਾਣਕਰਤਾ ਅਤੇ ਅਸਫਲ ਨਿਯਮ ਲੌਗ ਕਰੋ, ਬਿਨੈਕਾਰ ਵੱਲੋਂ ਟਾਈਪ ਕੀਤਾ ਹਰ ਖੇਤਰ ਨਹੀਂ।

ਇੱਕ ਕਾਰਵਾਈ 'ਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਬਿੰਦੂ ਬਣਾਓ

ਜੇ submission-1042 ਰਿਕਾਰਡ ਪਹਿਲੀ ਪੁਸ਼ਟੀ ਗੁੰਮ ਹੋਣ ਕਾਰਨ ਦੋ ਵਾਰ ਖਿੱਚਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਰਮਚਾਰੀ ਨੂੰ ਸਰੋਤ ਰਿਕਾਰਡ ਅਤੇ ਉਸਦੇ ਦਰਜ ਨਤੀਜੇ ਨੂੰ ਪਛਾਣਨ ਦਾ ਟਿਕਾਊ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ। ਕੰਮ ਇੱਕ ਵਾਰ ਚਲਾਉਣ ਵਾਲਾ ਸ਼ਡਿਊਲ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਹਰ ਕਤਾਰ ਇੱਕ ਵਾਰ ਲਾਗੂ ਹੋਈ। ਦੁਹਰਾ ਡਿਲਿਵਰੀ ਆਮ ਹੈ, ਇਸ ਲਈ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇਸਨੂੰ ਸਮੇਟਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਪਣਾ ਲੈਣ-ਦੇਣ ਅਤੇ ਦੁਹਰਾਅ ਸੰਭਾਲਣ ਵਾਲਾ ਵਿਧੀ ਵਰਤੋ, ਅਤੇ ਸਰੋਤ ਪਹਿਚਾਣਕਰਤਾ, ਨਤੀਜਾ ਅਤੇ ਪੁਸ਼ਟੀ ਇੱਕੋ ਲਗਾਤਾਰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ। ਇੱਛਤ ਕਾਰਵਾਈ ਦਰਜ ਹੋਣ ਜਾਂ ਟਿਕਾਊ ਰੂਪ ਵਿੱਚ ਸੌਂਪੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਹੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਬਾਈਟਸ ਡਾਊਨਲੋਡ ਹੋਣ ਕਾਰਨ ਪ੍ਰਾਪਤੀ ਕਤਾਰ ਕਦੇ ਵੀ ਨਾ ਮਿਟਾਓ।

ਫਿਰ ਤਿੰਨ ਫਿਕਸਚਰਾਂ ਨਾਲ ਇਹ ਸਾਬਤ ਕਰੋ: ਵੈਧ ਕਤਾਰ, ਗਲਤ ਢਾਂਚੇ ਵਾਲੀ ਕਤਾਰ, ਅਤੇ ਉਹੀ ਨਿਯੰਤਰਿਤ ਸਰੋਤ ਪਹਿਚਾਣਕਰਤਾ ਦੋ ਵਾਰ ਪਹੁੰਚਾਇਆ ਗਿਆ। ਹਰ ਇੱਕ ਉਸੇ ਐਂਡਪੁਆਇੰਟ ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ ਜੋ ਕਰਮਚਾਰੀ ਵਰਤਦਾ ਹੈ।

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

ਪਹਿਲੀਆਂ ਦੋ ਕਤਾਰਾਂ ਵੱਖਰੀਆਂ ਅੰਦਰੂਨੀ ਅਵਸਥਾਵਾਂ ਵਿੱਚ ਖਤਮ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਤੀਜੀ ਨੇ ਦੂਜੀ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਉਸ ਸਰੋਤ ਰਿਕਾਰਡ ਲਈ ਪਹਿਲਾਂ ਹੀ ਦਰਜ ਪਹਿਚਾਣਕਰਤਾ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਹੋਰ ਕੋਈ ਵੀ ਨਤੀਜਾ ਮਤਲਬ ਹੈ ਕਿ ਆਯਾਤ ਅਜੇ ਦੁਹਰਾਉਣ ਯੋਗ ਨਹੀਂ।