Skip to main content

بوابة DSAR الذاتية من البداية إلى النهاية

تقبل Devotel Orbit طلبات أصحاب البيانات عبر مساري استقبال: يقدّمها مشغلوك نيابة عن صاحب البيانات، وبوابة عامة يقدّم عبرها صاحب البيانات طلبه بنفسه. قائمة انتظار واحدة تغذي المسارين. هذا الدليل يتتبع مسار البوابة من نشر الرابط حتى الإنجاز، ويوضح كيف يتركب مع تقديم المشغلين. يوثّق مرجع DSAR سطح النقاط النهاية وآلة حالة مطالبات البريد/الهاتف العامة؛ هذه الصفحة هي دليل التشغيل الذي تعمل منه.
كل تحكم هنا مملوك للمستأجر: أنت تنشر الرابط، وأنت تدير قائمة الانتظار، وأنت تقرر وتُنجز. Orbit تستضيف البوابة، وتثبت الهوية برمز OTP بعاملين، وتتتبع الساعات القانونية — واجب الرد القانوني يبقى عليك، بصفتك المتحكم. تأكّد من التزاماتك لدى مستشارك القانوني.

1. مساران للاستقبال، قائمة انتظار واحدة

تقديم المشغلين. يقدّم فريقك طلبًا عبر POST /compliance/dsar أو نافذة Create DSAR في Settings → Compliance → DSAR. الطلب المقدَّم بهذه الطريقة يبدأ بـverification_status: pending — لا يلمسه عامل تصدير أو محو حتى يوافق مشغل على مراجعة الهوية أو يرفضها. يناسب هذا المسار حاليًا: أصحاب بيانات تعرفهم أصلًا (عميل مسجّل الدخول، جهة اتصال موجودة في مساحة عملك)، والحقوق التي لا يستطيع النموذج العام حملها (تصحيح، تقييد بيانات حساسة، عدم تمييز). البوابة العامة الذاتية. يقدّم صاحب البيانات طلبه بنفسه عبر الصفحة العامة المستضافة — بلا حساب، بلا مفتاح API، بلا جلسة. تتحقق الصفحة من هويته ببريد إلكتروني + SMS OTP بعاملين قبل أن يدخل أي شيء قائمة انتظارك، فيصل تقديم البوابة متحققًا منه مسبقًا ويبدأ عامل التصدير أو المحو فورًا. نفّذ المسارين معًا. تحمل البوابة حجم المستهلكين إلى صفر لمسات تشغيلية؛ ويغطي تقديم المشغلين الحالات الحدّية التي لا تستطيعها البوابة. كل طلب من أي من المسارين يهبط في قائمة Settings → Compliance → DSAR نفسها واستجابة GET /compliance/dsar نفسها — قائمة انتظار واحدة، لافتة SLA واحدة، سلسلة تدقيق واحدة.

2. جولة في البوابة

نشر الرابط

استضف البوابة كرابط “Submit a privacy request” في سياسة الخصوصية لديك، أو في تذييل موقعك، أو في مركز الخصوصية داخل المنتج:
<locale> هي البادئة Locale نفسها التي تحملها كل صفحة ويب في Orbit (en، fr، de، …). تعرض الصفحة نموذج معرفات من خطوتين خلف فحص بوتات Cloudflare Turnstile: يدخل صاحب البيانات بريده الإلكتروني وهاتفه (E.164)، ويختار نوع الطلب، ويبدأ إثبات الهوية.

شرط البريد المرسل

قرر من أي العناوين ترسل رموز تحقق البوابة قبل أن يصير الرابط مباشرًا — مرسل غير مضبوط يترك البوابة تفشل فشلًا مغلقًا علنًا. يُضبط مرسلان على مستوى المنصة مرة واحدة في بيئة الواجهة البرمجية لديك: بلا مرسل SMS وبلا بديل للمنصة، تعيد خطوة الهاتف 503 وتعرض البوابة رسالة “غير متاحة مؤقتًا”؛ وبلا مفتاح تسليم بريدي، تفشل خطوة البريد بالطريقة نفسها. في الإنتاج تحتاج الخطوة الأولى أيضًا رمز Turnstile — اضبط DEVOTEL_TURNSTILE_SECRET_KEY على الواجهة البرمجية وNEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY على نشر الويب، من لوحة Cloudflare (Turnstile → Add site). تركب رموز التحقق الهاتفية على سوفت سويتش Devotel بوصفها رموز OTP للمنصة — ليست حركة قابلة لفوترة المستأجر.

ما يراه صاحب البيانات

يكمل صاحب البيانات مطالبة من خمس خطوات؛ لا يدخل شيء قائمة الانتظار حتى يكتمل الإثباتان:
  1. البدء — البريد الإلكتروني، الهاتف (E.164)، نوع الطلب. يُرسل رمز OTP بريدي فورًا.
  2. التحقق من البريد — رمز بريدي من 6 أرقام (صلاحية 10 دقائق، 3 محاولات، فترة انتظار 60 ثانية لإعادة الإرسال).
  3. إرسال رمز الهاتف — رمز OTP هاتفي إلى الهاتف نفسه (فترة انتظار 60 ثانية بين الإرسالات).
  4. التحقق من الهاتف — رمز هاتفي من 6 أرقام.
  5. التقديم — يدخل الطلب قائمة انتظارك فقط مع اكتمال الإثباتين. للمطالبة كاملة صلاحية 30 دقيقة من البداية إلى النهاية.
