مصادقة الوكيل باسم المستخدم وكلمة المرور: الاتصال وتجنب الأخطاء

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

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

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

ما المقصود بالمصادقة باسم المستخدم وكلمة المرور

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

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

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

متى تفيد هذه الطريقة

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

مثلًا، يعمل فريق من مكتبين والمنزل، ولكل منها عنوان IP عام مختلف. ويمكن للتطبيقات استخدام بيانات اعتماد الوكيل نفسها إذا سمحت الخدمة بمشاركتها دون ربط IP. ويحتفظ كل تطبيق بإعدادات اتصاله الخاصة؛ ويفحص الوكيل بيانات الاعتماد التي يرسلها كل منها.

تعمل هذه الطريقة أيضًا مع عدة خوادم دائمة. لكن عدد الأجهزة والاتصالات المتزامنة والموارد المتاحة يعتمد على الخطة. ولا تمنح كلمة مرور واحدة وصولًا غير محدود.

كيف يرسل التطبيق بيانات اعتماد الوكيل

التسلسل العام بسيط: يتصل التطبيق بالوكيل، ويجتاز فحص الوصول، ويستخدمه للوصول إلى المورد المطلوب. وتعتمد التفاصيل على البروتوكول.

قد يعيد وكيل HTTP أولًا 407 Proxy Authentication Required ويحدد طريقة المصادقة التي يقبلها. ويرسل التطبيق معلومات المصادقة في رأس Proxy-Authorization. ويرسلها بعض العملاء فورًا، لذا قد لا يظهر التحدي الأولي في السجل.

عند فتح موقع HTTPS عبر وكيل HTTP عادي، قد تحدث المصادقة أثناء طلب CONNECT الذي ينشئ نفقًا. ثم ينشئ التطبيق اتصالًا آمنًا بالموقع. ولا تكرر طلبات الموقع اللاحقة عبر النفق القائم تسجيل الدخول إلى الوكيل المستخدم لفتحه.

مع SOCKS5، يُفحص اسم المستخدم وكلمة المرور في بداية الاتصال، قبل طلب الاتصال بالوجهة. وإذا فشل الفحص، فلا يحصل التطبيق على الاتصال المطلوب عبر الوكيل. وفشل مصادقة SOCKS5 الأصلي ليس استجابة HTTP 407.

اختر البروتوكول وطريقة المصادقة اللذين تدعمهما الخدمة. ويحتوي SOCKS4 حقل معرّف مستخدم، لكنه لا يعرّف تبادل اسم المستخدم وكلمة المرور الخاص بSOCKS5. ولا يجعل ملء ذلك الحقل عميل SOCKS4 يجري مصادقة SOCKS5 بكلمة مرور.

الإعدادات التي تدخلها في تطبيقك

ابدأ ببيانات الاتصال الخاصة بخدمتك. وإذا وفر التطبيق حقولًا منفصلة، فأدخل كل قيمة في حقلها:

تقبل بعض التطبيقات سلسلة واحدة بصيغة protocol://username:password@host:port. فمثلًا، في http://client01:River%[email protected]:8080، اسم المستخدم client01، وكلمة المرور River@2026، والمضيف proxy.example، والمنفذ 8080. ويُمثَّل الرمز @ داخل كلمة المرور بالشكل %40 حتى لا يختلط بالفاصل قبل المضيف.

تدعم curl، مثلًا، هذا التفسير لعنوان URL الوكيل. وعادةً يتوقع حقل كلمة مرور منفصل كلمة المرور نفسها دون ترميز URL. ولا تنسخ قيمة مرمزة من URL إلى حقل منفصل دون التحقق من التنسيق: فقد يتعامل التطبيق معها ككلمة مرور مختلفة. وللسلاسل التي تحتوي % أو النقطتين أو محارف خاصة أخرى، اتبع متطلبات التنسيق الخاصة بالعميل.

رمّز المحارف اللازمة داخل بيانات الاعتماد مرة واحدة؛ فترميز السلسلة كلها يفسد فواصلها. ولا يحل وضع وسيط أمر بين علامتي اقتباس محل ترميز URL. وقد تكون لطريقة المصادقة قيودها الخاصة: فHTTP Basic، مثلًا، يسمح بنقطتين في كلمة المرور لا في اسم المستخدم.

تختلف تنسيقات الاستيراد أيضًا. فhost:port:username:password وusername:password@host:port غير قابلين للتبادل. ولن تعمل القيم الصحيحة بالترتيب الخاطئ إذا توقع المستورد ترتيبًا مختلفًا.

تصف بادئة http:// في URL الوكيل كيفية اتصال التطبيق العميل بالوكيل نفسه. ولا تمنع الوصول إلى مواقع HTTPS: إذ يستطيع العميل إنشاء نفق لها. ولا تضيف مجرد إعادة كتابة البادئة https:// دعم الاتصال الآمن بالوكيل إلى الخادم.

تضمّن بعض الخدمات بلدًا أو مجموعة خروج أو معامل جلسة في اسم المستخدم. انسخ السلسلة كاملة. وتتحكم هذه المعاملات بالتوجيه وفق قواعد المزود؛ فلا تبتكر صياغتها ولا تستعرها من خدمة أخرى.

لماذا ينبغي فحص دعم المصادقة في التطبيق

دعم الوكيل ودعم المصادقة لدى الوكيل قدرتان منفصلتان. ولا تعني حقول المضيف والمنفذ بالضرورة قدرة التطبيق العميل على إرسال اسم مستخدم وكلمة مرور.

