اتخطّى للمحتوى

المرحلة 04 · الـ APIs والتكاملدرس 21 من 3415 دقيقة قراءةآخر تحديث:

Lesson 21 / 34

API Auth & Securityللموبايل والتكاملات.

مين بيقدر يوصل لإيه، وإزاي تتأكد. أنواع التوكنات والفرق بينها، الـ ACL وحماية الـ endpoints، والأخطاء الأمنية اللي بتتكرّر في تطبيقات الموبايل تحديداً.

● أمان أنواع التوكنات ACL سيناريو الموبايل

أمان الـ API في Magento 2 تلات طبقات: المصادقة بالتوكنات، والتفويض بالـ ACL في webapi.xml، والملكية اللي Magento مابيفحصهاش في كودك ولازم تعملها بـ UserContextInterface. Customer Token لتطبيقات العملاء، Integration Token للأنظمة الخارجية، والـ Admin Token مايتحطش في أي تطبيق عميل. استخدم /me و/mine، وارجّع 404 مش 403، واحسب أي قيمة مالية على السيرفر.

// ليه ده مختلف عن باقي المواضيع في المواضيع التانية، الخطأ بيسبب بطء أو سلوك غلط. هنا الخطأ بيسبب تسريب بيانات عملاء أو اختراق — وغالباً من غير ما تعرف إنه حصل. الفرق الجوهري إن الأخطاء الأمنية صامتة لحد ما تتستغل، فالمراجعة المسبقة هي الحماية الوحيدة.
◆ Part 1 — الفهم
01

المفاهيم الأساسية

تلات مفاهيم بيتخلطوا كتير، والخلط بينهم بيسبب ثغرات.

concept
Authentication — من أنت؟
التحقق من هوية الطالب. التوكن بيقول "أنا العميل رقم 42".
الأداةالتوكنات بأنواعها.
Authorization — مسموحلك بإيه؟
التحقق من الصلاحية. "العميل 42 مسموحله يشوف أوردراته هو".
الأداةالـ ACL والـ resources.
Ownership — البيانات دي بتاعتك؟
التحقق إن المورد المطلوب يخص الطالب فعلاً.
الأخطرMagento مابيعملهاش تلقائياً في كودك. دي مسؤوليتك.
تشبيه زي فندق. الـ authentication هو إثبات إنك نزيل (الكارت). الـ authorization إن الكارت بتاعك بيفتح الأدوار المسموحة. الـ ownership إن كارتك بيفتح أوضتك إنت مش أي أوضة في نفس الدور — ودي اللي الناس بتنساها.
!
أخطر ثغرة في APIs الموبايل هي نسيان الـ ownership. endpoint بيقول "هاتلي الأوردر رقم كذا" وبيتأكد إن الطالب عميل مسجّل — بس مابيتأكدش إن الأوردر ده بتاعه هو. النتيجة: أي عميل يقدر يقرا أوردرات كل العملاء بتغيير رقم في الطلب. القسم 08 فيه الحل بالكود.
• • •
◆ Part 2 — التوكنات والصلاحيات
02

أنواع التوكنات

أربع أنواع، وكل واحد لغرض مختلف.

token type
Customer Token
بيمثّل عميل واحد. صلاحياته محدودة ببياناته هو.
استخدمهفي تطبيق الموبايل لكل عميل مسجّل. ده اللي هتستخدمه أكتر حاجة.
Admin Token
بيمثّل مستخدم أدمن بصلاحياته.
حذرللعمليات الإدارية بس. متحطّهوش في تطبيق موبايل أبداً.
Integration Token
توكن دائم لنظام خارجي بصلاحيات محددة مسبقاً.
استخدمهللـ ERP والأنظمة اللي بتتكلم سيرفر لسيرفر.
Anonymous (بدون توكن)
مفيش تحقق — أي حد يقدر ينده.
خطرللبيانات العامة تماماً بس. القسم 07 بيفصّل.
إزاي التوكن بيتبعت
في الـ headerhttp
GET /rest/V1/customers/me HTTP/1.1
Host: store.com
Authorization: Bearer eyJraWQiOiIxIiwiYWxn...
Content-Type: application/json
!
الخطأ الأخطر على الإطلاق: استخدام admin token في تطبيق موبايل. التطبيق بيتنزّل على أجهزة الناس، والتوكن جوّاه ممكن يتستخرج بأدوات بسيطة. واللي هياخده هيبقى عنده صلاحيات أدمن كاملة على المتجر. ده اختراق كامل، مش ثغرة.
• • •
03