تتوافق أنواع الطلبات الودية التي يختارها صاحب البيانات مع enum المشغل: إن لم تطابق المعرفات أي جهة اتصال في مساحة عملك، تجيب خطوة التقديم بالطريقة نفسها — لا تكشف البوابة أبدًا وجود جهة اتصال من عدمه — وتُكتب صف التدقيق بنطاق المنصة لتنجو السلسلة الجنائية من حالة عدم التطابق.

الاختصاص يحدّد ساعة SLA

يختار صاحب البيانات الاختصاص الذي يندرج تحته طلبه، ويحدد هذا الاختيار كلا من الساعة القانونية التي تحملها الصف وقيم request_type التي قد تحملها قائمة الانتظار: إتقان المطابقة مهم: لا مقابل في GDPR لـopt_out_sale وlimit_sensitive_pi، واختصاص المشغل الافتراضي هو gdpr — اضبطه صراحة للمستهلكين في كاليفورنيا. تقديم بوابة بـopt_out يجعل الاختصاص افتراضيًا CCPA/CPRA لأن الافتراضي GDPR سيكون باطلًا خلاف ذلك. خطأ اختيار صاحب البيانات قابل للإصلاح: أعد تصنيف الاختصاص من قائمة الانتظار فيُعاد تثبيت شارة SLA.

3. ما يراه المشغلون بعد التقديم

تقديم البوابة الذي يطابق جهة اتصال يهبط في Settings → Compliance → DSAR إلى جانب طلبات المشغلين. ولأن OTP أثبت الهوية أصلًا، يصل بـverification_status: verified — لا بوابة موافقة/رفض تحجبه.
  • الحالة والموعد النهائي. تحمل الصف حالة دورة الحياة المعتادة وشارة SLA اليوم X من N المثبتة على نافذة الاختصاص؛ أي خرق يرفع لافتة SLA على مستوى مساحة العمل. GET /compliance/dsar/sla يعطي الصورة نفسها عبر الواجهة البرمجية.
  • تقديمات فئة المحو. صاحب البيانات الذي اختار “delete” يظهر في قسم البوابة ضمن لسان Erasure requests (Art. 17)، شارة SLA بجانبه، متقدمًا على افتراضي فترة التهدئة ذات الـ7 أيام.
  • الإنجاز. تقديم وصول أو قابلية نقل يجري حتى Completed مع export_url موقّع؛ وإجراء Download decrypted يبني التصدير النصي للمشغل. والمحو، بعد تنفيذه، يتيح شهادة Proof of deletion وPropagate إلى وجهاتك المتصلة.
  • سلسلة التدقيق. يكتب البدء والتحققان والتقديم صفوفًا بمعرفات مجزأة (ليست خامًا أبدًا)، وعنوان IP المصدر، ووكيل المستخدم — السجل الذي يسحب منه مجلد الأدلة حين يسأل المنظم كيف ثبتت الهوية.

4. ما لا تفعله Orbit

البوابة آلة للاستقبال وإثبات الهوية؛ القرارات القانونية تبقى لكم:
  • لا تقرر Orbit الصلاحية أبدًا. لا تقبل طلبًا ولا ترفضه لأسباب قانونية. الصفوف معلقة التحقق تنتظر قرار موافقتك/رفضك؛ والصفوف المتحققة تُنجز لأنك سمحت بذلك، لا لأن المنصة حكمت على المطالبة.
  • لا تُنجز Orbit حكم مشغل تلقائيًا أبدًا. لطلب قدّمه مشغل، لا يُنتج تصدير ولا يُمحى شيء ما دام verification_status: pending. تقديم البوابة يتجاوز البوابة فقط لأن OTP أثبت الهوية أصلًا.
  • يحترم المحو وضعية فترة التهدئة لديك. الافتراضي 7 أيام (قابل للتجاوز لكل مستأجر) يمنحك نافذة للرفض أو التعليق أو الإعفاء قبل الإتلاف.
  • إخبارك أي قانون يسري يبقى مهمة مستشارك القانوني. تثبت Orbit ساعة SLA على الاختصاص الذي اختاره صاحب البيانات وأكّدته.
  • تعرض البوابة مجموعة الحقوق الودية للمستهلك — صاحب البيانات الذي يحتاج حقًا خاصًا بالمشغل (تصحيح، تقييد بيانات حساسة، عدم تمييز) يقدّم عبر فريقك.

حلقة مطالبة البوابة — عينات طلب قابلة للتنفيذ

أفعال البوابة الستة غير الموثقة موجودة تحت /api/v1/compliance/public/dsar (السطح الكامل: مرجع DSAR). هذه السلسلة نفسها التي تشغّلها صفحة البوابة، قابلة للبرمجة من البداية إلى النهاية — مفيدة لاختبار تدخين نشر قبل نشر الرابط، أو لإظهار مسار إثبات الهوية لمنظم. لا مفتاح API: زوج OTP هو الإثبات، لذا أي مفتاح مشغل يقوّض الاستدعاء العام.

