التوقيع الإلكتروني على سيرفرك: DocuSeal أم Documenso؟

ترسل الشركة عقداً أو نموذج موافقة إلى موظف أو عميل، فيقوم بطباعته وتوقيعه بالقلم ثم تصويره بالجوال وإرساله مرة أخرى، أو تدفع الشركة اشتراكاً شهرياً لكل مستخدم في خدمة توقيع سحابية، فتخرج العقود وبيانات الموقعين إلى سيرفرات شركة أخرى. وهذا المقال هو أول مقال في مرحلة المستندات والنماذج والتوقيع والحجز، وسوف نبدأ فيه من السؤال الذي يسبق اختيار الأداة: ما الذي يحدث فعلاً عندما «يوقع» شخص مستنداً في المتصفح، وما الذي يثبته هذا التوقيع، ثم نقارن أداتين مفتوحتي المصدر تستضيفهما بنفسك، وهما Documenso وDocuSeal، ونشغل DocuSeal على جهازنا ونوقع به مستنداً حقيقياً ونفحص النتيجة.

وسوف نناقش في هذا المقال ما يلي:

• الفرق بين التوقيع الإلكتروني Electronic Signature والتوقيع الرقمي Digital Signature، ولماذا تجمع الأداتان بينهما.
• ماذا يقول نظام التعاملات الإلكترونية في المملكة عن التوقيع الإلكتروني، وما الذي يستثنيه.
• ماذا يحدث خلف الشاشة من رفع المستند إلى وصول النسخة الموقعة وسجل التدقيق Audit Trail.
• Documenso أم DocuSeal: نقاط القوة ونقاط الضعف والتراخيص كما في ملفات المستودع.
• تجربة عملية مع DocuSeal 3.3.1: نوقع ملف PDF، ونقرأ سجل التدقيق، ونتحقق من التوقيع بأداة مستقلة، ثم نغير بايتاً واحداً في الملف ونرى ماذا يحدث.
• ما الذي تغيره قبل التشغيل الفعلي، وأخطاء شائعة.

التوقيع الإلكتروني Electronic Signature والتوقيع الرقمي Digital Signature

التوقيع الإلكتروني Electronic Signature هو أي وسيلة إلكترونية يعبر بها شخص عن موافقته على مستند، فقد يكون رسماً بالإصبع على الشاشة، أو كتابة الاسم، أو الضغط على مربع «أوافق»، وقيمته ليست في شكل الرسم وإنما في الأدلة المحيطة به: من هو هذا الشخص (بريده أو رقم جواله)، ومتى وقع، ومن أي جهاز وعنوان IP، وما الخطوات التي مر بها قبل أن يوقع، وهذه الأدلة تحفظ في سجل التدقيق Audit Trail. أما التوقيع الرقمي Digital Signature فهو عملية تشفير، حيث يحسب البرنامج الهاش Hash لمحتوى الملف، ثم يوقع هذا الهاش بالمفتاح الخاص Private Key، ويضع التوقيع ومعه الشهادة Certificate داخل ملف PDF، فإذا تغير بايت واحد في الملف بعد ذلك فشل التحقق. وقد شرحنا فكرة التوقيع بالمفتاح الخاص وأنه ليس تشفيراً في مقال التشفير للمطورين، وشرحنا سلسلة الثقة Chain of Trust وملفات PKCS#12 في مقال الشهادات الرقمية، فلن نعيد ذلك هنا.

والصورة التالية تبين الفرق بين الاثنين، ولاحظ في أسفلها أن أدوات التوقيع التي تستضيفها بنفسك تقوم بالأمرين معاً: رسم الموقع وسجل التدقيق هما التوقيع الإلكتروني، ثم يختم السيرفر ملف PDF النهائي بشهادته هو، وهذا هو التوقيع الرقمي:

