08 ਨਵੰ 2025·8 ਮਿੰਟ
ਫਾਰਮਾਂ ਲਈ ਸਪੈਮ ਸੁਰੱਖਿਆ: CAPTCHAs ਬਿਨਾਂ ਸੁਚੱਜੀਆਂ ਸਾਈਨਅਪਸ
honeypots, rate limits, challenge pages ਅਤੇ validation ਵਰਤ ਕੇ ਫਾਰਮਾਂ ਲਈ ਅਮਲਣਯੋਗ ਸਪੈਮ ਸੁਰੱਖਿਆ ਸਿੱਖੋ ਤਾਂ ਕਿ ਅਸਲੀ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਸਾਈਨ ਅਪ ਕਰ ਸਕਣ।
honeypots, rate limits, challenge pages ਅਤੇ validation ਵਰਤ ਕੇ ਫਾਰਮਾਂ ਲਈ ਅਮਲਣਯੋਗ ਸਪੈਮ ਸੁਰੱਖਿਆ ਸਿੱਖੋ ਤਾਂ ਕਿ ਅਸਲੀ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਸਾਈਨ ਅਪ ਕਰ ਸਕਣ।
ਫਾਰਮ ਸਪੈਮ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਫਾਰਮ ਹਮਲਿਆਂ ਲਈ ਸਸਤੇ ਹੁੰਦੇ ਹਨ। ਕੁਝ ਦੁਰੁਪਯੋਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਟੋਮੇਟੇਡ ਹੁੰਦੇ ਹਨ: ਬੋਟ ਘੰਟਿਆਂ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਸਾਈਨਅਪ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਕੁਝ ਸਕ੍ਰਿਪਟ ਸਿੱਧਾ ਤੁਹਾਡੇ endpoint 'ਤੇ ਪੋਸਟ ਕਰ ਦਿੰਦੇ ਹਨ (ਪੇਜ skip ਕਰਕੇ)। ਅਤੇ ਕੁਝ ਘੱਟ-ਲਾਗਤ ਮਨੁੱਖੀ ਮਿਹਨਤ ਨਾਲ ਹੁੰਦੇ ਹਨ: click farms ਜੋ ਐਸੇ ਲੀਡ ਭੇਜਦੇ ਹਨ ਜੋ ਬੇਸਿਕ ਜਾਂਚਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਲਈ ਪੂਰੇ ਦਿਖਦੇ ਹਨ।
ਅਮਲ ਵਿੱਚ ਇਹ ਅਕਸਰ ਨਾਜੁਕ ਨਹੀਂ ਹੁੰਦਾ: ਫੇਕ ਸਾਈਨਅਪ ਜੋ ਕਦੇ verify ਨਹੀਂ ਕਰਦੇ, ਲਿੰਕਾਂ ਨਾਲ ਭਰੇ ਹੋਏ ਜੰਕ "contact us" ਸੁਨੇਹੇ, ਕੂਪਨ ਦੁਰੁਪਯੋਗ, login ਫਾਰਮਾਂ 'ਤੇ credential stuffing, ਜਾਂ ਇੱਕ ਲਗਾਤਾਰ ਧਾਰਾ ਜੋ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਭਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਦਾ ਸਮਾਂ ਖਾਂਦਾ ਹੈ।
ਫਾਰਮਾਂ ਲਈ ਸਪੈਮ ਸੁਰੱਖਿਆ ਦੀ ਨੀਅਤ ਇੱਕ ਅਟੁੱਟ ਦੀਵਾਰ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਦੁਰੁਪਯੋਗ ਨੂੰ ਉਸ ਪੱਧਰ ਤੱਕ ਘੱਟ ਕਰਨ ਬਾਰੇ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਰਹਿ ਸਕੋ, ਜਦੋਂ ਕਿ ਅਸਲੀ ਲੋਕਾਂ ਲਈ ਰਾਹ ਮulusasa ਰਹੇ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਕਦੇ-ਕਦਾਈ ਥੋੜ੍ਹਾ ਜਿਹਾ ਸਪੈਮ ਹੋ ਕੇ ਵੀ ਰਹਿ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਦੇ-ਕਦੇ ਤੁਸੀਂ ਕੁਝ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਚੈਲੇਂਜ ਵੀ ਦੇ ਸਕਦੇ ਹੋ। ਤੁਹਾਡਾ ਕੰਮ ਹੈ ਕਿ ਦੂਜਾ ਨੰਬਰ ਨਜ਼ਦੀਕ ਜ਼ੀਰੋ ਰੱਖੋ।
ਕੀਮਤੀ ਨਤੀਜੇ ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਤੁਸੀਂ ਮਾਪ ਸਕਦੇ ਹੋ, ਨਾ ਕਿ "ਹੋਰ ਸੁਰੱਖਿਆ ਜੋੜੋ"। ਕੁਝ ਸਧਾਰਣ ਸਿਗਨਲਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ: conversion (view ਤੋਂ submit, submit ਤੋਂ verified), false positives (ਅਸਲ ਯੂਜ਼ਰ ਰੋਕੇ ਜਾਂ ਚੈਲੇਂਜ ਕੀਤੇ ਗਏ), support ਸ਼ਿਕਾਇਤਾਂ ("ਮੈਂ ਸਾਈਨ ਅਪ ਨਹੀਂ ਕਰ ਸਕਦਾ"), ਸਪੈਮ ਵਾਲੀਅਮ ਅਤੇ ਖਰਚ (ਮੋਡਰੇਸ਼ਨ ਸਮਾਂ, ਈਮੇਲ deliverability ਸਮੱਸਿਆਵਾਂ), ਅਤੇ ਅਸਲ ਦੁਰੁਪਯੋਗ ਪ੍ਰਭਾਵ (ਫਰੌਡ, ਕੋਟਾ ਬਰਨ, ਸਿਸਟਮ ਲੋਡ)।
ਇਹ ਵੀ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇੱਥੇ ਕੀ ਨਹੀਂ ਹੱਲ ਕਰ ਰਹੇ: ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਵਿਅਕਤੀ ਖ਼ਿਲਾਫ਼ ਟਾਰਗੇਟ ਕੀਤੇ ਹਮਲੇ ਜਾਂ ਜਟਿਲ account takeovers ਲਈ ਵੱਖ-ਵੱਖ ਨਿਯੰਤਰਣਾਂ ਦੀ ਲੋੜ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai 'ਤੇ ਸਾਈਨਅਪ ਫਲੋ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਟੀਚੇ ਬਦਲਦੇ ਨਹੀਂ: endpoint ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ, friction ਘੱਟ ਰੱਖੋ, ਅਤੇ ਸਿਰਫ਼ ਉਹਨਾਂ ਤੇ ਵਧੇਰੇ ਜਾਂਚ ਜੋੜੋ ਜਦੋਂ ਵਿਹੇਵਿਅਰ ਸੰਦੇਹਜਨਕ ਲੱਗੇ।
"ਸਪੈਮ" ਕੁਝ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਸਲਾਹ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਆਮ ਪੈਟਰਨ:
CAPTCHAs ਅਕਸਰ ਤੇਜ਼ ਫਿਕਸ ਵਜੋਂ ਜੋੜੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਹਰ ਜਗ੍ਹਾ ਉਨ੍ਹਾਂ ਦਾ ਇਸਤੇਮਾਲ conversion ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇਹ mobile 'ਤੇ friction ਵਧਾਉਂਦੇ ਹਨ, autofill ਨੂ ਭੰਗ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਦੇ-ਕਦੇ ਅਸਲ ਲੋਕਾਂ ਨੂੰ fail ਕਰਦੇ ਹਨ (accessibility ਮੁੱਦੇ, ਧੀਮੀ ਕਨੈਕਸ਼ਨ, ਐੱਡਜ ਕੇਸ)। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਵਧੀਆ ਯੂਜ਼ਰ ਬੋਟ ਟੈਕਸ ਭੁਗਤਦੇ ਹਨ ਜਦੋਂ ਕਿ ਡਟੇ ਹੋਏ ਹਮਲਾਵਰ ਕੋਸ਼ਿਸ਼ ਜਾਰੀ ਰੱਖਦੇ ਹਨ।
ਇੱਕ ਬਿਹਤਰ ਮਾਡਲ spam filters ਦੇ ਨੇੜੇ ਹੈ: ਕੁਝ ਸ਼ੋਰ ਦੀ ਉਮੀਦ ਰੱਖੋ, ਜ਼ਾਹਰਦੀ automation ਨੂੰ ਰੋਕੋ, ਅਤੇ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਵਧੇਰੇ friction ਜੋੜੋ ਜਦੋਂ ਸੈਸ਼ਨ ਸੰਦੇਹਜਨਕ ਲੱਗੇ।
ਸਭ ਤੋਂ ਵਧੀਆ ਸਪੈਮ ਸੁਰੱਖਿਆ ਇੱਕ ਵੱਡੇ ਗੇਟ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਕੁਝ ਛੋਟੀ ਜਾਂਚਾਂ ਦਾ ਜੋੜ ਹੈ ਜੋ ਸਸਤੇ, ਜ਼ਿਆਦਾਤਰ ਅਦਿੱਖੇ, ਅਤੇ ਕੇਵਲ ਟ੍ਰੈਫਿਕ ਜੋਖਮ ਵਾਲੀ ਹੋਣ 'ਤੇ ਕਠੋਰ ਹੁੰਦੇ ਹਨ।
ਅਜਿਹੇ ਉਦਯਮਾਂ ਤੋਂ ਸ਼ੁਰੂਆਤ ਕਰੋ ਜੋ ਅਸਲ ਲੋਕਾਂ ਨੂੰ ਕਦੇ ਮਹਿਸੂਸ ਨਹੀ ਹੁੰਦੇ: ਮਜ਼ਬੂਤ ਸਰਵਰ-ਸਾਈਡ ਵੈਲੀਡੇਸ਼ਨ, ਇੱਕ ਸ਼ਾਂਤ honeypot ਫੀਲਡ, ਅਤੇ ਬੇਸਿਕ rate limits। ਇਹ ਬਹੁਤ ਸਾਰੇ ਬੋਟਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ ਬਿਨਾਂ ਵਾਧੂ ਕਲਿੱਕਾਂ ਦੇ।
ਜਦੋਂ ਜੋਖਮ ਵਧਦਾ ਹੈ, friction ਨੂੰ ਕਦਮ-ਬ-ਕਦਮ ਵਧਾਓ। ਜ਼ਿਆਦਾਤਰ ਯਾਤਰੀਆਂ ਲਈ ਅਮਨ ਰਾਹ ਰੱਖੋ, ਪਰ ਸੰਦੇਹਜਨਕ ਪੈਟਰਨਾਂ ਲਈ ਨਿਯਮ ਕਠੋਰ ਕਰੋ ਜਿਵੇਂ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ, ਅਜੀਬ user agents, ਇੱਕੋ-ਏਮੇਲ ਡੋਮੇਨ ਦਾ ਦੁਹਰਾਉਂ, ਜਾਂ ਇੱਕ IP ਰੇਂਜ ਤੋਂ ਬਰਸਟ। ਲਾਗਡ-ਇਨ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਨੇਾਨੋਨਿਮ ਟ੍ਰੈਫਿਕ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਹਲਕਾ ਸੁਪੁਰਦ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਵਿਸ਼ਵਾਸ ਅਤੇ ਇਤਿਹਾਸ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਸਟੈਕ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦਾ ਹੈ:
ਪਹਿਲਾਂ ਹੀ ਇਹ ਤੈਅ ਕਰੋ ਕਿ "fail" ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਕਿਉਂਕਿ ਹਰ failure ਨੂੰ hard block ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਕ ਅਜੀਬ ਲੱਗਣ ਵਾਲੀ ਸਾਈਨਅਪ ਕਿਸੇ ਯਾਤਰੀ ਦਾ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਯਾਦਵਾਸ਼ਤ ਵਿੱਚ ਯਾਤਰਾ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਤਿੰਨ ਨਤੀਜੇ ਜ਼ਿਆਦਾਤਰ ਕੇਸ ਕਵਰ ਕਰਦੇ ਹਨ:
ਉਦਾਹਰਣ: ਤੁਹਾਨੂੰ 10 ਮਿੰਟ ਵਿੱਚ 200 ਸਾਈਨਅਪ ਕਿੱਝ ਹੀ random emails ਨਾਲ ਵੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ। throttle ਅਤੇ ਕਠੋਰ validation ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਪੈਟਰਨ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਉਸ ਟ੍ਰੈਫਿਕ ਸਲਾਈਸ ਨੂੰ ਚੈਲੈਂਜ ਪੇਜ਼ ਦਿਖਾਓ ਜਦੋਂ ਕਿ ਹੋਰ ਸਭ ਲੋਕ ਆਮ ਤੌਰ ਤੇ ਸਾਈਨਅਪ ਕਰਦੇ ਰਹਿਣ।
ਜੇ ਤੁਸੀਂ ਐਸਾ ਸਪੈਮ ਸੁਰੱਖਿਆ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਅਸਲ ਲੋਕਾਂ ਲਈ ਅਦਿੱਖੀ ਰਹੇ, ਤਾਂ ਛੋਟੀ ਬੇਸਲਾਈਨ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਦੇ ਨਾਲ ਟਿਊਨ ਕਰੋ।
ਬ੍ਰਾਉਜ਼ਰ ਤੋਂ ਆਉਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਅਣ-ਟਰੱਸਟਡ ਸਮਝੋ। ਸਰਵਰ 'ਤੇ required fields, length limits, allowed characters ਅਤੇ ਬੇਸਿਕ ਨਿਯਮ (email email ਵਰਗਾ ਲੱਗੇ, phone phone ਵਰਗਾ ਲੱਗੇ) ਲਾਗੂ ਕਰੋ। ਇੰਪੁੱਟ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਵੀ ਕਰੋ: spaces ਕੱਟੋ ਅਤੇ emails ਨੂੰ lower-case ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ duplicates ਜਾਂ ajeeb variants ਨਾਲ data store ਨਾ ਕਰੋ।
ਤੁਹਾਨੂੰ ਬਹੁਤ ਫੈਂਸੀ ਡਿਟੈਕਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰਾ ਦੁਰੁਪਯੋਗ ਫੜ ਸਕੋ। ਕੁਝ ਸਧਾਰਣ ਸਿਗਨਲਾਂ ਨੂੰ ਜੋੜੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਸਕੋਰ ਬਨਾਓ।
ਆਮ ਉੱਚ-ਸਿਗਨਲ ਚੈੱਕ:
ਹਰ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਲੌਗ ਕਰੋ: timestamp, IP (ਜਾਂ hashed IP), user agent, form name, decision (allow, soft block, hard block), ਅਤੇ ਕਿਹੜੇ ਸਿਗਨਲ ਟ੍ਰਿਗਰ ਹੋਏ। ਇਹਨਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ consistent ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਪੈਟਰਨ ਤੇਜ਼ੀ ਨਾਲ ਦੇਖ ਸਕੋ।
ਹਰ ਸਕੋਰ ਲੈਵਲ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਮੋਬਾਈਲ ਅਤੇ ਡੈਸਕਟਾਪ 'ਤੇ ਅਸਲ ਯੂਜ਼ਰਾਂ (ਜਾਂ ਸਹਿਯੋਗੀ) ਨਾਲ ਟੈਸਟ ਕਰੋ। ਫਿਰ ਬੋਟ-ਵਾਂਗ ਵਿਹੇਵਿਅਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ: ਜੰਕ ਪੇਸਟ ਕਰੋ, ਤੁਰੰਤ submit ਕਰੋ, 20 ਵਾਰੀ ਦੁਹਰਾਓ। ਜੇ ਅਸਲੀ ਸਾਈਨਅਪ ਰੋਕੇ ਜਾ ਰਹੇ ਹਨ, ਤਾਂ ਇੱਕ-ਇੱਕ ਨਿਯਮ ਨੂੰ ਢੀਲਾ ਕਰੋ ਅਤੇ ਆਪਣੇ ਲੌਗ ਛਾਂਟੀ ਦੇਖੋ।
Honeypot ਇੱਕ ਐਸਾ ਫੀਲਡ ਹੁੰਦਾ ਹੈ ਜੋ ਅਸਲ ਲੋਕ ਕਦੇ ਨਹੀਂ ਵੇਖਦੇ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਬੋਟ ਭਰ ਦੇਂਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਸਪੈਮ ਟੂਲ ਹਰ ਇੰਪੁੱਟ ਨੂੰ ਭਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਐਸੇ ਫੀਲਡ ਜਿਹੜੇ "name", "email" ਜਾਂ "website" ਵਰਗੇ ਲੱਗਦੇ ਹਨ।
ਰੱਖਣ ਦੀ ਥਾਂ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਫੀਲਡ DOM ਵਿੱਚ ਰਹੇ (ਤਾਂ ਕਿ ਬੋਟ ਇਨ੍ਹਾਂ ਨੂੰ "ਦੇਖ" ਸਕਣ), ਪਰ ਵਿਜ਼ੂਅਲੀ ਤੌਰ 'ਤੇ ਛੁਪਾਇਆ ਜਾਵੇ ਬਿਨਾਂ display: none ਜਾਂ HTML hidden attribute ਵਰਤਣ ਦੇ।
ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਨਾ ਹੋਵੇ, ਇਸ ਲਈ accessibility ਅਤੇ autofill ਨੂੰ ਪਹਿਲੀ ਦਰਜੇ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸਮਝੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ honeypot ਕੀਬੋਰਡ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਨਾ ਹੋਵੇ, screen readers ਦੁਆਰਾ announce ਨਾ ਹੋਵੇ, ਅਤੇ password managers ਨੂੰ ਆਕਰਸ਼ਿਤ ਨਾ ਕਰੇ।
ਸੁਰੱਖਿਅਤ ਚੈੱਕਲਿਸਟ:
display: none)aria-hidden="true" ਹੋਵੇtabindex="-1" ਜੋੜੋ ਤਾਂ ਕਿ ਇਹ tab order ਵਿੱਚ ਨਾ ਆਏautocomplete="off" (ਜਾਂ ਕੋਈ ਐਸਾ ਮੁੱਲ ਜੋ autofill ਕੋਲੋਂ ਸੰਭਵ ਤੌਰ 'ਤੇ ਨਹੀਂ ਭਰਿਆ ਜਾਏ)ਜਦੋਂ ਇਹ ਭਰਿਆ ਜਾਵੇ ਤਾਂ ਤੁਹਾਡਾ ਐਕਸ਼ਨ ਜੋਖਮ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਘੱਟ-ਖਤਰੇ ਵਾਲੇ ਫਾਰਮਾਂ (newsletter) ਲਈ quietly submission drop ਕਰਨਾ ਕਾਫ਼ੀ ਹੋ ਸਕਦਾ ਹੈ। ਸਾਈਨਅਪ ਜਾਂ password reset ਲਈ ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਸਿਗਨਲ ਸਮਝੋ ਅਤੇ escalate ਕਰੋ: review ਲਈ queue ਕਰੋ ਜਾਂ ਯੂਜ਼ਰ ਨੂੰ one-time challenge step 'ਤੇ ਭੇਜੋ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਕਿਸੇ ਅਸਲੀ ਯੂਜ਼ਰ ਜਿਸ ਦੀ ਬਰਾਊਜ਼ਰ ਨੇ ਕਦੇ-ਕਦੇ ਕੁਝ ਗਲਤ autofill ਕੀਤਾ ਹੋਵੇ, ਨੂੰ ਸਜ਼ਾ ਨਹੀਂ ਦਿੰਦੇ।
ਬੋਟ-ਲਰਣਿੰਗ ਘੱਟ ਕਰਨ ਲਈ, honeypot field name ਰੋਟੇਟ ਕਰੋ ਕਦੇ-ਕਦੇ। ਉਦਾਹਰਣ ਲਈ, ਹਰ form render ਤੇ ਇੱਕ random field name ਜਨਰੇਟ ਕਰੋ, ਇਸਨੂੰ ਸਰਵਰ-ਸਾਈਡ 'ਤੇ store ਕਰੋ (ਜਾਂ token ਵਿੱਚ sign ਕਰੋ), ਅਤੇ ਕਿਸੇ ਵੀ non-empty value ਨੂੰ ਇੱਕ ਮਜ਼ਬੂਤ ਸਪੈਮ ਸਿਗਨਲ ਮੰਨੋ। ਇਹ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਹੈ ਜੋ hard-coded ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕਾਫ਼ੀ ਬੇਅਸਰ ਕਰ ਦਿੰਦਾ ਹੈ।
Rate limiting ਫਾਰਮਾਂ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਣ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ CAPTCHA ਹੱਲ ਕਰਨ 'ਤੇ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦੀ। ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਦੁਰੁਪਯੋਗ ਨੂੰ ਧੀਰਾ ਕਰੋ ਤੇ ਆਮ ਯੂਜ਼ਰਾਂ ਨੂੰ ਇਸਦਾ ਪਤਾ ਨਾ ਲੱਗੇ।
ਕੁਝ keys ਚੁਣੋ ਜਿਨ੍ਹਾਂ 'ਤੇ rate limit ਲਗਾਈ ਜਾਏ। ਸਿਰਫ਼ IP ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਇਹ ਪਹਿਲਾ ਪਰਤ ਹੈ। ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ device signal (cookie ਜਾਂ local storage ID) ਅਤੇ account signal ਵੀ ਜੋੜੋ। ਦੋ-ਤਿੰਨ ਸਿਗਨਲਾਂ ਨਾਲ ਤੁਸੀਂ ਬੋਟਾਂ 'ਤੇ ਕਠੋਰ ਅਤੇ ਲੋਕਾਂ 'ਤੇ ਨਿਆਇਪੂਰਨ ਰਹਿ ਸਕਦੇ ਹੋ।
ਵੱਖ-ਵੱਖ ਫਾਰਮਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਲਿਮਿਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:
ਹਾਰਡ ਬਲਾਕਿੰਗ ਦੀ ਥਾਂ cooldown delays ਪਸੰਦ ਕਰੋ ਜਦੋਂ ਦੁਹਰਾਈ ਗਈ ਨਾਕਾਮੀ ਹੋਵੇ। 3 ਨਾਕਾਮ ਲੌਗਿਨਾਂ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟਾ ਦੇਰੀ ਜੋੜੋ। 6 ਤੋਂ ਬਾਅਦ ਵੱਡੀ ਦੇਰੀ। ਅਸਲੀ ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ-ਦੋ ਵਾਰੀ ਹੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਬੋਟ ਲਗਾਤਾਰ ਹਠ ਕਰਦੇ ਹਨ ਅਤੇ ਆਪਣਾ ਸਮਾਂ ਖ਼ਤਮ ਕਰ देते ਹਨ।
ਸ਼ੇਅਰਡ IPs ਇੱਕ ਕਲਾਸਿਕ ਗੋਚਾ ਹਨ। ਸਕੂਲ, ਦਫ਼ਤਰ ਅਤੇ mobile carriers ਬਹੁਤ ਸਾਰੇ ਅਸਲੀ ਲੋਕ ਇਕ IP ਦੇ ਪਿੱਛੇ ਰੱਖ ਸਕਦੇ ਹਨ। ਉੱਥੇ ਨਰਮ ਲਿਮਿਟਾਂ ਵਰਤੋ: per device ਨੂੰ ਤਰਜੀਹ ਦਿਓ, windows ਛੋਟੀ ਰੱਖੋ ਤਾਂ ਕਿ ਗਿਣਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਘਟ ਜਾਣ, ਅਤੇ ਜਵਾਬ ਵਿੱਚ "ਕਿਰਪਾ ਕਰਕੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ" ਜਿਹਾ ਸੁਨੇਹਾ ਦਿਓ ਨਾ ਕਿ ਸਥਾਈ ਬਲੌਕ।
ਆਪਣੀ ਟੀਮ ਅਤੇ ਸਪੋਰਟ ਕੰਮ ਲਈ ਇੱਕ ਛੋਟਾ allowlist ਰੱਖੋ ਤਾਂ ਕਿ ਟੈਸਟਿੰਗ protections ਨੂੰ ਟ੍ਰਿਪ ਨਾ ਕਰੇ। rate limit triggers ਨੂੰ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਸਲੀ ਵੇਖੇ ਅਨੁਸਾਰ ਟਿਊਨ ਕਰ ਸਕੋ।
ਚੈਲੈਂਜ ਪੇਜ਼ ਇੱਕ ਚੰਗਾ ਸੁਰੱਖਿਆ ਵਾਲਵ ਹੈ, ਪਰ ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਤੌਰ 'ਤੇ ਦੂਜੇ ਕਦਮ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਦਾਖਲ ਦਾ ਰਸਤਾ। ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਇਸਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਣਗੇ।
ਸਿਰਫ਼ ਸਾਫ਼ ਦੁਰੁਪਯੋਗ ਦੇ ਨਿਸ਼ਾਨਾਂ ਤੋਂ ਬਾਅਦ ਚੈਲੈਂਜ ਦਿਖਾਓ: ਇੱਕ IP ਤੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ, ਅਸੰਭਵ ਟਾਈਪਿੰਗ ਸਪੀਡ, ਸੰਦੇਹਜਨਕ user agents, ਜਾਂ ਦੁਹਰਾਈ ਗਈ ਨਾਕਾਮੀਆਂ।
ਹਲਕੀ ਫੁਲਕੀ ਚੈਲੈਂਜ ਜਿਹੜੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:
ਜਦੋਂ ਜੋਖਮ ਉੱਚ ਹੋਵੇ ਜਾਂ ਟ੍ਰੈਫਿਕ ਸਪਿਟਿਕ ਹੋਵੇ ਤਾਂ ਪੂਰਾ ਚੈਲੈਂਜ ਪੇਜ਼ ਸਮਝਦਾਰ ਹੈ: ਸਾਈਨਅਪ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਸਿੱਧਾ spike, password reset ਹਮੇਸ਼ਾ hammer ਹੋਣਾ, ਜਾਂ ਕੋਈ ਫਾਰਮ ਜੋ ਮਹਿੰਗੀ ਚੀਜ਼ (trial accounts, credits, file uploads) ਬਣਾਉਂਦਾ ਹੋਵੇ।
ਕਾਪੀ ਸ਼ਾਂਤ ਅਤੇ ਨਿਰਦਿਸ਼ਟ ਰੱਖੋ। ਲੋਕਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਕੀ ਹੋਇਆ, ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਲਵੇਗਾ। "ਸਾਡੇ ਨੂੰ ਤੁਹਾਡਾ ਇੱਕ ਛੋਟਾ ਕਦਮ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਅਕਾਉਂਟ ਬਣ ਜਾਵੇ। ਆਪਣੇ ਇਮੇਲ ਵਿੱਚ ਲਿੰਕ ਚੈੱਕ ਕਰੋ। ਇਹ 10 ਮਿੰਟ ਵਿੱਚ expire ਹੋ ਜਾਵੇਗਾ." ਅਜਿਹਾ ਸੁਨੇਹਾ vague ਚਿਤਾਵਨੀਆਂ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
ਉਹਨਾਂ ਲਈ fallback ਯੋਜਨਾ ਰੱਖੋ ਜੋ ਫਸ ਜਾਂਦੇ ਹਨ (corporate filters, inbox ਨਾਹ ਹੋਣਾ, accessibility ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ)। ਇੱਕ ਵੱਖਰਾ support ਰਾਹ ਅਤੇ ਸੁਰੱਖਿਅਤ retry ਦਿਓ। ਜੇ ਤੁਸੀਂ ਫਲੋ Koder.ai (koder.ai) ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਚੈਲੈਂਜ ਨੂੰ ਇੱਕ ਵੱਖਰਾ ਕਦਮ ਬਣਾਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਪੂਰੇ ਸਾਈਨਅਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਬਗੈਰ ਇਸਨੂੰ ਬਦਲ ਸਕੋ।
ਜ਼ਿਆਦਾਤਰ ਸਪੈਮ ਇਸ ਲਈ ਗੁਜ਼ਰ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਫਾਰਮ ਕਗਭੀ ਵੀ ਕੁਝ ਵੀ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਫੇਲ ਕਰਦਾ ਹੈ। ਚੰਗੀ ਵੈਲੀਡੇਸ਼ਨ ਜੰਕ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਰੋਕਦੀ ਹੈ, ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸਾਫ਼ ਰੱਖਦੀ ਹੈ, ਅਤੇ CAPTCHAs ਦੀ ਲੋੜ ਘਟਾਉਂਦੀ ਹੈ।
ਵੈਲੀਡੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇੰਪੁੱਟ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ। spaces ਟrim ਕਰੋ, repeated whitespace collapse ਕਰੋ, ਅਤੇ emails ਨੂੰ lower-case ਕਰੋ। phone ਨੰਬਰਾਂ ਲਈ spaces ਅਤੇ punctuation ਹਟਾ ਕੇ ਇੱਕ consistent ਫਾਰਮੈਟ ਵਿੱਚ ਰੱਖੋ। ਇਹ ਆਸਾਨ ਬਾਇਪਾਸ ਜਾਂਚਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿਵੇਂ " [email protected] " ਵੱਸ "[email protected]"।
ਫਿਰ ਉਹ ਇੰਪੁੱਟ ਰੱਦ ਕਰੋ ਜੋ ਸਾਫ਼ ਗ਼ਲਤ ਹਨ। ਸਧਾਰਣ ਸੀਮਾਵਾਂ ਬਹੁਤ ਕੁਝ ਫੜ ਲੈਂਦੀਆਂ ਹਨ: ਘੱਟੋ-ਘੱਟ ਅਤੇ ਜ਼ਿਆਦਾ ਤੋਂ ਜ਼ਿਆਦਾ ਲੰਬਾਈ, ਮਨਜ਼ੂਰ ਕੈਰੈਕਟਰ, ਅਤੇ disposable-ਲੱਗਣ ਵਾਲੇ ਪੈਟਰਨ। ਨਾਂ ਅਤੇ ਸੁਨੇਹਿਆਂ ਦੇ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ: ਆਮ ਰੂਪ ਵਿੱਚ punctuation ਦੀ ਆਗਿਆ ਦਿਓ, ਪਰ control characters ਅਤੇ ਵੱਡੇ ਬਲਾਕ repeated symbols ਰੋਕੋ।
ਉਹ ਚੈੱਕ ਜਿਹੜੇ ਆਮ ਤੌਰ 'ਤੇ ਫਾਇਦੇਮੰਦ ਹੁੰਦੇ ਹਨ:
ਉਦਾਹਰਣ: ਇੱਕ signup ਫਾਰਮ abcd1234@tempmail... ਵਰਗੇ ਖਾਤਿਆਂ ਨਾਲ ਭਰ ਜਾਵੇ ਅਤੇ ਇੱਕੋ ਜਿਹੇ bio ਟੈਕਸਟ ਨਾਲ floods ਹੋ ਜਾਵੇ। ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ normalized email 'ਤੇ dedupe ਕਰ ਸਕਦੇ ਹੋ, repeated content ਵਾਲੀਆਂ bios reject ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ same domain 'ਤੇ rate-limit ਲਗਾ ਸਕਦੇ ਹੋ। ਅਸਲ ਯੂਜ਼ਰ ਫਿਰ ਵੀ ਸਾਈਨਅਪ ਕਰ ਲੈਂਦੇ ਹਨ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਜੰਕ ਉਹਨਾਂ ਦੀਆਂ table rows ਬਣਣ ਤੋਂ ਪਹਿਲਾਂ ਮਰ ਜਾਂਦਾ ਹੈ।
Error messages ਦੋਸਤਾਨਾ ਰੱਖੋ, ਪਰ attackers ਨੂੰ ਇੱਕ checklist ਨਾ ਦਿਓ। ਇੱਕ generic "Please enter a valid email" ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਉਹਦਾ ਸਿਰਫ਼ ਨੂੰ ਦਹਾੜਾ ਜਾਂ dozens ਦੇ fragile ਨਿਯਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਾ ਬਣਾਓ। ਕੁਝ ਸਧਾਰਣ ਵਿਹੇਵਿਅਰ ਚੈੱਕ ਬਹੁਤ ਸਾਰਾ ਦੁਰੁਪਯੋਗ ਫੜ ਲੈਂਦੇ ਹਨ ਅਤੇ ਰੱਖ-ਸੰਭਾਲ ਵਿੱਚ ਆਸਾਨ ਰਹਿੰਦੇ ਹਨ।
ਟਾਈਮਿੰਗ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਅਸਲ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਈਨਅਪ 1 ਸਕਿੰਟ ਤੋਂ ਘੱਟ 'ਚ ਪੂਰਾ ਨਹੀਂ ਕਰਦੇ। ਫਾਰਮ ਰੈਂਡਰ ਹੋਣ ਦਾ ਸਮਾਂ ਅਤੇ submit ਦਾ ਸਮਾਂ record ਕਰੋ। ਜੇ ਫਰਕ ਬਹੁਤ ਛੋਟਾ ਹੋਵੇ, ਤਾਂ ਇਸਨੂੰ ਉੱਚ ਜੋਖਮ ਵਜੋਂ ਮੰਨੋ: ਇਸਨੂੰ slow down ਕਰੋ, email verification ਮੰਗੋ, ਜਾਂ review ਲਈ queue ਕਰੋ।
ਫਿਰ repetition ਨੂੰ ਦੇਖੋ। ਹਮਲਾਵਰ ਅਕਸਰ ਇੱਕੋ payload ਨੂੰ ਛੋਟੇ-ਛੋਟੇ ਵੈਰੀਏਸ਼ਨਾਂ ਨਾਲ ਬਾਰ-ਬਾਰ ਭੇਜਦੇ ਹਨ। ਇਕ ਛੋਟੀ-ਜਿਵੇਂ fingerprint ਰੱਖੋ, ਜਿਵੇਂ email domain + IP prefix + user agent + key fields ਦਾ hash। ਜੇ ਤੁਸੀਂ minutes ਵਿੱਚ repeats ਵੇਖਦੇ ਹੋ, ਤਾਂ ਇੱਕ consistent ਜਵਾਬ ਦਿਓ।
ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਸਿਗਨਲ ਆਮ طور 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ:
ਨਿਗਰਾਨੀ ਲਈ ਹਰ ਚੀਜ਼ ਦਾ dashboard ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਦੋ ਨੰਬਰਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ: signup volume ਅਤੇ error rate। ਅਚਾਨਕ spikes ਆਮ ਤੌਰ 'ਤੇ ਜਾਂ ਤਾਂ ਬੋਟ ਲਹਿਰ ਜਾਂ ਕਿਸੇ broken release ਦਾ ਸਬੂਤ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਉਤਪਾਦ ਸਾਈਨਅਪ ਚਲਾ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਤਾਂ ਸਾਈਨਅਪ ਵਿੱਚ spike ਪਰ ਨਵੇਂ active users 'ਚ ਕਮੀ ਹੋਣਾ ਇੱਕ ਓਰ ਨਜਰਅੰਦਾਜ਼ ਕਰਨ ਯੋਗ ਇਸ਼ਾਰਾ ਹੈ।
ਲੌਗਸ ਨੂੰ ਹਫ਼ਤੇਵਾਰ ਸਮੀਖਿਆ ਕਰੋ, ਨਾ ਕਿ ਰੋਜ਼ਾਨਾ। thresholds ਨੂੰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਢੀਲਾ ਜਾਂ ਕਠੋਰ ਕਰੋ, ਅਤੇ ਜੋ ਤੁਸੀਂ ਬਦਲਿਆ ਉਸਦਾ ਨੋਟ ਲਿਖੋ।
ਇੱਕ ਛੋਟੀ startup ਦੇ ਕੋਲ ਦੋ public ਫਾਰਮ ਹਨ: ਇੱਕ signup ਫਾਰਮ (email ਅਤੇ password) ਅਤੇ ਇੱਕ contact ਫਾਰਮ (name ਅਤੇ message)। ਇਕ ਹਫਤੇ ਵਿੱਚ, ਡੇਟਾਬੇਸ junk signups ਨਾਲ ਭਰ ਜਾਂਦਾ ਹੈ, ਅਤੇ contact inbox 'ਚ ਹਰ ਦਿਨ 200 ਸਪੈਮ ਸੁਨੇਹੇ ਆਉਂਦੇ ਹਨ। ਅਸਲ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤ ਕਰਨ ਲੱਗਦੇ ਹਨ ਕਿ signup emails ਡਰਾਪ ਹੋ ਰਹੇ ਹਨ ਕਿਉਂਕਿ ਟੀਮ data ਠੀਕ ਕਰਨ ਅਤੇ ਬੋਟਾਂ ਨਾਲ ਲੜਨ ਵਿੱਚ ਰੁਕੀ ਹੋਈ ਹੈ।
ਉਹ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਬੋਰਿੰਗ fixes ਨਾਲ: ਸਰਵਰ-ਸਾਈਡ validation, ਇੱਕ honeypot ਫੀਲਡ, ਅਤੇ signup ਲਈ ਬੇਸਿਕ rate limiting۔ Validation ਸਖਤ ਪਰ ਸਧਾਰਣ ਰਹਿੰਦੀ ਹੈ: ਸਹੀ email ਫਾਰਮੈਟ, password ਲੰਬਾਈ, ਅਤੇ message ਲੰਬਾਈ caps। ਜੋ ਕੁਝ fail ਹੁੰਦਾ ਹੈ ਉਹ store ਨਹੀਂ ਹੁੰਦਾ। Honeypot ਮਨੁੱਖਾਂ ਤੋਂ ਛੁਪਾਇਆ ਗਿਆ ਪਰ ਬੋਟਾਂ ਲਈ ਦਿੱਖਦਾ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਇਹ ਭਰਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ request quietly reject ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਫਿਰ ਉਹ per IP ਅਤੇ per email rate limits ਜੋੜਦੇ ਹਨ। ਵਿੰਡੋ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਅਸਲ ਯੂਜ਼ਰ ਇੱਕ-ਦੋ ਵਾਰੀ ਗਲਤੀ ਕਰਕੇ recover ਕਰ ਸਕਣ। ਮਹੱਤਵਪੂਰਣ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹ ਇੱਕ ਸਧਾਰਨ error message ਵਾਪਸ ਕਰਦੇ ਹਨ, ਡਰਾਉਣਾ block page ਨਹੀਂ, ਤਾਂ ਕਿ ਮਨੁੱਖੀ ਯੂਜ਼ਰ ਸੰਦੇਹ ਵਿੱਚ ਨਾ ਪੈਣ।
ਕੁਝ ਦਿਨਾਂ ਬਾਅਦ, ਸਭ ਤੋਂ ਭਿਆਨਕ ਬੋਟ اړتیا ਅਪਡੇਟ ਕਰ ਲੈਂਦੇ ਹਨ ਅਤੇ ਹਮਲਕਾਰੀ ਰਫ਼ਤਾਰ ਜਾਰੀ ਰੱਖਦੇ ਹਨ। ਹੁਣ ਉਹ ਤਿੰਨ ਨਾਕਾਮ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਵਿੰਡੋ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਸੰਦੇਹਜਨਕ ਟ੍ਰੈਫਿਕ ਲਈ ਚੈਲੈਂਜ ਪੇਜ਼ ਜੋੜਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਅਸਲੀ ਯੂਜ਼ਰ ਇਹ ਕਦੇ ਵੀ ਨਹੀਂ ਦੇਖਦੇ, ਅਤੇ ਬੋਟਾਂ ਹੀ ਇਸਨੂੰ ਦੇਖਦੇ ਹਨ। signup completion ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਵਾਧੂ friction ਟਾਰਗੇਟਿਡ ਹੈ।
ਉਹ ਸਧਾਰਣ ਨਤੀਜੇ ਵੇਖਦੇ ਹਨ: ਘੱਟ ਜੰਕ ਐਂਟਰੀਜ਼, ਘੱਟ error rates, ਅਤੇ ਪੂਰੇ ਸਾਈਨਅਪ ਵਿੱਚ ਕੋਈ ਘਟੋਤਰੀ ਨਹੀਂ। ਜੇ ਇਹ ਗਲਤ ਚਲੇ (ਉਦਾਹਰਣ ਲਈ, ਕਿਸੇ mobile carrier NAT ਨੇ rate limit trigger ਕੀਤਾ), ਉਹ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਰਦੇ ਹਨ, ਫਿਰ thresholds ਟਿਊਨ ਕਰਦੇ ਹਨ ਜਾਂ hard block ਦੀ ਥਾਂ softer throttle ਲਗਾਉਂਦੇ ਹਨ।
ਤੁਰੰਤ friction ਜੋੜ ਕੇ conversion ਖਰਾਬ ਕਰਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਕਦਮ 'ਤੇ CAPTCHA ਲਗਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਅਸਲ ਲੋਕਾਂ ਨੂੰ ਸਜਾ ਮਿਲਦੀ ਹੈ ਅਤੇ ਬੋਟ ਅਕਸਰ ਇਸਦੇ ਗੋਲ-ਘਾਕ ਕੱਢ ਲੈਂਦੇ ਹਨ। ਪਹਿਲਾਂ quiet checks ਰੱਖੋ, ਫਿਰ ਸਿਰਫ਼ ਸੰਦੇਹਜਨਕ ਲੈਣ ਵਾਲੀ traffic ਲਈ ਵਿਸ਼ਿਬਲ challenges ਜੋੜੋ।
ਇੱਕ ਆਮ ਸੁਰੱਖਿਆ ਖ਼ਾਮੀ browser 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ। Client-side checks ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਇਹ ਆਸਾਨੀ ਨਾਲ bypass ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਜੋ ਵੀ ਮਹੱਤਵਪੂਰਕ ਹੈ (email ਫਾਰਮੈਟ, required fields, length limits, allowed characters) ਉਹ ਹਰ ਵਾਰੀ ਸਰਵਰ 'ਤੇ enforce ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਵੱਡੀਆਂ ਜ਼ਮੀਨਾਂ ਜਾਂ ਵੱਡੇ IP ਰੇਂਜਾਂ ਨੂੰ ਬਲਾਕ ਕਰਨਾ legitimate users ਨੂੰ ਕੱਟ ਸਕਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਤੁਸੀਂ ਗਲੋਬਲ ਹੋ ਜਾਂ ਤੁਹਾਡੀ ਟੀਮ ਰਿਮੋਟ ਹੈ। ਇਹ ਸਿਰਫ਼ ਤਦ ਕਰੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਸਬੂਤ ਹੋਵੇ ਅਤੇ ਇੱਕ rollback ਯੋਜਨਾ ਹੋਵੇ।
Rate limits ਵੀ ਗਲਤ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਬਹੁਤ ਕਡੀ ਹੁੰਦੀਆਂ ਹਨ। Shared networks ਹਰ ਜਗ੍ਹਾ ਹਨ: ਦਫ਼ਤਰ, ਸਕੂਲ, ਕੈਫੇ, mobile carriers। ਜੇ ਤੁਸੀਂ IP ਦੇ ਅਧਾਰ 'ਤੇ aggressively block ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਕਈ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲਾਕ ਆਉਟ ਕਰ ਸਕਦੇ ਹੋ।
ਜੋ ਜਾਲ ਬਾਅਦ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਦਰਦ ਪੈਦਾ ਕਰਦੇ ਹਨ:
ਲੌਗਜ਼ fancy ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਨ੍ਹਾ basic counts (ਪਰਗ਼ੋਗਾਂ ਪ੍ਰਤੀ ਘੰਟਾ, top failure reasons, rate limit hits, ਅਤੇ challenge triggers) ਵੀ ਦਿਖਾ ਸਕਦੀਆਂ ਹਨ ਕਿ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕੀ ਅਸਲੀ ਸਾਈਨਅਪਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਫਾਰਮਾਂ ਲਈ ਸਪੈਮ ਸੁਰੱਖਿਆ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਸਾਈਨਅਪ ਨੂੰ ਪਹੇਲੀਆਂ ਬਣਾਉਣ ਦੇ, ਤਾਂ ਕੁਝ ਸਧਾਰਣ ਪਰਤਾਂ ਇਕੱਠੀਆਂ ਸ਼ਿਪ ਕਰੋ। ਹਰ ਇੱਕ ਪਰਤ ਸਧਾਰਣ ਹੈ, ਪਰ ਜੋੜ ਜ਼ਿਆਦਾਤਰ ਦੁਰੁਪਯੋਗ ਰੋਕਦਾ ਹੈ।
ਹਰ ਫਾਰਮ ਲਈ ਇੱਕ ਸਰਵਰ-ਸਾਈਡ truth ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। Client-side checks ਅਸਲ ਯੂਜ਼ਰਾਂ ਲਈ ਮਦਦਗਾਰ ਹਨ, ਪਰ ਬੋਟ ਉਨ੍ਹਾਂ ਨੂੰ skip ਕਰ ਸਕਦੇ ਹਨ।
ਬੇਸਲਾਈਨ ਚੈੱਕਲਿਸਟ:
deploy ਤੋਂ ਬਾਅਦ routine ਹਫ਼ਤੇਵਾਰ ਹਲਕੀ ਰੱਖੋ: ਹਫਤੇ ਵਿੱਚ ਇੱਕ ਵਾਰੀ ਲੌਗਾਂ ਨੂੰ ਪੜ੍ਹੋ ਅਤੇ thresholds ਠੀਕ ਕਰੋ। ਜੇ ਅਸਲੀ ਯੂਜ਼ਰ ਬਲਾਕ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਨਿਯਮ ਢੀਲਾ ਕਰੋ ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਚੈੱਕ (ਚੰਗੀ validation, softer throttles) ਜੋੜੋ, ਬਲਕਿ ਸਾਰੀਆਂ ਸੁਰੱਖਿਆਆਂ ਹਟਾਉਣ ਦੀ ਥਾਂ।
ਉਦਾਹਰਣ: ਜੇ ਇੱਕ signup ਫਾਰਮ ਨੂੰ ਇੱਕ IP ਤੋਂ 10 ਮਿੰਟ ਵਿੱਚ 200 ਕੋਸ਼ਿਸ਼ਾਂ ਮਿਲ ਰਹੀਆਂ ਹਨ, ਤਾਂ rate limit ਲਗਾਓ ਅਤੇ ਚੈਲੈਂਜ ਟ੍ਰਿਗਰ ਕਰੋ। ਜੇ ਇੱਕ ਸਾਈਨਅਪ 'ਤੇ honeypot ਭਰਿਆ ਜਾਵੇ, ਤਾਂ ਉਸਨੂੰ quietly drop ਕਰੋ ਅਤੇ record ਕਰੋ।
ਇੱਕ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕੋ, ਫਿਰ ਇੱਕ ਪਰਤ-ਵਾਰ ਜੋੜੋ। ਜੇ ਤੁਸੀਂ ਇਕੱਠੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਬਦਲ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣੋਗੇ ਕਿ ਸਪੈਮ ਘਟਾਇਆ ਕਿਸ ਚੀਜ਼ ਨਾਲ ਗਿਆ ਜਾਂ ਕਿਹੜੀ ਬਦਲਾਉਂ ਨੇ ਅਸਲੀ ਸਾਈਨਅਪ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਇਆ।
ਆਪਣੇ ਨਿਯਮ ਪਹਿਲਾਂ ਤੋਂ ਲਿਖੋ। ਇੱਕ ਸਧਾਰਣ ਨੋਟ ਵੀ ਜਿਵੇਂ "5 ਮਿੰਟ ਵਿੱਚ 3 ਨਾਕਾਮ ਕੋਸ਼ਿਸ਼ਾਂ ਚੈਲੈਂਜ ਤੱਕ ਲੈ ਜਾਂਦੀਆਂ ਹਨ" ਬਾਅਦ ਦੇ random tweaks ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ support tickets ਸੱਜੇ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗੀ ਰੋਲਆਉਟ ਯੋਜਨਾ:
ਜਦੋਂ ਤੁਸੀਂ ਨਤੀਜੇ ਮਾਪਦੇ ਹੋ, ਤਾਂ ਟਰੇਡਆਫ਼ ਦੇ ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰੋ। "ਘੱਟ ਸਪੈਮ" ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ ਜੇ paid users ਸਾਈਨਅਪ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਟੀਚਾ ਇਹ ਹੋਵੇ ਕਿ "ਸਪੈਮ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਯੋਗ ਹੱਦ ਤੱਕ ਘਟੇ ਜਾਂਦਾ ਹੈ ਤੇ completion ਅਸਥਿਰ ਜਾਂ ਸੁਧਰੇ"।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਉਹ tooling ਚੁਣੋ ਜੋ ਛੋਟੇ ਬਦਲਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੋਵੇ। Koder.ai (koder.ai) 'ਤੇ ਤੁਸੀਂ chat ਰਾਹੀਂ form flows ਅਡਜਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਤੇਜ਼ੀ ਨਾਲ deploy ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ snapshots ਤੇ rollback ਵਰਤ ਕੇ anti-spam ਨਿਯਮਾਂ ਨੂੰ ਬਿਨ੍ਹਾਂ ਲੰਬੇ ਦਿਨ ਦੇ ਤਬਦੀਲ ਕਰ ਸਕਦੇ ਹੋ।
ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨਿਰੋਚਕ ਰੱਖੋ: ਇੱਕ ਨਿਯਮ ਬਦਲੋ, ਮੈਟ੍ਰਿਕਸ ਦੇਖੋ, ਨੋਟ ਲਿਖੋ, ਦੁਹਰਾਓ। ਇਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਅਸਲੀ ਲੋਕਾਂ ਲਈ ਨਜ਼ਰਅੰਦਾਜ਼ੀ ਵਾਲੀ ਸੁਰੱਖਿਆ ਤਿਆਰ ਕਰਦੇ ਹੋ।
ਫਾਰਮ ਸਪੈਮ ਬੜੀ ਆਸਾਨੀ ਨਾਲ ਪੈਦਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਹਮਲਾਉਣ ਵਾਲੇ ਆਟੋਮੇਟੇਡ ਸਬਮਿਸ਼ਨ ਚਲਾਉ ਸਕਦੇ ਹਨ, ਸਿੱਧਾ ਤੁਹਾਡੇ endpoint ਤੇ ਪੋਸਟ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਪੇਜ ਲੋਡ ਕੀਤੇ, ਜਾਂ ਸਸਤੀ ਮਨੁੱਖੀ ਲੇਬਰ ਵਰਤ ਕੇ ਐਸੇ ਲੀਡ ਭੇਜ ਸਕਦੇ ਹਨ ਜੋ ਬੇਸਿਕ ਜਾਂਚਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਲਾਇਕ “ਕਾਫ਼ੀ ਅਸਲੀ” ਲਗਦੇ ਹਨ।
ਅਕਸਰ ਇਹ ਲਕਸ਼ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਦੁਰੁਪਯੋਗ ਇਸ ਹੱਦ ਤੱਕ ਘਟਾਇਆ ਜਾਵੇ ਜੋ ਤੁਹਾਡੇ ਲਈ ਸਹਿਣਸ਼ੀਲ ਹੋਵੇ, ਜਦੋਂ ਕਿ ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੁਕਾਵਟ ਨਾ ਹੋਵੇ। ਥੋੜ੍ਹਾ ਜਿਹਾ ਸਪੈਮ ਛੁੱਟ ਜਾਣ ਦੀ ਉਮੀਦ ਰੱਖੋ ਅਤੇ false positives (ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਜਾਣਾ) ਨੂੰ ਨਜ਼ਦੀਕ ਜ਼ੀਰੋ ਰੱਖੋ।
ਸ਼ਾਂਤ ਰਖੋ: ਸਰਵਰ-ਸਾਈਡ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਇੱਕ honeypot ਫੀਲਡ ਅਤੇ ਬੇਸਿਕ ਰੇਟ ਲਿਮਿਟਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ ਸਿਰਫ਼ ਉਸੇ ਵੇਲੇ ਵਿਸ਼ਿਬਲ ਚੈਲੈਂਜ ਜੋੜੋ ਜਦੋਂ ਵਿਹੇਵਿਅਰ ਸੰਦੇਹਜਨਕ ਲੱਗੇ। ਇਸ ਤਰ੍ਹਾਂ ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਯੂਜ਼ਰ ਹੋਰ ਕਦਮ ਨਹੀਂ ਦੇਖਦੇ।
ਕਿਉਂਕਿ ਇਹ ਹਰ ਕਿਸੇ ਲਈ friction ਵਧਾਉਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ mobile ਤੇ, accessibility ਟੂਲਾਂ ਤੇ, ਧੀਮੇ ਕੁਨੈਕਸ਼ਨਾਂ ਤੇ ਜਾਂ autofill ਹਾਲਤਾਂ 'ਚ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਬਿਹਤਰ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਆਮ ਰਾਹ ਨੂੰ ਸਫ਼ਾ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਸੰਦੇਹਜਨਕ ਟ੍ਰੈਫਿਕ ਲਈ ਹੀ ਸਕਿੰਚਿਤ ਕਰੋ।
ਹਮੇਸ਼ਾ ਸਰਵਰ ਤੇ required fields, ਲੰਬਾਈ ਸੀਮਾਵਾਂ, ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕੈਰੈਕਟਰ ਅਤੇ ਬੇਸਿਕ ਫਾਰਮੈਟਾਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਇੰਪੁੱਟ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ (ਜਿਵੇਂ ਖਾਲੀ ਸਪੇਸ ਕੱਟਣਾ ਤੇ emails ਨੂੰ lower-case ਕਰਨਾ) ਤਾਂ ਜੋ ਛੋਟੀਆਂ ਵੈਰੀਏਸ਼ਨਾਂ ਨਾਲ ਬਾਈਪਾਸ ਨਾ ਹੋ ਸਕੇ ਤੇ ਗਲਤ ਜਾਂ ਡੁਪਲੀਕੇਟ ਰਿਕਾਰਡਸ ਨਾ ਬਣਨ।
ਇੱਕ off-screen ਫੀਲਡ ਵਰਤੋ ਜੋ DOM ਵਿੱਚ ਰਹੇ ਪਰ ਕੀ-ਨੇਵੀਗੇਸ਼ਨ ਜਾਂ ਸਕਰੀਨ ਰੀਡਰ ਦੁਆਰਾ ਪਹੁੰਚਯੋਗ ਨਾ ਹੋਵੇ ਅਤੇ ਜੋ autofill ਨੂੰ ਆਕਰਸ਼ਿਤ ਨਾ ਕਰੇ। ਜੇ ਇਹ ਭਰਿਆ ਗਿਆ ਹੋਵੇ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਮਜ਼ਬੂਤ ਸਪੈਮ ਸਿਗਨਲ ਮੰਨੋ, ਪਰ ਹਰ ਵੇਲੇ hard-block ਨਾ ਕਰੋ—ਉਦਾਹਰਣ ਲਈ ਵੈਰੀਫਿਕੇਸ਼ਨ ਮੰਗੋ ਜਾਂ escalated review ਰੱਖੋ ਤਾਂ ਕਿ ਕਦਰ-ਕਾਬਿਲ ਸਚੀਆਂ autofill ਗਲਤੀਆਂ ਨੂੰ ਸਜ਼ਾ ਨਾ ਦਿਓ।
IP ਇਕ ਅਚਛਾ ਪਹਿਲਾ ਪਰਤ ਹੈ ਪਰ ਕੇਵਲ ਉਸ ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ—ਸ਼ੇਅਰਡ ਨੈੱਟਵਰਕ ਬਹੁਤ ਆਮ ਹਨ। ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ ਤਾਂ device (cookie/localStorage ID) ਅਤੇ account ਨਿਸ਼ਾਨ ਵੀ ਵਰਤੋ। ਸਥਿਰ ਬਲਾਕਿੰਗ ਦੀ ਥਾਂ cooldown delays ਪਸੰਦ ਕਰੋ ਤਾਂ ਕਿ ਸਹਜ਼ ਯੂਜ਼ਰ ਬਾਜ਼ ਆ ਜਾਂ।
ਚੈਲੈਂਜ ਪੇਜ਼ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਆ ਵਾਲਵ ਤੇ ਹੀ ਰੱਖੋ—ਆਮ ਰੂਪ ਵਿੱਚ ਲੋਕਾਂ ਨੂੰ ਇਹ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ। ਜਦੋਂ ਸਪੈਮੀ ਵਿਹੇਵਿਅਰ ਸਾਫ ਹੋਵੇ (ਬਹੁਤ ਸਾਰੇ ਕੋਸ਼ਿਸ਼ਾਂ, ਅਸੰਭਵ ਟਾਈਪਿੰਗ ਸਪੀਡ ਆਦਿ), ਤਦ ਹੀ ਦਿਖਾਓ। ਸੁਨੇਹਾ ਸ਼ਾਂਤ ਅਤੇ ਐਕਸ਼ਨ-ਕੇਂਦਰਿਤ ਹੋਵੇ: "ਆਪਣੇ ਇਮੇਲ ਦੀ ਜਾਂਚ ਕਰੋ" ਜਾਂ "ਇੱਕ ਛੋਟਾ ਵੇਰਸ ਕੋਡ ਭਰੇ"।
ਛੋਟਾ, ਲਗਾਤਾਰ ਲੌਗ ਰੱਖੋ: ਸਮਾਂ, ਫਾਰਮ ਦਾ ਨਾਂ, ਫੈਸਲਾ (allow, soft block, hard block) ਅਤੇ ਕਿਹੜੇ ਸਿਗਨਲ ਟ੍ਰਿਗਰ ਹੋਏ। ਕੇਵਲ ਕੁਝ ਮੈਟਰਿਕਸ ਦੇਖੋ: conversion ਅਤੇ error rate — ਜੇ ਨਿਯਮ spam ਘਟਾਉਂਦੇ ਹਨ ਪਰ conversion ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਦਾ ਹੈ ਤਾਂ ਫੇਰ ਢੀਲਾ ਕਰੋ।
ਇਸਨੂੰ flow ਦਾ ਹਿੱਸਾ ਸਮਝੋ, ਨ ਕਿ ਇਕ ਵਾਰੀ ਦਾ ਪੈਚ। Koder.ai 'ਤੇ ਤੁਸੀਂ ਫਲੋ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੰਭਾਲ ਸਕਦੇ ਹੋ, ਚੈਟ ਰਾਹੀਂ ਬਦਲ ਸਕਦੇ ਹੋ, ਤੇ snapshots ਅਤੇ rollback ਨਾਲ ਮਾਮੂਲ ਤੌਰ 'ਤੇ ਹਟਾ ਸਕਦੇ ਹੋ ਜੇ false positives ਵਧਣ।