1. بدء المطالبة

202
احتفظ بـclaim_id — كل خطوة لاحقة تشير إليه. بريد بصيغة خاطئة، أو هاتف خارج E.164، أو رمز Turnstile سيئ يعيد 422 VALIDATION_ERROR؛ وبوابات لكل IP ولكل بريد تعيد 429 مع ترويسة Retry-After. تجيب خطوة البدء بالطريقة نفسها سواء طابق الزوج جهة اتصال أم لا — لا يستطيع المستدعون تعداد أزواج جهات اتصالك.

2. التحقق من رمز البريد

200
الرمز الخاطئ أو القديم يعيد الغلاف نفسه الذي تعرضه صفحة البوابة:
422
الرمز المنتهي، والرمز المستهلك، والمحاولة الثالثة الفاشلة يعيد كل منها رسالة 422 الخاصة به (“Code expired. Please request a new one.”، “Too many attempts. Please start over.”) — POST /api/v1/compliance/public/dsar/resend-email يصدر رمز بريد جديدًا بعد فترة الانتظار ذات الـ60 ثانية.

3. إرسال رمز الهاتف والتحقق منه

إعادة إرسال داخل فترة انتظار SMS ذات الـ60 ثانية تعيد 429 مع Retry-After. ثم:
200

4. التقديم بعد اكتمال الإثباتين

201
queued: true تعني أن الزوج طابق جهة اتصال في مساحة العمل ودخل الطلب قائمة انتظارك؛ queued: false هي حالة عدم التطابق — الشكل نفسه، فلا يستطيع المستدعي التمييز. قدّم قبل اجتياز الإثباتين وستنال 422 مع “Both verification steps must complete before submission.” مرجع dsar_pub_… هو معرّف صف التدقيق، المعرف نفسه الذي يسحبه مجلد الأدلة.

5. قراءته في قائمة انتظار المشغل

جانب المشغل يحتاج مفتاح API بصلاحية owner/admin أو جلسة لوحة بالمستوى نفسه:
200
لاحظ أن فعل صاحب البيانات الودي طوبق أصلًا مع enum المشغل (access → know) وأن verification_status: verified — لا بوابة استقبال تنتظرك. الموعد القانوني مهمة حمولة SLA:
200
sla_deadline_at هو تاريخ الاستحقاق المطلق الذي تثبت عليه شارة “اليوم X من 30” في لوحة التحكم؛ وbreach_count > 0 هو ما يشعل لافتة مساحة العمل. لا شيء من هذا يُنجز الطلب — قائمة الانتظار، والحكم، والإنجاز تبقى لكم؛ هذه الحلقة تثبت فقط أن صاحب البيانات هو من يدّعي، وتهبط تقديمه على الساعة الصحيحة.

5. مثال محلول — طلب وصول GDPR من البداية إلى النهاية

عميلة في برلين تفتح سياسة الخصوصية لديك، وتنقر رابط البوابة، وتطلب كل ما تحتفظ به. التسلسل:
  1. البدء. تدخل بريدها الإلكتروني وهاتفها بصيغة E.164 (+4915…)، وتختار access، وتجتاب فحص Turnstile. تعيد البوابة معرّف مطالبة؛ رمز OTP البريدي في طريقه أصلًا.
  2. التحقق من البريد. تقرأ الرمز المكون من 6 أرقام (صلاحية 10 دقائق، حتى 3 محاولات) وتجتاب العامل الأول.
  3. إرسال رمز الهاتف، التحقق من الهاتف. يتكرر العامل الثاني عبر SMS — تفصل فترة انتظار 60 ثانية بين الإرسالات — والإثباتان الآن مكتملان.
  4. التقديم. تقدّم البوابة الطلب. ولأن بريدها وهاتفها يطابقان جهة اتصال في مساحة عملك، تصطف الصف بـknow تحت gdpr وتعيد مرجع dsar_pub_….
  5. في قائمة انتظارك. تعرض الصف اليوم 1 من 30 — verification_status: verified — وعامل التصدير استلمها أصلًا. لا أحد من فريقك يلمس الفرز.
  6. الإنجاز. يجمّع عامل التصدير ويعلّم الصف Completed مع export_url وtables_exported. يسّلم مشغل رابط التنزيل (نسخة نصية خاصة بالمشغل على بعد نقرة Download decrypted واحدة).
  7. تجاوز سطر SLA. إن بقيت الصف مفتوحة حين تنقضي نافذة GDPR ذات الـ30 يومًا، ترفع لافتة SLA في مساحة العمل — ولو كانت أخطأت اختيار الاختصاص عند الاستقبال، يعيد تصنيف قائمة انتظارك إصلاح الساعة بأثر رجعي.
الزمن من أول تقديم نموذج لصاحب البيانات حتى الطلب المصفوف: جولتا مطالبة OTP. لمسات المشغل: صفر.

مراجع ذات صلة