Forms Intake, Consent, Rate Limit و Inbox Handoff

1. موفقیت HTTP را با پذیرش واقعی اشتباه نگیر

یک فرم ممکن است 200 یا 202 برگرداند اما هنوز fieldهایش نامعتبر، basis پردازش نامشخص، کنترل abuse ناکافی یا delivery آن شکست‌خورده باشد. در این درس submission success فقط یک event است؛ تصمیم نهایی از چند state مستقل ساخته می‌شود.

2. مرز مالکیت CON-008

CON-008 مالک قرارداد intake فرم، evidence مربوط به purpose/basis/consent، rate-limit decision، idempotency و inbox handoff است. CON-006 routeها، CON-007 workspace versionها، CON-009 SEO record و CON-010 rollback/monitoring را مالک‌اند.

3. فرم را version کن

form_id می‌تواند پایدار بماند، اما هر تغییر مهم در schema، purpose یا consent copy باید form_version مشخص داشته باشد. یک submission تاریخی باید به همان نسخه‌ای bind شود که کاربر واقعاً دیده است، نه آخرین نسخه موجود.

4. validation یک state مستقل است

Server-side validation باید قبل از handoff نتیجه typed بدهد: PASS، FAIL یا در صورت نبود evidence، UNKNOWN. ارسال موفق transport نباید FAIL یا UNKNOWN را به valid تبدیل کند.

5. processing purpose و legal-basis record را جدا ثبت کن

برای هر purpose باید رکورد صریح داشته باشی که چرا داده جمع می‌شود و basis اعلام‌شده چیست. این درس تعیین حقوقی basis مناسب را انجام نمی‌دهد؛ فقط مانع می‌شود نبودن یا unbound بودن آن پنهان شود.

6. اگر consent استفاده می‌شود، evidence آن باید قابل بازسازی باشد

راهنمای کمیسیون اروپا می‌گوید consent معتبر باید freely given، specific، informed و unambiguous باشد و امکان withdrawal وجود داشته باشد. در ledger حداقل consent_text_version، affirmative action و withdrawal path را bind کن. این یک قاعده عمومی GDPR است، نه تشخیص حقوقی برای هر فرم.

7. consent copy تاریخی را بازنویسی نکن

اگر متن opt-in از v2 به v3 تغییر کرد، submission قدیمی نباید ناگهان به v3 منتسب شود. stored evidence باید نسخه‌ای را حفظ کند که هنگام collection نمایش داده شده بود؛ mismatch یعنی evidence نیازمند repair است.

8. data minimization و retention را در همان intake ببین

Abuse-control یا analytics بهانه‌ای برای نگه‌داشتن نامحدود raw data نیست. فقط داده لازم را نگه دار، PII را در logها redaction کن و retention_class bounded داشته باش تا تصمیم handoff قابل ممیزی بماند.

9. rate limit یک signal واحد نیست

OWASP دفاع لایه‌ای را توصیه می‌کند: rate limit و quota روی keyهای مناسب، به‌اضافه logging و signalهای دیگر. فقط IP، CAPTCHA یا یک score را «حکم نهایی» تلقی نکن؛ rate_limit_key, window و decision را صریح ثبت کن.

10. legitimate traffic را با global ban له نکن

اگر یک source به limit رسید، این به معنی block کردن همه traffic نیست. key و scope تصمیم را نگه دار؛ برای مثال source محدودشده می‌تواند BLOCK شود ولی یک session/identity مستقل که زیر threshold است همچنان ALLOW بماند.

11. idempotency جلوی intake تکراری را می‌گیرد

کاربر ممکن است بعد از timeout همان درخواست را دوباره بفرستد. submission_id و idempotency_key باید اجازه دهند retry همان logical intake را ادامه دهد؛ دو record مستقل برای یک retry موفق، duplicate-risk است.

12. inbox handoff یک envelope نسخه‌دار می‌خواهد

قبل از ارسال downstream، یک handoff_envelope_id بساز که به submission، مقصد، payload/version و provenance bind باشد. پذیرش درخواست توسط provider فقط یک delivery attempt است؛ هنوز اثبات receipt نهایی نیست.

13. provider ACCEPTED با DELIVERED یکی نیست

ممکن است API ایمیل پیام را بپذیرد و بعد bounce/failure اعلام کند. در این حالت status نباید DELIVERED بماند؛ تصمیم درست RETRY_PENDING یا state محدودشده دیگری است تا evidence بعدی برسد.

14. مثال منفی و Transfer

فرض کن form یک attachment و purpose اختیاری marketing اضافه می‌کند، کاربر retry می‌زند و provider بعداً failure می‌دهد. باید form/purpose/consent version جدید bind شود، retry یک intake منطقی بماند، abuse decision قابل audit باشد و handoff تا receipt واقعی RETRY_PENDING بماند.

15. خروجی قابل ممیزی

Form Intake Decision Ledger & Handoff Envelope v1 باید Form/Version، Submission/Idempotency، Validation، Purpose/Basis، Consent Evidence، Withdrawal Path، Retention، Rate-Limit Key/Window/Decision، Abuse State، Handoff Envelope، Destination، Delivery Attempt/Status، Retry، PII Redaction، Decision، Reason و Provenance را نگه دارد. HANDOFF_COMPLETE فقط برای همان evidence بسته‌شده معتبر است.