> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # التوقيع الإلكتروني على سيرفرك: DocuSeal أم Documenso؟ - URL: https://arabroot.io/articles/التوقيع-الإلكتروني-على-سيرفرك-docuseal-و-documenso/ - Published: 2026-10-09T06:30:00.000Z - Updated: 2026-10-14T07:41:30.000Z - Description: ما الفرق بين التوقيع الإلكتروني والرقمي، وكيف توقع مستنداتك على سيرفرك وتتحقق أن الملف لم يتغير بعد التوقيع. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, تطبيقات لفريقك, الاستضافة الذاتية, DocuSeal, Documenso ترسل الشركة عقداً أو نموذج موافقة إلى موظف أو عميل، فيقوم بطباعته وتوقيعه بالقلم ثم تصويره بالجوال وإرساله مرة أخرى، أو تدفع الشركة اشتراكاً شهرياً لكل مستخدم في خدمة توقيع سحابية، فتخرج العقود وبيانات الموقعين إلى سيرفرات شركة أخرى. وهذا المقال هو أول مقال في مرحلة [المستندات والنماذج والتوقيع والحجز](https://arabroot.io/start/#stage-office)، وسوف نبدأ فيه من السؤال الذي يسبق اختيار الأداة: ما الذي يحدث فعلاً عندما «يوقع» شخص مستنداً في المتصفح، وما الذي يثبته هذا التوقيع، ثم نقارن أداتين مفتوحتي المصدر تستضيفهما بنفسك، وهما 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، فإذا تغير بايت واحد في الملف بعد ذلك فشل التحقق. وقد شرحنا فكرة [التوقيع بالمفتاح الخاص وأنه ليس تشفيراً](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B4%D9%81%D9%8A%D8%B1-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D9%87%D8%A7%D8%B4-%D9%88%D9%83%D9%84%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D9%88%D8%B1-%D9%88%D8%A7%D9%84%D9%85%D9%81%D8%A7%D8%AA%D9%8A%D8%AD/#signatures) في مقال التشفير للمطورين، وشرحنا [سلسلة الثقة Chain of Trust](https://arabroot.io/articles/%D8%A7%D9%84%D8%B4%D9%87%D8%A7%D8%AF%D8%A7%D8%AA-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A%D8%A9-tls-%D9%88-x509-%D9%88%D8%B5%D9%8A%D8%BA-pem-%D9%88-der/#chain-of-trust) وملفات [PKCS#12](https://arabroot.io/articles/%D8%A7%D9%84%D8%B4%D9%87%D8%A7%D8%AF%D8%A7%D8%AA-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A%D8%A9-tls-%D9%88-x509-%D9%88%D8%B5%D9%8A%D8%BA-pem-%D9%88-der/#pkcs12) في مقال الشهادات الرقمية، فلن نعيد ذلك هنا. والصورة التالية تبين الفرق بين الاثنين، ولاحظ في أسفلها أن أدوات التوقيع التي تستضيفها بنفسك تقوم بالأمرين معاً: رسم الموقع وسجل التدقيق هما التوقيع الإلكتروني، ثم يختم السيرفر ملف PDF النهائي بشهادته هو، وهذا هو التوقيع الرقمي: ![مخطط من جزأين: على اليسار التوقيع الإلكتروني وهو مستند عليه رسم توقيع ومعه أدلة من وقع ومتى ومن أي جهاز وما الخطوات، وعلى اليمين التوقيع الرقمي حيث يحسب هاش SHA-256 لملف PDF ثم يوقع بالمفتاح الخاص ويوضع التوقيع والشهادة داخل الملف](https://arabroot.io/content/images/2026/10/esign-01-esign-vs-digital.webp) التوقيع الإلكتروني يجيب: هل وافق هذا الشخص؟ والتوقيع الرقمي يجيب: هل تغير الملف، ومن يملك المفتاح؟ وقد يتساءل البعض: إذا كان التوقيع الرقمي أقوى، فلماذا لا يوقع كل شخص بمفتاحه الخاص؟ والإجابة أن ذلك يحتاج أن يملك كل موقع شهادة صادرة له باسمه من جهة تصديق، على بطاقة ذكية أو تطبيق أو جهاز آمن، وهذا متاح في بعض الجهات ولكنه غير عملي لعميل يوقع نموذجاً واحداً، لذلك تعتمد هذه الأدوات على أدلة الهوية في سجل التدقيق، ثم تختم الملف بشهادة واحدة للمنصة، وتذكر أن هذه الشهادة تثبت أن الملف لم يتغير بعد الختم، ولا تثبت وحدها هوية من رسم التوقيع. ## ماذا يقول النظام عن التوقيع الإلكتروني؟ في المملكة يعرف [نظام التعاملات الإلكترونية](https://laws.boe.gov.sa/BoeLaws/Laws/LawDetails/6f509360-2c39-4358-ae2a-a9a700f2ed16/1?ref=arabroot.io) الصادر بالمرسوم الملكي رقم م/18 بتاريخ 8/3/1428هـ التوقيع الإلكتروني في مادته الأولى بأنه «بيانات إلكترونية مدرجة في تعامل إلكتروني أو مضافة إليه أو مرتبطة به منطقياً تستخدم لإثبات هوية الموقع وموافقته على التعامل الإلكتروني واكتشاف أي تعديل يطرأ على هذا التعامل بعد التوقيع عليه»، ولاحظ أن التعريف نفسه يجمع العناصر الثلاثة التي رأيناها في الصورة السابقة: الهوية، والموافقة، واكتشاف التعديل. وتنص المادة الخامسة على أن للتعاملات والسجلات والتوقيعات الإلكترونية حجيتها الملزمة، ولا يجوز نفي صحتها بسبب أنها تمت إلكترونياً، وتنص المادة الرابعة عشرة على أنه إذا اشترط وجود توقيع خطي على مستند أو عقد فإن التوقيع الإلكتروني الذي يتم وفقاً للنظام يعد مستوفياً لهذا الشرط. ولكن النظام يستثني في مادته الثالثة التعاملات المتعلقة بالأحوال الشخصية، وإصدار الصكوك المتعلقة بالتصرفات الواردة على العقار، وتشترط المادة التاسعة لقبول التوقيع دليلاً في الإثبات أن يستوفي سجله الإلكتروني متطلبات المادة الثامنة. وفي الاتحاد الأوروبي يميز [نظام eIDAS](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=arabroot.io) بين ثلاثة مستويات: التوقيع الإلكتروني العادي، والتوقيع المتقدم Advanced، والتوقيع المؤهل Qualified الذي يعتمد على شهادة مؤهلة وجهاز توقيع مؤهل، والمؤهل وحده له أثر التوقيع الخطي نفسه هناك. ⚠️ هذا المقال تقني وليس استشارة قانونية، فإذا كانت مستنداتك عقوداً كبيرة أو تخضع لتنظيم خاص في قطاعك، فراجع المختص القانوني في جهتك عن مستوى التوقيع المطلوب، وهل تكفي شهادة المنصة أم تحتاج شهادة صادرة من مقدم خدمات تصديق معتمد. ## ماذا يحدث من رفع المستند إلى وصول النسخة الموقعة؟ الأداتان تتبعان المسار نفسه تقريباً، فالمرسل يرفع ملف PDF ويحدد عليه أماكن الحقول مثل التوقيع والتاريخ ولمن يتبع كل حقل، ثم ينشئ السيرفر طلب توقيع Submission ورابطاً فريداً لكل موقع، ويرسله بالبريد أو تأخذه أنت من ال API وترسله بطريقتك، ثم يفتح الموقع الرابط في أي متصفح ويرسم توقيعه ويكمل الحقول، وبعدها يقوم السيرفر بدمج صورة التوقيع والقيم في ملف PDF، ويحسب الهاش، ويختم الملف بشهادة المنصة، وينشئ سجل التدقيق في ملف PDF مختوم أيضاً، والصورة التالية تبين هذه الخطوات: ![مخطط فيه المرسل على اليسار وسيرفرك في الوسط والموقع على اليمين، مع خمس خطوات مرقمة: رفع المستند وتحديد الحقول، ثم إرسال رابط التوقيع، ثم الرسم وإكمال التاريخ، ثم دمج التوقيع وحساب الهاش وختم الملف بشهادة السيرفر، ثم تنزيل النسخة الموقعة وسجل التدقيق](https://arabroot.io/content/images/2026/10/esign-02-signing-flow.webp) كل الخطوات تتم على سيرفرك، فلا يخرج المستند ولا بيانات الموقع إلى خدمة خارجية ولاحظ أن الخطوة الرابعة هي التي تجعل المستند قابلاً للتحقق لاحقاً، لأن الختم الرقمي يغطي الملف كاملاً، وأن سجل التدقيق يحتوي على هاش الملف الأصلي وهاش الملف الناتج، فإذا أرسل لك أحد نسخة يدعي أنها الموقعة، تستطيع أن تحسب هاشها وتقارنه بالسجل كما سوف نرى في التجربة. ## Documenso أم DocuSeal؟ الأداتان مفتوحتا المصدر، وتعملان في Docker، ولكل منهما نسخة سحابية مدفوعة ونسخة تستضيفها بنفسك، والفرق الحقيقي بينهما في طريقة التشغيل وما الذي يبقى في النسخة المجانية. ### Documenso Documenso مكتوب بلغة TypeScript، وأحدث إصدار عند كتابة المقال هو [v2.20.0](https://github.com/documenso/documenso/releases/tag/v2.20.0?ref=arabroot.io) بتاريخ 8 أكتوبر 2026\. ويحتاج بحسب [دليل التثبيت بال Docker](https://docs.documenso.com/docs/self-hosting/deployment/docker?ref=arabroot.io) قاعدة PostgreSQL من الإصدار 14 أو أحدث، وبيانات سيرفر بريد SMTP، وشهادة توقيع بصيغة `.p12` تمررها عبر `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` و`NEXT_PRIVATE_SIGNING_PASSPHRASE`، وينبه الدليل إلى ألا تنشئ الشهادة داخل ال Container، لأنها تضيع إذا أعيد إنشاؤه. وتذكر صفحة [شهادة التوقيع](https://docs.documenso.com/docs/self-hosting/configuration/signing-certificate?ref=arabroot.io) أن الشهادة الموقعة ذاتياً Self-signed كافية لأغلب الاستخدامات، ولكن Adobe Acrobat لن يظهر معها العلامة الخضراء لأنها ليست في قائمة الثقة لديه. - **نقاط القوة:** تفرض عليك من البداية التفكير في شهادة التوقيع وحفظها خارج ال Container، والكود بلغة واحدة مألوفة لمطوري الويب، وفيها API وتكامل للتضمين Embedding. - **نقاط الضعف:** تحتاج قاعدة بيانات وسيرفر بريد وشهادة قبل أن توقع أول مستند، وبعض الميزات خارج الترخيص المفتوح كما في قسم التراخيص. ### DocuSeal DocuSeal مكتوب بلغة Ruby on Rails، وأحدث إصدار هو [3.3.1](https://github.com/docusealco/docuseal/releases/tag/3.3.1?ref=arabroot.io) بتاريخ 5 أكتوبر 2026، ويعمل بأمر `docker run` واحد، حيث يستخدم قاعدة SQLite داخل ال Volume إذا لم تحدد `DATABASE_URL`، وينشئ شهادة توقيع ذاتية تلقائياً عند أول تشغيل، كما سوف نرى في التجربة، ويدعم PostgreSQL وMySQL بمتغير `DATABASE_URL`، وتخزين الملفات على القرص أو S3 أو Google Storage أو Azure بحسب [صفحة المشروع](https://github.com/docusealco/docuseal?ref=arabroot.io). - **نقاط القوة:** أسهل في البداية، وفيه محرر حقول مرئي، وتحقق من توقيع ملفات PDF من داخل الواجهة، وAPI وWebhooks في النسخة المفتوحة، وواجهة التوقيع متاحة بعدة لغات. - **نقاط الضعف:** الشهادة التلقائية ذاتية ولا يثق بها أي قارئ PDF خارج DocuSeal، وإنشاء القوالب من ملفات PDF عبر ال API، والتضمين، والتذكير التلقائي، والتحقق برسائل SMS، وSSO كلها في نسخة Pro المدفوعة بحسب صفحة المشروع. ### التراخيص كما في المستودع قرأنا ملفات الترخيص من المستودعين عند الإصدارين المذكورين، وهذه النتيجة: | الأداة | الترخيص الأساسي | الاستثناءات | | ----------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Documenso v2.20.0 | [AGPL-3.0](https://github.com/documenso/documenso/blob/v2.20.0/LICENSE?ref=arabroot.io) | المجلد packages/ee تحت [ترخيص تجاري](https://github.com/documenso/documenso/blob/v2.20.0/packages/ee/LICENSE?ref=arabroot.io) لا يسمح بالاستخدام في الإنتاج دون اشتراك Enterprise، وملف [FEATURES](https://github.com/documenso/documenso/blob/v2.20.0/packages/ee/FEATURES?ref=arabroot.io) يذكر منها بوابة دخول المنظمة، وإعادة التحقق بال Passkeys و2FA قبل التوقيع، و21 CFR، ونطاقات البريد، وأدوات التضمين. | | DocuSeal 3.3.1 | [AGPL-3.0](https://github.com/docusealco/docuseal/blob/3.3.1/LICENSE?ref=arabroot.io) | ملف [شروط إضافية](https://github.com/docusealco/docuseal/blob/3.3.1/LICENSE%5FADDITIONAL%5FTERMS?ref=arabroot.io) بحسب المادة 7(b) من AGPL يشترط بقاء إشارة DocuSeal الأصلية في الواجهات التفاعلية، وميزات Pro ليست في المستودع أصلاً. | وتذكر أن ترخيص AGPL يلزمك بنشر كود أي تعديل تقوم به إذا قدمت الأداة المعدلة لمستخدمين عبر الشبكة، وقد شرحنا ذلك في [مقال التراخيص](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/)، أما استخدامها كما هي داخل شركتك فلا يلزمك بشيء. ## تجربة عملية: نوقع مستنداً مع DocuSeal 3.3.1 اخترنا DocuSeal للتجربة لأنه يعمل بأمر واحد، ولأن ما نريد فهمه، أي الختم وسجل التدقيق والتحقق، موجود في الأداتين بالطريقة نفسها. والتجربة على Docker Engine 29.8.0، والمنفذ مربوط بالعنوان 127.0.0.1 فقط، وأسماء ال Container وال Volume تبدأ ب `lab-office2-` لأنها أسماء بيئة التجربة عندنا، فاستبدلها بما يناسبك. وإذا لم يكن Docker مثبتاً لديك فقد شرحنا [تثبيت Docker على Ubuntu](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-docker-%D8%B9%D9%84%D9%89-ubuntu/). ### التشغيل والإعداد الأول ```bash 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 ``` والمخرج سوف يكون كما يلي: ```text 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: ```bash docker exec lab-office2-docuseal ls /data/docuseal ``` ```text 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** للحقلين من إعدادات كل حقل، لأن الحقول المكتشفة تلقائياً تأتي اختيارية، وبدون هذا الخيار يستطيع الموقع إكمال الطلب دون أن يوقع. والصورة التالية تبين القالب بعد التعديل: ![محرر القوالب في DocuSeal وفيه ملف Test Service Agreement وحقل توقيع وحقل تاريخ في مكانهما، وعلى اليمين قائمة أنواع الحقول وحقلا Signature Field 1 وDate Field 1](https://arabroot.io/content/images/2026/10/esign-03-builder.webp) القالب بعد الاكتشاف التلقائي وتصحيح نوع الحقل الأول إلى Signature ### إنشاء طلب التوقيع عبر ال API يمكنك إرسال الطلب من زر **Send**، ولكنه يحتاج إعداد SMTP لإرسال البريد، لذلك أنشأنا الطلب عبر ال API مع `send_email` بقيمة false، ثم أخذنا الرابط من الرد. ومفتاح ال API تجده في **Settings ثم API**، ويرسل في الترويسة `X-Auth-Token`: ```bash 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":"signer@example.com","name":"Test Signer"}]}' ``` والمخرج سوف يكون كما يلي: ```text [{"id":1,"slug":"GPYX3zM3daR17t","uuid":"38b12407-8666-4bfd-8658-d272d9775435","name":"Test Signer","email":"signer@example.com","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 بدل الواجهة، فكان الرد: ```text {"status":404,"message":"This feature is available in Pro Edition: https://www.docuseal.com/pricing"} ``` أي أن إنشاء الطلبات وقراءة حالتها متاح في النسخة المفتوحة، أما إنشاء القوالب من الملفات عبر ال API فهو في Pro، فإذا كان نظامك يولد عقوداً تلقائياً ويريد إرسالها للتوقيع دون تدخل يدوي فاحسب هذا الأمر قبل أن تختار. ### التوقيع من جهة الموقع يفتح الموقع الرابط فيرى المستند وزر **Sign Now**، ثم يرسم توقيعه أو يكتبه أو يرفع صورته، ثم ينتقل إلى حقل التاريخ ويضغط **Complete**: ![صفحة التوقيع في DocuSeal وفيها مربع التوقيع محدد على المستند، وفي الأسفل لوحة رسم فيها توقيع وأزرار Type وUpload وزر Next](https://arabroot.io/content/images/2026/10/esign-04-signing.webp) صفحة الموقع: لا يحتاج حساباً ولا تطبيقاً، ويكفيه المتصفح ![المستند بعد التوقيع وفيه رسم التوقيع والتاريخ 10/08/2026، وفي الأسفل رسالة Document has been signed وزر Download](https://arabroot.io/content/images/2026/10/esign-05-completed.webp) بعد الإكمال يستطيع الموقع تنزيل نسخته مباشرة ثم نتأكد من الحالة عبر ال API، ونعد الأحداث التي سجلها DocuSeal: ```bash 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 ``` ```text 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`، والصورة التالية تبين سجل التدقيق: ![سجل التدقيق من DocuSeal وفيه رقم الطلب وهاش SHA256 للملف الأصلي والناتج، وبريد الموقع واسمه وعنوان IP ومعرف الجلسة والمتصفح والمنطقة الزمنية، ثم صورة التوقيع والتاريخ، ثم قائمة الأحداث بالوقت](https://arabroot.io/content/images/2026/10/esign-06-audit-log.webp) سجل التدقيق: من وقع، ومن أين، ومتى، وما هاش الملف قبل التوقيع وبعده ولاحظ أن الهاش في السجل مكتوب بترميز Base64 بالصيغة الآمنة للروابط URL-safe، لذلك نحسب هاش الملفين بالطريقة نفسها لنقارن: ```bash for f in test-agreement.pdf signed.pdf; do echo "$f $(openssl dgst -sha256 -binary $f | base64 | tr '+/' '-_')" done ``` ```text 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](https://arabroot.io/articles/%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D9%83-%D8%AE%D9%84%D9%81-reverse-proxy/)، وإلا ظهر في كل السجلات عنوان ال Proxy. ### التحقق من الختم بأداة مستقلة لا نريد أن نعتمد على DocuSeal وحده ليخبرنا أن توقيعه صحيح، لذلك تحققنا بمكتبة [pyHanko](https://github.com/MatthiasValvekens/pyHanko?ref=arabroot.io) بالإصدار [0.29.1](https://pypi.org/project/pyHanko/0.29.1/?ref=arabroot.io) داخل Container من `python:3.13-slim-trixie`، بهذا السكربت: ```python 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`، وشغلنا السكربت على الملفين: ```bash python /work/val.py /work/signed.pdf /work/tampered.pdf ``` ```text /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 يثق بالشهادة الرئيسية التي أنشأها هو، وعندما رفعنا الملف المعدل ظهرت الرسالة التالية: ![صفحة إعدادات E-Signature في DocuSeal وفيها نتيجة فحص tampered.pdf برسالة Signature verification failed وسلسلة الشهادات، وتحتها جدول شهادات التوقيع وفيه DocuSeal Self-Host Autogenerated صالحة حتى 2126، وخيار Timestamp Server](https://arabroot.io/content/images/2026/10/esign-07-verify-tampered.webp) بعد تغيير بايت واحد يفشل التحقق، وفي الصفحة نفسها ترى الشهادة التلقائية وخيار رفع شهادتك والصورة التالية تجمع الفكرتين، فالسلامة Integrity سؤال، والثقة Trust سؤال آخر: ![مخطط من جزأين: على اليسار ملف موقع يعاد حساب هاشه فيطابق، وملف تغير فيه بايت واحد فلا يطابق، وعلى اليمين سلسلة الشهادات من DocuSeal Root CA إلى Sub-CA إلى شهادة التوقيع، موثوقة داخل DocuSeal وغير موثوقة في pyHanko وAdobe](https://arabroot.io/content/images/2026/10/esign-08-verify.webp) الختم الذاتي يثبت أن الملف لم يتغير، ولكن القارئ الخارجي لا يعرف من يملك المفتاح ## قبل التشغيل الفعلي التجربة أعلاه تكفي لتفهم الأداة، أما التشغيل الفعلي فيحتاج ما يلي: 1. **قاعدة البيانات Database:** ملف [docker-compose.yml](https://github.com/docusealco/docuseal/blob/3.3.1/docker-compose.yml?ref=arabroot.io) الرسمي يستخدم PostgreSQL 18 عبر `DATABASE_URL`، وهو أنسب من SQLite إذا كثرت الطلبات أو أردت نسخاً احتياطياً بأدوات قواعد البيانات المعتادة. 2. **HTTPS:** الملف نفسه يضع Caddy أمام التطبيق ويضبط `FORCE_SSL`، وإذا كان لديك Reverse Proxy فقد شرحنا [تثبيت Caddy](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-caddy-reverse-proxy/)، ولا تقم بفتح المنفذ 3000 للإنترنت مباشرة. 3. **البريد SMTP:** حتى تصل روابط التوقيع والنسخ الموقعة بالبريد، وتأكد أن رسائلك لا تذهب إلى الرسائل المزعجة كما في [مقال البريد التفاعلي](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B9%D9%84%D9%8A-transactional-email/). 4. **شهادة التوقيع:** إذا كان المستلمون يفتحون الملفات في Adobe Acrobat ويتوقعون العلامة الخضراء، فارفع شهادة `.p12` صادرة من جهة موثوقة من **Upload Cert**، وأضف خادم ختم زمني Timestamp Server حتى يبقى وقت التوقيع قابلاً للإثبات بعد انتهاء الشهادة. 5. **النسخ الاحتياطي Backup:** قاعدة البيانات ومجلد `attachments` وملف `docuseal.env` معاً، واختبر الاستعادة كما في [قاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، والسبب أن المستند الموقع دون سجله، أو السجل دون مفتاح فك الشهادة، أقل قيمة بكثير عند أي نزاع. ## أخطاء شائعة ### الموقع أكمل الطلب دون أن يوقع السبب أن الحقل اختياري، وهذا ما يحدث مع الحقول المكتشفة تلقائياً، فافتح إعدادات كل حقل في القالب وفعل 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. [![](https://arabroot.io/content/images/2026/10/crypto-for-devs-cover-cover.webp)دليلالتشفير للمطورين: ماذا تستخدم ولماذا لا تخترع خوارزميتكأي هاش تستخدم لكلمات المرور، ومتى تحتاج التشفير المتماثل أو غير المتماثل، وأين تحفظ المفاتيح بأمان في تطبيقك.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B4%D9%81%D9%8A%D8%B1-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D9%87%D8%A7%D8%B4-%D9%88%D9%83%D9%84%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D9%88%D8%B1-%D9%88%D8%A7%D9%84%D9%85%D9%81%D8%A7%D8%AA%D9%8A%D8%AD/)[![](https://arabroot.io/content/images/2026/10/certificates-cover-cover.webp)دليلالشهادات الرقمية TLS للمبتدئين وصيغ ملفاتهاكيف يعرف المتصفح أنه يتحدث مع الموقع الحقيقي، وماذا يوجد داخل الشهادة، ولماذا تأتي ملفاتها بأكثر من صيغة.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B4%D9%87%D8%A7%D8%AF%D8%A7%D8%AA-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A%D8%A9-tls-%D9%88-x509-%D9%88%D8%B5%D9%8A%D8%BA-pem-%D9%88-der/)[![](https://arabroot.io/content/images/2026/10/audit-trail-cover-cover.webp)دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/)[![](https://arabroot.io/content/images/2026/10/formbricks-cover-cover.webp)دليلFormbricks: استبيانات ونماذج حديثة على سيرفرككيف تثبت Formbricks وتنشئ استبياناً عربياً بالرابط أو داخل تطبيقك، وتبقى الإجابات في قاعدة بياناتك على سيرفرك.](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-formbricks-%D9%84%D9%84%D9%86%D9%85%D8%A7%D8%B0%D8%AC-%D9%88%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، والتجربة العملية على DocuSeal 3.3.1 مع SQLite، والتحقق بمكتبة pyHanko 0.29.1، وقراءة تراخيص Documenso v2.20.0 وDocuSeal 3.3.1 من المستودعين.