وقد يتساءل البعض: إذا كان التوقيع الرقمي أقوى، فلماذا لا يوقع كل شخص بمفتاحه الخاص؟ والإجابة أن ذلك يحتاج أن يملك كل موقع شهادة صادرة له باسمه من جهة تصديق، على بطاقة ذكية أو تطبيق أو جهاز آمن، وهذا متاح في بعض الجهات ولكنه غير عملي لعميل يوقع نموذجاً واحداً، لذلك تعتمد هذه الأدوات على أدلة الهوية في سجل التدقيق، ثم تختم الملف بشهادة واحدة للمنصة، وتذكر أن هذه الشهادة تثبت أن الملف لم يتغير بعد الختم، ولا تثبت وحدها هوية من رسم التوقيع.

ماذا يقول النظام عن التوقيع الإلكتروني؟

في المملكة يعرف نظام التعاملات الإلكترونية الصادر بالمرسوم الملكي رقم م/18 بتاريخ 8/3/1428هـ التوقيع الإلكتروني في مادته الأولى بأنه «بيانات إلكترونية مدرجة في تعامل إلكتروني أو مضافة إليه أو مرتبطة به منطقياً تستخدم لإثبات هوية الموقع وموافقته على التعامل الإلكتروني واكتشاف أي تعديل يطرأ على هذا التعامل بعد التوقيع عليه»، ولاحظ أن التعريف نفسه يجمع العناصر الثلاثة التي رأيناها في الصورة السابقة: الهوية، والموافقة، واكتشاف التعديل. وتنص المادة الخامسة على أن للتعاملات والسجلات والتوقيعات الإلكترونية حجيتها الملزمة، ولا يجوز نفي صحتها بسبب أنها تمت إلكترونياً، وتنص المادة الرابعة عشرة على أنه إذا اشترط وجود توقيع خطي على مستند أو عقد فإن التوقيع الإلكتروني الذي يتم وفقاً للنظام يعد مستوفياً لهذا الشرط.

ولكن النظام يستثني في مادته الثالثة التعاملات المتعلقة بالأحوال الشخصية، وإصدار الصكوك المتعلقة بالتصرفات الواردة على العقار، وتشترط المادة التاسعة لقبول التوقيع دليلاً في الإثبات أن يستوفي سجله الإلكتروني متطلبات المادة الثامنة. وفي الاتحاد الأوروبي يميز نظام eIDAS بين ثلاثة مستويات: التوقيع الإلكتروني العادي، والتوقيع المتقدم Advanced، والتوقيع المؤهل Qualified الذي يعتمد على شهادة مؤهلة وجهاز توقيع مؤهل، والمؤهل وحده له أثر التوقيع الخطي نفسه هناك.

ماذا يحدث من رفع المستند إلى وصول النسخة الموقعة؟

الأداتان تتبعان المسار نفسه تقريباً، فالمرسل يرفع ملف PDF ويحدد عليه أماكن الحقول مثل التوقيع والتاريخ ولمن يتبع كل حقل، ثم ينشئ السيرفر طلب توقيع Submission ورابطاً فريداً لكل موقع، ويرسله بالبريد أو تأخذه أنت من ال API وترسله بطريقتك، ثم يفتح الموقع الرابط في أي متصفح ويرسم توقيعه ويكمل الحقول، وبعدها يقوم السيرفر بدمج صورة التوقيع والقيم في ملف PDF، ويحسب الهاش، ويختم الملف بشهادة المنصة، وينشئ سجل التدقيق في ملف PDF مختوم أيضاً، والصورة التالية تبين هذه الخطوات:

ولاحظ أن الخطوة الرابعة هي التي تجعل المستند قابلاً للتحقق لاحقاً، لأن الختم الرقمي يغطي الملف كاملاً، وأن سجل التدقيق يحتوي على هاش الملف الأصلي وهاش الملف الناتج، فإذا أرسل لك أحد نسخة يدعي أنها الموقعة، تستطيع أن تحسب هاشها وتقارنه بالسجل كما سوف نرى في التجربة.

Documenso أم DocuSeal؟

الأداتان مفتوحتا المصدر، وتعملان في Docker، ولكل منهما نسخة سحابية مدفوعة ونسخة تستضيفها بنفسك، والفرق الحقيقي بينهما في طريقة التشغيل وما الذي يبقى في النسخة المجانية.

Documenso