توكن العميل

الأساس في أي تطبيق موبايل.

إيميل + باسورد
توكن
كل الطلبات
1 — الحصول على التوكنbash
curl -X POST https://store.com/rest/V1/integration/customer/token \
  -H "Content-Type: application/json" \
  -d '{"username":"customer@mail.com","password":"..."}'

# الرد: نص التوكن
# "eyJraWQiOiIxIiwiYWxnIjoiSFMyNTYifQ..."
2 — استخدامهbash
# بيانات العميل الحالي
curl https://store.com/rest/V1/customers/me \
  -H "Authorization: Bearer TOKEN"

# سلة العميل الحالي
curl https://store.com/rest/V1/carts/mine \
  -H "Authorization: Bearer TOKEN"
الـ /me و/mine — ميزة أمنية مهمة

لاحظ إن الـ endpoints دي مابتاخدش رقم العميل. Magento بيستنتجه من التوكن نفسه. ده بيمنع تغيير الرقم للوصول لبيانات غيرك — لأن مفيش رقم أصلاً تغيّره.

i
القاعدة الذهبية: استخدم صيغ /me و/mine كل ما تقدر بدل ما تمرّر أرقام. دي أبسط وأقوى حماية من ثغرات الـ ownership — الحماية بتبقى في التصميم نفسه مش في كود بتفتكر تكتبه.
مدة الصلاحية

التوكنات ليها مدة انتهاء بتتحدد من: Stores → Configuration → Services → OAuth → Access Token Expiration. الافتراضي ساعة للأدمن وساعة للعميل (بالساعات).

!
لو التطبيق مش بيتعامل مع انتهاء التوكن، المستخدم هيتطرد فجأة أو هيشوف أخطاء غامضة. التطبيق لازم يمسك رد 401 ويعيد المصادقة تلقائياً — ودي من أكتر الشكاوى المتكررة في تطبيقات الموبايل.
تخزين التوكن في التطبيق

غلط

تخزين عادي (SharedPreferences / UserDefaults) — بيتقرا على جهاز مكسور الحماية.

صح

التخزين الآمن للنظام — Keychain في iOS وEncryptedSharedPreferences في Android.

• • •
04

الـ Integration Tokens

للأنظمة الخارجية — سيرفر لسيرفر.

إيه هو

توكن دائم (مالوش انتهاء) بصلاحيات محددة مسبقاً، بيتعمل من الأدمن لنظام خارجي معيّن — ERP، نظام شحن، أداة تسويق.

الإنشاء من الأدمن
  • System → Extensions → Integrations ثم Add New Integration.
  • اكتب اسم واضح — اسم النظام المستخدم مش "integration 1".
  • من تبويب API، اختار الصلاحيات المطلوبة بس.
  • احفظ، وبعدين اضغط Activate عشان تاخد التوكن.
!
في خطوة 3، متختارش "All". لو النظام الخارجي محتاج يقرا الأوردرات بس، ادّيله صلاحية الأوردرات بس. لو التوكن ده اتسرّب، الضرر بيبقى محدود بالصلاحيات دي — ودي الفكرة كلها.
الإنشاء بالكود
etc/integration/config.xmlxml
<?xml version="1.0"?>
<config>
  <integration name="ERP Sync">
    <email>erp@company.com</email>
  </integration>
</config>
etc/integration/api.xml — الصلاحياتxml
<?xml version="1.0"?>
<config>
  <integration name="ERP Sync">
    <resources>
      <!-- الصلاحيات المطلوبة بس -->
      <resource name="Magento_Sales::sales"/>
      <resource name="Magento_Sales::actions_view"/>
    </resources>
  </integration>
</config>
ليه بالكود أفضل

الصلاحيات بتبقى موثّقة في الـ git وبتتطبّق على كل بيئة. ولو حد وسّع الصلاحيات من الأدمن بالغلط، هتلاحظ الفرق عن الملف.

