لوحة المتصدرين

دلوقتي لما تكون شغال علي موقع في اكتر من طريقة بتوصلك لنفس الهدف يعني علي سبيل المثال ممكن عنصرين قريبين من بعض وانت عايز تجيبهم جنب بعض ممكن تعملها بل float وممكن تعملها بل postion وممكن تظبتها بردو عن طريق padding و margin بطرقا ما يعني بس هل دي ممكن تكون مشكلة ؟ ولا اختار براحتي مع العلم في الي حيعملك مشاكل قدام بس انت مش حتاخد بالك منها دلوقتي

السلام عليكم. vs code يظهر لي الخطأ التالي: الغريب في الأمر أني عندما قمت بفتح console لم ألاحظ الخطأ الرجاء المساعدة و المزيد من التوضيح.

قد لا يدعم برنامج VS Code بعض الهاشات التي تم توليدها من قِبل بعض المواقع، يمكنك أن تستخدم موقع zinoui لتوليد هاش صحيح، لكن عليك أن تضيف .css إلى نهاية الرابط لكي يعمل الموقع بشكل سليم: https://fonts.googleapis.com/css2?family=El+Messiri&display=swap.css // ^^^^^ وسيتم توليد كودج سليم بالشكل التالي: <link href="https://fonts.googleapis.com/css2?family=El+Messiri&display=swap.css" rel="stylesheet" integrity="sha384-d5m239bU1uZmu/M/j2JqVS8ZbQYLFSfp3cefs1vrIB8UaXE1DTSFwhtAioI18Nck" crossorigin="anonymous">

للأسف أخي نفس الرسالة ظهرت مجددا

عندما قمت بإضافة crossorigin attribute ظهرت الرسالة التالية: Resource was requested without the 'integrity' attribute. في الواقع لما بحثت عن integrity attribute (الخاصة بخطوط غوغل) وقمت بالدخول إلى الرابط: https://www.srihash.org/ ثم أدخلت رابط خطوط غوغل لم أصل إلى نتيجة ربما لأن الموضوع معقد أكثر مما تصورت. على كل شكرا جزيلا أخي الكريم على كل الإيضاحات.

في الحقيقة، لا مشكلة بإستعمال أي سياق مادام يؤدي الغرض ويعطي التنسيق أو التموضع المطلوب، ولكن الذي يتحكم ويؤول خاصية عن أخرى هو بالدرجة الأولى تجاوب كل خاصية مع مختلف حالات الاستعمال التي يمكن لها أن تحدث. على سبيل المثال: ان كنا نريد مثلا أن يظهر زر التسجيل في القائمة البريدية في منتصف الترويسة الأساسية للموقع، سيمكننا أن نعطي هذا الزر وضعية ثابتة position:fixed ونقوم بضبط المسافة من اليمين واليسار إلى حد أن تتموضع في المنتصف تماما. لحد ما تفي هاته الفكرة بالغرض، ولكن بعض حالات الاستعمال الأخرى قد تسقط هذا المنطق وتفضل طريقة أخرى عن هاته الطريقة. مثل: ان قام المستخدم بالانزلاق الى الاسفل لتفحص باقي العناصر فإن العنوان سيبقى ثابتا في منتصف الصفحة بشكل مزعج يغطي باقي الأقسام. ولو حدث وقلنا أن موقعنا ككل يمتلك قسما واحدا. فإن مشكلة أخرى ستظهر في حالة تصفح العميل للموقع عن طريق الهاتف أو التابلت مثلا، فالنسب من اليمين واليسار في شاشة الكمبيوتر 24" ليست هي نفسها في شاشة الهاتف أو التابلت، ولذلك فإن تموضع العنصر سيتغير في كل من الشاشات. هاته المشاكل تجعل من الأفضل استعمال هامش تلقائي على المحور x بدل الوضعية الثابتة. فإن حدث وقام المستخدم بتصفح الموقع من الهاتف فسيحافظ الموقع على شكله هنا أيضا، لأن الهامش التلقائي من اليمين واليسار لن يتغير من الهاتف الى الكمبيوتر. كما أن العنصر لن يبقى في المنتصف في حالة انزلاق المستخدم لتصفح أقسام اخرى. هاته الاحتمالات والاعتبارات التي يجب أن يأخذها المصمم أثناء عمله لتصميم موقع هي ما يعتبر جزءا هاما من ادارة أولويات التصميم، وهي ما يسقط خاصية على أخرى. وعموما، لا يكتسب ذلك إلا بالاختبار والتجريب والتكرار والخبرة. والتفاعل مع العناصر بشتى الاحتمالات. واستخراج مختلف حالات الاستعمال سيجعلنا نقرر بالضبط أي خاصية نستخدمها وأي خاصية لا، مثل: ما الذي يحدث عندما يضغط المستخدم الزر؟ ما الذي يحدث عندما ينزلق المستخدم الى القسم التالي؟ ماذا سيحدث ان حاول مستخدمنا سحب العنصر؟ ماذا سيحدث ان قام المستخدم بإعادة تحجيم نافذة الموقع؟ الى أي حد تلائم هاته الخاصية التصميم الحالي؟ إلى أي مدى تتجاوب هاته الخاصية أو الخواص مع مختلف الشاشات ولا تتطلبنا أن نخصص كل مجموعة من الخواص لكل شاشة بمفردها؟ هل تعتبر هاته الخواص هي أقل وأنظف شيفرة تحقق الغرض؟ وما الى ذلك من احتمالات واعتبارات..

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

