لماذا هي فكرة سيئة استخدام ClientLogin لتطبيقات الويب في جوجل API؟

Question

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

أحتفظ بالمشاهدة، ومرارا وتكرارا في المطورين أن العملاء، والتي تبدو وكأنها أفضل خيار لتنفيذ ما أريد القيام به، ليست فكرة جيدة مصادقة المستخدم في تطبيق الويب. لا يبدو أن "AuthSub لتطبيقات الويب" هي أفضل آلية لما أريد تطبيقه!

أي أفكار عما يمكن القيام به؟

شكرا لك

Answer 1

بعد اللعب مع Google API ومقدمي خدمات الفيديو الأخرى، تعلمت API الكثير عن المصادقة. oauth and authsub هي طريقتان تستخدم Google لمصادقة تطبيقات الويب الخاصة بالطرف الثالث على حساب مستخدم.

قد تبدو العملية فوضوي في البداية، ولكن بمجرد فهمها، فهي ليست سيئة للغاية. تظهر الصورة التالية عملية AuthSub.

1. عندما يحتاج تطبيق الويب إلى الوصول إلى خدمة Google للمستخدم، فإنه يجعل استدعاء AuthSUB لخدمة وكيل تفويض Google.
2. تستجيب خدمة التفويض من خلال خدمة صفحة طلب الوصول. تطالب هذه الصفحة من Google المدارة المستخدم بمنح / رفض الوصول إلى خدمة Google الخاصة بهم. قد يطلب من المستخدم أولا تسجيل الدخول إلى حسابهم.
3. يقرر المستخدم سواء لمنح أو رفض الوصول إلى تطبيق الويب. إذا رفض المستخدم الوصول، فهي موجهة إلى صفحة Google بدلا من العودة إلى تطبيق الويب.
4. إذا كان المستخدم يمنح الوصول، فإن خدمة التفويض تعيد توجيه المستخدم مرة أخرى إلى تطبيق الويب. يحتوي إعادة التوجيه على رمز ترخيص جيد للاستخدام واحد؛ يمكن تبادلها لتميز طويل العمر.
5. يقوم تطبيق الويب باتهام خدمة Google بطلب، باستخدام رمز التخويل ليكون بمثابة وكيل للمستخدم.
6. إذا كانت خدمة Google تتعرف على الرمز المميز، فإنها توفر البيانات المطلوبة.

http://code.google.com/apis/accounts/docs/authsub.html#euthprocess.

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

تتمثل المزايا حول هذه الأساليب عبر اسم مستخدم المدرسة القديمة وكلمة المرور (في رأيي) ما يلي:

1. الأمان المحسن للمستخدم: لن يتعين على المستخدم أن يعطيك اسم المستخدم وكلمة المرور الخاصة بك، فلا عليهم تسجيل الدخول إلى Google وستحصل على رمز وصول سيستخدمه لإجراء أي مكالمات إضافية في API. يمكن للمستخدم إلغاء الوصول إلى طلبك من داخل Google إذا أرادوا ذلك.
2. قد تعطي العملية للمستخدم ضمان أن تطبيقك هو "شرعي". إذا كان لدى المستخدم من خلال Google لتسجيل الدخول والسماح للتطبيق الخاص بك، فقد يبدو جيدا إذا تم تسجيل نطاقك مع Google.
3. يمكن الترويج الرمز المميز إلى رمزية جلسة: هذا يعني أنه لا يتعين عليك طلب تسجيل الدخول في كل مرة تحتاج إلى طلب الوصول إلى حساب مستخدم Google، ما عليك سوى استخدام الرمز المميز للجلسة (يجب عليك حفظ مكان ما بشكل آمن وأنت انتهيت.
4. بمجرد فهم العملية، من السهل جدا مصادقة المستخدمين.
5. (غير مؤلم) إذا كان المستخدم يغير كلمة المرور الخاصة بهم، فلن تضطر إلى تحديث رمز الأمان.
6. أخيرا إذا كنت تستخدم OAuth، يمكنك إنشاء واجهة قد تسمح لك بمصادقة المستخدمين بسهولة عند الاتصال بخدمات الويب الأخرى مثل Vimeo!

مع كل هؤلاء قالوا أعتقد أنه يمكنك معرفة سبب وجود فكرة سيئة لاستخدام اسم المستخدم وكلمات المرور (التي لا يفعلها clientlogin) للاتصال بحساب مستخدم. تتيح لك أساليب المصادقة الأخرى أن تفعل الشيء نفسه (طلب الوصول) وإضافة مجموعة من المزايا.

يمكن العثور هنا على التعليمات البرمجية حول كيفية مصادقة المستخدمين باستخدام AuthSub هنا، فهي تلعب الكثير من التوصيل. فقط تأكد من حفظ $ _Session ["sssnetoken"] إلى موقع أكثر دامة مثل DB.

http:/code.google.com/apis/youtube/2.0/developers_guide_php.html#euthsub_for_web_applications.

Answer 2

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

هل نظرت في جوجل Oauth.ب إنه يحل مشكلة معالجة كلمة المرور بأناقة جميلة وهي معيار ثابت.

Answer 3

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

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