!
التوكنات دي مالهاش انتهاء — فلو اتسرّب واحد، بيفضل شغّال للأبد. غيّرهم دورياً، وألغِ أي تكامل مابقاش مستخدم فوراً من Integrations.
• • •
05

الـ ACL — الصلاحيات

إزاي تعرّف صلاحيات لموديولك.

إيه هو

شجرة صلاحيات. كل عملية في الأدمن أو الـ API مربوطة بـ resource، وأدوار المستخدمين بتاخد صلاحية على resources محددة.

etc/acl.xmlxml
<?xml version="1.0"?>
<config>
  <acl>
    <resources>
      <resource id="Magento_Backend::admin">
        <resource id="Vendor_Module::tickets"
          title="Tickets" sortOrder="50">

          <!-- صلاحية القراءة -->
          <resource id="Vendor_Module::tickets_view"
            title="View Tickets" sortOrder="10"/>

          <!-- صلاحية التعديل — منفصلة -->
          <resource id="Vendor_Module::tickets_manage"
            title="Manage Tickets" sortOrder="20"/>

        </resource>
      </resource>
    </resources>
  </acl>
</config>
ليه فصلت القراءة عن التعديل

عشان تقدر تدّي موظف صلاحية يشوف من غير ما يعدّل. لو resource واحد، الاختيار بيبقى "كل حاجة أو لا حاجة" — وده بيخلّي الفرق يدّوا صلاحيات أوسع من اللازم.

الاستخدام في webapi.xmlxml
<route url="/V1/tickets/:id" method="GET">
  <service class="Vendor\Module\Api\TicketRepositoryInterface"
    method="getById"/>
  <resources>
    <!-- لازم صلاحية القراءة -->
    <resource ref="Vendor_Module::tickets_view"/>
  </resources>
</route>
الفحص في الـ controllerphp
class Edit extends Action
{
    // Magento بيشيّك عليها تلقائياً قبل execute()
    public const ADMIN_RESOURCE = 'Vendor_Module::tickets_manage';

    public function execute()
    {
        // لو وصلنا هنا، الصلاحية اتأكدت
    }
}
!
لو نسيت ADMIN_RESOURCE في controller أدمن، Magento بيستخدم قيمة افتراضية عامة — يعني أي مستخدم أدمن يقدر يوصل للصفحة حتى لو دوره مالوش علاقة بالموديول. حدّدها دايماً.
• • •
◆ Part 3 — الحماية
06

حماية الـ endpoints

القواعد اللي تمشي عليها في كل endpoint تعمله.

كل endpoint لازم يعدّي على أربعة
  • مصادقة — مين الطالب؟ (التوكن)
  • تفويض — مسموحله بالعملية دي؟ (الـ ACL)
  • ملكية — المورد ده بتاعه؟ (كودك إنت)
  • تحقق من المدخلات — البيانات سليمة؟
غلط — مفيش فحص ملكيةphp
public function getTicket(int $ticketId): TicketInterface
{
    // الـ ACL أكّد إنه عميل مسجّل
    // بس مين قال إن التذكرة دي بتاعته؟
    return $this->ticketRepository->getById($ticketId);
}

// أي عميل يغيّر الرقم ويقرا تذاكر غيره
// GET /V1/tickets/1, /V1/tickets/2, /V1/tickets/3 ...
صح — فحص الملكيةphp
use Magento\Authorization\Model\UserContextInterface;
use Magento\Framework\Exception\NoSuchEntityException;

class TicketService
{
    public function __construct(
        private readonly TicketRepositoryInterface $repository,
        // بيديك هوية الطالب من التوكن
        private readonly UserContextInterface $userContext
    ) {}

    public function getTicket(int $ticketId): TicketInterface
    {
        $ticket = $this->repository->getById($ticketId);

        $callerId = (int) $this->userContext->getUserId();
        $callerType = $this->userContext->getUserType();

        // الأدمن يشوف كل حاجة
        if ($callerType === UserContextInterface::USER_TYPE_ADMIN) {
            return $ticket;
        }

        // العميل يشوف بتاعه بس
        if ((int) $ticket->getCustomerId() !== $callerId) {
            // مهم: نفس رسالة "مش موجود"
            throw new NoSuchEntityException(
                __('No such entity.')
            );
        }

        return $ticket;
    }
}
ليه "مش موجود" مش "ممنوع"

