كيفية إنشاء ملف .htpasswd: دليل مصادقة HTTP Basic

ملف .htpasswd هو مخزن بيانات الاعتماد على جانب الخادم لمصادقة HTTP Basic: ملف نصي عادي يمثّل كل سطر فيه زوجًا واحدًا من username:hash. لإنشاء ملف .htpasswd تُولّد ذلك السطر المُجزّأ (المُهشّم) وتحفظه في مكان يستطيع خادم الويب قراءته منه. وهناك ثلاث طرق للقيام بذلك:

• أمر htpasswd (من حزمة apache2-utils / httpd-tools) — الأداة المعيارية لهذا الغرض.
• openssl passwd — مُثبَّت أصلًا في كل مكان تقريبًا، دون حاجة إلى حزمة إضافية.
• داخل متصفحك — استخدم مُولّد htpasswd لإنشاء مدخل محليًا دون أي تثبيت ودون إرسال أي شيء عبر الشبكة.

لكن الأمر لا يقف عند ذلك السطر الواحد. سنشرح كيف تعمل مصافحة Basic Auth، وكيف تُنشئ الملف بثلاث طرق، وأيّ صيغة من صيغ التجزئة الخمس تختار، وكيف توصّله في Apache وnginx وDocker وKubernetes وCaddy وTraefik، وكيف تؤمّنه حتى لا ينتهي بك الأمر إلى شحن ملف بيانات اعتماد يستطيع أي أحد تنزيله.

ما هو ملف .htpasswd؟

كل سطر في ملف .htpasswd يحمل بيانات اعتماد مستخدم واحد كزوج مفصول بنقطتين. يُخزَّن اسم المستخدم كما هو؛ أما كلمة المرور فتُخزَّن فقط على هيئة تجزئة أحادية الاتجاه، فلا يُكتب النص الصريح إلى القرص أبدًا. وتبدو بنية سطر bcrypt واحد على النحو التالي:

admin    :    $2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
│             │
└─ username   └─ hash (algorithm prefix $2y$ + cost + salt + digest)

يأتي اسم المستخدم أولًا، ثم : واحدة، ثم التجزئة. ويمكن أن يصل طول اسم المستخدم إلى 255 بايت، ويجب ألا يحتوي على نقطتين إطلاقًا، لأن النقطتين هما الفاصل بين الحقول. وتحمل التجزئة علامة الخوارزمية الخاصة بها كبادئة ($2y$ لـ bcrypt، و$apr1$ لـ Apache MD5، و{SHA} لـ SHA-1)، فيعرف الخادم كيفية التحقق منها دون أي إعداد إضافي.

لعدّة مستخدمين، تضيف سطرًا واحدًا لكل مستخدم:

admin:$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
alice:$2y$10$3bQ8xY7tLp2mZ0xW5cR4fO9vK1jH6sD2nG8aQ5wE3rT7uI4oP1cm
bob:$apr1$mZ0xW5cR$4fK1jH6sD2nG8aQ5wE3rT2

ويمكن مزج الخوارزميات في الملف نفسه. يقرأ الخادم كل سطر، ويكتشف الصيغة من بادئتها، ويتحقق وفق ما استُخدم. هنا يتعايش مستخدمان بصيغة bcrypt ومستخدم واحد بصيغة apr1 دون أي مشكلة.

.htpasswd مقابل .htaccess

كثيرًا ما يُخلط بين هذين الملفين لأنهما يسيران معًا في Apache، لكنهما يؤدّيان وظيفتين مختلفتين. فملف .htaccess هو ملف إعدادات Apache لكل دليل على حدة. وهو يحمل التوجيهات — بما فيها تلك التي تُفعّل Basic Auth وتُشير إلى مخزن بيانات الاعتماد لديك. أما .htpasswd فهو قاعدة بيانات الاعتماد — مجرد أسطر username:hash لا غير، دون أي إعداد.

باختصار: .htaccess هو الذي يقرّر أن دليلًا ما يتطلّب تسجيل دخول وأين يجد قائمة المستخدمين؛ و.htpasswd هو تلك القائمة. أما nginx فلا يستخدم .htaccess إطلاقًا — إذ يقع إعداد Basic Auth الخاص به داخل كتلة server أو location في الإعداد الرئيسي، لكنه يقرأ صيغة بيانات الاعتماد .htpasswd نفسها.

