عرض نطاق مجاني لمدة عام مع خدمة WordPress GO

تُركز هذه التدوينة على مشاكل مشاركة الموارد عبر المصادر (CORS) التي يواجهها مطورو الويب بشكل متكرر. تبدأ بشرح ماهية CORS ومبادئها الأساسية وأهميتها. ثم تتعمق في كيفية حدوث أخطاء CORS وكيفية حلها. كما تُسلط الضوء على أفضل الممارسات والاعتبارات الرئيسية لتطبيق CORS بشكل آمن وفعال. يهدف هذا الدليل إلى مساعدتك في فهم وحل المشاكل المتعلقة بـ CORS في تطبيقات الويب الخاصة بك.
مشاركة الموارد عبر الأصول (CORS)آلية أمان تُمكّن متصفحات الويب من السماح لصفحة ويب بالوصول إلى موارد من نطاق مختلف. تُنظّم هذه الآلية، في جوهرها، وصول تطبيق الويب إلى الموارد (مثل واجهات برمجة التطبيقات والخطوط والصور) خارج نطاقه. افتراضيًا، تحظر المتصفحات الطلبات من نطاق إلى آخر، وذلك بفضل سياسة المصدر نفسه. يُتيح نظام CORS تجاوز هذا التقييد بأمان.
تنبع أهمية نظام CORS من تعقيد تطبيقات الويب الحديثة والحاجة إلى جمع البيانات من مصادر متعددة. يعتمد العديد من تطبيقات الويب على واجهات برمجة التطبيقات (APIs) وشبكات توصيل المحتوى (CDNs) أو مصادر خارجية أخرى مستضافة على خوادم مختلفة. بدون نظام CORS، سيكون الوصول إلى هذه الموارد مستحيلاً، مما يحدّ بشدة من وظائف تطبيقات الويب. كورسإنه يمنح المطورين المرونة اللازمة لسحب البيانات من مصادر مختلفة مع الحفاظ على أمان تطبيقات الويب الخاصة بهم.
في الجدول أدناه، كورسيتم تلخيص المفاهيم الأساسية وكيفية عملها على النحو التالي:
| مفهوم | توضيح | أهمية |
|---|---|---|
| سياسة المنشأ نفسه | إنه يمنع المتصفحات من الوصول إلى الموارد من مصدر مختلف عن طريق البرامج النصية المحملة من مصدر واحد. | ويضمن الأمان ويمنع البرامج النصية الضارة من الوصول إلى البيانات الحساسة. |
| طلب عبر الأصول | طلب HTTP تم إرساله إلى نطاق مختلف عن نطاق صفحة الويب. | إنه يتيح لتطبيقات الويب الحديثة الوصول إلى واجهات برمجة التطبيقات والموارد المختلفة. |
| كورس العناوين (كورس (الرؤوس) | عناوين خاصة يضيفها الخادم إلى عناوين الاستجابة للسماح بالطلبات متعددة الأصول. | يخبر المتصفح عن المجالات التي يمكنها الوصول إلى الموارد. |
| طلب ما قبل الرحلة | طلب يرسله المتصفح إلى الخادم عبر طريقة OPTIONS قبل إجراء طلبات معقدة عبر الأصول. | إنه يسمح للخادم بالتحقق مما إذا كان سيقبل الطلب أم لا. |
كورستعتمد العملية الأساسية لـ على قيام خادم الويب بإبلاغ المتصفح بالموارد التي يسمح بالوصول إليها عبر رؤوس استجابة HTTP. يحدد الخادم النطاقات التي يمكنها الوصول إلى موارده باستخدام رأس Access-Control-Allow-Origin. إذا كان النطاق الطالب مُدرجًا في هذا الرأس أو إذا تم تحديد * (الجميع)، يقبل المتصفح الطلب. وإلا، يحظر المتصفح الطلب ويرسل كورس يحدث خطأ.
كورس غالبًا ما تحدث الأخطاء بسبب سوء تهيئة الخادم. من المهم للمطورين تهيئة خوادمهم بشكل صحيح للسماح فقط للمجالات الموثوقة بالوصول إلى الموارد. بالإضافة إلى ذلك، كورس يساعد اتباع أفضل الممارسات على تقليل الثغرات الأمنية.
كورسإنه جزء لا يتجزأ من تطبيقات الويب الحديثة، إذ يوفر مرونةً في سحب البيانات من مصادر مختلفة مع الحفاظ على الأمان. عند إعداده بشكل صحيح، يُوسّع وظائف تطبيقات الويب ويُحسّن تجربة المستخدم.
الموارد متعددة الأصول CORS هي آلية تُمكّن متصفحات الويب من السماح لصفحات الويب من مصدر واحد بالوصول إلى موارد من مصدر مختلف. عادةً ما تُطبّق المتصفحات سياسة المصدر نفسه، أي أن صفحة الويب لا يمكنها الوصول إلى الموارد إلا من مصدر له نفس البروتوكول والمضيف والمنفذ. طُوّر CORS للتغلب على هذا القيد وتمكين مشاركة البيانات بشكل آمن بين مصادر مختلفة.
الغرض الرئيسي من CORS هو تأمين تطبيقات الويب. يمنع مبدأ المصدر الواحد المواقع الضارة من الوصول إلى بيانات المستخدمين الحساسة. ومع ذلك، في بعض الحالات، تكون مشاركة البيانات بين مصادر مختلفة ضرورية. على سبيل المثال، قد يحتاج تطبيق ويب إلى الوصول إلى واجهة برمجة تطبيقات (API) على خادم مختلف. يوفر CORS حلاً آمنًا لمثل هذه السيناريوهات.
| منطقة | توضيح | مثال |
|---|---|---|
| أصل | عنوان المورد الذي بدأ الطلب. | http://example.com |
| التحكم في الوصول - السماح - الأصل | يحدد الموارد التي يسمح بها الخادم. | http://example.com، * |
| طريقة طلب التحكم في الوصول | يحدد طريقة HTTP التي يريد العميل استخدامها. | نشر، احصل |
| طرق السماح بالتحكم في الوصول | يحدد طرق HTTP التي يسمح بها الخادم. | النشر، الحصول، الخيارات |
يعمل بروتوكول CORS عبر سلسلة من رؤوس HTTP بين العميل (المتصفح) والخادم. عندما يُجري العميل طلبًا عبر المصادر، يُضيف المتصفح تلقائيًا رأس الأصل إلى الطلب. يفحص الخادم هذا الرأس ليقرر ما إذا كان سيسمح بالطلب. إذا سمح الخادم بالطلب، فإنه يُجيب برأس Access-Control-Allow-Origin. يُحدد هذا الرأس الموارد التي يمكنها الوصول إلى الطلب.
يُعد فهم آلية عمل CORS أمرًا بالغ الأهمية لمطوري الويب. قد يؤدي ضبط إعدادات CORS بشكل خاطئ إلى ثغرات أمنية في تطبيقات الويب. لذلك، يُعد فهم آلية عمل CORS وكيفية ضبطها بشكل صحيح أمرًا أساسيًا لتطوير تطبيقات ويب آمنة وفعالة.
في CORS، تُستخدم عمليات الأذونات لتحديد الموارد التي يُسمح للخادم بالوصول إليها. الخادم، التحكم في الوصول - السماح - الأصل يمكنك السماح بموارد محددة عبر الرأس أو السماح بجميع الموارد * يمكن استخدام الشخصية. ومع ذلك، * قد يُشكّل استخدام هذه الأحرف مخاطر أمنية، لذا يجب توخي الحذر. يُعدّ منح الأذونات لموارد مُحددة نهجًا أكثر أمانًا، خاصةً عندما يتعلق الأمر ببيانات حساسة.
غالبًا ما تحدث أخطاء CORS بسبب إعدادات الخادم الخاطئة. أحد أكثر الأخطاء شيوعًا هو التحكم في الوصول - السماح - الأصل الرأس مفقود أو مُهيأ بشكل غير صحيح. في هذه الحالة، يحظر المتصفح الطلب ويعرض خطأ CORS. لحل هذه الأخطاء، يجب عليك التحقق من إعدادات الخادم و التحكم في الوصول - السماح - الأصل من المهم التأكد من إعداد الرأس بشكل صحيح. ومن المهم أيضًا التأكد من معالجة طلبات الخيارات (OPTIONS)، المعروفة أيضًا بطلبات الفحص المسبق، بشكل صحيح.
الموارد متعددة الأصول أخطاء CORS مشكلة شائعة ومستهلكة للوقت لمطوري الويب. تحدث هذه الأخطاء عندما تحاول صفحة ويب طلب مورد من مصدر مختلف (نطاق، بروتوكول، أو منفذ)، فيحظر المتصفح الطلب لأسباب أمنية. يُعد فهم أخطاء CORS وحلها أمرًا بالغ الأهمية لضمان سلاسة تشغيل تطبيقات الويب الحديثة.
يُعد تشخيص أخطاء CORS الخطوة الأولى في تحديد مصدر المشكلة. يُمكن أن يُساعدك فحص رسائل الخطأ في أدوات مطوّري المتصفح (عادةً في علامة تبويب "وحدة التحكم") على فهم المورد المحظور وسببه. غالبًا ما تحتوي رسائل الخطأ على أدلة لحل المشكلة. على سبيل المثال، تُشير رسالة مثل "لا يوجد رأس 'Access-Control-Allow-Origin' موجود على المورد المطلوب" إلى عدم وجود رأس CORS على الخادم.
| رمز الخطأ | توضيح | الحلول الممكنة |
|---|---|---|
| 403 ممنوع | لقد فهم الخادم الطلب ولكنه رفضه. | تحقق من إعدادات CORS على جانب الخادم. قم بتكوين الموارد المسموح بها بشكل صحيح. |
| خطأ الخادم الداخلي 500 | حدث خطأ غير متوقع على الخادم. | راجع سجلات الخادم وحدد مصدر الخطأ. قد تكون هناك مشكلة في تكوين CORS. |
| خطأ CORS (وحدة التحكم في المتصفح) | قام المتصفح بحظر الطلب بسبب انتهاك سياسة CORS. | قم بتعيين رأس 'Access-Control-Allow-Origin' بشكل صحيح على جانب الخادم. |
| خطأ في طلب CORS وليس HTTP | لا يتم إجراء طلبات CORS عبر بروتوكولي HTTP أو HTTPS. | تأكد من أن الطلب تم تقديمه عبر البروتوكول الصحيح. |
هناك عدة طرق لحل أخطاء CORS. الطريقة الأكثر شيوعًا هي إضافة رؤوس CORS اللازمة على جانب الخادم. 'التحكم في الوصول-السماح-الأصل' يُحدد العنوان الموارد المسموح لها بالوصول إلى الخادم. يعني تعيين هذا العنوان إلى '*' السماح بجميع الموارد، ولكن لأسباب أمنية، لا يُنصح عادةً بهذا النهج. بل من الأفضل السماح بموارد محددة فقط. على سبيل المثال، سيسمح الأمر 'Access-Control-Allow-Origin: https://example.com' بالطلبات الواردة من 'https://example.com' فقط.
فيما يلي بعض النقاط الرئيسية الأخرى لمنع أخطاء CORS واستكشاف أخطائها وإصلاحها:
بالإضافة إلى التغييرات من جانب الخادم، يمكن إجراء بعض التعديلات من جانب العميل لحل أخطاء CORS. على سبيل المثال، قد يكون من الممكن إعادة توجيه الطلبات باستخدام خادم وكيل أو استخدام طرق تبادل بيانات بديلة مثل JSONP. مع ذلك، من المهم تذكر أن هذه الطرق قد تُسبب ثغرات أمنية. لذلك، الحل الأفضل عادةً ما يتعلق الأمر بضمان تكوين CORS الصحيح على جانب الخادم.
الموارد متعددة الأصول يُعدّ تهيئة CORS بشكل صحيح أمرًا بالغ الأهمية لضمان أمان تطبيقات الويب ووظائفها. قد يؤدي إعداد سياسة CORS بشكل غير صحيح إلى ثغرات أمنية والسماح بالوصول غير المصرح به. لذلك، من المهم توخي الحذر واتباع أفضل الممارسات عند تطبيق CORS.
| أفضل الممارسات | توضيح | أهمية |
|---|---|---|
| الحد الأقصى للأصول المسموح بها | التحكم في الوصول - السماح - الأصل أشر فقط إلى المجالات الموثوقة في الرأس. * تجنب الاستخدام. |
يزيد من الأمان ويمنع الوصول غير المصرح به. |
| استخدم معلومات الهوية عند الضرورة | لإرسال معلومات التعريف الشخصية مثل ملفات تعريف الارتباط أو رؤوس التفويض التحكم في الوصول - السماح - بيانات الاعتماد: صحيح يستخدم. |
يوفر الوصول إلى الموارد التي تتطلب المصادقة. |
| إدارة طلبات ما قبل الرحلة بشكل صحيح | خيارات معالجة الطلبات بشكل صحيح وتضمين الرؤوس المطلوبة (طرق السماح بالتحكم في الوصول, التحكم في الوصول - السماح - الرؤوس) يمد. |
الطلبات المعقدة (على سبيل المثال المعبود, يمسح) يضمن أن يتم ذلك بأمان. |
| تعامل مع رسائل الخطأ بعناية | قم بإبلاغ أخطاء CORS للمستخدم بطريقة مفيدة وتجنب الكشف عن نقاط الضعف الأمنية المحتملة. | ويحسن تجربة المستخدم ويقلل من المخاطر الأمنية. |
لزيادة أمنك، التحكم في الوصول - السماح - الأصل تجنب استخدام أحرف البدل (*) في العنوان. هذا يسمح لأي نطاق بالوصول إلى مواردك، وقد يسمح للمواقع الضارة بسرقة بياناتك أو التلاعب بها. بدلاً من ذلك، اذكر فقط النطاقات التي تثق بها وترغب في السماح لها بالوصول.
التحكم في الوصول - السماح - الأصل تكوين الرأس: على جانب الخادم، قم بإدراج المجالات المسموح بها فقط.التحكم في الوصول - السماح - بيانات الاعتماد ضع العنوان بشكل صحيح.خيارات الاستجابة بشكل مناسب لطلباتهم.فضلاً عن ذلك، طلبات ما قبل الرحلة من المهم أيضًا إدارتها بشكل صحيح. تستطيع المتصفحات التعامل مع بعض الطلبات المعقدة (على سبيل المثال، المعبود أو يمسح (مثل) قبل الإرسال إلى الخادم خيارات يُرسل الطلب. يجب أن يستجيب خادمك بشكل صحيح لهذا الطلب طرق السماح بالتحكم في الوصول و التحكم في الوصول - السماح - الرؤوس الرؤوس. هذا يسمح للمتصفح بإرسال الطلب الفعلي.
من المهم اختبار ومراقبة إعدادات CORS بانتظام. جرّب سيناريوهات مختلفة لتحديد السلوك غير المتوقع أو الثغرات الأمنية المحتملة. يمكنك أيضًا تحديد محاولات الوصول غير المصرح بها من خلال مراقبة سجلات الخادم. تذكر أن بناء تطبيق ويب آمن عملية مستمرة تتطلب تحديثات وتحسينات منتظمة. الموارد متعددة الأصول من خلال تكوين مشاركاتك باستخدام أفضل الممارسات هذه، يمكنك زيادة أمان تطبيقات الويب لديك بشكل كبير.
الموارد متعددة الأصول عند استخدام CORS، هناك عدة اعتبارات مهمة لضمان أمان تطبيقك وتشغيله بشكل صحيح. CORS هي آلية تسمح لتطبيقات الويب بتبادل البيانات من مصادر مختلفة، ولكن في حال تكوينها بشكل غير صحيح، فقد تؤدي إلى ثغرات أمنية خطيرة. لذلك، من المهم تهيئة سياسات CORS بعناية واتباع خطوات محددة لتجنب أي مشاكل محتملة.
قد تؤدي الأخطاء في إعدادات CORS إلى تعريض البيانات الحساسة للوصول غير المصرح به أو التعرض لهجمات خبيثة. على سبيل المثال، التحكم في الوصول - السماح - الأصل قد يؤدي تكوين رأس CORS بشكل غير صحيح إلى السماح بالطلبات من جميع المصادر. وهذا يُشكل خطرًا أمنيًا جسيمًا عند السماح بالطلبات من مصادر محددة فقط. يُلخص الجدول التالي الأخطاء الشائعة في تكوين CORS وعواقبها المحتملة.
| خطأ | توضيح | النتيجة |
|---|---|---|
التحكم في الوصول-السماح-الأصل: * يستخدم |
السماح بالطلبات من جميع المصادر. | تكمن المشكلة في قدرة المواقع الضارة على الوصول إلى البيانات. |
التحكم في الوصول - السماح - بيانات الاعتماد: صحيح مع التحكم في الوصول-السماح-الأصل: * يستخدم |
السماح بإرسال بيانات الاعتماد إلى كافة الموارد (محظورة بواسطة المتصفحات). | سلوك غير متوقع، مصادقة غير صحيحة. |
| السماح بطرق HTTP الخاطئة | السماح بجميع الطرق، بينما يجب السماح فقط بطرق معينة مثل GET أو POST. | نقاط الضعف المحتملة والتلاعب بالبيانات. |
| قبول الألقاب غير الضرورية | قبول كافة الألقاب، في حين ينبغي قبول الألقاب الضرورية فقط. | ثغرات أمنية ونقل بيانات غير ضرورية. |
من النقاط المهمة الأخرى التي يجب مراعاتها عند استخدام CORS هي التهيئة الصحيحة لآلية طلب الفحص المسبق. طلبات الفحص المسبق هي طلبات خيارات تُرسلها المتصفحات للتحقق من سياسات CORS الخاصة بالخادم قبل إرسال الطلب الفعلي إليه. إذا لم يستجب الخادم لهذه الطلبات بشكل صحيح، فسيتم حظر الطلب الفعلي. لذلك، يجب عليك التأكد من استجابة خادمك بشكل صحيح لطلبات الخيارات.
نقاط يجب مراعاتها
التحكم في الوصول - السماح - الأصل اضبط العنوان بشكل صحيح. اسمح فقط بالمصادر الموثوقة.التحكم في الوصول - السماح - بيانات الاعتماد كن حذرًا عند استخدام العنوان. تجنب استخدامه إلا للضرورة.يُعد استخدام أدوات تطوير المتصفحات لاستكشاف أخطاء CORS وإصلاحها مفيدًا للغاية. تساعدك هذه الأدوات في تحديد مصدر المشكلة من خلال عرض الأخطاء والتحذيرات المتعلقة بـ CORS. يمكنك أيضًا التحقق من سجلات الخادم للتأكد من تنفيذ سياسات CORS بشكل صحيح. تذكر أن إعداد سياسة CORS بشكل صحيح يُعد جزءًا أساسيًا من تعزيز أمان تطبيق الويب وتحسين تجربة المستخدم.
لماذا يعد CORS مهمًا وكيف يؤثر على عملية تطوير الويب؟
يُعزز نظام CORS أمان مواقع الويب من خلال منع وصول المصادر الضارة إلى البيانات الحساسة. يُساعد هذا على حماية معلومات المستخدم وسلامة التطبيق. في تطوير الويب، يضمن هذا النظام تجربة آمنة ومستقرة من خلال ضمان مشاركة الموارد بشكل مُتحكّم بين مختلف النطاقات. يُعدّ فهم هذه الآلية أمرًا بالغ الأهمية للمطورين لمعالجة الثغرات الأمنية المحتملة وضمان تطوير سلس للتطبيقات.
كيف تقوم المتصفحات بتنفيذ سياسات CORS وما هي رؤوس HTTP المستخدمة في هذه العملية؟
تُجري المتصفحات عمليات فحص CORS تلقائيًا عندما تطلب صفحة ويب موردًا من نطاق آخر. في هذه العملية، يُرسل المتصفح ترويسة "Origin" إلى الخادم. يستجيب الخادم بترويسة "Access-Control-Allow-Origin". يُحدد المتصفح مدى أمان الطلب بمقارنة قيم هذه الترويسات. بالإضافة إلى ذلك، تُستخدم ترويسات مثل "Access-Control-Allow-Methods" و"Access-Control-Allow-Headers" و"Access-Control-Allow-Credentials" لتحديد الطرق والترويسات وبيانات الاعتماد المطلوبة. يُعدّ التهيئة الصحيحة لهذه الترويسات أمرًا بالغ الأهمية لمنع مشاكل CORS.
ما هي الأسباب الأكثر شيوعًا لأخطاء CORS وكيف يمكنني اكتشافها؟
تشمل الأسباب الأكثر شيوعًا لأخطاء CORS التكوين الخاطئ لرأسية "Access-Control-Allow-Origin" في الخادم، والطلبات الصادرة من منافذ أو بروتوكولات مختلفة، وأخطاء طلبات الفحص المسبق، ومعالجة بيانات الاعتماد بشكل غير صحيح. يمكنك استخدام أدوات مطوري المتصفح لتحديد هذه الأخطاء. عادةً ما تشير رسائل الخطأ المعروضة في علامة تبويب "وحدة التحكم" إلى مصدر مشكلة CORS. يمكنك أيضًا التحقق من استجابات الخادم المتعلقة بـ CORS من خلال فحص رؤوس HTTP في علامة تبويب "الشبكة".
ما هو "طلب ما قبل الرحلة" ومتى يتم تشغيله؟
طلب الفحص المسبق هو طلب خيارات يُرسله المتصفح إلى الخادم ليسأله عن أساليب HTTP ورؤوسها المُستخدمة قبل إرسال الطلب الفعلي. يُفعّل هذا الطلب تحديدًا عند استخدام أساليب HTTP غير GET وPOST (مثل PUT وDELETE، إلخ) أو عند إضافة رؤوس مُخصصة. يجب أن يُقدّم الخادم استجابة CORS صحيحة لهذا الطلب، وإلا فسيتم حظر الطلب الفعلي.
هل من الممكن تعطيل أو التحايل على CORS وما هي المخاطر المحتملة؟
CORS هي آلية أمان تُطبّق على جانب المتصفح. من خلال تهيئة رؤوس CORS على جانب الخادم، يمكنك التحكم في الموارد المسموح لها بالوصول إليها. لا يُنصح عمومًا بتعطيل CORS تمامًا، إذ قد يُعرّض موقعك الإلكتروني لثغرات أمنية مُختلفة. مع ذلك، أثناء التطوير أو في بعض سيناريوهات الاختبار، يُمكن تجاوز CORS مؤقتًا من خلال إضافات المتصفح أو خوادم البروكسي. من المهم عدم استخدام هذه الحلول البديلة في بيئة الإنتاج.
ما هي نقاط الضعف المرتبطة بـ CORS وما هي التدابير التي يجب أن نتخذها لمنعها؟
تتضمن أكثر ثغرات CORS شيوعًا ضبط ترويسة "Access-Control-Allow-Origin" على "*" (منح الوصول للجميع)، مما يسمح للمواقع الضارة بالوصول إلى بيانات الاعتماد. لتجنب هذه الثغرات، يجب قصر ترويسة "Access-Control-Allow-Origin" على النطاقات المسموح بها فقط، واستخدام ترويسة "Access-Control-Allow-Credentials" بحذر، وتطبيق تدابير أمان إضافية من جانب الخادم (مثل حماية CSRF).
ما هي الطرق المتاحة لتكوين CORS على جانب الخادم وكيف يمكنني اختيار النهج الأكثر ملاءمة؟
هناك طرق مختلفة لتكوين CORS على جانب الخادم. تشمل هذه الطرق ضبط رؤوس HTTP يدويًا، أو استخدام برمجيات CORS الوسيطة، أو تهيئة خادم ويب (مثل Nginx أو Apache). يعتمد النهج الأنسب على احتياجات تطبيقك، والتقنية المستخدمة، والبنية التحتية لخادمك. مع أن استخدام البرمجيات الوسيطة يوفر عادةً حلاً أكثر مرونة وسهولة في الإدارة، إلا أن ضبط الرؤوس يدويًا قد يكون كافيًا للتطبيقات البسيطة.
كيف يمكنني إدارة إعدادات CORS عبر بيئات مختلفة (التطوير والاختبار والإنتاج)؟
يمكنك استخدام متغيرات البيئة أو ملفات التكوين لإدارة إعدادات CORS في بيئات مختلفة. في بيئة التطوير، يمكنك استخدام إعدادات أكثر مرونة (مثل "Access-Control-Allow-Origin: *") لتقليل أخطاء CORS، ولكن يجب عدم استخدام هذه الإعدادات في بيئة الإنتاج. في بيئة الاختبار، يجب استخدام إعدادات CORS أكثر صرامةً تُحاكي بيئة الإنتاج. في بيئة الإنتاج، يجب استخدام التكوين الأكثر أمانًا عن طريق تقييد ترويسة "Access-Control-Allow-Origin" على النطاقات المسموح بها فقط. يمكن تحقيق ذلك بإنشاء ملفات تكوين منفصلة لكل بيئة أو باستخدام متغيرات البيئة.
لمزيد من المعلومات: تعرف على المزيد حول CORS
اترك تعليقاً