لو رجّعت 403 ممنوع، بتأكّد للمهاجم إن التذكرة دي موجودة فعلاً وبس مش بتاعته. لو رجّعت 404 مش موجود، مابيعرفش يفرّق بين رقم مش موجود ورقم بتاع غيره. ده اسمه منع تعداد الموارد.

i
الـ UserContextInterface هو الطريقة الصحيحة لمعرفة مين بينده الـ API. بيشتغل مع كل أنواع التوكنات، وبيديك النوع (عميل/أدمن/integration) والرقم.
• • •
07

مشكلة الـ anonymous

امتى مقبول وامتى كارثة.

شكل الـ route المفتوحxml
<route url="/V1/products/featured" method="GET">
  <service class="..." method="getFeatured"/>
  <resources>
    <resource ref="anonymous"/>
  </resources>
</route>

مقبول

بيانات الكتالوج العامة — منتجات، أقسام، صفحات محتوى. حاجة أي زائر يشوفها من الموقع أصلاً.

خطر

أي حاجة تخص عميل، أو أي عملية بتكتب بيانات، أو بتكشف معلومات داخلية.

الاختبار البسيط

اسأل نفسك: "لو نشرت رابط الـ endpoint ده على تويتر، فيه مشكلة؟" لو الإجابة أيوة، يبقى مينفعش يكون anonymous.

!
حتى مع الـ endpoints العامة المشروعة، فيه خطرين لازم تتعامل معاهم: الاستنزاف (حد بيسحب الكتالوج كله) وكشف بيانات زيادة (الـ endpoint بيرجّع حقول داخلية زي التكلفة أو الهامش). حدّد الحقول الراجعة صراحةً وحط حد للمعدّل.
اكتشاف الـ endpoints المفتوحة عندك
فحص سريعbash
# كل الـ routes المفتوحة في موديولاتك
grep -rn -B5 'ref="anonymous"' app/code/ \
  --include="webapi.xml"

# وفي الموديولات الخارجية كمان
grep -rln 'ref="anonymous"' vendor/ \
  --include="webapi.xml"
i
شغّل الأمرين دول على مشروعك دلوقتي. الأمر التاني غالباً هيطلّع نتايج من موديولات خارجية إنت مش عارف إنها فاتحة endpoints — وده أول حاجة تراجعها في أي تدقيق أمني.
• • •
08

أخطاء تطبيقات الموبايل

الأخطاء اللي بتتكرّر في السياق ده تحديداً.

mistake
1 · admin token في التطبيق
توكن أدمن مدفون في كود التطبيق عشان "يسهّل" الوصول.
الضرراختراق كامل للمتجر. الأخطر على الإطلاق. استخدم customer token.
2 · مفيش فحص ملكية
endpoint بياخد رقم من غير ما يتأكد إنه بتاع الطالب.
الضررأي عميل يقرا بيانات كل العملاء بتغيير رقم.
3 · كشف الـ quote id الرقمي
استخدام الرقم المتسلسل للضيوف بدل المعرّف المقنّع.
الضررالوصول لسلال الآخرين بتجربة أرقام. استخدم GuestCart.
4 · الثقة في بيانات العميل
التطبيق بيبعت السعر أو الخصم والسيرفر بيقبله.
الضررشراء بأي سعر. السعر يتحسب على السيرفر دايماً.
5 · مفيش معالجة لانتهاء التوكن
التطبيق مش بيمسك 401 ويعيد المصادقة.
الضررمش أمني بس بيخرّب التجربة. المستخدم بيتطرد فجأة.
6 · تخزين التوكن بدون تشفير
التوكن في تخزين عادي على الجهاز.
الضرربيتقرا على جهاز مكسور الحماية. استخدم التخزين الآمن للنظام.
الخطأ رقم 4 بالتفصيل — الثقة في المدخلات
غلط — بيثق في السعر الجايphp
public function addItem(int $productId, float $price)
{
    $item->setCustomPrice($price);  // من التطبيق!
    // العميل يقدر يبعت price = 0.01
}
صح — السعر من السيرفرphp
public function addItem(int $productId, int $qty)
{
    // السعر بيتقرا من المنتج نفسه
    $product = $this->productRepository->getById($productId);

    // Magento بيحسب السعر والخصومات
    $quote->addProduct($product, new DataObject([
        'qty' => $qty,
    ]));

    $quote->collectTotals();
}
!
القاعدة العامة: التطبيق بيبعت نوايا (عايز المنتج ده بالكمية دي)، مش حقائق (سعره كذا). أي رقم له قيمة مالية لازم يتحسب على السيرفر. التطبيق كود بيشتغل على جهاز مش بتاعك، فأي حاجة جاية منه ممكن تكون متلاعب فيها.
• • •
09