كيف تعمل مصادقة HTTP Basic

مصادقة HTTP Basic هي مصافحة من نوع تحدٍّ واستجابة (challenge-response) مدمجة في مواصفة HTTP، ومتى فهمت خطواتها الثلاث صار استكشاف أي خطأ لاحق أسهل بكثير:

1. يطلب العميل موردًا محميًّا دون أي بيانات اعتماد.
2. يردّ الخادم بـ 401 Unauthorized ويُضمّن ترويسة WWW-Authenticate: Basic realm="..." — وهذا هو التحدّي.
3. يعيد العميل المحاولة بترويسة Authorization: Basic <base64(user:password)>. وإذا طابقت بيانات الاعتماد سطرًا في ملف .htpasswd، أعاد الخادم المورد.

هذا هو البروتوكول بأكمله. لا نموذج تسجيل دخول، ولا ملف تعريف ارتباط جلسة، ولا رمز مميّز (token). فكل طلب لاحق يحمل الترويسة نفسها.

تحدّي 401 / WWW-Authenticate

تؤدّي ترويسة WWW-Authenticate أمرين. فرمزها Basic يخبر العميل بالمخطّط الذي يستخدمه، وسلسلة realm فيها تُعنون مجال الحماية. وتعرض المتصفحات نص realm في نافذة تسجيل الدخول (“يقول الموقع: …”) وتستخدمه مفتاحًا للتخزين المؤقت: فبيانات الاعتماد المُدخَلة لمجال واحد تُعاد لعناوين أخرى ضمن المجال نفسه، فلا يُطالَب المستخدم بإدخالها مجددًا في كل صفحة.

وفيما يلي التبادل الخام، مُلتقَطًا بأمر curl -i:

$ curl -i https://example.com/admin/
HTTP/2 401
www-authenticate: Basic realm="Restricted Area"

$ curl -i -u admin:s3cret https://example.com/admin/
HTTP/2 200

ترويسة Authorization: Basic

بيانات الاعتماد التي يرسلها العميل هي base64(username:password). وهذه أهم حقيقة أمنية بشأن Basic Auth: فـ base64 هو ترميز وليس تشفيرًا. وهو قابل للعكس بالكامل من قِبل أي أحد، فتنتقل بيانات الاعتماد بصيغة نصية صريحة فعليًّا. ويمكنك أن ترى الرحلة كاملة بنفسك:

# Encode the credential the way a browser does
printf 'admin:s3cret' | base64
# → YWRtaW46czNjcmV0

# Anyone who captures the header can decode it instantly
printf 'YWRtaW46czNjcmV0' | base64 -d
# → admin:s3cret

هذه القابلية للعكس هي السبب في أن Basic Auth يجب أن يعمل فوق HTTPS — فبدون TLS تكون كلمة المرور قابلة للقراءة من أي أحد على مسار الشبكة. وإن أردت بناء تلك الترويسة أو فحصها يدويًّا، فإن مُرمّز/مُفكّك base64 يُجري تحويل user:password نفسه داخل المتصفح.

كيفية إنشاء ملف .htpasswd

هناك ثلاث طرق عملية لإنشاء الملف. اختر بناءً على ما هو مُثبَّت وأين تريد أن تستقرّ كلمة المرور.

باستخدام أمر htpasswd

يأتي ثنائي htpasswd ضمن حزمة أدوات Apache. ثبّته أولًا:

# Debian / Ubuntu
sudo apt install apache2-utils

# RHEL / CentOS / Fedora
sudo yum install httpd-tools

أنشئ الملف وأول مستخدم فيه. تعني الراية -c إنشاء، وهي ستستبدل ملفًا قائمًا — فاستخدمها في المرة الأولى فقط لا غير:

htpasswd -c /etc/nginx/.htpasswd admin
# prompts twice for the password, then writes the file

ولإضافة مزيد من المستخدمين، أسقِط الراية -c لكي تُلحِق بدلًا من أن تطمس:

htpasswd /etc/nginx/.htpasswd alice