الأمر بسيط وليس بذلك التعقيد الذي يظهر عليه، فالتواصل بين الخادم والعميل يتم عن طريق آلية سهلة وبسيطة. لنقل أن التطبيق ككل يتكون من قسمين أساسين: قسم يراه المتصفح ويقرأه ويظهره للعميل الذي يتصفح هذا الموقع. قسم لا يراه المتصفح، ولا يصل إليه مباشرة وتتم فيه أغلب العمليات الحساسة التي من غير الآمن أن يراها من هو المتصفح. القسم الأول يدعى بقسم العميل، في حين أن القسم الثاني يدعى بقسم الخادم. والتواصل بينهما يتم غالبا بالشكل الآتي: عندما نستعرض موقعا ما، فإن تطبيقنا يسمح بتسليم الجزء المسموح إظهاره للمتصفح. يستقبل جزء "العميل" مجموع الشيفرات والملفات المسموح عرضها، ويترجمها المتصفح إلى هياكل HTML و تنسيقات CSS و تفاعلات جافاسكربت مع الموقع. وبناءا على حدث ما (وليكن ضغطة زر) يقوم العميل بالتواصل مع الجزء الخفي للتطبيق، ويكون ذلك عن طريق طلبيات الـ HTTP أين يتم ارسال أو طلب بيانات واستقبال رد. عندما يستقبل العميل هذا الرد يقوم بالتصرف بناءا عليه. لنقم بفهم هذا التكامل جيدا عن طريق مثال شائع عن عمليات تسجيل الدخول: يقوم الطالب "أحمد" بالتصفح عن طريق المتصفح الى رابط تسجيل الدخول في أحد المنصات التي يسجل بها https://app.co/login . يستقبل الجزء الخفي من هذا التطبيق طلب أحمد، ويقوم بإرسال الملف الموافق لصفحة تسجيل الدخول في الرد. يستقبل المتصفح هذا الملف، ويقوم بترجمة HTML و CSS و جافاسكربت ليظهر الموقع بشكله وتنسيقاته وتفاعليته المطلوبة. يقوم "أحمد" بعد أن يعرض له المتصفح تفاصيل الموقع بملئ حقل البريد الالكتروني ببريده الذي سجل به، وحقل كلمة المرور بكلمة المرور الخاصة به. عندما يظغط "أحمد" زر "تسجيل الدخول" يقوم العميل بالتحسس الى هذا الحدث ومعرفة أن أحمد يريد ان نتحقق من بياناته ونسجل دخوله. وبالتالي يقوم بإرسال طلبية HTTP إلى الخادم مرفقة ببريده الالكتروني وكلمة مروره. لأن من غير الآمن أن نتحقق من صدق كلمة المرور ومطابقتها البريد الالكتروني في الجزء الذي يظهر لأحمد، وإلا فإنه سيمكنه تزييف دخوله ومعرفة كلمة المرور الحقيقية لأننا نقارن التي يرسلها مع الحقيقية. يستقبل الخادم هذا الطلب ويقوم بمعالجة هاته البيانات ويتحقق منها، فإن كانت مطابقة قام بإرسال رد بالنجاح، وإلا فإنه سيرسل ردا بالفشل لأحمد. يستقبل أحمد هذا الرد من الخادم، ويقوم بالتصرف بناءا على هذا الرد، فإن كانت بياناته صحيحة طبقا للخادم فسيتم توجيهه مثلا إلى لوحة تحكمه، وإلا فإنه سيتم إظهار رسالة الخطأ الموافقة لذلك. مبدئيا، هاته هي الخطوط العريضة في التواصل بين الخادم والعميل عن طريق طلبيات الـ HTTP. إذ يمكن تكييف أي مثال وفق طريقة الاستماع إلى حدث يعطي إشارة بإرسال الطلب وإستقبال الرد والتصرف بناءا عليه.

شكرا على التوضيح. لكن عندما قمت بإضافة crossorigin="anonymous" لم يعد css يعمل كأنني قمت فقط بملف html