أمان GraphQL

مخاطر إضافية مش موجودة في REST.

ليه مختلف

في REST، كل endpoint بيرجّع شكل ثابت. في GraphQL، العميل بيحدد شكل الرد — وده بيفتح مخاطر جديدة.

risk
الاستعلامات المتداخلة
استعلام بيتداخل لعمق كبير ويستهلك موارد السيرفر.
الحلحدّ للعمق والتعقيد في الإعدادات.
الاستكشاف (introspection)
أي حد يقدر يسأل عن الـ schema كامل ويعرف كل العمليات.
الحلعطّلها في production لو مش محتاجها.
الـ N+1 في الـ resolvers
resolver بينده قاعدة البيانات لكل عنصر.
الحلالجلب المجمّع. مشكلة أداء بتتحوّل لباب استنزاف.
تسريب الحقول
الـ schema بيكشف حقول داخلية (التكلفة، الهامش).
الحلراجع كل حقل في الـ schema — هل العميل المفروض يشوفه؟
فحص الصلاحية في resolverphp
public function resolve(
    Field $field, $context, ResolveInfo $info,
    array $value = null, array $args = null
) {
    // التحقق إن العميل مسجّل
    if (!$context->getExtensionAttributes()->getIsCustomer()) {
        throw new GraphQlAuthorizationException(
            __('Authorization required.')
        );
    }

    // الرقم من السياق مش من الـ args
    $customerId = $context->getUserId();

    return $this->loadDataFor($customerId);
}
!
لاحظ السطر الأخير: الرقم بيتاخد من $context مش من $args. لو أخدته من الـ args، العميل يقدر يمرّر رقم غيره — وده نفس ثغرة الملكية بس في GraphQL.
• • •
◆ Part 4 — العملي
10

التقوية والإعدادات

إعدادات بتقلّل المخاطر فوراً.

setting
مدة انتهاء التوكن
Services → OAuth → Access Token Expiration
الضبطأقصر مدة عملية. كل ما قلّت، نافذة استغلال التوكن المسروق قلّت.
حد محاولات الدخول
Customers → Customer Configuration → Password Options
الضبطفعّل القفل بعد محاولات فاشلة — بيمنع تخمين كلمات السر.
HTTPS إجباري
General → Web → Use Secure URLs
الضبطإجباري. التوكن في طلب غير مشفّر = التوكن مكشوف.
2FA للأدمن
موجود ومفعّل افتراضياً في النسخ الحديثة.
الضبطمتعطّلهوش. ده أهم حاجة بتحمي لوحة الأدمن.
مسار أدمن مخصّص
Advanced → Admin → Admin Base URL
الضبطغيّره من /admin. مش حماية حقيقية بس بيقلّل الهجمات الآلية.
فحوصات سريعةbash
# هل HTTPS مفروض؟
bin/magento config:show web/secure/use_in_frontend
bin/magento config:show web/secure/use_in_adminhtml

# مدة التوكنات
bin/magento config:show \
  oauth/access_token_lifetime/customer

# التكاملات النشطة — راجعها
# System → Extensions → Integrations
!
لو المتجر بيشتغل بـ HTTP في أي مكان، كل التوكنات معرّضة للاعتراض على شبكات الواي فاي العامة — وده سيناريو واقعي جداً مع تطبيقات الموبايل تحديداً، لأن المستخدمين بيتنقلوا بين شبكات مش موثوقة.
• • •
11

قائمة المراجعة

امشي عليها قبل أي إطلاق.