ولفرض bcrypt بدلًا من الافتراضي على المنصة، أضِف -B. ولطباعة المدخل إلى المُخرَج القياسي دون المساس بأي ملف — وهو أمر مفيد للتمرير إلى ملف إعداد أو إلى Dockerfile — اجمع بين -b (كلمة المرور على سطر الأوامر) و-n (دون ملف):

htpasswd -Bbn admin 's3cret'
# → admin:$2y$10$N9qo8uLOickgx2ZMRZoMye...

الرايات التي ستستخدمها فعليًّا:

الراية	المعنى
-c	إنشاء ملف جديد (يستبدل القائم إن وُجد) — لأول مستخدم فقط
-B	استخدام bcrypt
-b	أخذ كلمة المرور كوسيطة على سطر الأوامر (دون مُطالَبة)
-n	الطباعة إلى المُخرَج القياسي بدلًا من كتابة ملف
-D	حذف المستخدم المُسمّى من الملف

ثمة تحفّظ واحد على -b: تنتهي كلمة المرور إلى سجلّ صدفتك (shell history). ومع بيانات اعتماد الإنتاج لمرة واحدة، فضّل الصيغة بالمُطالَبة أو خيار المتصفح أدناه.

دون apache2-utils — باستخدام OpenSSL

لا يوجد ثنائي htpasswd؟ إن OpenSSL موجود على كل نظام تقريبًا، ويستطيع إنتاج تجزئة apr1 مباشرة. لُفّه بأمر printf لبناء سطر كامل:

printf "admin:$(openssl passwd -apr1 's3cret')\n" >> /etc/nginx/.htpasswd
# admin:$apr1$k3l4Hj9.$qN8vY7tLp2mZ0xW5cR4f.

صيغة apr1 محمولة عبر كلٍّ من Apache وnginx، ما يجعلها المسار الأقل اعتمادًا على التبعيات على جهاز بحدّه الأدنى.

في المتصفح — دون تثبيت ودون تسرّب

إن لم ترغب في تثبيت حزمة، أو فضّلت ألّا تكتب كلمة مرور إنتاجية في صدفة تستقرّ فيها ضمن ~/.bash_history، فولّد المدخل على جانب العميل. يحسب مُولّد htpasswd تجزئات bcrypt وapr1 وSHA-1 بالكامل داخل متصفحك، ويسلّمك سطر user:hash جاهزًا للصق إضافةً إلى كتلة إعداد خادم مطابقة، ولا يرسل أي شيء إطلاقًا. وما دمت هناك، فأنشئ كلمة مرور قوية وفريدة عبر مُولّد كلمات المرور العشوائية بدلًا من إعادة استخدام كلمة سابقة.

مقارنة صيغ كلمات مرور htpasswd

يستطيع أمر htpasswd أن يُصدِر خمس صيغ، وهي ليست متساوية. وهذا الجدول هو المرجع السريع لاختيار واحدة منها:

الصيغة	البادئة	مُملَّحة	المتانة	استخدمها لـ
bcrypt	$2y$	نعم	الأقوى	Apache، Docker Registry، Caddy، Traefik
apr1 (Apache MD5)	$apr1$	نعم	متوسطة	nginx (محمولة، افتراضي آمن)
SHA-1	{SHA}	لا	ضعيفة	للتوافق القديم فقط
crypt (DES)	(لا شيء)	نعم (حرفان)	ضعيفة جدًّا	لا تستخدمها
plain	(لا شيء)	لا	لا شيء	للاختبار المحلي فقط

وثمة تفاصيل لا تتّسع لها خلية في جدول. تستخدم bcrypt ملحًا عشوائيًّا بطول 16 بايت وعامل كلفة تكيّفي (الافتراضي 10، والموصى به حديثًا 12)، فتُنتج كلماتُ المرور المتطابقة تجزئات مختلفة، ويتدرّج عامل العمل مع العتاد. ولها خصوصية واحدة: يبتر bcrypt كلمة المرور عند 72 بايت — وأي زيادة تُتجاهَل بصمت. أما apr1 فيُجري 1,000 جولة من MD5 المُملَّح؛ وهو أضعف بكثير من bcrypt، لكنه مُنفَّذ أصليًّا في كلٍّ من Apache وnginx، ولهذا فهو الخيار المحمول. و**SHA-1** غير مُملَّح، فتُنتج كلماتُ المرور المتطابقة ملخّصات متطابقة وتنطبق عليه جداول قوس قزح (rainbow tables) — فأبقِه للأنظمة القديمة فقط. أما crypt و**plain** فموجودان لأسباب تاريخية وللاختبار؛ ولا مكان لأي منهما في الإنتاج.