Documenso مكتوب بلغة TypeScript، وأحدث إصدار عند كتابة المقال هو v2.20.0 بتاريخ 8 أكتوبر 2026. ويحتاج بحسب دليل التثبيت بال Docker قاعدة PostgreSQL من الإصدار 14 أو أحدث، وبيانات سيرفر بريد SMTP، وشهادة توقيع بصيغة .p12 تمررها عبر NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH وNEXT_PRIVATE_SIGNING_PASSPHRASE، وينبه الدليل إلى ألا تنشئ الشهادة داخل ال Container، لأنها تضيع إذا أعيد إنشاؤه. وتذكر صفحة شهادة التوقيع أن الشهادة الموقعة ذاتياً Self-signed كافية لأغلب الاستخدامات، ولكن Adobe Acrobat لن يظهر معها العلامة الخضراء لأنها ليست في قائمة الثقة لديه.

• نقاط القوة: تفرض عليك من البداية التفكير في شهادة التوقيع وحفظها خارج ال Container، والكود بلغة واحدة مألوفة لمطوري الويب، وفيها API وتكامل للتضمين Embedding.
• نقاط الضعف: تحتاج قاعدة بيانات وسيرفر بريد وشهادة قبل أن توقع أول مستند، وبعض الميزات خارج الترخيص المفتوح كما في قسم التراخيص.

DocuSeal

DocuSeal مكتوب بلغة Ruby on Rails، وأحدث إصدار هو 3.3.1 بتاريخ 5 أكتوبر 2026، ويعمل بأمر docker run واحد، حيث يستخدم قاعدة SQLite داخل ال Volume إذا لم تحدد DATABASE_URL، وينشئ شهادة توقيع ذاتية تلقائياً عند أول تشغيل، كما سوف نرى في التجربة، ويدعم PostgreSQL وMySQL بمتغير DATABASE_URL، وتخزين الملفات على القرص أو S3 أو Google Storage أو Azure بحسب صفحة المشروع.

• نقاط القوة: أسهل في البداية، وفيه محرر حقول مرئي، وتحقق من توقيع ملفات PDF من داخل الواجهة، وAPI وWebhooks في النسخة المفتوحة، وواجهة التوقيع متاحة بعدة لغات.
• نقاط الضعف: الشهادة التلقائية ذاتية ولا يثق بها أي قارئ PDF خارج DocuSeal، وإنشاء القوالب من ملفات PDF عبر ال API، والتضمين، والتذكير التلقائي، والتحقق برسائل SMS، وSSO كلها في نسخة Pro المدفوعة بحسب صفحة المشروع.

التراخيص كما في المستودع

قرأنا ملفات الترخيص من المستودعين عند الإصدارين المذكورين، وهذه النتيجة:

وتذكر أن ترخيص AGPL يلزمك بنشر كود أي تعديل تقوم به إذا قدمت الأداة المعدلة لمستخدمين عبر الشبكة، وقد شرحنا ذلك في مقال التراخيص، أما استخدامها كما هي داخل شركتك فلا يلزمك بشيء.

تجربة عملية: نوقع مستنداً مع DocuSeal 3.3.1

اخترنا DocuSeal للتجربة لأنه يعمل بأمر واحد، ولأن ما نريد فهمه، أي الختم وسجل التدقيق والتحقق، موجود في الأداتين بالطريقة نفسها. والتجربة على Docker Engine 29.8.0، والمنفذ مربوط بالعنوان 127.0.0.1 فقط، وأسماء ال Container وال Volume تبدأ ب lab-office2- لأنها أسماء بيئة التجربة عندنا، فاستبدلها بما يناسبك. وإذا لم يكن Docker مثبتاً لديك فقد شرحنا تثبيت Docker على Ubuntu.

التشغيل والإعداد الأول

docker volume create lab-office2-docuseal-data
docker run -d --name lab-office2-docuseal \
  -p 127.0.0.1:28301:3000 \
  -v lab-office2-docuseal-data:/data \
  docuseal/docuseal:3.3.1
docker logs lab-office2-docuseal 2>&1 | head -7

والمخرج سوف يكون كما يلي:

Puma starting in single mode...
* Puma version: 8.0.2 ("Into the Arena")
* Ruby version: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux-musl]
*  Min threads: 15
*  Max threads: 15
*  Environment: production
*          PID: 1

بعد ذلك نفتح http://127.0.0.1:28301 فتحولنا الأداة إلى صفحة /setup، وفيها الاسم والبريد واسم الشركة وكلمة المرور وعنوان التطبيق App URL، وعنوان التطبيق مهم لأن روابط التوقيع التي تصل إلى الموقعين تبنى منه، فإذا وضعت فيه عنواناً داخلياً وصلت إليهم روابط لا تفتح. ولاحظ ما الذي أنشأه DocuSeal داخل ال Volume:

docker exec lab-office2-docuseal ls /data/docuseal

attachments
db.sqlite3
db.sqlite3-shm
db.sqlite3-wal
docuseal.env
dump.rdb

في المخرج أعلاه لاحظ التالي:

• db.sqlite3 هي قاعدة البيانات، وفيها القوالب والطلبات وسجل الأحداث، وفيها أيضاً شهادة التوقيع التي أنشأها DocuSeal مشفرة.
• docuseal.env يحتوي على المتغيرين DATABASE_URL وSECRET_KEY_BASE، والثاني هو المفتاح الذي تفك به البيانات المشفرة، فإذا فقدته فقدت الشهادة، لذلك يدخل في كل نسخة احتياطية مع القاعدة.
• attachments فيها ملفات PDF الأصلية والموقعة وصور التوقيعات.

القالب Template والحقول

جهزنا ملف PDF تجريبياً من صفحة واحدة فيه مربع للتوقيع ومربع للتاريخ، ورفعناه من زر Upload في لوحة التحكم، فتح DocuSeal محرر الحقول، وعند الضغط على Autodetect fields اكتشف المربعين وحدهما، ولكنه اعتبر مربع التوقيع حقل نص Text، فغيرنا نوعه إلى Signature من القائمة بجانب اسم الحقل، ثم فعلنا خيار Required للحقلين من إعدادات كل حقل، لأن الحقول المكتشفة تلقائياً تأتي اختيارية، وبدون هذا الخيار يستطيع الموقع إكمال الطلب دون أن يوقع. والصورة التالية تبين القالب بعد التعديل:

إنشاء طلب التوقيع عبر ال API

يمكنك إرسال الطلب من زر Send، ولكنه يحتاج إعداد SMTP لإرسال البريد، لذلك أنشأنا الطلب عبر ال API مع send_email بقيمة false، ثم أخذنا الرابط من الرد. ومفتاح ال API تجده في Settings ثم API، ويرسل في الترويسة X-Auth-Token:

TOKEN='ضع-مفتاح-API-هنا'
curl -s -X POST http://127.0.0.1:28301/api/submissions \
  -H "X-Auth-Token: $TOKEN" -H 'Content-Type: application/json' \
  -d '{"template_id":1,"send_email":false,"submitters":[{"role":"First Party","email":"[email protected]","name":"Test Signer"}]}'

والمخرج سوف يكون كما يلي:

[{"id":1,"slug":"GPYX3zM3daR17t","uuid":"38b12407-8666-4bfd-8658-d272d9775435","name":"Test Signer","email":"[email protected]","phone":null,"completed_at":null,"declined_at":null,"external_id":null,"submission_id":1,"metadata":{},"opened_at":null,"sent_at":null,"created_at":"2026-10-08T18:36:53.651Z","updated_at":"2026-10-08T18:36:53.651Z","status":"awaiting","application_key":null,"values":[],"preferences":{"send_email":false,"send_sms":false},"role":"First Party","embed_src":"http://127.0.0.1:28301/s/GPYX3zM3daR17t"}]

ولاحظ أن الحالة awaiting، وأن embed_src هو رابط التوقيع الذي ترسله للموقع بأي طريقة، وأن الرابط مبني من عنوان التطبيق الذي أدخلناه في الإعداد الأول. وقد حاولنا أيضاً إنشاء القالب نفسه من ملف PDF عبر ال API بدل الواجهة، فكان الرد:

{"status":404,"message":"This feature is available in Pro Edition: https://www.docuseal.com/pricing"}