لكل endpoint
  • محدّد له ACL resource مناسب، مش anonymous بالغلط؟
  • فيه فحص ملكية لو بيرجّع بيانات مرتبطة بعميل؟
  • بيستخدم /me أو /mine بدل تمرير أرقام؟
  • بيرجّع 404 مش 403 للموارد اللي مش بتاعة الطالب؟
  • بيتحقق من المدخلات ومابيثقش في أي قيمة مالية جاية من العميل؟
  • بيرجّع الحقول المطلوبة بس من غير بيانات داخلية؟
للمشروع كله
  • راجعت كل الـ anonymous في app/code و vendor؟
  • التكاملات النشطة كلها مستخدمة فعلاً وبأقل صلاحيات؟
  • HTTPS مفروض في كل مكان؟
  • الـ 2FA للأدمن مفعّل؟
  • مفيش admin token في أي تطبيق عميل؟
  • التطبيق بيخزّن التوكن في التخزين الآمن وبيعالج الـ 401؟
i
اعمل المراجعة دي مع فريق الموبايل مش لوحدك. نصف البنود بتخص جانب التطبيق (تخزين التوكن، معالجة 401، عدم إرسال الأسعار)، والجانب التاني عندك. الثغرات الأمنية بتعيش في الفراغ بين الفريقين — كل واحد فاكر إن التاني مغطّيها.
• • •
12

أسئلة الإنترفيو

الأمان بيتسأل فيه كتير في المستوى السنيور.

Q1إيه أنواع التوكنات في Magento وامتى تستخدم كل واحد؟
الإجابة: customer token لتطبيقات العملاء — صلاحيات محدودة ببيانات العميل. admin token للعمليات الإدارية ومينفعش يتحط في تطبيق عميل. integration token دائم للأنظمة الخارجية بصلاحيات محددة. وanonymous للبيانات العامة بس.
Q2إزاي تمنع عميل من قراءة بيانات عميل تاني؟
الإجابة: بفحص الملكية في كودي — أقارن رقم المالك بـ UserContextInterface::getUserId(). والأفضل استخدام صيغ /me و/mine اللي مابتاخدش رقم أصلاً. ومهم أرجّع 404 مش 403 عشان ما أأكّدش وجود المورد.
Q3ليه ماينفعش تستخدم admin token في تطبيق موبايل؟
الإجابة: التطبيق بيتنزّل على أجهزة المستخدمين، وأي حاجة جوّاه ممكن تتستخرج. واللي يستخرج التوكن هيبقى عنده صلاحيات أدمن كاملة — اختراق كامل مش ثغرة. الصح هو customer token لكل مستخدم.
Q4endpoint بياخد سعر من التطبيق — إيه المشكلة؟
الإجابة: التطبيق كود بيشتغل على جهاز مش بتاعنا، فأي قيمة منه ممكن تكون متلاعب فيها. العميل يقدر يبعت سعر 0.01. أي قيمة مالية لازم تتحسب على السيرفر — التطبيق يبعت نوايا (المنتج والكمية) مش حقائق.
Q5امتى يكون الـ anonymous route مقبول؟
الإجابة: لما البيانات عامة فعلاً — كتالوج، أقسام، محتوى. الاختبار: لو نشرت الرابط علناً، فيه مشكلة؟ وحتى وقتها لازم أحدد الحقول الراجعة وأحط حد للمعدّل عشان أمنع الاستنزاف.
Q6إزاي تأمّن سلة الضيف في API؟
الإجابة: بالمعرّف المقنّع من quote_id_mask مش بالرقم المتسلسل، وعن طريق واجهات GuestCart. الرقم المتسلسل بيتخمّن بسهولة، فكشفه بيسمح بالوصول لسلال الآخرين.

API Auth & Security ✓

دلوقتي فاهم الفرق بين المصادقة والتفويض والملكية، أنواع التوكنات وامتى تستخدم كل واحد، إزاي تحمي الـ endpoints، والأخطاء اللي بتتكرّر في تطبيقات الموبايل.

الخلاصة: الملكية مسؤوليتك مش مسؤولية Magento، وأي قيمة مالية تتحسب على السيرفر، و/me أأمن من تمرير الأرقام.