تحقق من التركيبة الدقيقة لبروتوكول الوكيل وطريقة المصادقة والتطبيق. فمثلًا، لا يدعم تنفيذ SOCKS5 المدمج في Chrome المصادقة لدى وكيل SOCKS5. ولا تستطيع بيانات اعتماد صحيحة وحدها إصلاح ذلك القيد. كذلك لا تضيف إضافة لاختيار الوكلاء طريقة المصادقة المفقودة بالضرورة.

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

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

ماذا يحدث عندما يتغير عنوان IP الخاص بك

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

لكن تغيير الشبكات قد يقطع الاتصالات القائمة. وسيحتاج التطبيق العميل إلى إعادة الاتصال، وقد يحتاج طلب غير مكتمل إلى إعادة المحاولة. ولا ينبغي اعتبار خطأ يلي الانتقال مباشرةً من Wi-Fi إلى إنترنت محمول مشكلة كلمة مرور تلقائيًا.

تفحص بعض الخدمات بيانات الاعتماد وعنوان المصدر معًا. ولا تتجاوز كلمة مرور صحيحة ذلك القيد الشبكي: إذ يجب أن يطابق IP الجديد عنوانًا أو نطاقًا مسموحًا. وقبل نقل برنامج نصي، حدد ما إذا كانت الخدمة تقبل اتصالات من أي شبكة أو تطبق فحصًا مشتركًا.

هل كلمة المرور محمية أثناء النقل؟

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

يرمّز HTTP Basic اسم المستخدم وكلمة المرور بBase64. وهذا تمثيل قابل للعكس، وليس تشفيرًا. ودون حماية الاتصال بالوكيل، يستطيع من يراقب ذلك المسار الشبكي الحصول على بيانات الاعتماد. كذلك لا تشفر مصادقة SOCKS5 القياسية باسم المستخدم وكلمة المرور إرسالهما.

يحمي HTTPS في موقع الوجهة الاتصال بين التطبيق وذلك الموقع. ومع وكيل HTTP، تحدث المصادقة أثناء إعداد النفق قبل ذلك؛ ولا يحمي TLS الموقع بيانات اعتماد الوكيل التي أُرسلت بالفعل. وكذلك لا يشفر طلب HTTPS عبر SOCKS5 فحص كلمة مرور الوكيل السابق له.

تتطلب حماية ذلك الجزء من المسار حماية بين التطبيق والوكيل، مثل وكيل HTTPS يستخدم TLS، حين تدعمه الخدمة والعميل معًا. ويجب أن يتحقق التطبيق من شهادة الوكيل. وفي بعض قوائم البيع، تعني «وكيل HTTPS» فقط إمكان الوصول إلى مواقع HTTPS، فتحقق من الموضع الذي ينطبق فيه TLS فعليًا.

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

هل تستطيع عدة تطبيقات استخدام بيانات الاعتماد نفسها؟

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

مثلًا، قد يستخدم برنامجان نصيان حسابًا واحدًا مع فتح عددين مختلفين من الاتصالات. ولا تعني كلمة مرور واحدة اتصالًا واحدًا. وبالمثل، لا يضاعف تشغيل عشر عمليات إجمالي حصة الاتصالات لدى الخدمة عشر مرات.

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

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

لماذا يرفض الوكيل اسم مستخدم وكلمة مرور

حدد أولًا من أعاد الخطأ. يتعلق HTTP 407 بمصادقة الوكيل؛ ويتعلق 401 من موقع الوجهة بالوصول إلى ذلك الموقع. ولا تثبت رسالة 403 أو انتهاء مهلة، دون دليل إضافي، صحة كلمة مرور الوكيل أو خطأها.

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

كيفية حفظ بيانات الاعتماد وتغييرها في البرامج النصية العاملة

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

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

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

إذا وجب ألا تعمل كلمة المرور القديمة، فاختبر رفض اتصال جديد يستخدمها. وتتبع الاتصالات القائمة قواعد الخدمة الخاصة: فتغيير كلمة مرور لا يغلقها دائمًا فورًا. وللإلغاء العاجل، استخدم طريقة تعطيل الوصول التي يدعمها المزود.

المصادقة المشتركة: IP وكلمة المرور

في المصادقة المشتركة، يفحص الوكيل شرطين: بيانات الاعتماد والعنوان الذي يتصل منه التطبيق. ويجب اجتياز كليهما. ولا تتجاوز كلمة مرور صحيحة وحدها قيد IP.

لباقات ProxyCompass الثابتة، يستخدم الوضع المشترك شبكة فرعية /24. وإذا كانت لديك عدة عناوين IPv4 عامة في الشبكة الفرعية نفسها، فيكفي إضافة أحدها إلى قائمة السماح. وتستطيع العناوين الأخرى في تلك الشبكة الاتصال باسم المستخدم وكلمة المرور الصحيحين، دون مدخل منفصل لكل عنوان.

في الرسم، يشترك عنوان IP العام للتطبيق في الأرقام الثلاثة الأولى مع العنوان المدرج في قائمة السماح. ويمكنه الاتصال ببيانات اعتماد صحيحة؛ ويفشل عنوان خارج الشبكة الفرعية في الفحص الشبكي، وتفشل كلمة مرور خاطئة حتى داخلها. ويمكن لعناوين IP عميلة أخرى في الشبكة نفسها استخدام هذا المدخل أيضًا. ويفيد ذلك للتطبيقات التي تتطلب حقلي اسم المستخدم وكلمة المرور. وتتعلق القاعدة بعناوين IP العامة لتطبيقاتك، لا عناوين IP المشتراة لخروج الوكلاء.