أي أن إنشاء الطلبات وقراءة حالتها متاح في النسخة المفتوحة، أما إنشاء القوالب من الملفات عبر ال API فهو في Pro، فإذا كان نظامك يولد عقوداً تلقائياً ويريد إرسالها للتوقيع دون تدخل يدوي فاحسب هذا الأمر قبل أن تختار.

التوقيع من جهة الموقع

يفتح الموقع الرابط فيرى المستند وزر Sign Now، ثم يرسم توقيعه أو يكتبه أو يرفع صورته، ثم ينتقل إلى حقل التاريخ ويضغط Complete:

ثم نتأكد من الحالة عبر ال API، ونعد الأحداث التي سجلها DocuSeal:

curl -s http://127.0.0.1:28301/api/submissions/1 -H "X-Auth-Token: $TOKEN" \
  | grep -o '"status":"[a-z]*"\|"completed_at":"[^"]*"\|"event_type":"[a-z_]*"' | sort | uniq -c

      2 "completed_at":"2026-10-08T18:40:53.600Z"
      1 "event_type":"complete_form"
      1 "event_type":"start_form"
      7 "event_type":"view_form"
      2 "status":"completed"

ولاحظ أن كل مرة فتح فيها الموقع الرابط سجلت كحدث view_form، وقد فتحناه سبع مرات أثناء التجربة، وهذه الأحداث نفسها هي التي تظهر في سجل التدقيق.

قراءة سجل التدقيق Audit Log

يحتوي رد ال API على audit_log_url ورابط الملف الموقع في documents، وقد نزلنا الملفين باسم audit.pdf وsigned.pdf، والصورة التالية تبين سجل التدقيق:

ولاحظ أن الهاش في السجل مكتوب بترميز Base64 بالصيغة الآمنة للروابط URL-safe، لذلك نحسب هاش الملفين بالطريقة نفسها لنقارن:

for f in test-agreement.pdf signed.pdf; do
  echo "$f $(openssl dgst -sha256 -binary $f | base64 | tr '+/' '-_')"
done

test-agreement.pdf HCXV4XC1rNerZ87vwl5BO6z-kzU-uQVEzpcBmRWBdTA=
signed.pdf dMzCe7s_TyOpO4jGTmxNldFou1l5ScANJ_4EpHP7qqY=

والقيمتان مطابقتان لما في السجل في السطرين Original SHA256 وResult SHA256، وهذا يعني أنك تستطيع بعد سنوات أن تثبت أن الملف الذي بين يديك هو الملف نفسه الذي وقع، ولاحظ أيضاً أن عنوان IP في السجل هو 172.17.0.1، وهو عنوان شبكة Docker وليس عنوان الموقع، والسبب أننا فتحنا الرابط من الجهاز نفسه، وفي الإنتاج خلف Reverse Proxy يجب أن يمرر ال Proxy عنوان الزائر الحقيقي، كما شرحنا في مقال تطبيقك خلف Reverse Proxy، وإلا ظهر في كل السجلات عنوان ال Proxy.

التحقق من الختم بأداة مستقلة

لا نريد أن نعتمد على DocuSeal وحده ليخبرنا أن توقيعه صحيح، لذلك تحققنا بمكتبة pyHanko بالإصدار 0.29.1 داخل Container من python:3.13-slim-trixie، بهذا السكربت:

import logging; logging.disable(logging.CRITICAL)
import sys
from pyhanko.pdf_utils.reader import PdfFileReader
from pyhanko.sign.validation import validate_pdf_signature
for fn in sys.argv[1:]:
    with open(fn, 'rb') as f:
        r = PdfFileReader(f)
        print(fn, 'signatures:', len(r.embedded_signatures))
        for s in r.embedded_signatures:
            st = validate_pdf_signature(s)
            c = s.signer_cert
            print(' field:', s.field_name)
            print(' signer:', c.subject.human_friendly)
            print(' issuer:', c.issuer.human_friendly)
            print(' signing time:', s.self_reported_timestamp)
            print(' intact:', st.intact, '| valid:', st.valid, '| trusted:', st.trusted)
            print(' coverage:', st.coverage.name, '| md:', st.md_algorithm)