// magento 2 · api security · tokens · acl

خلّصت الدرس؟علّمه عشان تتابع تقدّمك في الكورس.

كاتب الدرس

Abdulrahman Masoud

عندك سؤال على الدرس أو محتاج مساعدة في مشروع Magento؟ كلّمني.

أسئلة شائعة

إيه أنواع التوكنات في Magento 2 وامتى أستخدم كل واحد؟

أربعة: Customer Token لتطبيقات العملاء وصلاحياته محدودة ببيانات العميل، Admin Token للعمليات الإدارية ومينفعش يتحط في أي تطبيق عميل، Integration Token دائم لنظام خارجي زي ERP بصلاحيات محددة من الأدمن، و anonymous من غير توكن للبيانات العامة بس. التوكن بيتبعت في header Authorization: Bearer.

إزاي أجيب Customer Token في Magento 2 REST API؟

POST على /rest/V1/integration/customer/token بالإيميل والباسورد، والرد نص التوكن. بعدها استخدمه في header Authorization: Bearer مع endpoints زي /V1/customers/me و /V1/carts/mine اللي بتستنتج العميل من التوكن من غير ما تمرّر رقم. مدة صلاحيته الافتراضية ساعة من Stores › Configuration › Services › OAuth، والتطبيق لازم يمسك 401 ويعيد المصادقة.

إزاي أمنع عميل من قراءة بيانات عميل تاني في الـ API؟

الـ ACL بيتأكد إن الطالب عميل مسجّل بس، مش إن المورد بتاعه. فحص الملكية مسؤوليتك: احقن UserContextInterface وقارن رقم المالك بـ getUserId()، والأدمن من getUserType() يشوف كل حاجة. لو المورد مش بتاعه ارمي NoSuchEntityException عشان يرجع 404 مش 403 ومايتأكدش إن المورد موجود. والأفضل صيغ /me و/mine اللي مابتاخدش رقم أصلًا.

امتى ينفع الـ route يكون anonymous في webapi.xml؟

لما البيانات عامة فعلًا زي المنتجات والأقسام وصفحات المحتوى، يعني حاجة أي زائر بيشوفها من الموقع أصلًا. أي حاجة تخص عميل أو بتكتب بيانات أو بتكشف حقول داخلية زي التكلفة مينفعش. وحتى للعام حدّد الحقول الراجعة وحط حد للمعدّل. راجع الـ endpoints المفتوحة عندك بـ grep -rn 'ref="anonymous"' app/code vendor --include=webapi.xml.

ليه مينفعش أستخدم Admin Token في تطبيق الموبايل؟

لأن التطبيق بيتنزّل على أجهزة المستخدمين، وأي توكن مدفون جوّاه ممكن يتستخرج بأدوات بسيطة. اللي هياخده هيبقى عنده صلاحيات أدمن كاملة على المتجر، وده اختراق كامل مش ثغرة. الصح Customer Token لكل مستخدم بيتخزّن في Keychain أو EncryptedSharedPreferences، والتطبيق يبعت نوايا زي المنتج والكمية مش حقائق زي السعر.

إزاي أعرّف صلاحيات ACL لموديول في Magento 2؟

في etc/acl.xml تحت Magento_Backend::admin عرّف resources بمعرّف زي Vendor_Module::tickets_view و tickets_manage منفصلين عشان تدّي موظف قراءة من غير تعديل. في webapi.xml اربط كل route بـ &lt;resource ref="..."/&gt;، وفي controllers الأدمن حدّد ADMIN_RESOURCE دايمًا، لأن من غيره Magento بيستخدم قيمة عامة وأي مستخدم أدمن يقدر يفتح الصفحة.

إيه المخاطر الأمنية الخاصة بـ GraphQL في Magento 2؟

الاستعلامات المتداخلة بعمق كبير بتستنزف السيرفر فحدّد العمق والتعقيد، والـ introspection بيكشف الـ schema كامل فعطّله في production، والـ N+1 في الـ resolvers بيتحوّل لباب استنزاف، وتسريب حقول داخلية. في الـ resolver خد رقم العميل من $context->getUserId() مش من $args، واتأكد من getIsCustomer() وإلا ارمي GraphQlAuthorizationException.