الآن بعد أن أكملنا تحديث جانب الخادم،
حان الوقت للانتقال إلى العميل الزاوي.
لراحتك، لقد قدمت لك
مستودع GitHub الذي يحتوي على الإصدار النهائي من
عميل Angular القادر على التواصل مع
خادم REST API الخاص بنا ثم عرض وجهات النظر المختلفة لعميلنا.
لذلك، لقد اتخذت تطبيق Angular الذي قمنا
بتطويره في الدورة الثانية من هذا التخصص،
ومن ثم تعديله.
ونحن سوف تأخذ جولة قصيرة من خلال رمز في وقت لاحق قليلا.
الآن، ستقوم باستنساخ مستودع Git إلى جهاز الكمبيوتر الخاص بك،
ثم بدء تشغيل عميل Angular الخاص بك،
ثم رؤيته يتواصل مع جانب الخادم الخاص بنا.
دعونا نرى التفاصيل التالية.
للبدء في هذا التمرين،
في المحطة الطرفية أو نافذة الأوامر،
انتقل إلى موقعك المناسب ثم في
موجه نوع git clone
https://github.com/jmuppala/conFusion-Angular6.git.
ثم، دع تطبيق Angular يتم استنساخه إلى جهاز الكمبيوتر الخاص بك.
بمجرد اكتمال الاستنساخ،
انتقل إلى مجلد Confusion-angular6
الذي تم إنشاؤه للتو عند استنساخ مستودع git هذا.
ثم ستلاحظ على الفور أن هناك مجموعة من الملفات بالفعل هناك.
الآن، في موجه، اكتب npm install،
من أجل تثبيت جميع وحدات العقدة
التي يعتمد عليها هذا التطبيق Angular.
لذلك، مرة واحدة وحدات عقدة أو كل تثبيت،
ثم يمكننا بدء لدينا نغ خدمة لتجميع وخدمة ما يصل لدينا تطبيق الزاوي.
بمجرد تثبيت كل شيء عن طريق تثبيت npm
، تأكد من أن خادم MongoDB
الخاص بك يعمل ويعمل وكذلك خادم REST API الخاص بك يعمل أيضًا.
خلاف ذلك، لن يعمل عميل Angular الخاص بك.
لذلك، الآن بعد أن قمت بتثبيت عميل Angular الخاص بك على جهاز الكمبيوتر الخاص بك،
في نوع موجه ng خدمة
وسيتم تجميع تطبيق Angular الخاص بك وتقديمه بواسطة ng خدمة في فترة قصيرة.
بمجرد تجميع تطبيق Angular الخاص بك بنجاح،
انتقل إلى متصفح وافتح تطبيق Angular الخاص بك في المتصفح.
الذهاب إلى المتصفح،
في شريط العناوين،
اسمحوا لي أن اكتب في localhost: 4200
وسترى أن تطبيق Angular الخاص بك
يبدأ ويظهر على الشاشة هنا.
ستلاحظ على الفور أن تطبيق Angular الخاص بك
قادر على جلب البيانات من الخادم ثم تقديم
الأجزاء المختلفة من تطبيق Angular الخاص بك تمامًا مثل ما
فعلته في نهاية دورة Angular الخاصة بك.
عندما تذهب للحديث عن المجلد،
سترى أيضًا أن الصفحة حول تعرض أيضًا المعلومات على هذا النحو.
في القائمة، ترى العناصر في القائمة التي يتم
عرضها تماما كما رأينا مع تطبيق Angular.
الآن، بالإضافة إلى ذلك، لقد أضفت في
صفحة واحدة أخرى إلى تطبيق صفحة واحدة يسمى المفضلة،
والتي لا يمكنك الانتقال إليها لأنه لم يتم تسجيل دخول أي مستخدم إلى النظام.
لذلك، ترى أنه ليس لدي أي مستخدم تسجيل الدخول إلى النظام.
لذلك، هذا هو السبب في عدم وجود نقطة في الإشارة إلى المفضلة،
لأنك لا تعرف أي مستخدم،
كمفضلة، يجب أن تظهر هنا.
صفحة الاتصال كالمعتاد.
الآن، دعونا تسجيل الدخول.
لتسجيل الدخول إلى تطبيقنا،
سنضغط على زر تسجيل الدخول ثم سترى أن مربع حوار تسجيل الدخول للملوثات العضوية الثابتة.
ثم، اسمحوا لي أن تسجيل الدخول كواحد من المستخدمين المسجلين،
والتي قمنا بتسجيلها كجزء من هذه الدورة في وقت سابق.
لذلك، بمجرد تسجيل الدخول،
ستلاحظ على الفور أنه،
إلى الزاوية اليمنى،
سترى زر تسجيل الدخول قد تحول الآن إلى
تسجيل الخروج ويشار إلى اسم المستخدم هنا.
لذا، من قام بتسجيل الدخول يشار إليه هنا.
يمكنك أيضا، من حيث المبدأ،
استبدال هذا مع صورة المستخدم.
الآن، لذلك تحتاج إلى إجراء المزيد من التعديلات
على كل من العميل والخادم من أجل دعم عرض الصورة هنا.
ولكن، في الوقت الحالي، أنا فقط تظهر لك كيف
يمكننا بسهولة عرض معلومات المستخدم هنا.
لذلك، يتطلب هذا تعديلًا
طفيفًا على رأس المكون حيث سأتمكن من استرداد
اسم المستخدم من خدمة
تسمى خدمة OAuth التي سنتحدث عنها في فترة قصيرة.
لذلك، بمجرد تسجيل دخول المستخدم،
ثم إذا قمت الآن بالنقر فوق المفضلة،
ستلاحظ أنه لا يوجد شيء في المفضلة للمستخدم.
من الواضح، لأن المستخدم لم يختار بعد أي المفضلة.
لذلك، دعونا نذهب الآن إلى القائمة ثم في القائمة،
اسمحوا لي أن حدد عنصر واحد ومن ثم أنها سوف تضيف هذا الطبق إلى المفضلة لدينا.
لذلك، النزول أدناه هنا،
ترى رمز القلب هناك،
انقر على ذلك وسترى أن هذا سيتم إضافته إلى المفضلة.
ويشار إلى حقيقة أن هذا قد تمت إضافته إلى المفضلة من خلال
التغيير في الرمز هنا من قلب شاغر إلى قلب مملوء.
الآن، إذا ذهبت إلى أي طبق آخر،
ستلاحظ أن هذا له قلب شاغر،
مما يعني أن هذا ليس بعد من بين المفضلة لدينا.
لذلك، اسمحوا لي أن أضيف في عنصر واحد آخر إلى
المفضلة ومن ثم دعونا إضافة عنصر ثالث إلى المفضلة أيضا.
لذلك، الآن، سترى أنه إذا ذهبت الآن إلى المفضلة،
سترى مجموعة من المفضلة التي يتم عرضها هنا.
لذا، رَأيتَ بأنّني فقط أضفتُ هذه الصحون الثلاثة إلى المفضّلةِ.
لذلك، يتم عرض هذه هنا.
لذلك، يتم تتبع هذا باستخدام نقطة النهاية المفضلة على جانب الخادم،
والتي قمت بتطبيقها كجزء من المهمة الأخيرة.
لذا، إذا قمت بهذا التعيين بشكل صحيح، فيجب أن يعمل هذا الجزء كما هو متوقع.
الآن، يمكننا أيضا تعديل المفضلة.
لذلك، على سبيل المثال، في الزاوية اليمنى هنا،
ترى هذا تبديل الحذف هنا.
لذلك، اسمحوا لي أن تشغيل ذلك.
لذلك، عند تشغيله،
سترى على الفور ثلاثة الصلبان الحمراء
تظهر في الجزء السفلي من هذه العناصر الثلاثة في المفضلة.
عندما أنقر عليه، ثم تختفي.
لذلك، هذه طريقة واحدة لتشغيل أزرار الحذف على المفضلة لديك ثم.
لذلك، اسمحوا لي أن المضي قدما وحذف أحد العناصر من المفضلة.
لذلك، عند النقر على هذا الزر،
ستلاحظ على الفور أن هذا العنصر يتم حذفه من المفضلة،
ويختفي على الفور
ويتم تحديث المفضلة وسترى القيمة الناتجة التي يتم عرضها هنا.
وفي الوقت نفسه،
يتم إيقاف تشغيل تبديل الحذف هذا،
بحيث أزرار الحذف لم تعد مرئية.
يمكنني دائما تشغيل أزرار الحذف مرة أخرى عن طريق النقر على تشغيل وإيقاف هنا.
لذلك، لاحظ أنه سيتم عرض المفضلة فقط
للمستخدمين الذين قاموا بتسجيل الدخول إلى النظام.
لذلك، تلاحظ على الفور مجموعة من التغييرات التي تم
إجراؤها على العميل الزاوي من أجل
دعم بعض هذه الميزات الإضافية التي تراها هنا.
رأيت أيضًا ميزة تسجيل الدخول والخروج مدعومة هنا.
لذلك، عند النقر على زر تسجيل الخروج،
لاحظت على الفور أن المستخدم يحصل على تسجيل الخروج
ويختفي اسم المستخدم من هناك،
وبالتالي يتم تشغيل الزر أيضا إلى زر تسجيل الدخول.
لذا، مع هذا، تلاحظ كيف تم
تحديث عميل Angular الخاص بي للاستفادة من خادم REST API الجديد
من أجل دعم المفضلة التي يتم حفظها وعلى جانب الخادم
ثم تنعكس تلقائيًا في تطبيق العميل الخاص بي كما هو موضح هنا.
دعونا نلقي جولة قصيرة من خلال
رمز Angular الذي قمت بتوفيره لك في مستودع GitHub،
ونرى أيضًا كيف قمنا بتعديل أجزاء من الشفرة من
أجل تنفيذ تطبيق Angular المحدث.
ستلاحظ أن هناك خدمة جديدة
قمت بتقديمها هنا تسمى خدمة المصادقة.
تعتني خدمة المصادقة
بجميع الإجراءات المتعلقة بالمصادقة لتطبيق Angular.
لذلك، ضمن خدمة المصادقة،
ستلاحظ على الفور أن لدي
مجموعة من المعلومات التي قمت بتكوينها هنا.
نظرًا لأنك تعرف Angular بالفعل،
يجب أن تكون قادرًا على معالجة كل ما هو مكتوب هنا بسهولة.
لاحظ على وجه الخصوص أنه داخل خدمة المصادقة نفسها،
أقوم بتخزين معلومات مثل،
على سبيل المثال، TokenKey،
وهو مفتاح التخزين المحلي حيث أقوم بتخزين JSON Web Token،
وكذلك بعض المتغيرات الإضافية
هنا حيث أتتبع اسم المستخدم وأين أنا ،
وكذلك تتبع رمز JSON Web Token هنا.
الآن، دعونا نبدأ بالنظر إلى عندما يقوم المستخدم بتسجيل الدخول.
لذلك، عندما يقوم المستخدم بتسجيل الدخول،
سيتم استدعاء هذه الوظيفة التي تسمى تسجيل الدخول في خدمة المصادقة لدينا هنا،
وعندما يتم استدعاء تسجيل الدخول في خدمة المصادقة،
سيتم تمرير هذا في معلمة تسمى المستخدم الذي يحتوي على
اسم المستخدم وكلمة المرور كجزء من كائن جافا سكريبت المستخدم.
لذلك، في هذه المرحلة، أفعل مشاركة هتب إلى باسيورل بالإضافة إلى المستخدمين/تسجيل الدخول.
لاحظ أيضًا أنه هنا،
أقوم بتوفير AuthResponse كمؤهل هنا.
إن AuthResponse ليس سوى واجهة قمت بتطبيقها هنا،
في الأعلى هنا.
لذا، تحدد هذه الواجهة بشكل أساسي
المعلومات التي ستعود
كرد المصادقة الخاص بي من جانب الخادم،
وهيكل بيانات JSON التي
تعود من جانب الخادم وكائنات JavaScript المقابلة.
لذلك، لاحظت أنه عندما قمنا بتحديث الخادم،
تأكدنا من أن الخادم يقوم بإرسال الحالة
والنجاح والعلامة والرمز المميز في فهرس السلسلة.
لذلك، يتم الحصول على تلك المعلومات هنا.
الآن، عندما أقوم بعمل مشاركة على ذلك،
أقوم بتمرير اسم المستخدم وكلمة المرور إلى المشاركة على نقطة النهاية هذه /المستخدمين/تسجيل الدخول.
عندما يعود الرد من الاستجابة،
فإن رسالة الاستجابة نفسها سوف تحتوي، كما رأينا،
على النجاح، حقل الرمز المميز
، وكذلك رسالة الحالة هنا.
لذا، من رسالة الاستجابة،
أقوم باستخراج الرمز المميز ثم تمريره إلى هذه الوظيفة التي أقوم بتطبيقها هنا،
الوظيفة المحلية هنا، تسمى StoreUserCedencies.
لذلك، سيتم إرجاع ذلك إلى طلبي وسيتم تخزينها في جانب العميل الخاص بي،
في التخزين المحلي.
ثم، من هذه الوظيفة،
أعيد هذه المعلومات مرة أخرى إلى
وظيفة الاستدعاء من حيث بدأت عملية تسجيل الدخول.
لذا، بهذه الطريقة، سأشير إلى مكون تسجيل الدخول الخاص بي أن تسجيل الدخول كان ناجحًا،
ثم سأقوم أيضًا بتمرير اسم المستخدم إلى مكون تسجيل الدخول الخاص بي،
والذي سيقوم بعد ذلك بتمرير تلك المعلومات
إلى مكون الرأس، ويستخدم مكون الرأس ذلك لتعكس اسم المستخدم
على في الجزء العلوي هناك،
وأيضا نحن التقاط الخطأ هنا.
لذلك، هذا هو تنفيذ بسيط جدا لكيفية قيامنا بتسجيل الدخول.
عند القيام بتسجيل الخروج،
لاحظ ما أفعله عندما يقوم المستخدم باستدعاء تسجيل الخروج.
عندما يقوم المستخدم باستدعاء الخروج،
أقوم ببساطة بتدمير بيانات اعتماد المستخدم،
والذي يتضمن التخلص من رمز
JSON Web Token الذي حصلت عليه عند تسجيل الدخول إلى طلبي.
ثم،
يتم تسجيل بعض وظائف المساعد الإضافية التي قمت بتطبيقها هنا تسمى GetUsername في و GetToken،
والتي ستكون مفيدة من تطبيقاتي
الأخرى والمكونات والخدمات الأخرى.
لذلك، الآن دعونا ننظر إلى بعض وظائف المساعد التي قمنا بتنفيذها هنا.
لذلك، سيقوم LoadUserCredencies باسترداد بيانات الاعتماد من التخزين المحلي.
لذلك، لاحظت أن هنا أنا استدعاء لوكالستوراج ومن ثم أقول جيتيتم.
لذلك، يستخدم LocalStorage هنا
التخزين المحلي لمتصفح الويب المدعوم من قبل متصفحات الويب القياسية،
وتخزين المعلومات هناك،
ومن ثم يتم استرداد هذه المعلومات هناك.
ثم، من هناك، معلومات الاعتماد،
إذا كانت صالحة،
ثم سيتم إعداد بيانات الاعتماد هذه هنا.
لذلك، سيتم تهيئة جميع هذه المتغيرات التي قمت بتعريفها هنا مع
المعلومات المناسبة بعد استردادها من LocalStorage.
الآن، وبالمثل، يتم استدعاء وظيفة StoreUserCedencies
التي قمت بتطبيقها هنا من طريقة تسجيل الدخول.
عندما يتم تمرير هذه المعلومات في،
يتم تمرير معلومات الاعتماد في،
يتم تخزين هذه المعلومات في التخزين المحلي في هذه المرحلة مع هذا المفتاح.
ثم، يقوم UsecRedentials بشكل أساسي
بإعداد جميع المتغيرات التي لدي في خدمة المصادقة.
لذلك، فإنه يقوم بإعداد الرمز المميز،
فإنه يقوم بإعداد اسم المستخدم،
ثم يقوم بإعداد وظيفة IsAuthenticated هنا.
لذلك، لاحظ أن اسم المستخدم نفسه هنا،
لقد أعلنت أنه موضوع،
وهو ليس سوى ملاحظة هنا.
لذلك، هذا هو السبب عندما أقول،
سيندوسرنر هنا، أقول بيانات الاعتماد اسم المستخدم.
لذا، تم تنفيذ هذا SendUsername في الأعلى هنا،
لاحظ أن هذا هو المكان الذي يتم فيه إرسال القيمة القابلة للملاحظة مرة أخرى.
لذلك، هذا هو السبب في أنني أقول هذا اسم المستخدم بعد ذلك.
لذلك، يمكن ملاحظتها.
سيتم إرسال الاسم الذي يتم توفيره
كمعلمة إلى كل من قام بتسجيل نفسه لمراقبة هذا يمكن ملاحظته.
لذلك هذا يمكن ملاحظته، أنا ذاهب لمراقبة هذا من
مكون رأس بلدي وبهذه الطريقة كلما تغير اسم المستخدم،
إما من غير معرفة إلى اسم مستخدم معين أو العكس،
ثم يمكنني تحديث شريط الأدوات الخاص بي في
مكون الرأس لتعكس ما إذا كان المستخدم قد تم تسجيل الدخول أو تسجيل الخروج.
بحيث يتم إعداد ذلك باستخدام هذا أوسيكردنتينالز.
الآن يقوم DestroyUserCedentials بتعيين رمز المصادقة إلى غير محدد.
يقوم بمسح اسم المستخدم ثم يقوم بتعيين IsAuthenticated إلى false ثم
يزيل هذه المعلومات من متجري المحلي
لذلك يتم التخلص من jsonwebtoken في هذا الجزء.
لذلك هذا هو كيف تحب المستخدم.
لذلك بمجرد فقدان jsonwebtoken، لم يعد بإمكان المستخدم
مصادقة نفسه أو نفسها
على جانب الخادم لأن الرمز المميز لم يعد متاحًا لنا.
لذلك هذه هي الطريقة التي ننفذ بها وظيفة الخروج داخل تطبيقنا.
لذا خذ بعض الوقت للذهاب من خلال
auth.service هنا لمعرفة كيف قمت بتنفيذ الوظائف المختلفة.
الآن، بحلول هذا الوقت،
أنا متأكد من أنك على دراية كبيرة بكيفية تنفيذ تطبيقات Angular،
لذلك لا ينبغي أن يكون من الصعب عليك فهم كيفية تنفيذ هذا الرمز.
الآن وظيفة واحدة أخرى أود أن ألفت انتباهكم إليها هي رمز JWT الاختيار، هنا.
يمكن استدعاء هذه الوظيفة في أي نقطة للتحقق
والتأكد من أن رمز ويب JSON الخاص بنا لا يزال صالحًا.
لذلك هذا هو المكان الذي أرسل فيه طلب الحصول على المستخدمين شرطة مائلة تحقق JWT الرمز المميز.
أذكر أننا نفذنا هذا الطريق على جانب الخادم في user.js و.
لذلك من هناك سنكون قادرين على التحقق مما إذا كان jsonwebtoken لا يزال صالحًا أم لا.
إذا كان jsonwebtoken غير صالح،
فسنقوم
بتدمير بيانات اعتماد المستخدم ثم نتوقع من المستخدم تسجيل الدخول مرة أخرى.
إذا كان jsonwebtoken صالحًا، فلا بأس
ويمكننا المضي قدمًا في السماح للمستخدم
بالتعرف على أننا قمنا بتسجيل الدخول. لذلك حتى إذا قمت بإغلاق
المتصفح الخاص بك ثم إعادة فتح المتصفح ثم إعادة فتح تطبيق Angular الخاص بك،
إذا قمت بتسجيل الدخول في وقت سابق تم حفظ jsonwebtoken في التخزين المحلي،
ويمكن استرجاعها من هناك ومن ثم
سيتم استعادة حالة تسجيل الدخول الخاصة بك داخل تطبيق Angular الخاص بك.
إذا انتهت صلاحية رمز ويب json،
فلن يُسمح لنا بتسجيل الدخول.
لذلك في كل مرة تقوم فيها بتحديث تطبيق Angular الخاص بك في متصفحك أو
إعادة تحميل تطبيق Angular الخاص بك في متصفحك، ستقوم
بالتحقق من jsonwebtoken للتأكد من أنه لا يزال صالحًا.
إذا لم يكن صالحًا، فسيتم
مسح المستخدم وبالتالي سيتعين عليك تسجيل الدخول مرة أخرى.
إذا لم يكن الأمر كذلك، فسيتم استرداد معلومات المستخدم الذي قام بتسجيل الدخول
من LocalStorage ثم تهيئتها داخل تطبيق Angular الخاص بي.
بشكل دوري، إذا كان الخادم
يستجيب في أي وقت برسالة 401 غير مصرح بها،
حتى في هذه المرحلة،
سنقوم مرة أخرى بالتراجع لمعرفة أن jsonwebtoken صالح ومن ثم السماح بذلك.
سنفعل ذلك باستخدام شيء يسمى اعتراضات هتب.
اسمحوا لي أن تأخذ جولة في ذلك الجزء من التعليمات البرمجية،
ومن ثم شرح لكم كيف يعمل المعترضون في فترة قصيرة.
حتى الآن بالإضافة إلى AuthService،
في مجلد الخدمات نفسه سترى هذا الملف يسمى ملف AuthInterceptors.ts.
لذا افتح هذا وسترى أنه هنا قمت بتنفيذ اعتراضات Http.
الآن ما تفعله أجهزة اعتراض Http هذه،
يتم دعم هذا مع عميل Http الذي يأتي كجزء من Angular 4.4.
ما يفعله اعتراض http هو أنه يمكنهم اعتراض
رسائل الطلبات الصادرة إجراء
تعديلات على رسالة الطلب قبل إرسالها.
وبالمثل، يمكنهم اعتراض رسائل الاستجابة الواردة ثم تعديل
رسالة الاستجابة الواردة قبل
تسليم الاستجابة إلى تطبيق Angular.
إذن من خلال الإعتراض، كيف يعمل هذا المُعترض؟
لذلك لجعل هذا العمل اعتراض،
ونحن تنفيذ، كما ترون،
فئة تسمى هتبنتر سيبتور من خلال توسيع هتبنتر سيبتور.
حتى هنا لقد نفذت أوثينتيرسيبتور.
إذن ماذا يفعل هذا AuthInterceptor؟
هذا AuthInterCeptor هو أساسا التقاط الطلبات الصادرة.
لذلك لالتقاط طلب صادر يمكنك استدعاء هذه الوظيفة تسمى اعتراض
ومن ثم هذا سوف تعطيك الوصول إلى الطلب والقادم.
حتى تتمكن من سلسلة في
مجموعة من اعتراضات واحد وراء الآخر إذا اخترت ذلك،
حتى يتمكنوا من معالجة الطلبات الصادرة واحدا تلو الآخر إذا اخترت ذلك.
ما يفعله هذا الاعتراض هو أنه يمنحك الوصول إلى رسالة طلب Http.
لذلك عندما أحصل على الوصول إلى رسالة طلب هتب،
ستلاحظ أن هنا أنا حقن خدمة المصادقة.
الآن على عكس الطريقة التي كنا حقن الخدمات في المكونات،
وهنا أنا تظهر استخدام حاقن.
الحاقن هو جزء من رمز الزاوي.
لذلك باستخدام حاقن يمكنك حقن الخدمات أو
المكونات الأخرى في خدمات أو مكونات أخرى.
حتى هنا ترى أنني حقن خدمة المصادقة هنا باستخدام هذا.
الآن سبب آخر هو أنه إذا قمت بحقن الخدمة مباشرة في منشئ بلدي،
فإنه سيتم تطوير تبعية دائرية بين المعترض و AuthService،
وهذا سيؤدي إلى عدم عمل التعليمات البرمجية الخاصة بك.
لذلك هذا هو العمل حول المشاكل.
حتى أن اعتراضك - لأنني بحاجة إلى
أوثسرفيس، من أجل الحصول على عقد من الرمز المميز من
أوثسيرفيس و أوثسرفيس بدوره يعتمد على هذا اعتراض لذلك
لهذا السبب من أجل كسر حلقة أنا صراحة حقن أوثسرفيس في هذه الحالة.
الآن هذا شيء قد أحسب من خلال التجربة
والخطأ ذهبت في البداية إلى الأمام وحقن ببساطة
الخدمات الفردية إلى المنشئ ثم وجدت أن
Angular لم يكن يقوم بتجميع التعليمات البرمجية ثم اكتشفت أن
هناك خطأ هناك ثم بعد إجراء بعض بحث Google
أن هذه طريقة بديلة للتعامل مع
نفس الشيء وهذا يعمل بشكل أفضل بكثير لتطبيقنا.
لذلك بمجرد حقن AuthService من الخدمة أحصل على
عقد من الرمز المميز ثم لاحظ ما أفعله هنا.
هنا أقول استنساخ كونست المصادقة ريك استنساخ.
لذلك سنقوم باستنساخ الطلب ومن ثم سنقوم بإعداد في الرؤوس.
لذلك سنقول رؤوس req تعيين
التفويض ثم لاحظ ما أقوم
بإعداد رأس التفويض ليكون، حامل.
زائد أوثتوكين.
لذلك في رأس التفويض أقوم بإعداد حامل و AuthToken هنا.
إذن هذه هي الطريقة التي أقوم بها بإعداد
رأس التفويض في
رسالة الطلب الصادرة في تطبيق Angular الخاص بي. لذا هناك
وبهذه الطريقة تأكدت من أن جميع الطلبات الصادرة سيتم
إعداد رأس التفويض قبل تمريرها إلى جانب الخادم.
وبعد ذلك، سنقوم ببساطة بتمريره إلى المعترض التالي، إذا كان موجودًا،
أو إلى قائمة الانتظار الصادرة،
بحيث يتم إرسال رسالة الطلب إلى جانب الخادم.
وبالمثل، لدي اعتراض آخر قمت بتنفيذه هنا.
يعترض هذا الاعتراض أي رسائل رد غير مصرح بها
التي تعود من جانب الخادم.
لذلك، إذا كان الخادم الردود مع 401 رسالة رد غير مصرح به.
حتى في هذه المرحلة مرة أخرى، نفس الشيء،
لقد قمت بإعداد أوثسيرفيس هنا،
وبعد ذلك، داخل هنا ثم سأقول،
لا التعامل مع إذا كان الخطأ.
لذلك هذا هو المكان الذي سوف تحصل على عقد من هتبفنت هنا.
و هتبفينت هو كائن مستوى أقل من الطلب،
ولكن هذا يسمح لنا بالوصول إلى رسالة الرد الواردة،
وبعد ذلك سوف نتحقق لمعرفة ما إذا كان هناك خطأ،
وبعد ذلك إذا كان الخطأ هو مثيل استجابة خطأ هتب،
وإذا كانت حالة الخطأ 401.
مما يعني أنني قد اكتشفت للتو أن الخادم أرسل رسالة خطأ 401.
لذلك مما يعني أن هناك بعض مشكلة التفويض على جانب الخادم.
ثم في هذه المرحلة سوف تحقق
من رمز ويب جسون للتأكد من أن رمز ويب جسون لا يزال صالحا.
إذا لم يكن
صالحًا، فسأتجاهل بيانات الاعتماد الخاصة بي وأتوقع من المستخدم تسجيل الدخول مرة أخرى.
وبهذه الطريقة، سأتأكد من أنه إذا
انتهت صلاحية رمز الويب الخاص بي json في عملية محاولة جلب البيانات،
فسيظل ذلك يتم اعتراضه هنا لأنه إذا كان الخادم يستجيب بـ 401،
فسوف أعترض ذلك ثم قم بمسح
رمز الويب الخاص بي json وأتوقع من المستخدم تسجيل الدخول مرة أخرى.
يمكننا أيضًا إعادة توجيه المستخدم إلى صفحة تسجيل الدخول إذا كنت تريد ذلك،
ولكن مع تطبيق Angular، يكون الأمر أكثر تعقيدًا قليلاً
للقيام بذلك ولم أكن أرغب في إرباكك عن طريق القيام بكل ذلك.
بدلا من ذلك، أنا ببساطة تسجيل الخروج من
المستخدم في هذه المرحلة ومن ثم تدمير بيانات اعتماد المستخدم،
بحيث يتوقع من المستخدم تسجيل الدخول في هذه المرحلة.
لذلك، معالجة بسيطة لكيفية حقن رأس التفويض في الطلب الصادر،
وأيضا اعتراض أي 401 رسائل غير مصرح بها
التي تعود من جانب الخادم.
لذلك، ترى كيف يجب إجراء هذه التغييرات الإضافية على
تطبيق Angular الخاص بك لجعله يعمل مع جانب الخادم الخاص بك.
مع تعيين جزء المصادقة،
إذا لم يكن لديك مصادقة وإذا كنت ستصل فقط إلى
بقية نقاط نهاية واجهة برمجة التطبيقات والحصول على عمليات،
فلا داعي للقلق حتى بشأن أي من هذه الأشياء.
لا توجد مصادقة مطلوبة.
يمكن جلب البيانات بسهولة جدا.
ولكن بالنسبة لأي وظيفة،
وضع وحذف العمليات،
نحتاج إلى دعم كل هذه الميزات.
لذلك هذا هو السبب في أنني نفذت جزء المصادقة في طلبي.
كما أوضحت سابقًا،
عندما لا يتم تسجيل دخول أي مستخدم،
فلن نتمكن من الانتقال إلى نقطة النهاية المفضلة،
ولكن عندما يتم تسجيل دخول المستخدم،
سنكون قادرين على رؤية المفضلة للمستخدم المحدد.
يتم تنفيذ ذلك باستخدام حراس الطريق في Angular.
الآن لتنفيذ حراس الطريق هذه،
لقد نفذت خدمة أخرى هنا تسمى AuthGuardService.
لذلك في هذا AuthGuardService،
قمنا بتنفيذ هذه الطريقة التي تسمى طريقة CanActivate والتي
سنقوم بتصنيفها الفرعي من أجل تنفيذ ذلك.
وفي طريقة CanActivate،
سيعود التنفيذ منطقيًا،
وفي هذه الحالة،
ما نتحقق منه هو إذا تم تسجيل دخول هذا المستخدم،
فسنسمح للمستخدم بالتنقل.
وإلا، سوف تنقل المستخدم إلى نقطة النهاية الرئيسية.
لذلك هذه هي الطريقة التي يتم بها تنفيذ حارس الطريق في هذه الحالة.
الآن، للاستفادة من حارس الطريق هذا،
سنذهب لنرى كيف يتم تحديث الطرق للاستفادة من حراس الطريق.
حتى في ملف routes.ts،
يمكنك أن ترى أنه بالنسبة لمكون المفضلة،
نرى أننا نحدد المسار كمفضلة والمكون كـ
favoritesComponent ثم نحدد هذا الحقل الآخر
يسمى CanActivative الذي حددنا AuthGuard كمعلمة هنا،
وهذا AuthGuard ليست سوى خدمة AuthGuard التي قمنا بتنفيذها،
والتي يتم استيرادها هنا.
لذا بهذه الطريقة عندما يتم تقييم AuthGuard إلى false،
فلن يُسمح لك بالانتقال إلى المكون المفضل،
بدلاً من ذلك، سيتم إعادة توجيهك إلى المنزل،
ولكن عندما يتم تسجيل دخول المستخدم، فمن الواضح أن AuthGuard سيقيم إلى true
، وفي هذه الحالة،
ستتمكن من للانتقال إلى مسار المفضلة هناك.
الآن أيضا وبالمثل هناك تعديلات طفيفة على المكونات المتبقية في هناك،
والتي تسمح لك للتعامل مع
تعقيدات كيفية العميل والخادم الخاص بك سوف نتحدث مع بعضها البعض. على
وجه الخصوص، لاحظ كيف تم تحديث مكون الرأس
لتعكس حالة تسجيل الدخول للمستخدم في شريط الأدوات في الأعلى.
هذا هو مرة أخرى تغيير آخر مثير للاهتمام
قمت به إلى مكون الرأس في طلبنا.
لذا سأترك ذلك كممارسة لك لمعرفة كيف تم تنفيذ ذلك.
رمز بسيط جدا هناك.
يجب أن يكون من السهل عليك أن تكتشف ذلك
لذلك مع كل هذه التغييرات، الآن،
العميل الزاوي قادر على التفاعل مع الخادم الخاص بي.
اسمحوا لي أن تظهر لك مرة أخرى كيف يمكننا نشر بعض التعليقات على الخادم،
ومن ثم نرى التعليق ينعكس على الفور في الطبق.
لذلك، مرة أخرى العودة إلى طلبنا،
يمكننا الآن الذهاب إلى القائمة ومن ثم سحب ما يصل أي طبق هنا،
ويمكنني نشر التعليقات على الطبق هنا،
لذلك أود أن إعداد على الفور تصنيف هنا،
وقيمة تعليقي هنا.
لاحظ أنني لا
أدخل اسم المستخدم الخاص بي أو اسم المؤلف الخاص بي هنا في النموذج هنا.
الآن بالطبع، من أجل تقديم تعليق،
تحتاج إلى تسجيل الدخول.
حتى إذا لم يتم تسجيل الدخول في هذا التعليق لن يتم قبوله من قبل الخادم الخاص بي.
لذلك اسمحوا لي أولا تسجيل نفسي في.
حتى أتمكن من تسجيل الدخول هنا.
وفي اللحظة التي أقوم فيها بتسجيل الدخول،
تلاحظ على الفور أنه يتم تحديث شريط أدوات الرأس للإشارة إلى حالتي.
الآن يمكنني نشر هذا التعليق.
وستلاحظ أنه عند نشر التعليق،
يتم إضافة التعليق إلى قائمة التعليقات،
وتلاحظ أيضًا أن حقل المؤلف يتم ملؤه تلقائيًا هنا.
لأن هذه هي الطريقة التي نقوم بها بإعداد جانب الخادم الخاص بنا.
في حقل التعليقات،
قمنا بإعداد مستخدمنا
كمرجع إلى معلومات المستخدم
التي نقوم بتخزينها في جانب الخادم الخاص بنا، وبما أننا نستخدم ملء،
Mongoose Populate على جانب الخادم،
يتم ملء معلومات المستخدم تلقائيًا
في التعليقات الواردة من الخادم الجانب.
لذا، هذه هي الطريقة التي تلاحظ بها كيف يمكنني الاستفادة
من ما يقدمه الخادم بالفعل بالنسبة لي لملء التفاصيل تلقائيًا.
لذلك، تغييرات طفيفة مرة أخرى حتى
في صفحة تفاصيل الطبق لتعكس استخدام دعم التعليقات على جانب الخادم.
مع هذا أكمل التوضيح السريع
للعميل Angular الذي قمنا بتنفيذه كجزء من هذا التمرين.
وآمل أن تذهب من خلال تفاصيل التعليمات البرمجية في العميل الزاوي أيضا،
ومن ثم تعكس مرة أخرى على ما تعلمته في الدورة الزاوي ونرى
كيف تمكننا التعديلات من تنفيذ
في عميل الزاوي المعدل الذي أصبح الآن
قادرا على التواصل مع الخادم و ثم دعم جميع الميزات
التي كنا نعتزم تنفيذها في الأصل كجزء من كل من العميل وجانب الخادم.