ثم غيرنا بايتاً واحداً في نسخة من الملف الموقع، وهو رقم الإصدار في حقل /Producer من 1.7.0 إلى 1.7.1، وحفظناها باسم tampered.pdf، وشغلنا السكربت على الملفين:

python /work/val.py /work/signed.pdf /work/tampered.pdf

/work/signed.pdf signatures: 1
 field: Signature1
 signer: Common Name: DocuSeal, Organization: DocuSeal, Country: AT
 issuer: Common Name: DocuSeal Sub-CA, Organization: DocuSeal, Country: AT
 signing time: 2026-10-08 18:40:55+00:00
 intact: True | valid: True | trusted: False
 coverage: ENTIRE_FILE | md: sha256
/work/tampered.pdf signatures: 1
 field: Signature1
 signer: Common Name: DocuSeal, Organization: DocuSeal, Country: AT
 issuer: Common Name: DocuSeal Sub-CA, Organization: DocuSeal, Country: AT
 signing time: 2026-10-08 18:40:55+00:00
 intact: False | valid: True | trusted: False
 coverage: ENTIRE_FILE | md: sha256

في المخرج أعلاه لاحظ التالي:

• intact تعني أن هاش الملف الحالي يطابق الهاش الموقع، وهي True للملف الأصلي وFalse بعد تغيير بايت واحد، وهذا هو اكتشاف التعديل الذي يذكره تعريف النظام.
• valid تعني أن التوقيع نفسه صحيح رياضياً على البيانات الموقعة، وتبقى True في الملفين لأن التوقيع لم يتغير، والذي تغير هو الملف.
• trusted هي False في الملفين، والسبب أن السلسلة تنتهي عند شهادة رئيسية Root CA اسمها DocuSeal Root CA أنشأها السيرفر بنفسه، ولا يعرفها pyHanko ولا Adobe.
• coverage: ENTIRE_FILE تعني أن التوقيع يغطي الملف كله، فلا يمكن إضافة صفحة أو تعديل نص دون أن يكتشف.
• الموقع في الشهادة هو DocuSeal وليس Test Signer، وهذا ما قلناه في البداية: الشهادة تخص المنصة، وهوية الشخص في سجل التدقيق.

وفي DocuSeal نفسه صفحة Settings ثم E-Signature وفيها Verify Signed PDF، وعندما رفعنا الملف الأصلي ظهرت الرسالة Signature valid مع Signed with trusted certificate، لأن DocuSeal يثق بالشهادة الرئيسية التي أنشأها هو، وعندما رفعنا الملف المعدل ظهرت الرسالة التالية:

والصورة التالية تجمع الفكرتين، فالسلامة Integrity سؤال، والثقة Trust سؤال آخر:

قبل التشغيل الفعلي

التجربة أعلاه تكفي لتفهم الأداة، أما التشغيل الفعلي فيحتاج ما يلي:

1. قاعدة البيانات Database: ملف docker-compose.yml الرسمي يستخدم PostgreSQL 18 عبر DATABASE_URL، وهو أنسب من SQLite إذا كثرت الطلبات أو أردت نسخاً احتياطياً بأدوات قواعد البيانات المعتادة.
2. HTTPS: الملف نفسه يضع Caddy أمام التطبيق ويضبط FORCE_SSL، وإذا كان لديك Reverse Proxy فقد شرحنا تثبيت Caddy، ولا تقم بفتح المنفذ 3000 للإنترنت مباشرة.
3. البريد SMTP: حتى تصل روابط التوقيع والنسخ الموقعة بالبريد، وتأكد أن رسائلك لا تذهب إلى الرسائل المزعجة كما في مقال البريد التفاعلي.
4. شهادة التوقيع: إذا كان المستلمون يفتحون الملفات في Adobe Acrobat ويتوقعون العلامة الخضراء، فارفع شهادة .p12 صادرة من جهة موثوقة من Upload Cert، وأضف خادم ختم زمني Timestamp Server حتى يبقى وقت التوقيع قابلاً للإثبات بعد انتهاء الشهادة.
5. النسخ الاحتياطي Backup: قاعدة البيانات ومجلد attachments وملف docuseal.env معاً، واختبر الاستعادة كما في قاعدة 3-2-1، والسبب أن المستند الموقع دون سجله، أو السجل دون مفتاح فك الشهادة، أقل قيمة بكثير عند أي نزاع.