هذا ليس خطأ error بل تحذير warning من برنامج VS Code لكي تقوم بإضافة الخاصية crossorigin إلى العنصر link بالشكل التالي: <link rel="stylesheet" href="..." crossorigin="anonymous"> وقد تم شرح هذه الخاصية وكيفية إستخدامها في هذه المقالة (قسم سياسة تعدد المصادر Crossorigin policy): يمكنك تجاهل مصل هذه التحذيرات وسيعمل الموقع بدون مشكلة، ولكن البحث عن معناها وكيفية إصلاحها سوف يزيد من معلوماتك.

أحاول إنشاء نموذج form لتعديل بيانات المستخدم (Profile Page). لذلك أحتاج إلى تضمين بعض الحقول من نموذج المستخدم ونموذج Profile. حاليا أنا أستخدم نموذجين بالشكل التالي: class ProfileForm(ModelForm): class Meta: model = UserProfile fields = ("bio", "phone", "email", "username") class UserEditForm(ModelForm): class Meta: model = User fields = ("name", "age") هل هناك طريقة لدمج نموذجين في نموذج واحد أم أحتاج إلى إنشاء نموذج جديد بالكامل؟

كيفيه ارسال حواله من اكونت paypal الي اخر عن طريق RESTAPI?

يمكن إرسال تفاصيل التحويل إلى الواجهة البرمجية الخاصة ببايبال عبر طلب POST إلى المسار التالي: /v1/payments/payouts الترويسات الواجب إرسالها هي نوع المحتوى Content-Type لوصف نوع المحتوى المرسل، وتروسية التوثيق Authorization كالتالي (مع تبديل المفتاح بالمفتاح الخاص بحسابك): Content-Type: application/json Authorization: Bearer <المفتاح الخاص بحسابك> جسم الطلب هو غرض JSON يتضمن مفتاحين رئيسيين : sender_batch_header: وفيه معلومات عن الحوالة الحالية من معرّف خاص تضع فيه أي قيمة تريد، وعنوان ومحتوى البريد الالكتروني المرسل للحساب الوجهة عند استلامه للحوالة "sender_batch_header": { "sender_batch_id": "1234", "email_subject": "تم إرسال أرباحك", "email_message": "المبلغ المرسل هو أرباحك خلال المدة الماضية، شكرًا لك" } items: وهي مصفوفة تضم أكثر من حوالة وتفاصيل عم الوجهة يمكنك إرسالها معًا، تتضمن التفاصيل التالية: recipient_type: وهو نوع حساب الوجهة إما لديك عنوان بريده أو رقم هاتفه أو معرّف بايبال الخاص به تكون إحدى القيم التالية (EMAIL - PHONE - PAYPAL_ID) receiver: وهو عنوان الحساب الوجهة قيمته بحسب نوع العنوان في الحقل السابق amount: يتضمن العملة والقيمة المرسلة: value: القيمة currency: العملة "items": [ { "recipient_type": "EMAIL", "receiver": "receiver@example.com", "amount": { "value": "9.87", "currency": "USD" }, } ] بحسب لغة البرمجة أو إطار العمل المستخدم تقوم ببناء الطلب على الشكل السابق وإرساله

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

نعم هناك طريقة: قُم بالفصل بين المهام التي يتعين على الخادم القيام بها وبين إرسال الرد للعميل. إستخدم مكتبة بايثون threading لإنشاء Thread ليقوم بتنفيذ الدالة بعد إرسال الرد للعميل على الشكل الآتي: from flask import Flask, request import time import threading#قم باستدعاء مكتبة بايثون app = Flask(__name__) @app.route('/your-route', methods=['POST']) def start_task(): def long_running_task(**kwargs): # أنشئ الدالة """ مهمة طويلة المدى """ ... # قم بتنفيذ الدالة داخل # Thread thread = threading.Thread(target=long_running_task) thread.start() return {"message": "Accepted"}, 202 # هنا تقوم بإرجاع الرد للعميل if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=True)

السلام عليكم .. اقوم بعمل تسجيل الدخول لدى موقعي و لا اعلم ماذا يجب ان استخدم تحديدا في عملية تسجيل الدخول API token, Passport, JWT Authentication,bcrypt اعلم ان جميعها هو لغرض الامان لكن سبب سؤالي هو اي وسيلة استخدم ؟ لانني رايت مواقع تستخدم passport و bcrypt فما هو الافضل ؟ شكرا .