البوادئ $2a$ / $2b$ / $2y$

سترى تجزئات bcrypt تبدأ بـ $2a$ أو $2b$ أو $2y$. وهي الخوارزمية نفسها وتُنتج تجزئات متكافئة قابلة للتبادل؛ وأحرف الإصدار هي بقايا من إصلاحات علل تاريخية في طريقة معالجة بعض المكتبات للأحرف ذات البتّ العالي ولطول السلسلة. ويُصدِر أمر htpasswd في Apache الصيغة $2y$، ويتحقق منها كلٌّ من Caddy وTraefik وDocker Registry بشكل صحيح.

وإن أردت المقارنة الأعمق بين bcrypt والبدائل الحديثة، فإن دليل bcrypt مقابل Argon2 مقابل scrypt يشرح كيف تختلف خوارزميات تجزئة كلمات المرور هذه في الكلفة، وصلابة الذاكرة، ونموذج التهديد.

ضبط Basic Auth على خادمك

ملف بيانات الاعتماد لا يفعل شيئًا وحده؛ لا بدّ من إخبار خادمك بأن يشترطه. إليك كيف تضبط ذلك على ست منصّات.

Apache (‏.htaccess)

ضع هذا داخل ملف .htaccess في الدليل الذي تريد حمايته (أو داخل كتلة <Directory> في المضيف الافتراضي لديك):

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

AuthName هو سلسلة realm التي يعرضها المتصفح؛ وAuthUserFile هو المسار المطلق إلى ملف بيانات الاعتماد لديك؛ وRequire valid-user يقبل أي مستخدم مُدرَج فيه.

nginx (‏auth_basic)

يضع nginx الإعداد في كتلة location أو server — ولا وجود لـ .htaccess:

location /admin/ {
    auth_basic           "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

أعِد التحميل بأمر nginx -s reload. استخدم صيغة apr1 هنا. إذ يفوّض nginx التحقق من bcrypt إلى دالة crypt() في النظام، وهي تفشل على كثير من البِنى (مزيد عن ذلك في استكشاف الأخطاء)، في حين يُتحقَّق من apr1 داخليًّا على كل منصّة.

Docker Registry وKubernetes ingress-nginx

تقبل خلفية htpasswd في Docker Registry الخاص bcrypt فقط. ولّد المدخل، وثبّته، ووجّه السجلّ (registry) إليه:

# Generate a bcrypt entry into a file
htpasswd -Bbn admin 's3cret' > auth/htpasswd

# Run the registry with that file
docker run -d -p 5000:5000 \
  -v "$(pwd)/auth:/auth" \
  -e REGISTRY_AUTH=htpasswd \
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
  registry:2

أما لـ Kubernetes ingress-nginx، فخزّن الملف كسرّ (Secret) وأشِر إليه عبر التعليقات التوضيحية (annotations):

kubectl create secret generic basic-auth --from-file=auth=./auth/htpasswd

metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"

لاحظ أن مفتاح الـ Secret يجب أن يُسمّى auth — فـ ingress-nginx يبحث عن هذا المفتاح بالضبط.

Caddy وTraefik

يتوقع كلاهما تجزئات bcrypt. يستخدم Caddy توجيه basic_auth (الصق تجزئة bcrypt، لا النص الصريح):

example.com {
    basic_auth /admin/* {
        admin $2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
    }
}

ويستخدم Traefik وسيطًا (middleware) باسم basicauth، مع أزواج user:bcrypt-hash (تخلّص من أي $ بحسب صيغة إعدادك):

http:
  middlewares:
    admin-auth:
      basicAuth:
        users:
          - "admin:$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy"

وبمجرد حماية نقطة نهاية، تحقّق من عملها من سطر الأوامر. إذ يُجمّع لك مُنشئ أوامر cURL طلب -u user:pass لتؤكّد كلًّا من 401 و200 المُصادَق عليها.

أفضل الممارسات الأمنية

بساطة Basic Auth تعني أن طرق إساءة استخدامه قليلة ومعروفة، وكلها سهلة التفادي.

• قدّم الخدمة دائمًا عبر HTTPS. فبيانات الاعتماد مجرد base64 قابل للعكس، فيكشف HTTP العادي كلمة المرور على الشبكة. أنهِ TLS أمام أي نقطة نهاية محمية، دون استثناء.
• خزّن الملف خارج جذر الويب. فإن وُضع .htpasswd في دليل مُقدَّم، أمكن لخطأ في الإعداد أن يتيح لأحدهم تنزيله. أبقِه في مكان مثل /etc/nginx/.htpasswd، واضبط chmod 640، واجعل ملكيته لمستخدم خادم الويب (www-data، nginx) حتى يستطيع الخادم قراءته وتعجز الحسابات الأخرى عن ذلك.
• استخدم كلمات مرور قوية وفريدة. ينبغي أن يحصل كل حساب على كلمة مرور خاصة عالية الإنتروبيا من مُولّد كلمات المرور العشوائية، دون إعادة استخدامها أبدًا. وإن أردت أن تفهم معنى “قوية بما يكفي” بوحدة البتّ، فإن شرح إنتروبيا كلمة المرور يفكّك الحسابات.
• اعرف حدوده. ليس لـ Basic Auth تسجيل خروج ولا جلسة: يخزّن المتصفح بيانات الاعتماد مؤقتًا لكل مجال حتى تغلقه، وتُعاد إرسالها في كل طلب. وللاطّلاع على قائمة فحص أوسع حول التجزئة والترويسات والتحقق، راجع أفضل ممارسات أمان الويب لدينا.

استكشاف الأخطاء الشائعة

nginx: crypt_r() failed (22: Invalid argument)

هذا أكثر إخفاقات Basic Auth شيوعًا في nginx، وهو يعني الشيء نفسه دائمًا: حاول nginx التحقق من تجزئة bcrypt ($2y$) على مكتبة libc لا تتضمّن مخطّط Blowfish — وعادةً ما تكون مكتبة musl في Alpine أو نسخة glibc قديمة. والحل هو إعادة توليد المدخل بصيغة apr1، التي يتحقق منها nginx داخليًّا على أي منصّة:

printf "admin:$(openssl passwd -apr1 's3cret')\n" > /etc/nginx/.htpasswd
nginx -s reload

والتحول إلى صورة أساس (base image) تدعم مكتبة libc فيها bcrypt ينجح أيضًا، لكن apr1 هو الحل الأبسط والأكثر حملًا.

401 حتى مع كلمة المرور الصحيحة

حين تكون واثقًا من صحة كلمة المرور لكنك لا تزال تحصل على 401، اتبع قائمة الفحص هذه بالترتيب:

1. مسار الملف. تأكّد من أن AuthUserFile / auth_basic_user_file يشير إلى الملف الفعلي (مسار مطلق، دون أخطاء طباعية).
2. الصلاحيات. يجب أن يتمكّن مستخدم خادم الويب من قراءة الملف. تحقّق بأمر sudo -u www-data cat /etc/nginx/.htpasswd.
3. نهايات الأسطر / الترميز. قد يحمل ملف حُرّر على Windows أحرف \r تُفسد التجزئة. شغّل file .htpasswd وطبّق عليه dos2unix إن لزم.
4. ذاكرة المتصفح القديمة. يخزّن المتصفح بيانات الاعتماد مؤقتًا لكل مجال. اختبر في نافذة خاصة/تصفّح متخفٍّ لاستبعاد كلمة مرور قديمة محفوظة.
5. عدم تطابق التجزئة. تحقّق من أن التجزئة المخزّنة تطابق كلمة المرور فعلًا — الصق كليهما في وضع التحقق بـ مُولّد htpasswd للتأكيد قبل أن تلوم الإعداد.

متى لا تستخدم Basic Auth

Basic Auth هو الأداة المناسبة لمجموعة ضيّقة من المهام: موقع تجهيز (staging)، أو مسار إدارة داخلي، أو نقطة نهاية لمُنتَجات CI، أو لوحة مقاييس، أو سجلّ خاص. فهو عديم التبعيات ويستغرق إعداده دقيقتين.

وهو الأداة الخاطئة لتسجيل دخول مُنتَج. فلا تسجيل خروج، ولا إعادة تعيين لكلمة المرور، ولا تحديد لمعدّل الطلبات، ولا قفل للحساب، ولا مصادقة متعدّدة العوامل (MFA). وتُعاد بيانات الاعتماد في كل طلب ويخزّنها المتصفح مؤقتًا حتى يُغلَق. ولأي شيء يسجّل المستخدمون دخولهم إليه، الجأ إلى الجلسات أو OAuth أو OIDC بدلًا منه. احترم هذا الحدّ تُبقِ الأداة في الموضع الذي تتفوّق فيه.

الأسئلة الشائعة

ماذا يحتوي سطر واحد في ملف .htpasswd فعليًّا؟

زوج username:hash مفصول بنقطتين. تبدأ التجزئة ببادئة الخوارزمية ($2y$ لـ bcrypt، و$apr1$ لـ Apache MD5، و{SHA} لـ SHA-1)، يتبعها الملح والملخّص. ولا تظهر كلمة المرور بنصها الصريح في الملف أبدًا.

ما الفرق بين .htpasswd و.htaccess؟

.htaccess هو ملف إعدادات Apache لكل دليل على حدة — وهو يُفعّل Basic Auth ويُشير إلى مخزن بيانات الاعتماد. أما .htpasswd فهو مخزن بيانات الاعتماد ذاك، ويحمل أسطر username:hash. ويستخدم nginx صيغة .htpasswd لكنه يضبط المصادقة في كتل server/location لديه، لا في .htaccess.

كيف أضيف مستخدمًا أو أغيّره أو أزيله في ملف .htpasswd؟

لإضافة مستخدم أو تغييره، شغّل htpasswd /path/.htpasswd username دون -c — فإن كان المستخدم موجودًا، حُدّثت تجزئته. ولإزالة واحد، شغّل htpasswd -D /path/.htpasswd username. ولا تستخدم -c إلا لأول مستخدم لا غير، لأنها تستبدل الملف بأكمله.

كيف يتذكّر المتصفح بيانات اعتماد Basic Auth، وكيف يسجّل المستخدمون خروجهم؟

يخزّن المتصفح بيانات الاعتماد مؤقتًا مُفهرسةً بالمجال ويعيد إرسالها تلقائيًّا في كل طلب مطابق. ولا يوجد تسجيل خروج معياري: فالطريقتان الوحيدتان لمسحها هما إغلاق المتصفح أو محو ذاكرته المؤقتة. وغياب تسجيل الخروج هذا أحد أسباب عدم ملاءمة Basic Auth لمصادقة المُنتَجات.

هل يمكنني استخدام ملف .htpasswd نفسه لكلٍّ من Apache وnginx؟

نعم، ما دامت صيغة التجزئة مدعومة على كليهما. فصيغة apr1 (Apache MD5) يُتحقَّق منها أصليًّا في Apache وnginx في كل مكان، فهي الخيار المشترك الأكثر أمانًا. أما bcrypt فيعمل على Apache لكنه على nginx يعتمد على دالة crypt() في النظام، وهي تفشل على بِنى Alpine/musl.

هل ما زالت مصادقة HTTP Basic ذات صلة في عام 2026؟

نعم. فبوصفها بوّابة خفيفة فوق HTTPS — للأدوات الداخلية، وبيئات التجهيز، والسجلّات الخاصة، ونقاط نهاية المراقبة — لا تزال عملية وعديمة التبعيات. لكن لا تخلط بينها وبين مصادقة المُنتَجات الموجّهة للمستخدم، التي تحتاج إلى جلسات وإعادة تعيين وتحديد لمعدّل الطلبات ومصادقة متعدّدة العوامل لا يستطيع Basic Auth توفيرها.

راجعه فريق Go Tools: جرى التحقّق من كل أمر وكتلة إعداد وصيغة تجزئة في هذا الدليل بمقارنتها بمخرجات Apache المرجعية لأداة htpasswd (apache2-utils) ومخرجات OpenSSL المرجعية.