أخطاء شائعة

الموقع أكمل الطلب دون أن يوقع

السبب أن الحقل اختياري، وهذا ما يحدث مع الحقول المكتشفة تلقائياً، فافتح إعدادات كل حقل في القالب وفعل Required قبل أن ترسل أي طلب.

الخطأ This feature is available in Pro Edition

يظهر عند استدعاء جزء من ال API خارج النسخة المفتوحة، مثل /api/templates/pdf، والحل أن تنشئ القالب من الواجهة مرة واحدة ثم تنشئ الطلبات منه عبر /api/submissions، أو أن تشترك في Pro إذا كانت القوالب تتغير مع كل طلب.

Adobe يقول إن التوقيع لا يمكن التحقق منه

هذا متوقع مع الشهادة التلقائية، لأن الشهادة الرئيسية التي أنشأها السيرفر ليست في قائمة الثقة لدى Adobe، والملف لم يتغير، فإذا كان هذا التحذير يربك عملاءك فالحل شهادة صادرة من جهة موثوقة.

فقدت الشهادة بعد نقل السيرفر

السبب في الغالب أنك نقلت قاعدة البيانات دون docuseal.env، فلا يستطيع DocuSeal فك البيانات المشفرة، فانقل ال Volume كاملاً، أو انقل الملف مع القاعدة دائماً.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• التوقيع الإلكتروني يثبت الموافقة بالأدلة في سجل التدقيق، والتوقيع الرقمي يثبت أن الملف لم يتغير، وDocuSeal وDocumenso يقومان بالأمرين: رسم الموقع وسجله، ثم ختم الملف بشهادة المنصة.
• نظام التعاملات الإلكترونية يعطي التوقيع الإلكتروني حجية التوقيع الخطي، ويستثني الأحوال الشخصية وصكوك العقار، وللعقود الحساسة راجع المختص القانوني.
• DocuSeal يعمل بأمر واحد وشهادة تلقائية، وDocumenso يطلب PostgreSQL وSMTP وشهادة من البداية، والاثنان AGPL مع أجزاء مدفوعة: مجلد packages/ee في Documenso، وميزات Pro خارج المستودع في DocuSeal.
• في التجربة طابق هاش الملفين ما في سجل التدقيق، وفشل التحقق بعد تغيير بايت واحد، وظهرت الشهادة التلقائية غير موثوقة خارج DocuSeal.
• قبل الإنتاج: PostgreSQL وHTTPS وSMTP وشهادة موثوقة إذا احتجتها، ونسخ احتياطي يشمل مفتاح فك الشهادة.

وفي المقالات القادمة من هذه المرحلة بإذن الله سوف نتحدث عن النماذج والاستبيانات، ثم حجز المواعيد وتحويل ملفات PDF.

دليلالتشفير للمطورين: ماذا تستخدم ولماذا لا تخترع خوارزميتكأي هاش تستخدم لكلمات المرور، ومتى تحتاج التشفير المتماثل أو غير المتماثل، وأين تحفظ المفاتيح بأمان في تطبيقك.دليلالشهادات الرقمية TLS للمبتدئين وصيغ ملفاتهاكيف يعرف المتصفح أنه يتحدث مع الموقع الحقيقي، وماذا يوجد داخل الشهادة، ولماذا تأتي ملفاتها بأكثر من صيغة.دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.دليلFormbricks: استبيانات ونماذج حديثة على سيرفرككيف تثبت Formbricks وتنشئ استبياناً عربياً بالرابط أو داخل تطبيقك، وتبقى الإجابات في قاعدة بياناتك على سيرفرك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتجربة العملية على DocuSeal 3.3.1 مع SQLite، والتحقق بمكتبة pyHanko 0.29.1، وقراءة تراخيص Documenso v2.20.0 وDocuSeal 3.3.1 من المستودعين.