الأساس في العملية هو قسمان: إنشاء معرّف للمستخدم: وهي العملية الأسهل حيث تقوم بعد أن تتأكد من صحة بيانات الدخول من إنشاء قيمة تحوي داخلها دليل على هوية المستخدم، قد تضع فيها المعرف الخاص بالمستخدم، أو رقم الجلسة بعد إنشاءها للمستخدم، أو صلاحيات المستخدم، هذه القيمة ستعتبر تصريح دخول في المرات القادمة يجب على كل طلب أن يبرزها بدل إعادة إبراز بيانات تسجيل الدخول حماية المعرّف: يمكن لأي مستخدم أن يقوم بكتابة قيمة مشابهة لطريقة توليدك للمعرفات وإرسالها ضمن طلباته وسيستطيع انتحال شخصية أي مستخدم والحصول على أي صلاحيات، لذا يجب علينا التأكد من تأمين تلك القيمة إما بتشفيرها أو بإضافة توقيع عليها يمكننا التحقق منه للتأكد بأننا من أصدر تلك القيمة حصرًا التقنيات والمكتبات التي ذكرتها تتقاطع في عملها ولا يمكن المقارنة بينها: bcrypt: عملية لتشفير البيانات، يمكن أن تفيدك في تشفير كلمة سر المستخدم قبل تخزينها في قاعدة البيانات، وذلك كنوع من الحماية من تسريب كلمات السر. JWT Authentication: هي طريقة لتوليد Token آمنة ووضع البيانات داخلها والتوقيع عليها للتأكد من مصدرها لاحقًا API token: هو مفهوم عام ويعني إصدار Token مخصصة للاستخدام مع الواجهة البرمجية لموقعك، قد تكون تستخدم طريقة JWT أو غيرها Passport: هي مكتبة تساعدك في عملية التوثيق وإصدار ال Token للمستخدمين، لكن يمكنك إعدادها لاستخدام التقنيات التي تفضلها مثل JWT أو غيرها الأمر يعتمد على مشروعك ومتطلباته وخبرتك البرمجية في التعامل مع المفاهيم السابقة وسهولة تضمين المكتبة أو الطريقة ضمن مشروعك يمكنك الاطلاع على المقالات التالية المتعلقة بالموضوع:

حاولي حل المشكلة بنفسك، وعندما تواجهين مشكلة ضمن شيفرة ما أو لديك استفسار يرجى إرفاق الشيفرة وتوضيح استفسارك عنها لنتمكن من مساعدتك، أحد الحلول يكون بتحديد نوع الملف عن طريق الللاحقة له: $filename = ... // اسم الملف المرفوع $ext = end((explode(".", $name))); // اللاحقة هي القسم الأخير بعد النقطة ... // نضع الملف في مساره المحدد بحسب اللاحقة حاولي انجاز المطلوب على خطوات ليصبح المشروع اسهل: رفع الملفات بنجاح وضع الملفات المرفوعة بمجلد معين معرفة نوع الملف المرفوع فرز الملفات بحسب نوعها ونقلها لمسارها الخاص

استعمل form.errors التي ستعطيك مُلخصاً لجميع الأخطاء: for field, err in form.errors.items(): print(err )

يُمكنك تعطيل خاصية الautoescape للحصول على النتيجة التي ترغب بها: {% autoescape false %} {{ 'username|name|email' | replace("|", ":<br/>") }} {% endautoescape %} لكن هذه الطريقة لا يُنصح بها لأنك تقوم بعطيل الحماية ضد حَقْن ال HTML أو ما يُعرف بالإنجليزية HTML Injection. في طريقة أخرى وهي إنشاء مُرشح خاص يقوم بهذا العمل: # myapp/util/filters.py from .. import app from markupsafe import Markup @app.template_filter() def custom_split(text): """ الفصل بين العناصر بأسطر""" return Markup("<br>".join(text.split("|"))) القالب يُصبحْ: {{ 'username|name|email'|custom_split }}

لإضافة خاصية تسجيل المعلومات لكل الزيارات التي يقوم بها المستخدمون قم بإضافة الشفرة الآتية إلى ملف الإعدادات settings.py: LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': 'path to the forlder temp/app.log',# ضع هنا المسار الكامل لملف التسجيل }, }, 'loggers': { 'django': { 'handlers': ['file'], 'level': 'DEBUG', 'propagate': True, }, }, } بعدها في ملف ال views.py الخاص بك أضف الشفرة التالية: import logging# قم بإستيراد المكتبة الخاص بالتسجيل logger = logging.getLogger(__name__) # قم بجلب المٌسجل def profile(request): ... # بعدها سجل ما تريد من المعلومات # التسجيلات سوف تٌحفظ في الملف الذي عينته في الإعدادات logger.debug('User visited /profile/me') logger.debug('User is %s' % (request.user.get_full_name())) logger.debug('User age is %s' % (request.user.profile.age)) 14:22:10 Jan 31 2022 Username is Mohssen 14:22:10 Jan 31 2022 User age is 23