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

سواءًا كنت تعمل على صفحة هبوط لمنتج، لخدمة أو على صفحتك الشخصية من أجل عملك الحر، فإن كل الصفحات تشترك في عدة أمور بينها. اليوم سنشاهد دور كل واحد منها، وأنواعاها ومتى نستعلمها وما الفائدة منها. في هذا الدرس سنتطرق إلى 6 أجزاء مهمة في كل صفحة، وهي على الترتيب كالتالي: رأس الصفحة (Header) التعريف القيمة أو الشيء المميز محل الثقة نقطة التحويل (Call to action) ذيل الصفحة (Footer) سنستعين برسوم تويضحية في الطريق لفهم وشرح كل نقطة وكيف نستخدمها على أتم وجه، وفي نهاية الدرس ستكون قادرا على إنشاء صفحة هبوط أو صفحة شخصية بكل سهولة. لكن تذكر، لا صفحة تشبه الأخرى، ولا منتج يشبه الآخر، لذا قد لا يفيدك هذا الأمر تماما ولا يغطي احتياجياتك. ماهي صفحة الهبوط؟حتى نعرف ما الذي نقوم به، علينا أن نعرف أولا ماهي صفحة الهبوط، حسب موقع unbounce فإن صفحة هبوط هي: إذا، حسب هذا المفهوم، صفحة الهبوط تستطيع أن تكون صفحة لبيع كتاب، لبيع منتج ما، للتسجيل في خدمة، لطرح فكرة، لتقديم خدمة... كل هذه الأمور مختلفة، ولكنها تشترك في شيء واحد وهي أنّها تريد أن تحول الزائر إلى زبون. صفحات الهبوط تنقسم إلى قسمين اثنين، صفحات التحويل (Click Through) وصفحات التجميع (Lead Generation). صفحات التحويلصفحات التحويل هي كل الصفحات التي تحول المستخدم إلى صفحة أخرى، صفحات مثل هذه تحول المستخدم إلى متجر، إلى منصة البيع، أو بشكل عام هذه الصفحات تقدم المعلومات الشاملة للشيء، وليست مسؤولة عن تحويل المستخدم إلى زبون بشكل مباشرة، ولكن لها علاقة كبيرة بالأمر. صفحات التجميعصفحات التجميع هي الصفحات الأخرى، وتكون هذه الصفحات للتسجيل، للبيع مباشرة، للاشتراك، أو لملأ استمارة ما، أو للتواصل المباشرة، للحصول على نسخة الكترونية من كتاب أو منتج ما أو للتعريف بمنتج ما (مع هدف مشاركة المستخدم له عبر حساباته في الشبكات الاجتماعية). 1. رأس الصفحة (Header)من بين كل الأجزاء الأخرى، رأس الصفحة يكاد يكون أهم جزء في أيّ صفحة، فهو يستغل منطقة fold وهي المنطقة التي يراها المستخدم فور وصوله للصفحة بدون التمرير للأسفل، نشر أحمد مجدي في معمل ألوان مقالا ممتازا عن هذه النقطة. بهذه المنطقة بالتحديد، على المصمم أن يستعرض بعض النقاط المهمة، وهذه النقاط تكون كالتالي: الفكرة الموجزة تكون هذه الفكرة عادة عنوانا كبيرا بخط عريض في وسط الصفحة ليدل المستخدم على ماهية المنتج أو الخدمة (برنامج، أو خدمة ويب). أو عنوانا لكتاب مع شرح بسيط له وغلاف الكتاب: أو الاسم ومجال التخصص في حال كانت صفحة شخصية لمستقل أو شركة: في الحالات السابقة يتم إضافة شعار فوق الفكرة الموجزة، وفي حال صفحة شخصية يتم إضافة صورة شخصية، في حال منتج ككتاب أو شيء مشابه، يتم إضافة الغلاف. نقطة التحويل (Call to action) يتم إضافة هذا الجزء للهيدر عادة لأهميته. سنتكلم عن التفاصيل أكثر في جزئه المخصص، أما هنا فنشرح أهم النقاط. عادة هذا الجزء يكون زرا، أو مُدخلا (input). الزر يسمح للشخص بالانتقال إلى جزء الشراء، أو إلى صفحة التسجيل، أو إلى استمارة التواصل: وعندما لا يوجد شيء ليقود له هذا الجزء، يتم استعمال زر للتنقل إلى الجزء الذي بعده. يمكن أن يكون مُدخلا للاشتراك في قائمة بريدية من أجل التنبيه، أو للتسجيل في الخدمة، أو للحصول عل المنتج عبر إرساله في البريد. روابط التصفح (navigation) تكون روابط التصفح عادة موجزة ومسؤولة عن التصفح داخل الصفحة وليس من أجل روابط لخارج الصفحة، تحتوي القائمة على أقسام الصفحة (مثل التعريف، نقطة التحويل، التسعير...) يستحسن أن تكون متلصقة (sticky أو fixed) من أجل أن تكون في متناول اليد دوما. يوجد أكثر من نوع لذلك الجزء، تستطيع مثلا وضع زر للتسجيل بداخله: لإبقاء الزر قريبا من المستخدم دوما، عادة يحدث هذا للصفحات التي تبيع منتجا أو تقدم خدمة، بحيث في أيّ نقطة ما يكون المستخدم قد حصل على ما يكفي من المعلومات وهو بالتالي مستعد للطلب أو التواصل. 2. التعريفالتعريف هو جزء مهم في بعض الحالات ولكنه أمر اختياري في حالات أخرى، مثلا في صفحات لمنتج ما أو خدمة فيمكن الاستغناء عن التعريف حيث أنّه سيكون مدمجا في جزء "القيمة"، في حالات أخرى قد يكون مفيدا، في حال كنت مستقلا أو شركة أو خدمة جديدة، فالتعريف سيعطي الزائر فكرة عن الموقع أو الخدمة، التعريف يكون نصيا، التعريف التي يستخدم الصور محله يكون في جزء "القيمة". كمثال تعريف لمستقل يجب أن يحتوي على اسم المستقل، ربما البلد (في حالات معينة) ومجال الاختصاص وما ستقوم به بالتحديد عادة، نبذة عن الشخص وعن مراكز عمله السابقة ستعطي ثقة أكثر للعميل، حيث سيدرك أنه لا يتواصل مع آلة بل مع انسان فعلي. نفس الأمر ينطبق على الشركات، حاول أن تجعل الجزء قصيرا ومباشرا، لا أحد يملك الوقت لقراءة نص طويل. إذا وجدت أن "الفكرة الموجزة' رأس الصفحة تكفي لتشرح الفكرة فلا داعي لوضع تعريف. كما قلنا التعريف أمر اختياري تماما والعديد من الأشخاص يختارون عدم استخدامه. 3. القيمةالقيمة أو الشيء المميز هي أهم جزء في أيّ صفحة هبوط، فهي تشرح الخواص والمميزات لمنتج ما، أو خدمة ما، تقدم شرحا وافيا للكتاب، أو تقدم مجالات خبرة المستقل أو خدمات الشركة. أحيانا يختار المستقل تجاهل هذه المرحلة وجعل العمل يتكلم عن نفسه في جزء "محل الثقة" لكن ليتم هذا على المستقل أو يصف كامل مهاراته في الجزء الأسبق وهو "التعريف". بالنسبة للتطبيقات فهي تستغل هذه النقطة في عرض مميزات للتطبيق مثلا: أما عن المواقع أو خدمات الويب فهي تعرض المميزات على شكل نقاط مع أيقونة لكل جزء: 4. محل الثقةلأنّك لا تستطيع أن تقفز على شخص في الطريق من اللامكان ثم تخبره أنّ عليه أن يشتري منتجك المذهل أو يستأجرك للعمل، أنت أيضا لا تستطيع أن تطلب من زائر دخل لتوه الموقع أن يشتري منتجك، لذا عليك أن تبني ثقة لدى الزائر، وهنا يأتي جزء محل الثقة. محل الثقة قد تعني أكثر من شيء، ولكنها بالمجمل العام المكان الذي يُكسب الزائر ثقة في المنتج أو المشروع أو الشخص. ويكون له أكثر من شكل: العملاء: عادة ما يستخدم هذا بكثرة مع المستقلين ومع البرامج والخدمات. جزء العملاء يكون بأن يتم وضع مجموعة من شعارات أهم العملاء الذين مروا على العميل/منتج [figure 11]. يكسب العميل ثقة مباشرة في المنتج في حال رؤية شعارات شركات معروفة، هذا يعني له أنّ المنتج جيد وبالتالي يستحق المال الذي سيصرفهالتغطية الإعلامية: التغطية الإعلامية تكون عندما لا يوجد عملاء لاستخدامهم، أو عندما لا يكون من المنطقي استخدام عملاء (كتاب مثلا). في هذه الحالات يتم إضافة شعارات المواقع الإخبارية التي قامت بتغطية المنتج ويكون شكلها شبيها بشكل العملاء السابقيين، التغطية الإعلامية تُكسب قدر جيد من الثقة أيضا.الشهادات: الشهادات هي الخيار الثالث ومن أكثر الخيارات شيوعا، ببساطة تعتمد طريقة الشهادات على إدراج شهادات حقيقية من العملاء السابقين أو أشخاص جربوا الخدمة. أن تقول جملة عشوائية لوحدك، وأن تقول نفس الجملة ثم تُرفق أنها من قول العالم الفلاني أمران مختلفان، فالأخير يكسب ثقة أكبر في الجملة وبالتالي يجعلها ذات مصداقية، لذلك شهادات العملاء يجب أن تتبع نفس النسق، لذا ينصح أن يتم إضافة اسم صاحب الشهادة، وكذى صورته، حيث الصورة تجعل الزائر يعرف أنّه يسمع من شخص ما ربما قد رآه من قبل. وإضافة منصب العمل قد يكون مهما أيضا، أنت ستثق بمسؤول التصميم في شركة ما إذا كان يتكلم حول برنامج تصميم مثلا.الشبكات الاجتماعية: في حال لم يتوفر شيء مما سبق، فخيار آخر هو الشبكات الاجتماعية، لكن الأمر لا يصلح دوما، فعدد قليل من الصفحات تستفيد من الشبكات، ولكن إن كانت خدمتك أو موقعك يملك جمهوريا جيدا على الشبكات الاجتماعية، فمن المستحسن أن تضيف عدد المتابعين أو المعجبين من الشبكات الاجتماعية.صاحب المنتج: قد يبدو الأمر غريبا بعض الشيء لأول وهلة، ولكن إذا قرر بيل غيتس إنشاء صفحة لمنتجه فالأغلب أنه سيضيف صورته أو يجعل الأمر واضحا أنّه هو المالك . الأمر لا ينجح كثيرا لأننا لست دوما مشاهير، ولكن ربما كنت تسوق كتابا لكاتب معروف، فإضافة صورته ونبذة عنه تولد بعض الثقة أيضا. المشاريع السابقة: الأمر مخطط للمستقلين أو الشركات والوكالات بشكل خاص. المشاريع السابقة أو معرض الأعمال (Portfolio) هو أهم جزء في صفحة هبوط لمستقل، أن تقول أنّك مصمم بارع، وأن تظهر للزائر أنّك مصمم بارع بعرض أمثلة حقيقية هما أمران مختلفان. النمط السائد في عرض في المشاريع هو على شكل مربعات (grid) ولكن أنت حر بعرضها بأيّ طريقة تشاء.5. نقطة التحويل (Call to action)يأتي أهم جزء في كل الصفحات، أو كما يقول المثل الشعبي (الزبدة). فكل ما سبق كان لتحضير الزائر لهذه النقطة بالتحديد. لقد عرفت المنتج، أعطيت قيمته الفعلية، وبنيت الثقة لدى الزائر، تأتي النقطة التي يحين فيها تحويل الزائر إلى زبون، عادة هذا الجزء يكون زرا يقود لصفحة للتسجيل، أو لتحميل ملف ما، لإدخال معلومات للتسجيل في نشرة، جدول للاشتراكات. دعنا نشاهد أشكاله المختلفة: الزر: هذا الشكل هو الأكثر شيوعا وهو يتكون من زر كبير نسبيا، ويكون واضحا ويملك لونا مختلفا عن بقية العناصر حتى يستقل عنهم، يجب أن يكون بعبارة واضحة وغير خادعة للزائر، كأن تعرض فترة تجريبية وعندما يسجل الزائر لا يجد شيئا. العبارة يجب أن تكون لطيفة وغير عدائية، عبارات مثل "اشتري الآن" أو "حمل الكتاب" أو "سجل معنا" أو "تواصل" هي عبارات معتادة ولا تقدم الكثير من الحماس أو الرغبة للزبون لذا عليك أن تجرب عبارات تبدو وكأنها صدرت من انسان أو أقل عدائية مثل "هيا لنبني شيئا معا". اللون شيء مهم في كل زر، إلا أذا كنت ملزما بلون واحد لهوية الموقع أو المنتج، فعليك أن تختار الألوان بحذر، في تجربة قام بها موقع Performable وُجد أن تغيير لون الزر من الأخضر إلى الأحمر رفع نسبة التحويل (وهي عدد الزبائن على عدد الزوار) بنسبة 21% حيث أنّ اللون الأحمر يصنع شعورا بالعجلة ويَبرز أكثرمن بقية الألوان، والقاعدة العامة هي أنّ كل الألوان الساخنة (أحمر، برتقالي، أصفر، بنفسجي محمر...) مرحب بها. استمارة: وهو النوع الثاني الأكثر شيوعا وهو يتكون من استمارة يملأها الزائر من أجل الاشتراك في نشرة بريدية، أو من أجل الاشتراك في الخدمة، أو من أجل التواصل الجداول: شكل آخر شائع هو الجداول، فهي تسمح لك بعرض خطط الاشتراك، الاستضافة، باقات الشراء، وأيّ شيء تستطيع أن تبيعه في أكثر من باقة بأكثر من سعر، عادة يتم التركيز على العرض أو الباقة الأكثر شيوعا ووضعه في المنتصف وتمييزه عن البقية. 6. ذيل الموقع (Footer)ذيل الموقع لا تكون له أهمية كبيرة في بعض الصفحات، بعض الصفحات تختار أن تزيله تماما لأنها تريد أن ينصب تركيز الزائر على جزء التحويل فحسب. إذا كانت الصفحة هي تقديما لموقع ما، فالأحرى أن تضيف الذيل لتضع فيه روابط ترسل إلى أماكن أخرى، إلى جانب الصفحات الاجتماعية نظرة على صفحات حقيقيةفي هذا الجزء سنلقي نظرة على صفحات هبوط من الواقع، وكيف طبقت القواعد البسيطة العامة. صفحة كتاب Zero to oneكتاب Zero to one كتاب رائع قد سبق وأن قرأته، وكتاب رائع كهذا لابد أنّه سيملك صفحة رائعة لبيعه: Zero to One book. رأس الصفحة مباشر ويحتوي أهم المعلومات المتوقعة، فهو يحتوي على روابط للتصفح داخل الصفحة مثل معلومات حول الكتاب وحول صاحبه، الواجهة تملك صورة لغلاف الكتاب إلى جانب سطر تشويقي للكتاب، مع وجود زرين، أول زر وهو أهمهم ويعمل بصفته زر Call to action من أجل شراء الكتاب، الزر الثاني هو من أجل قراءة مقتطف من الكتاب بشكل مجاني. عند النزول تحصل على شهادات حول الكتاب من شخصيات معروفة وهذا لبناء الثقة حول المنتج. الموقع مقسم إلى أكثر من صفحة للتوزيع الجيد للمحتوى، مع تواجد جزء التحويل (call to action) أسفل كل صفحة لضمان وجوده قرب المستخدم دوما. تطبيق التصميم InvisionInvision هو منصة وتطبيق لصنع التصاميم الأولية (prototype) جنبا إلى جنب مع فريقك. في الأغلب ستتوقع تصميما ممتازا من منصة للتصميم، وهذا ما ستحصل عليه مع صفحة هبوط تطبيق Invision. رأس الصفحة يقدم أهم العناصر اللازمة لأيّ زائر، جزء التصفح يملك روابطا تأخذك إلى أجزاء مهمة في المنصة إلى جانب زر بارز للتسجيل. تحتوي الصفحة على عنوان كبير يصف المنصة إلى جانب سطر آخر للشرح. مع وضع زر CTA. بالنزول نجد مميزات المنصة وإلى جانب كل واحدة منها شهادة أحد الزبائن إلى جانب شعار شركته من أجل بناء الثقة في كلامه. في الأسفل نجد جزء بناء الثقة حيث يقوم التصميم بعرض أهم العملاء وقصصهم مع التطبيق. أخيرا يتم التطرق إلى جزء التحويل حيث أنّه استمارة للاشتراك في التطبيق خاتمةفي هذه المقالة تطرقنا إلى مامعنى صفحة هبوط، وإلى أهم الأساليب والعناصر في كل صفحة، كما عرضنا بعض الأمثلة الناجحة من الحياة اليومية. في المقالين القادمين سنقوم بتصميم وبناء صفحة هبوط خاصة بنا باتباع ما تكلمنا عنه هنا.

OAuth 2 هو آليّة للتّرخيص تسمح للتطبيقات بطلب وصول محدود إلى حسابات المستخدمين في خدمات HTTP، مثل Facebook وGitHub وDigitalOcean. يعمل OAuth 2 بتوكيل الخدمة المستضيفة لحساب المستخدم باستيثاق هذا الحساب، ثمّ السّماح للتطبيقات الخارجيّة بالوصول إلى حساب المستخدم هذا. يوفّر OAuth 2 مسارًا لترخيص تطبيقات الويب وتطبيقات سطح المكتب والأجهزة المحمولة. هذا الدّرس موجّه لمطوّري التّطبيقات، وهو يُلقي الضّوء على أدوار OAuth 2 وأنواع الرُّخَص المتاحة، وكذلك يستعرض مجالات استخدامه وسير عمليّة التّرخيص. لنبدأ بالتّعرّف على أدوار OAuth. أدوار OAuth يُحدِّد OAuth أربعة أدوار: مالك المحتوى العميل خادوم المحتوى خادوم التّرخيص سنُفصّل كلًّا من هذه الأدوار في الفقرات التّالية. مالك المحتوى: المستخدم مالك المحتوى هو المستخدم الذي يُرخِّص لتطبيقٍ الوصول إلى حسابه. وصول التّطبيق إلى حساب المستخدم محدودٌ "بنطاق" (scope) الترخيص الممنوح (مثلاً: صلاحيّة القراءة والكتابة). خادوم المحتوى/التّرخيص: الواجهة البرمجيّة (API) يستضيف خادوم المحتوى حسابات المستخدمين المحميّة، ويتحرّى خادوم التّرخيص هويّة المستخدم ثمّ يمنح التّطبيق رمز وصول (access token). من وجهة نظر مطوّر التّطبيقات، فإنّ الواجهة البرمجيّة للخدمة تؤدّي كلا الدّورين، دور خادوم المحتوى ودور خادوم التّرخيص. سنُشير إلى هذين الدّورين مجتمعين على أنّهما دور الخدمة أو الواجهة البرمجيّة. العميل: التّطبيق العميل هو التّطبيق الّذي يريد الوصول إلى حساب المستخدم، وقبل أن يستطيع ذلك، يجب أن يحصل على "ترخيص" المستخدم، وعلى هذا التّرخيص أن يُصادَق من الواجهة البرمجيّة. سير البروتوكول نظريًّا بعد أن تعرّفنا على أدوار OAuth، دعونا نلقِ نظرةً على المخطّط التالي، والذي يبيّن كيف تتفاعل هذه الأدوار فيما بينها: وفيما يلي شرح أكثرُ تفصيلًا للخطوات المُبيّنة في المُخطّط: يطلب التطبيق رخصةً للوصول إلى الخدمة من المستخدم إن رخّص المستخدم الطّلب، فإنّ التطبيق يحصل على إذن بالتّرخيص يطلب بعدها التطبيق رمز وصول (access token) من خادوم التّرخيص (الواجهة البرمجيّة) مُقدّمًا ما يُثبت هوّيته مع إذن التّرخيص الّذي حصل عليه. إن كانت هويّة التّطبيق موثّقة وإذن التّرخيص سليمًا، أصدر خادوم التّرخيص (الواجهة البرمجيّة) رمز وصول (access token) يمنحه للتّطبيق، لتكتمل حينئذٍ عمليّة الترخيص. يطلب التّطبيق من خادوم المحتوى (الواجهة البرمجيّة) المحتوى المطلوب، مُقدّمًا رمز الوصول الّذي حصل عليه. إن كان رمز الوصول سليمًا، قدّم خادوم المحتوى (الواجهة البرمجيّة) المحتوى المقصود للتطبيق قد يختلف مسار العمليّة الفعليّ بحسب نوع الرّخصة المُستخدمة، ولكن هذه هي الفكرة العامّة. سنستعرض أنواع الرُّخَص المُختلفة في فقرة لاحقة. تسجيل التّطبيق قبل استخدام OAuth في تطبيقاتك، عليك تسجيل التّطبيق في الخدمة المعنيّة. يجري التسجيل عادةً من خلال نموذج في قسم المُطوّرين أو الواجهة البرمجيّة في موقع الخدمة على الويب، حيث ينبغي عليك تقديم البيانات التالية (وربّما معلومات أخرى عن تطبيقك): اسم التّطبيق موقع التّطبيق رابط إعادة الّتوجيه (Redirect URL) أو الاستدعاء الرّاجع (Callback URL) تُعيد الخدمة توجيه المستخدم إلى رابط إعادة التّوجيه الّذي توفّره بعد ترخيصه لتطبيق (أو رفضه)، وعليه فإنّ هذا الرابط هو المسؤول عن التّعامل مع رموز الترخيص أو رموز الوصول (access tokens). مُعرّف العميل وكلمة سرّ العميل ستمنحك الخدمة بعد تسجيل تطبيقك "وثائق اعتماد العميل" المؤلّفة من معرّف العميل وكلمة سرّ العميل. معرّف العميل هو سلسلة من الحروف مكشوفة للعموم تستخدمها الواجهة البرمجيّة للخدمة لتحديد هويّة التّطبيق، ولبناء روابط التّرخيص المُقدّمة للمستخدمين. أمّا كلمة سر العميل فتُستخدم للاستيثاق من هويّة التّطبيق بالنّسبة للواجهة البرمجيّة للخدمة عندما يطلب التّطبيق الوصول إلى حساب المُستخدم، ويجب أن تبقى سرّيّة بين التّطبيق والواجهة البرمجيّة. إذن التّرخيص في فقرة "سير البروتوكول نظريًّا"، تبيّن الخطوات الأربع الأولى كيفيّة الحصول على إذن بالتّرخيص ورمز للوصول. يعتمد نوع الإذن على طريقة طلب التّطبيق للتّرخيص، وأنواع الأذون الّتي تدعمها الواجهة البرمجيّة. يعرّف OAuth 2 أربعة أنواع من أذون التّرخيص، يمكن الاستفادة من كلّ منها في حالات مُختلفة: رمز التّرخيص (Authorization Code): تستخدمه التّطبيقات الّتي تعمل على الخواديم ضمنيّ (Implicit): تستخدمه تطبيقات الويب وتطبيقات الأجهزة المحمولة (أي التّطبيقات الّتي تعمل على جهاز المُستخدم) كلمة مرور مالك المحتوى: تستخدمها التّطبيقات الموثوقة، كتلك الّتي تتبع للخدمة ذاتها كلمة مرور العميل: تستخدم في حالة الوصول للواجهة البرمجيّة للتّطبيقات سنشرح أنواع الأذون وحالات استخدامها بالتّفصيل في الفقرات التّالية. الإذن من نوع "رمز الترخيص": هذا النّوع من الأذون هو الأكثر استخدامًا لأنّه مُصمّم للتطبيقات الّتي تعمل على الخواديم، حيث لا يُكشف النّص المصدريّ للتّطبيق للعموم، وحيث يمكن الاحتفاظ بسرّيّة كلمة سرّ العميل بصورة تامّة. ويعتمد سير التّرخيص هنا على إعادة التّوجيه، ممّا يعني أنّه على التّطبيق أن يكون قادرًا على التّفاعل مع وكيل المستخدم (كمتصفّح الويب الّذي يستخدمه) وعلى استقبال رموز التّرخيص الّتي توفّرها الواجهة البرمجيّة والّتي تمرّ من خلال وكيل المستخدم. سنشرح الآن سير عمليّة التّرخيص في هذا النّوع من الأذون: سير التّرخيص بالرّمز الخطوة 1: رابط رمز الترخيص يُعطى المُستخدم في البداية رابطًا لرمز التّرخيص يُشبه هذا: https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read فيما يلي شرحٌ لمكوّنات الرابط: https://cloud.digitalocean.com/v1/oauth/authorize: نقطة الوصول إلى قسم التّرخيص في الواجهة البرمجيّة client_id=client_id: مُعرّف العميل للّتطبيق (كيفيّة تحديد الواجهة البرمجيّة لهويّة التّطبيق) redirect_uri=CALLBACK_URL: المكان الّذي تعيد الخدمة توجيه وكيل المستخدم إليه بعد منح رمز الترخيص response_type=code: يُبيّن أنّ تطبيقك يطلب إذنًا بالحصول على رمز ترخيص scope=read: يُعيّن مستوى الوصول الّذي يطلبه المُستخدم الخطوة 2: يُرخّص المستخدم التّطبيق عندما ينقر المُستخدم الرّابط، يجب عليه أوّلًا تسجيل الدّخول إلى الخدمة، وذلك للتّحقق من هويّة المُستخدم (ما لم يكن قد سجّل دخوله من قبل). ثم تعرض عليه الخدمة ترخيص أو رفض وصول التّطبيق إلى حسابه. فيما يلي مثال عن صفحة ترخيص التّطبيق: هذه الصّورة مُلتقطة من صفحة ترخيص DigitalOcean، ونرى فيها التّطبيق "Thedropletbook App" يطلب إذنًا بقراءة حساب المُستخدم "manicas@digitalocean.com". الخطوة 3: يتلقّى التطبيق رمز التّرخيص إذا نقر المُستخدم "Authorize Application"، فإنّ الخدمة تُعيد تحويل وكيل المستخدم إلى رابط إعادة التّوجيه الّذي حدّده التّطبيق أثناء تسجيل المُطوِّر له، وتُرفق الخدمة مع الرّابط رمز التّرخيص. مثال على الرّابط (مُفترضين أنّ التّطبيق هو "dropletbook.com"): https://dropletbook.com/callback?code=AUTHORIZATION_CODE الخطوة 4: يطلب التّطبيق رمز الوصول (Access Token) يطلب التّطبيق من الخدمة رمز وصول، مُمرّرًا لها رمز التّرخيص مع تفاصيله، بما في ذلك كلمة سرّ العميل، والّتي تُرسل جميعها إلى رابط الحصول على رمز الوصول الخاصّ بالخدمة. فيما بلي مثال على طلب POST يُرسل إلى رابط رمز الوصول في DigitalOcean: https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL الخطوة 5: يتلقّى التّطبيق رمز الوصول إن كان التّرخيص سليمًا، فإنّ الواجهة البرمجيّة تردّ على الطّلب بجواب يحوي رمز الوصول (مع رمز إعادة تجديد الرّخصة، غير إلزاميّ) إلى التّطبيق. يبدو الجواب مثل هذا: {"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}} أصبح التّطبيق الآن مُرخّصًا! وبإمكانه استخدام الّرمز للوصول إلى حساب المُستخدم عن طريق الواجهة البرمجيّة للخدمة، محدودًا بنطاق الوصول، إلى أن تنتهي مدّة الرّمز أو يُسحب التّرخيص. في حال أُصدر رمز إعادة تجديد الرّخصة (refresh token)، فبإمكان التّطبيق استخدامه للحصول على رمز وصول جديد في حال انتهى مدّة السّابق. الإذن الضّمنيّ يُستخدم نوع الأذون الضّمنيّ في تطبيقات الويب (التي تعمل في المتصفح) وتطبيقات الأجهزة المحمولة، حيث يصعب ضمان سرّية كلمة سرّ العميل. يقوم هذا النّوع من الأذون على مبدأ إعادة التّوجيه أيضًا، إلّا أنّ رمز الوصول يُعطى لوكيل المُستخدم ليقوم بدفعه إلى التّطبيق، وبهذا قد يُكشف للمُستخدم وللتّطبيقات على جهازه. لا يتضمّن سير التّرخيص في هذا النّوع هوّيّة التّطبيق، بل يعتمد على رابط إعادة التّوجيه (الّذي سُجّل في الخدمة) للوصول إلى هذا الهدف. لا يدعم هذا النّوع من الأذون رموز إعادة تجديد التّرخيص. يسير التّرخيص في هذا النّوع كما يلي: يُطلب من المُستخدم ترخيص التّطبيق، ثمّ يُمرّر خادوم التّرخيص رمز الوصول إلى وكيل المُستخدم، الّذي ينقله بدوره إلى التّطبيق. إن كُنت مُهتمًّا بالتّفاصيل، فتابع القراءة. سير التّرخيص الضّمنيّ الخطوة 1: رابط التّرخيص الضّمني يُعرض على المُستخدم رابط التّرخيص، الّذي يطلب رمزًا من الواجهة البرمجيّة، يبدو هذا الرّابط مُشابهًا لرابط رمز التّرخيص، باستثناء أنّه يطلب رمز token بدلًا من code (لاحظ نوع الجواب المطلوب "token"): https://oauth.example.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص الضّمني، لذا ذكرنا رابطًا وهميًّا "oauth.example.com". الخطوة 2: يرخّص المُستخدم التّطبيق عندما ينقر المُستخدم الرّابط، يجب عليه أوّلًا تسجيل الدّخول إلى الخدمة، وذلك للتّحقق من هويّة المُستخدم (ما لم يكن قد سجّل دخوله من قبل). ثم تعرض عليه الخدمة ترخيص أو رفض وصول التّطبيق إلى حسابه. فيما يلي مثال عن صفحة ترخيص التّطبيق: نرى في الصّورة التّطبيق "Thedropletbook App" يطلب إذنًا بقراءة حساب المُستخدم "manicas@digitalocean.com". الخطوة 3: يتلقّى وكيل المُستخدم رمز الوصول مع رابط إعادة التّوجيه إذا نقر المُستخدم "Authorize Application"، فإنّ الخدمة تُعيد تحويل وكيل المستخدم إلى رابط إعادة التّوجيه الّذي حدّده التّطبيق أثناء تسجيل المُطوِّر له، وتُرفق الخدمة مع الرّابط رمز الوصول. مثال على الرّابط: https://dropletbook.com/callback#token=ACCESS_TOKEN الخطوة 4: يتبع وكيل المُستخدم مسار إعادة التّوجيه يتبع وكيل المُستخدم رابط إعادة التّوجيه مع احتفاظه برمز الوصول. الخطوة 5: يُرسل التّطبيق نصًّا برمجيًّا لاستخراج رمز الوصول يُعيد التّطبيق صفحة ويب تحوي نصًّا برمجيًّا بإمكانه استخراج رمز الوصول من رابط إعادة التّوجيه الكامل الّذي احتفظ به وكيل المُستخدم. الخطوة 6: يُمرّر رمز الوصول إلى التّطبيق يُنفّذ وكيل المستخدم النّصّ البرمجيّ ويُمرّر رمز الوصول المُستخرَج إلى التّطبيق. أصبح التّطبيق الآن مُرخّصًا! وبإمكانه استخدام الّرمز للوصول إلى حساب المُستخدم عن طريق الواجهة البرمجيّة للخدمة، محدودًا بنطاق الوصول، إلى أن تنتهي مدّة الرّمز أو يُسحب التّرخيص. ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص الضّمني، لذا ذكرنا رابطًا وهميًّا "oauth.example.com". الإذن بالوصول إلى كلمة مرور مالك المُحتوى في هذا النّوع من التّرخيص، يزوّد المستخدم التّطبيق مباشرةً باسم حسابه وكلمة مروره، ليستخدمها للحصول على رمز الوصول من الخدمة. يجب استخدام هذا النّوع من الأذون في الخوادم عندما لا تكون الأنواع الأخرى مُناسبة فقط. ويجب استخدامه فقط في حال كان التّطبيق موضع ثقة المُستخدم، كأن يكون تابعًا للخدمة ذاتها، أو أن يكون نظام التّشغيل على حاسوب المُستخدم هو ما يطلب الوصول. سير التّرخيص بالحصول على كلمة مرور المُستخدم بعد أن يُعطي المستخدم كلمة مروره للتّطبيق، يطلب التّطبيق رمز الوصول من خادوم التّرخيص. يُشبه طلب POST ما يلي: https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID إن كان اسم المُستخدم وكلمة المرور صحيحين، يُعيد خادوم التّرخيص رمز وصول للتّطبيق ويُصبح التّطبيق مُرخّصًا! ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص بالحصول على كلمة المرور، لذا ذكرنا رابطًا وهميًّا "oauth.example.com". الإذن بالوصول إلى كلمة مرور العميل في هذا النّوع من التّرخيص، يوفّر التّطبيق طريقة للوصول إلى حسابه الخاصّ على الخدمة. من الأمثلة الّتي يكون فيها استخدام هذا النّوع مُفيدًا أن يرغب التّطبيق بتحديث وصفه أو رابط إعادة التّوجيه المُسجّلين في الخدمة، أو أن يصل إلى بيانات أخرى حول حسابه على الخدمة عن طريق الواجهة البرمجيّة. سير التّرخيص بالحصول على كلمة مرور العميل يطلب التّطبيق رمز الوصول مُرسلًا مُعرَّفه وكلمة مروره إلى خادوم التّرخيص، فيما يلي مثال عن طلب POST: https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET إن كان مُعرّف التّطبيق وكلمة مروره صحيحين، يُعيد خادوم التّرخيص رمز وصول للتّطبيق ويُصبح التّطبيق مُرخّصًا باستخدام حسابه الخاصّ! ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص بالحصول على كلمة مرور العميل، لذا ذكرنا رابطًا وهميًّا "oauth.example.com". مثال على استخدام رمز الوصول بعد أن يحصل التّطبيق على رمز الوصول، إمكانه استخدام هذا الّرمز للوصول إلى حساب المُستخدم عن طريق الواجهة البرمجيّة للخدمة، محدودًا بنطاق الوصول، إلى أن تنتهي مدّة الرّمز أو يُسحب التّرخيص. فيما يلي مثال عن طلب يُرسل للواجهة البرمجيّة للخدمة باستخدام curl، لاحظ أنّه يتضمّن رمز الوصول: curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT" على فرض أنّ رمز الوصول سليم، فإنّ الواجهة البرمجيّة تُعالج الطّلب حسب ما صُمِّمت؛ وإلّا أعادت الواجهة خطأ "invalid_request"، كما يحدث عند انتهاء مدّة التّرخيص أو استخدام رمز خاطئ. سير الحصول على رمز إعادة تجديد الرُخصة يؤدّي استخدام رمز وصول بعد انتهاء مدّة صلاحيّته إلى "خطأ رمز غير سليم (Invalid Token Error)". في هذه النّقطة، يمكن استخدام رمز إعادة تجديد الرّخصة في حال أُصدَر مع رمز الوصول للحصول على رمز وصول جديد من خادوم التّرخيص. فيما يلي مثال على طلب POST للحصول على رمز وصول جديد مُستخدمين رمز إعادة تجديد: https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN الخاتمة إلى هناك نكون قد وصلنا إلى ختام دليل OAuth. من المُفترض أن لديك الآن فكرة جيّدة عن البروتوكول وكيف يعمل، ومتى يمكن استخدام كلّ نوع من الأذون. إذا أردت تعلّم المزيد عن OAuth 2، اطّلع على هذه المصادر القيّمة (بالإنكليزيّة): How To Use OAuth Authentication with DigitalOcean as a User or Developer How To Use the DigitalOcean API v2 The OAuth 2.0 Authorization Framwork ترجمة (بشيء من التّصرّف) لمقال Introduction to OAuth 2 لصاحبه Mitchell Anicas.

إذا التقى شخصان في قرى الهيمالايا، حيِّا أحدهما الآخر قائلًا: "هل جسدك معافى؟" وأما في اليابان فقد ينحنيان أحيانًا، وفي عُمان يطبع كلّ منهما قبلة على أنف الآخر بعد التصافح، في كمبوديا وتايلاند، يضمّ كلّ منهما يديه وكأنّه يدعو. كل هذه الوسائل هي "بروتوكولات" للتواصل، أي سلسلة بسيطة من الرموز ذات المعنى والّتي تمهّد لتبادل حديث مُفيد. في عالم الويب، لدينا بروتوكول فعّال جدًّا على مستوى التّطبيقات يُمهّد الحواسيب حول العالم لتبادل الأحاديث النّافعة، واسمه Hypertext Transfer Protocol، أو HTTP اختصارًا؛ وهو بروتوكول يُصنّف ضمن طبقة التّطبيقات فوق TCP/IP، وهو أيضًا بروتوكول للتواصل. كثيرًا ما يغيب شرح HTTP في دروس التصميم والتطوير للويب، وهذا أمرٌ مُخزٍ: ففهمه يُعينك في تحسين تفاعل المستخدم وتحقيق أداء أفضل للموقع وإنشساء أدوات فعّالة لإدارة المعلومات على الويب. هذا المقال هو الجزء الأول من سلسلة تهدف إلى تعليم أساسيّات HTTP، وكيف يمكن استخدامه بفعّاليّة أكبر. سنطّلع في هذا الدّرس على محلّ HTTP من الإنترنت. ما معنى بروتوكول تواصل؟ قبل الدّخول في التفاصيل، لنتخيّل موقفًا بسيطًا يحدث فيه تواصل بين طرفين، ولكي يحدث هذا التواصل، فإن على الطّرفين (برنامجين كانا أم جهازين أم شخصين... إلخ.) أن يتّفقا على: الصياغة (تنسيق البيانات) الدلالات (معلومات التحكم والتعامل مع الأخطاء) التوقيت (تطابق السرعة والتتالي) عندما يلتقى اثنان، فإنّهما يتفاهمان من خلال بروتوكل تواصل: ففي اليابان مثلًا، يؤدي أحدهما حركة جسدية، كأن يحني ظهره. وهذه هي الصياغة المعتمدة في التواصل. وفي عادات اليابان، تدل حركة الانحناء هذه (وحركات أخرى مشابهة) على التّحيّة. وبحركة انحناء أحد الشخصين للآخر تنطلق سلسلة من الأحداث بينهما مرتبة بتوقيت معيّن. يتركّب بروتوكل التواصل عبر الشبكات من المكوّنات ذاتها. فأمّا الصّياغة فهي سلسلة من الحروف كالكلمات المفتاحيّة المُستخدمة في كتابة البروتوكول، وأمّا الدلالات فهي المعاني المُرتبطة بكلّ من هذه الكلمات، وأمّا التوقيت فهو ترتيب تبادل هذه الكلمات بين الطّرفين. ما محلّ HTTP من الإنترنت؟ يقوم HTTP نفسه فوق بروتوكولات أخرى. فعند الاتصال بموقع ويب مثل www.example.org، يستخدم وكيل المستخدم (user agent) مجموعة بروتوكولات TCP/IP، والتي صُمّمت في عام 1970 مؤلّفة من 4 طبقات: طبقة الوصلة (Link)، والتي تصف الوصول إلى الوسيط المادّي (كاستخدام بطاقة الشبكة مثلًا) طبقة الإنترنت، والتي تصف كيفيّة تغليف البيانات وتوجيهها (IP أو Internet Protocol) طبقة النقل (Transport)، والتي تصف كيفية نقل البيانات من نقطة الانطلاق إلى الوجهة (TCP وUDP) طبقة التطبيقات (Application)، والتي تصف معنى وصياغة الرسائل المنقولة (HTTP) فـ HTTP إذًا هو بروتوكول على مستوى التطبيقات يقوم على الطبقات السابقة، لا تنسَ هذه الفكرة. يُساعد فصل هذا النّموذج في طبقات على تطوير أجزاءه بصورة منفصلة دون الحاجة لإعادة تصميمها جميعًا. فمثلًا، يمكن تطوير TCP، باعتباره بروتوكولًا في طبقة النّقل، دون الحاجة لتعديل HTTP كونه برتوكولًا في طبقة التّطبيقات. لكن الواقع العمليّ يجعل التفاصيل أكثر تعقيدًا عند الحاجة للوصول إلى تواصل ذي أداء عالٍ. سنركّز في الأجزاء الأولى من هذه السّلسلة على فصل الطّبقات كما هو مُعرَّف في نموذج TCP/IP. صُمِّم HTTP بغرض تبادل المعلومات بين برنامجين من خلال رسائل تُسمّى رسائل HTTP، وتؤثّر طريقة تشكيل هذه الرسائل في العميل (client) والخادوم (server) والأطراف الوسيطة (كالخواديم الوكيلة proxies). لنتواصل مع خادوم! يُعتبر المنفذ رقم 80 المنفذ المبدئيّ للاتّصال بخواديم الويب، ويمكن التأكّد من ذلك بتجربة نُجريها من الطّرفيّة. افتح الطّرفية (أو سطر الأوامر) وجرّب الاتصال بـ www.opera.com على المنفذ 80 مُستخدمًا الأمر التالي: telnet www.opera.com 80 من المُفترض أن يكون الناتج: Trying 195.189.143.147... Connected to front.opera.com. Escape character is '^]'. Connection closed by foreign host. كما نرى فإن الطرفيّة تحاول الاتصال بالخادوم ذي عنوان IP‏ 195.189.143.147. إن لم نفعل شيئًا آخر سيغلق الخادوم الاتصال بنفسه. من الممكن بالطّبع استخدام منفذ آخر بل وحتّى بروتوكول تواصل آخر، ولكن هذه هي الإعدادات الشّائعة. لنتحدّث بلغة HTTP! لنحاول ثانية التواصل مع الخادوم. أدخل الرسالة التالية في الطرفية (أو سطر الأوامر): telnet www.opera.com 80 ما إن يُؤسّس الاتصال، اكتب رسالة HTTP التالية بسرعة (قبل أن يُغلق الخادوم الاتصال بنفسه)، ثم اضغط Enter مرّتين: GET / HTTP/1.1 Host: www.opera.com تُحدّد هذه الرسالة: GET: أي أننا نريد "الحصول على" تمثيل البيانات. /: أي أنّ المعلومات التي نريدها مخزنة في جذر الموقع. HTTP/1.1: أي أننا نتحدث ببروتوكول HTTP ذي الإصدارة 1.1. Host:: أي أننا نريد الوصول إلى الموقع المُحدّد. www.opera.com: اسم الموقع هو www.opera.com. على الخادوم الآن أن يُجيب طلبنا. من المفترض أن تمتلئ نافذة الطرفية بمحتوى مشابه لما يلي: HTTP/1.1 200 OK Date: Wed, 23 Nov 2011 19:41:37 GMT Server: Apache Content-Type: text/html; charset=utf-8 Set-Cookie: language=none; path=/; domain=www.opera.com; expires=Thu, 25-Aug-2011 19:41:38 GMT Set-Cookie: language=en; path=/; domain=.opera.com; expires=Sat, 20-Nov-2021 19:41:38 GMT Vary: Accept-Encoding Transfer-Encoding: chunked <!DOCTYPE html> <html lang="en"> ... يقول الخادوم هنا: "أنا أتحدث HTTP الإصدارة 1.1. نجحَ طلبك، لذا أجبت بالرمز 200." الكلمة OK ليست إلزامية والهدف منها شرح معنى الرمز للبشر - وهي تُشير في حالتنا إلى أن الأمور تسير على ما يرام وأن رسالتنا قُبلت. يلي ذلك سلسلة من "ترويسات HTTP" التي تُرسل لتصف الرسالة، وكيف يجب أن تُفهم. أخيرًا نجد محتويات الصفحة المُستضافة على جذر الموقع، والّتي تبدأ بـ <!DOCTYPE html>.

إعداد جدارٍ ناريّ قوي هو خطوةٌ أساسية يجب فعلها بهدف تأمين أيّ نظام تشغيلٍ حديث. تأتي معظم توزيعات لينكس بأدواتٍ مختلفة يمكننا استخدامها لضبط جداراتنا الناريّة. في هذا الدرس، سنتحدّث عن جدار iptables الناريّ. Iptables هو عبارة عن جدارٍ ناريّ عادي موجود في معظم توزيعات لينكس افتراضيًا (برنامجٌ آخر يدعى nftables سيبدأ قريبًا باستبداله). هو في الواقع عبارة عن واجهةٍ أمامية لخطّافات netfilter على مستوى النواة (kernel-level netfilter hooks) يمكنه التعامل مع مكدّس شبكة لينكس (Linux network stack). يعمل iptables عن طريق مطابقة كلّ حزمة (packet) تمرّ عبر الشبكة بمجموعة من القواعد (rules) التي تجعله يقرر ما يجب فعله. ملاحظة: يغطّي هذا الدرس أساسيات الحماية لـIPv4. في نظام لينكس، هناك فرق بين طرق الحماية لـIPv4 و IPv6. كمثال فإنّ iptables يقوم فقط بالتحكّم في قواعد جدار الحماية لعناوين IPv4 إلّا أنّه يمتلك برنامجًا خارجيًا يدعى ip6tables يمكن استخدامه للتحكّم في قواعد جدار الحماية لعناوين IPv6. إذا كان خادومك الافتراضي الخاصّ مُعدًّا ليستخدم IPv6، فرجاءً تذكّر حماية كلّ من واجهتيّ الشبكة IPv4 و IPv6 باستخدام الأدوات المناسبة. للمزيد من المعلومات عن أدوات IPv6، راجع هذا الدرس: كيفية ضبط بعض الأدوات لاستخدام IPv6 على نظام لينكس. أوامر iptables الأساسية الآن وبعد أن صار لديك المفاهيم الأساسية حول iptables، فإنّه يجب علينا تغطية الأوامر الأساسية التي سيتم استعمالها لتشكيل مجموعات قواعد iptables أكبر بالإضافة إلى إدارة واجهة iptables بشكلٍ عام. أولًا، يجب عليك أن تنتبه إلى أنّ أوامر iptables يجب أن يتم تشغيلها بصلاحيات الجذر (root privileges). هذا يعني أنّه يجب عليك الولوج إلى النظام باسم المستخدم root، استخدم su أو sudo -i للولوج إلى صدفة المستخدم الجذر، أو يمكنك ببساطة وضع sudo قبل جميع الأوامر التي ستطبّقها. سنستخدم sudo في هذا الدرس بما أنّها طريقة شائعة الاستخدام على نظام Ubuntu. نقطة جيدة للبداية بها هي كيفية سرد قواعد iptables المُستخدمة حاليًا. يمكنك فعل هذا باستخدام الخيار -L : $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination كما يمكنك أن ترى، لدينا ثلاث سلاسل (chains) هنا. يمكننا أيضًا أن نرى السياسة المتّبعة في كلّ سلسلة (كل سلسلة افتراضيًا تمتلك سياسة ACCEPT للاتصالات المارّة منها). يمكننا أيضًا رؤية بعض ترويسات العواميد في ناتج الأمر السابق، إلّا أنّنا فعليًا لا نرى أيّ قواعد مطبّقة. هذا بسبب أنّ Ubuntu لا تأتي مع مجموعةٍ افتراضية من قواعد iptables. يمكننا رؤية الخرج بصيغةٍ تعكس الأوامر الضرورية لتفعيل كلّ قاعدة وسياستها عبر استخدام الخيار -S : $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT لإعادة إنتاج الإعدادات وتطبيقها من جديد، سيجب علينا فقط كتابة الأمر sudo iptables متبوعًا بكلّ واحدٍ من السطور الظاهرة في الخرج. (اعتمادًا على الإعدادات، قد يكون الأمر أكثر تعقيدًا في حال كنّا متّصلين عن بعد إلى الخادوم حيث أننا لا نريد إضافة قواعد iptables معيّنة تمنع جميع الاتصالات الواردة إليها مثلًا دون استثناء اتّصالنا الحالي لكي لا ينقطع فجأة ولكي يبقى متّصلًا). إذا كان لديك قواعد بالفعل لديك في iptables وكنتَ ترغب بإتلافها والبدء من جديد، فيمكنك فعل ذلك عبر تطبيق: $ sudo iptables -F مرةً أخرى، سياسة قبول الاتصالات أو رفضها مهمّة هنا، لأنّه وبينما يتم حذف جميع القواعد الأخرى من السلاسل الخاصّة بك، فإنّ السياسة الافتراضية لن تتغيّر باستخدام هذا الأمر. هذا يعني أنّه في حال كنت متّصلًا عن بعد بخادومك، فإنّه يجب عليك التأكّد من أنّ السياسة الافتراضية لسلسلتيّ INPUT و OUTPUT هي ACCEPT بالتزامن مع قيامك بإتلاف قواعدك السابقة. يمكنك فعل ذلك عبر تطبيق الأوامر التاليّة: $ sudo iptables -P INPUT ACCEPT $ sudo iptables -P OUTPUT ACCEPT $ sudo iptables -F يمكنك تغيير سياسة الحظر أو الترك (drop) مجددًا إلى DROP بعد أن تقوم بإعداد القواعد التي تسمح ببقاء اتّصالك الحالي. سنفصّل كيفيّة ذلك بعد قليل. إنشاء قاعدتك الأولى سنبدأ ببناء سياسة جدار الحماية الخاصّ بن حول قبول أو رفض الاتصالات. كما قلنا أعلاه، فإنّنا سنعمل مع سلسلة INPUT بما أنّها المصدر الرئيسي لتدفّق الزوار القادم إلى خادومنا. سنبدأ مع القاعدة التي تحدّثنا عنها مسبقًا من قبل بالأعلى: القاعدة التي تسمح لنا بشكل خاص بمتابعة اتّصال SSH الحالي. القاعدة الكاملة التي نحتاج إليها هي هذه: $ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT قد يبدو هذا معقّدا للغاية لك في الوهلة الأولى، إلّا أنّ معظم مكوّنات الأمر السابق ستكون ذات معنى بالنسبة لك عندما تفهمها: -A INPUT: يقوم الخيار -A بإضافة قاعدةٍ ما إلى نهاية السلسلة المطلوبة. هذا هو الجزء الذي يقوم بإخبار iptables بأنّنا نريد إضافة قاعدةٍ جديدة إلى سلسلة معيّنة، والسلسلة التي نريدها في مثالنا حاليًا هي سلسلة INPUT. -m conntrack: يمتلك iptables عدّة وظائف داخليّة، ولكنّه أيضًا يمتلك مجموعةً من الامتدادات والوحدات التي تقوم بتوفير مزايا إضافيّة. إنّنا نقوم في هذا الجزء من الأمر بإخبار iptables بأنّنا نريد الحصول على إذن بالوصول إلى الوظيفة التي يتم توفيرها عبر الوحدة المسماة "conntrack”. تعطينا هذه الوحدة وصولًا إلى الأوامر التي يمكن أن يتم استخدامها بناءً على علاقة حزمة البيانات الداخلة بالاتّصال السابق. --ctstate: هذا واحدٌ من الأوامر التي أصبحت متوفّرة بعد أن تم استدعاء وحدة "conntrack”. يسمح لنا هذا الأمر بمطابقة حزم البيانات بناءً على ماهيّة ارتباطها بحزم البيانات التي رأيناها من قبل. إننا نقوم بتمرير قيمة ESTABLISHED للسماح بمرور حزم البيانات الداخلة التي هي جزء من اتّصالٍ عاملٍ حاليًا فقط. ونقوم بتمرير قيمة RELATED للسماح بمرور حزم البيانات المرتبطة باتّصالٍ مُنشَئٍ بالفعل. هذا الجزء من القاعدة هو الجزء الذي يتطابق مع جلسة SSH الحالية الخاصّة بنا. -j ACCEPT: يقوم هذا الخيار بتحديد هدف مطابقة حزم البيانات. هنا، نقوم بإخبار iptables أنّ حزم البيانات التي تطابق القاعدة السابقة يجب أن يتم السماح لها بالمرور. قمنا بوضع هذه القاعدة في البداية لأننا أردنا أن نتأكّد أنّ اتصالنا الحالي مطابق، مقبول وخارج إطار السلسلة قبل تنفيذ أيّ قواعد DROP. يمكننا الآن رؤية حالة التغييرات التي قمنا بها عن طريق: $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination الآن وبعد أن صرتَ تعرف الصياغة العامّة لقواعد iptables، فلنتابع عبر استعراض المزيد من الحالات التي سنحتاج فيها إلى قبول الاتّصالات. قبول الاتّصالات المهمّة الأخرى أخبرنا iptables أن يبقي أيّ اتصالاتٍ مفتوحة على وضعها الحالي بالإضافة إلى السماح بالاتصالات الجديدة المرتبطة بتلك الاتصالات. على كلّ حال، نحتاج إلى إنشاء بعض القواعد الضرورية لتحديد متى نريد قبول اتّصالاتٍ جديدة لا تطابق هذه المعايير التي طبّقناها. نريد إبقاء منفذين اثنين مفتوحين بالتحديد. نريد إبقاء منفذ اتّصال SSH الخاصّ بنا مفتوحًا (سنفترض في هذا الدرس أنّ المنفذ الافتراضي له هو المنفذ 22. إذا كنتَ غيّرت هذا المنفذ على خادومك من إعدادات SSH فقم بتعديل قيمته هنا). سنقوم أيضًا بافتراض أنّ هذا الحاسوب يقوم أيضًا بتشغيل خادوم ويب يعمل على المنفذ 80. إذا لم يكن هذا هو نفس الوضع بالنسبة لك فلن تحتاج تطبيق القاعدة التالية. السطران اللذان سنستعملهما لتطبيق هذه القواعد هما: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT كما يمكنك أن ترى، هذه القواعد مشابهة جدًا لقاعدتنا الأولى التي كتبناها، ولكنها ربما تكون أكثر بساطةً. الخيارات الجديدة هي: -p tcp: يقوم هذا الخيار بمطابقة حزم البيانات في حال كان البروتوكول المستخدم هو TCP. هذا البروتوكول هو بروتوكولٌ مستخدم بواسطة معظم التطبيقات لأنّه يسمح بتواصلٌ مرن وقوي بين المستخدم والتطبيق. --dport: يكون هذا الخيار متوفّرًا للاستخدام فقط في حال كان الخيار -p tcp موجودًا في الأمر. إنّه يقوم أيضًا بتحديد رقم المنفذ الذي يجب مطابقة حزم البيانات عبره. تقوم القاعدة الأولى بمطابقة حزم البيانات المارّة عبر بروتوكول TCP بالمنفذ 22، بينما تقوم الثانية بمطابقتها عبر المنفذ 80. هناك قاعدة ACCEPT أخرى يجب علينا التأكّد من أنّ خادومنا يقبلها بشكل صحيح. غالبًا، تتواصل الخدمات (services) مع بعضها البعض على الحاسوب عبر إرسال حزم بياناتٍ فيما بينها، وهي تقوم بذلك عبر الاستفادة من واجهة شبكةٍ زائفة تدعى loopback device ، والتي تقوم بتوجيه التدفّق إلى نفسها عوضًا عن الأجهزة الأخرى. لذا إذا كانت واحدة من الخدمات تريد التواصل مع خدمةٍ أخرى تستمع إلى المنفذ 4555، فإنّه بمقدورها إرسال حزمة بيانات إلى المنفذ 4555 على الشبكة الزائفة loopback device. نريد أن يتم السماح بهذا النوع من السلوك بين الخدمات لأنّه ضروري للعديد من برامج نظام التشغيل. القاعدة التي نحتاج تطبيقها هي هذه: $ sudo iptables -I INPUT 1 -i lo -j ACCEPT يبدو هذا الأمر مختلفًا قليلًا عن الأوامر السابقة. فلنشرح ما يفعله: -I INPUT 1: يقوم الخيار -I بإخبار iptables بإدراج قاعدةٍ جديدة. هذا الخيار مختلف عن الخيار -A والذي يقوم بإضافة القاعدة الجديدة إلى نهاية قواعد iptables. يحتاج الخيار -I إلى اسم السلسلة والمكان الذي تريد إدراج القاعدة الجديدة فيه. في حالتنا، فإننا نقوم بإضافة هذه القاعدة كأول قاعدة في سلسلة INPUT. هذا سيدفع بقية القواعد إلى الأسفل بدرجةٍ واحدة تلقائيًا. نحتاج لهذه القاعدة أن تكون بالأعلى لأنّها أساسية ولا يجب أن يتم التأثير عليها عبر قواعد فرعيّة أخرى. -i lo: يقوم هذا المكوّن من القاعدة بمطابقة ما إذا كانت الواجهة التي تستخدمها حزمة البيانات هي واجهة "lo”. واجهة "lo” هي عبارة عن اسمٍ آخر لـloopback device. هذا يعني أنّ أيّ حزمةِ بياناتٍ تستعمل تلك الواجهة الشبكيّة للتواصل (حزم البيانات الناتجة في خادومنا، إلى خادومنا) يجب أن يتم قبولها من طرف iptables. لرؤية قواعدنا الحاليّة، يجب أن نستخدم الخيار -a . هذا بسبب أنّ الخيار -L لا يتضمّن بعض المعلومات، مثل اسم الواجهة المرتبطة بالقواعد، والذي يعتبر جزءًا مهمًّا في القاعدة التي قمنا بإضافتها: $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT تضمين قاعدة حظر (Drop) نمتلك الآن 4 قواعد منفصلة تقبل الاتصالات بناءً على معايير معيّنة. وبالرغم من ذلك، فإنّا خادومنا حاليًا لا يحظر وصول أيّ شيء إليه. إذا دخلت حزمة بياناتٍ إلى سلسلة INPUT ولم تكن مطابقة لأيٍّ من القواعد الأربعة التي أدخلناها، فإنّه سيتم تحويلها إلى السياسة الافتراضية للتعامل مع حزم البيانات، والتي هي حاليًا "قبول حزم البيانات جميعها"، ونحتاج لتغيير هذا الأمر. هناك طريقتان يمكننا فعل ذلك بهما، مع بعض الاختلافات الجوهرية. الطريقة الأولى التي يمكننا من خلالها القيام بهذا هي عن طريق تعديل السياسة الافتراضية لسلسلة INPUT. يمكننا القيام بذلك عبر كتابة: $ sudo iptables -P INPUT DROP ستقوم القاعدة السابقة بالتقاط أيّ حزم بياناتٍ تفشل بالمرور عبر سلسلة INPUT الخاصّة بنا ويمنع وصولها إلى الخادوم. هذا ما ندعوه بسياسة المنع الافتراضيّة (default drop policy)، من مساوئ هذه الطريقة هي أنّ قاعدة الـDROP هذه يتم إلغاؤها في حال تم مسح قواعد iptables (حيث أنّها قاعدة هي الأخرى وبالتالي سيتم مسحها معها). قد تكون هذه الطريقة أكثر أمنًا، ولكنك قد تواجه عواقب وخيمة في حال لم يكن لديك طريقةٌ أخرى للوصول إلى خادومك. في DigitalOcean، يمكنك الولوج عبر لوحة التحكّم إلى خادومك والوصول إلى طرفيّة ويب تمكّنك من التحكّم به إذا حصل هذا. طرفيّة الويب هذه تعرّف نفسها على أنّها اتصال وهمي محلّي ولذلك فإنّ قواعد iptables لا تؤثّر عليها. قد تودّ لخادومك أن يقوم بحظر جميع الاتصالات في حال مسح جميع القواعد. قد يمنع هذا من ترك خادومك مفتوحًا للجميع. وهذا يعني أيضًا أنّه بمقدورك بسهولة إضافة القواعد إلى نهاية أيّ سلسلة تريدها بينما تحظر حزم البيانات التي لا تريدها بسهولة. إذا قمتَ بتغيير السياسة الافتراضيّة لسلسلة INPUT، فإنّه يمكنك إرجاعها عبر تطبيق: $ sudo iptables -P INPUT ACCEPT الآن، يمكنك إضافة قاعدة إلى نهاية السلسلة والتي ستقوم بحظر أيّ حزم بياناتٍ متبقية: $ sudo iptables -A INPUT -j DROP النتائج تحت شروطٍ تشغيلية عادية ستكون بالضبط هي نفس سياسة الحظر الافتراضيّة. تعمل هذه القاعدة عبر مطابقة كلّ حزمة بياناتٍ متبقية تصل إليها. يمنع هذا حزمةَ البيانات من الوصول إلى الخادوم في حال فشلت بتجاوز القواعد السابقة التي قمنا بإنشائها. بشكلٍ عام، يتم استخدام هذه القاعدة لجعل السياسة الافتراضيّة في التعامل مع الاتصالات تقبل التدفّق الواصل إليها. بهذه الطريقة، في حال كان هناك أيّ مشاكل وتم مسح جميع القواعد، فإنّك ستبقى قادرًا على الوصول إلى الآلة عبر الشبكة. بالطبع، هذا يعني أيضًا أنّ أيّ قاعدةٍ إضافية تودّ إضافتها إلى نهاية السلسلة يجب أن تكون قبل قاعدة الحظر أو الـdrop. يمكنك فعل هذا عبر حذف قاعدة الحظر مؤقتًا عبر: $ sudo iptables -D INPUT -j DROP $ sudo iptables -A INPUT new_rule_here $ sudo iptables -A INPUT -j DROP أو، يمكنك إدراج القواعد التي تحتاجها في نهاية السلسلة (ولكن قبل قاعدة الـdrop) عبر تحديد رقم السطر. لإدراج قاعدةٍ في السطر رقم 4، يمكنك كتابة: $ sudo iptables -I INPUT 4 new_rule_here إذا كنتَ تواجه مشاكل في معرفة إلى أيّ سطرٍ تنتمي أيّ قاعدة، فيمكنك إخبار iptables بأن يقوم بسرد السطور المتوفّرة عبر: $ sudo iptables -L –line-numbers Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere 2 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 3 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh 4 ACCEPT tcp -- anywhere anywhere tcp dpt:http Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination يمكن لهذا أن يكون مفيدًا للتأكّد من أنّك تضيف القاعدة إلى مكانها الصحيح. حفظ إعدادات iptables الخاصّة بك افتراضيًا، تكون القواعد التي تضيفها إلى iptables غير دائمة. هذا يعني أنّك عندما تقوم بإعادة تشغيل خادومك، فإنّ جميع قواعد iptables ستختفي. هذه المشكلة في الواقع هي ميّزة لبعض المستخدمين لأنّها تعطيهم فرصةً للعودة إلى التحكّم بالخادوم في حال قاموا بحبس أنفسهم خارجها عن طريق الخطأ في تطبيق القواعد. وعلى كلّ حال، معظم المستخدمين سيودّون أن يكون هناك طريقة تلقائية لحفظ القواعد التي أنشؤوها وتحميلها تلقائيًا عند إقلاع الخادوم. هناك عدّة طرق لفعل هذا، لكنّ أسهلها هو باستخدام حزمة iptables-presistent، يمكنك تحميل هذه الحزمة من مستودعات Ubuntu الافتراضيّة: $ sudo apt-get update $ sudo apt-get install iptables-persistent أثناء التثبيت، سيتم سؤالك عمّا إذا كنتَ تحبّ حفظ قواعد iptables الحاليّة ليتم تحميلها تلقائيًا. إذا كنتَ مسرورًا مع إعداداتك الحاليّة (واختبرت قدرتك على الوصول إلى اتصالات SSH جديدة مستقلة) فإنّه يمكنك الموافقة على ذلك. سيتم سؤالك أيضًا عمّا إذا كنتَ تريد حفظ قواعد IPv6 التي قمتَ بإعدادها، يتم إعداد هذه القواعد عبر أداة منفصلة تدعى ip6tables والتي تتحكم بحزم بيانات IPv6 بنفس الطريقة. بمجرّد اكتمال التثبيت، ستتوفر خدمة جديدة لديك تدعى iptables-presistent وهي مُعدّة ليتم تشغيلها عند الإقلاع. ستقوم هذه الخدمة بتحميل قواعد iptables الحاليّة وتطبيقها من جديد في كلّ مرّة يتم إعادة تشغيل النظام فيها. الخاتمة يجب أن تكون الآن قد امتلكت نقطة بداية جيّدة للبدء في تطوير جدارٍ ناري يلبي احتياجاتك. هناك العديد من أدوات الجدران الناريّة الأخرى التي يمكنك استخدامها والتي قد تكون أسهل، ولكن iptables أداةٌ جيّدة لتعلّمها، ذلك لأنّها توفّر بنية netfilter تحتية جيّدة للاستعمال ولأنّها متوفّرة افتراضيًا في العديد من أنظمة التشغيل. ترجمة -وبتصرّف- للمقال: How To Set Up a Firewall Using IPTables on Ubuntu 14.04.

سنتناول في هذه المقالة بقليلٍ من التفصيل شرح خاصّيّة هامّة من خواصّ أوراق الأنماط المُتتالية CSS وهي "ظلال النصّ" text-shadows، وتجدرُ الإشارة إلى أنه يوجد خاصّيّة مُشابهة لهذه الخاصّيّة وهي "ظلّ الصندوق" box-shadow، والخاصّيّتان مُعرفتان في وحدتين مختلفتين في المعايير القياسية لـ W3C على الرُغم من أنها مُتطابقتان إلى حدٍ كبير. سيكون من السهل تعلّم خاصّيّة "ظلّ النصّ" عند توفر معرفة مُسبقة بخاصّيّة "ظلّ الصندوق"، ولكن قبل كل شيء لكي يُفهم الفرق بينهُما، يجب القراءة قليلًا عن الجانب النظري من الموضوع، ودعم المُتصفحات لهذه الخاصّيّة، ومن ثُمّ التطبيق مع الأمثلة العملية. دعمُ المتصفحاتتدعمُ مُعظم المُتصفحات الحديثة الخاصّيّتان "ظلّ النصّ" و"ظلّ الصندوق" كما هو موضّح في الشكل التالي: يدعم المُتصفح Opera mini خاصّيّة "ظلّ النصّ" بشكل جزئيّ حيث لايَظهر تأثير الغشاوة blur على النصّ، وتُحاكي الإصدارات السابقة للإصدار العاشر من IE لخاصّيّة "ظلّ النصّ" باستخدام مُرشّحات filters غير معياريّة non-standard مثل مُرشّح dropshadow. الفرقُ بين "ظلّ النصّ" text-shadow و"ظلّ الصندوق" box-shadow طريقة كتابة الشيفرة الخاصّة بـ "ظلّ الصندوق" هي كالتالي: box-shadow: none|h-shadow v-shadow blur spread color |inset|initial|inherit;أمّا طريقة كتابة الشيفرة البرمجية لـ "ظلّ النصّ" فهي كالتالي: text-shadow: h-shadow v-shadow blur color|none|initial|inherit;تعملُ الخاصّيّتان بأسلوب مُماثل مع بعض الاستثناءات، حيثُ لا يُمكن إنشاء ظلّ داخليّ للنصِّ كما في خاصِّيَّة "ظلّ الصندوق"، كما لا يُمكن التحكم بمقدار التوسّع spread في "ظلّ النصّ"، ولكن يُمكن إنشاء أكثر من ظلّ لتُعرض فوق بعضها البعض بطريقة مُماثلة لـ "ظل الصندوق" كما سوف نوضّح بالأمثلة. يُوضّح الشكل التالي الاختلاف بين المفاهيم الأربعة التي سوف نعمل عليها. الجانب العمليّ لخاصّيّة "ظلّ النصّ"الألوان والإزاحةتُحرّكُ قيمُ الإزاحة الموجبة الظلّ بالاتجاه الأيمن والأسفل، وتُحرّكُ القيمُ السالبة الظلّ بالاتجاه المُعاكس أيّ نحو اليسار والأعلى. تحديدُ لون الظلّ هو أمرٌ إختياريّ، وسيأخذ الظلّ لون العنصر الأب في حال عَدم تحديد لون مُحددٍ له، ويُنصح دائمًا بتحديد اللون وذلك لأن المُتصفّحات سوف تُظهر لون الظلّ بشكل مُختلف فيما بينها. في الأمثلة التالية سوف نُحدّد الإزاحة الأُفقيّة والعموديّة مع ألوان مُخصّصة text-shadow:10px 10px; text-shadow:-5px -5px; color:blue; text-shadow:-1px -1px white; color:blue; background:#888; text-shadow:1px 1px rgba(255,255,255, 0.5); color:blue; background:#eee; الغشاوة blurالمُعامل الخاصّ بالغشاوة هو مُعاملٌ اختياريّ، وقيمته تُحدد مدى انتشار الغشاوة لحواف الظلّ، ويجب أن تكون قيمتُه موجبة، حيث القيمة صفر تعني بدون غشاوة، أي أنّ حواف الظلّ ستكون حادّة. /*blur*/ .example1 { text-shadow:5px 5px 3px darkred; color:red; } .example2 { text-shadow:4px -4px 10px red; color:azure; background:#333; } .example3 { text-shadow:0px 0px 4px ; } .parent-of-example3 { color:red; } .example4 { text-shadow:0px 0px 4px ; } .parent-of-example4 { color:lightgray; background:#333; } استخدمنا في المثال الأول والثاني غشاوة مُختلفة، حيثُ الأول 3px والثاني 10px، ولم نُحدد لون العنصر بشكل مُباشر في المثال الثالث والرابع بل على العنصر الأب. التوسّع والانكماش Expansion and contractionسوف يتم إضافة إمكانية تحديد التوسّع spread لخاصّيّة "ظلّ النصّ" في الإصدار الرابع من `أوراق الأنماط المُتتالية` CSS4، ولكن IE10 يدعم هذه الخاصّيّة مُنذ الآن، ولذلك في الأمثلة سوف يظهر تأثير هذا المُعامل parameter -وهو الرابع للخاصّيّة text-shadow- على المُتصفح IE10 وIE11. تزيد القيّم الموجبة من توسّع الظلّ وتُقلّص القيّمُ السالبة من توسّع الظل، وتُستخدم القيمة صفر لإضافة حدود خارجية للنصّ. text-shadow:5px 5px 0px 3px lightgreen; color:green; text-shadow:8px 8px 2px -3px darkgreen; color:green; font-weight:900; text-shadow:0 0 0 3px rgba(128, 255, 0, 0.75); color:green; background:#333; الظلّ المُتعدد Multiple shadowتُمكنك خاصّيّة "ظل الصندوق" من إنشاء أكثر من ظلّ لنفس النصّ، وذلك عبر كتابة قيمة كل ظلّ والفصل بينها بالفاصلة (,) /*Multiple shadow*/ .example1 { text-shadow: 0 0 0 3px white, 0 0 0 4px gray; color:magenta; } .example2 { text-shadow: 3px 3px 4px 2px rgba(255,255,255,0.35), 6px -6px 4px 2px rgba(255,255,255,0.25), -3px -3px 4px 6px rgba(255,0,255,0.15); } .example3 { text-shadow: 0 0 0 3px white, 0 0 2px 6px magenta, 0 0 1px 9px white, 0 0 6px 12px magenta; color: magenta; } .example4 { text-shadow: 0 0 2px #fff, 0 0 4px 2px rgba(255,255,255,0.5), 0 0 6px 6px #f0f, 0 0 4px 7px #fff, 0 0 3px 15px #222, -4px 0 2px 9px #f0f, 4px 0 2px 9px #f0f, 0 -4px 2px 9px #f0f, 0 4px 2px 9px #f0f; color: white; } .example5 { text-shadow: 0 -3px 3px 15px white, 0 1px 2px 9px; color: magenta; } مُحاكات التوسّع Emulating expansionأشرت سابقًا إلى أنّ إمكانية عمل التوسّع spread للنصّ مُتوفرة فقط في الإصدار الرابع من CSS، ولكن يُمكن عمل مُحاكات لها في الإصدار الثالث. text-shadow: 0px 0px 0px 4px magenta; /* الشيفرة السابقة مُشابهة للشيفرة التالية */ text-shadow: 0px 2px magenta, 2px 0px magenta, -2px 0px magenta, 0px -2px magenta, -1.4px -1.4px magenta, 1.4px 1.4px magenta, 1.4px -1.4px magenta, -1.4px 1.4px magenta; كما هو مُبيّن في المثالين السابقين أنّ المُحاكات ليست مثاليّة من ناحية المظهر ودقّة الحواف الخاصة بالظلّ، وكما تختلفُ سرعة المُتصفح في عرض المثالين السابقين. أمثلة إضافيةظلّ مزدوج /*Twin shadow*/ .twin { text-shadow: 0 0 2px 2px white, 2px 0 2px 5px #222, 3px 0 3px 6px #933, 5px 0 2px 14px #222, 6px 0 5px 16px #533; background-color: #222; color: white; } تأثير Letter-press /*Letter-press*/ .le-pr { text-shadow: 0px 2px 3px #555; background-color:#333; }قوس قزح /*Rainbow*/ /*IE*/ .rainbow { text-shadow: 0 0 2px 3px yellow, 0 0 2px 6px orange, 0 0 2px 9px red, 0 0 2px 12px lime, 0 0 2px 15px blue, 0 0 2px 18px violet; }ثلاثي الأبعاد /*3D*/ .threed { text-shadow: 0 0 1px #999, 1px 1px 1px #888, 2px 2px 1px #777, 3px 3px 1px #666, 4px 4px 1px #555, 5px 5px 1px #444; background-color:#333; color:white; }تأثير Retro /*Retro / Vintage effect*/ .retro { text-shadow: 2px 2px #fff, 3px 3px #666; }الحرف الأول باستخدام "شبه الصنف" pseudo-class المُسمى "الحرف الأول" first-letter /*First-letter-only shadow */ .text { text-shadow: 0 0 5px; } .text::first-letter { color:azure; text-shadow: 0 0 5px, 0 0px 6px 3px blue, 0 -2px 6px 6px cyan, 0 -4px 9px 9px lightblue ; }التوهج .flame { text-shadow: 0 0 2px #eee, 0 0 4px 2px #fff, 0 -2px 4px 2px #ff3, 2px -4px 6px 4px #fd3, -2px -6px 11px 6px #f80, 2px -8px 18px 8px #f20; background-color:#222; color:white; } ترجمة -وبتصرّف- للدّرس Practice with Text Shadows

كاتب هذا المقال هو ساشا جريف Sacha Greif؛ المُصمِّم ورائد الأعمال الذي باع مؤخَّرًا آلاف النُسَخ من كتابه الإلكتروني المنشور بالجهود الذاتية الذي يوضِّح كيفية تصميم واجهة مُستخدِم بالخطوات. لقد عمل مع شركات ناشئة مُتعدِّدة وهو كذلك مؤسِّس خدمة Folyo التي تساعد الشركات في العثور على مُصمِّمين يعملون لحسابهم الخاص. يشرح ساشا هنا كيف حدَّد سِعرًا لكتابه الإلكتروني، الأمر الذي لعب دورًا أساسيّا في نجاحه. وبَّخَني أبي مؤخَّرًا لشراء خبزٍ بُنِّي رخيص. وبما أنَّه قد كان لدينا أيضًا خُبزًا دنماركيًّا مستوردًا فاخرًا؛ تحدَّيته أن يخضع لاختبار تذوُّقٍ دون أن ينظر إلى نوع الخبز الذي يتناوله. بالطبع لم يستطِع معرفة الفرق بينهما، رغم أنَّ تكلفة أحدهما تبلغ ضِعف تكلفة الآخر. نميل بداهةً إلى النظر إلى الأسعار باعتبارها نتيجةً مُترتِّبة على القيمة المُتأصِّلة في المُنتَج؛ ويريد المُسوِّقون في كل مكان أن يبقى الوضع على ما هو عليه. ولكن يعرف علماء النَفس أنَّ للأسعار قوَّةً أكبر من ذلك بكثير؛ فقد يؤثِّر السعر المناسب تأثيرًا عظيمًا على القيمة المُدرَكة للمُنتَج، بل ويخلقها من العدم (هل سمعتَ عن الألماس من قبل؟). لطالما أذهلَتني قوّة الأسعار، كما تُوضِّحها قصصٌ مثل بائعة المجوهرات التي ضاعَفَت مبيعاتها بزيادة أسعارها ثلاث مرَّات. لذا عندما ألَّفتُ مؤخَّرًا كتابًا إلكترونيًّا يوضِّح للناس كيفية تصميم واجهات المُستَخدِم، كنتُ أعرف مدى أهميَّة تحديد السعر المناسب. لماذا تتقاضى ثمنًا من الأساس؟ألا تكفيك الشُهرة، والمَجد، وعدد المُشتَركين في خلاصات RSS الخاصة بك؟ إلى جانب الإجابة البديهيَّة (جَني المال)، أعتقد أنَّ الأشياء المجَّانية تجتاح الإنترنت بالفعل. فأنا أحمِّلُ بنفسي عشرات الخطوط، والأيقونات، والكُتُب، والفيديوهات المجَّانية كل أسبوع ولا أستخدم أيًا منهم بسبب ضيق الوقت. إذًا فأنا بِتَقاضِي نقودًا ملموسة مقابل مُنتَجي، كنتُ أُحقق أمرين: كنتُ أرسِل إشارةً مفادها أنَّه أفضل من المحتوى الذي يمكن للمستخدم الحصول عليه مجَّانًا؛ وكنتُ أزيد من فُرَص قراءة الناس للكتاب بالفعل بعد تحميله، بما أنَّهم قد دفعوا مالًا ليحصلوا عليه (ومن ثَمَّ أستخدم مغالطة التكلفة الغارقة sunk costs fallacy لصالحي). كانت الخطوة الأولى هي القيام ببعض أبحاث السوق الأساسية لمعرفة كَم من المال سيكون الناس مُستعدِّين لدفعه. سألتُ الناس على موقع تويتر وجاءتني الإجابات تتراوح ما بين 5 إلى 10 دولارات. كما بحثتُ عن الأسئلة الموجودة بالفعل على موقع Quora، وسألتُ إذا ما كان من الأفضل البدء بأسعارٍ منخفضة ثم زيادتها أم البدء بأسعار عالية ثم تخفيضها. (الإجابة المُختَصَرة: الأمر نسبي). كما وضعتُ في الاعتبار حقيقة أنَّ الناس الآن معتادون على دفع مبالغ ضئيلة (أقل مِمَّا يُكلِّفه كوبٌ من القهوة في ستاربَكس) بفضل متاجر التطبيقات. ولكنَّني كنتُ أعرف أيضًا أنَّ أي شيء يزيد عن 10 دولارات سيُؤثّر على آليّات نفسية مختلفة. (سترى خلال دقيقة إثباتًا أو دحضًا لهذه الفرضية). بما أنَّ هدفي كان تحقيق أعلى المبيعات الممكنة لخلق قاعدة من القُرَّاء، وربما لتمهيد الطريق أمام كتبي المُستقبَليّة، قرَّرتُ البقاء داخل إطار الأسعار التي تتراوح بين دولارٍ واحد وعشرة دولارات. بعد اتخاذ قرارٍ بشأن السعر التقريبي، كانت الخطوة التّالية التركيز على تجزئة السوق. شعرتُ بالتنوير نوعًا ما بعد قراءة هذا المقال الذي كتبه Joel Spolsky عن التجزئة (قد يكون هذا المقال على الأرجح واحدًا من أفضل عشر مقالات عن المبيعات على الإنترنت)؛ وأدركتُ أن هذا المصطلح الذي يبدو مُعقَّدًا ينطوي في الحقيقة على مفهومٍ مألوفٍ للغاية. لتبسيط الأمور، تعني تجزئة السوق أن تُسعّر لكل شخصٍ بأقصى ما يرغب في دفعه. هذا بالتحديد ما يحدث عندما تساوِم في أحد الأسواق في بكين أو القدس؛ إذ يبدأ البائع بسعرٍ باهظٍ للغاية، ويتم البيع عندما تنجح في خفض السعر إلى أعلى سعر ترغب في دفعه (وبالتالي مضاعفة أرباحه). وبما أنَّه من الأصعب كثيرًا معرفة المبلغ الذي قد يرغب شخصٌ ما في دفعه عبر الإنترنت، فلتُقدِّم ببساطة أسعارًا مختلفة وتدع المستخدمين يختارون بأنفسهم ما يناسب احتياجاتهم. لا يمكنك بالطبع تقديم المُنتَج نفسه مقابل سعرين مختلفين؛ لذا تحتاج إلى إيجاد عامل تفاضل. في حالتي، قررتُ أن تتضمَّن النسخة الفاخرة من الكتاب الإلكتروني على ملفات فوتوشوب المصدرية. كان تكتيك التسعير الآخر الذي استخدمته هو توفير سعر افتتاحي أصغر. يؤدِّي ذلك إلى أمرين: الأول هو زيادة عدد من سيشترون المُنتَج مبكِّرًا: ممَّا سيحقِّق انطلاقةٍ أكبر ويساعد على الوصول إلى الكتلة الحرجة، حيث أنّه كلَّما زاد عدد من اشتروا الكتاب زاد عدد من سيشترونه، وفقًا لأساسيَّات ظاهرة الإثبات الاجتماعي (ظاهرة الإثبات الاجتماعي: أي أن يُقلِّد الشخص أفعال الآخرين في محاولةٍ معرفة السلوك الصحيح أو الخاطيء في المواقف الاجتماعية). ولكنَّها كذلك كانت طريقة لمكافأة العُملاء الأوائل؛ فهُم مَن يخاطرون لمعرفة ما إذا كان الكتاب يستحقُ القراءة، كما أنَّهم مَن يتابعونك عن كثبٍ ويهتمُّون بك أكثر من غيرهم. إنَّهم جماعةٌ مميَّزة ويجب معاملتهم باعتبارهم كذلك (ستجد بأن سيث جودين يركّز على هذه الفكرة كثيرًا). لنراجع معًا قيود التسعير التي وضعتها: - لابد أن يكون هناك تسعريان مُختلفان. - لابد أن يكونا عاليين بما يكفي للسماح بوجود تخفيض افتتاحي (تخفيض لأوائل الزّبائن) - لابد أن يتراوحا ما بين دولارٍ واحد وعشرة دولارات. عندما تضع الأمور نصب عينيك هكذا، يتَّضح أنَّه ليس هناك الكثير من الخيارات. فاخترتُ: طبعة عادية: سعرها 5.99$ يصل بعد التخفيض إلى 2.99$ وطبعة فاخرة: سعرها 12.99$ يصل بعد التخفيض إلى 5.99$. يبلغ سعر الطبعة الفاخرة ضِعف سعر الطبعة العادية، وقيمة الخصم كذلك 50%، مما يجعل حساب الأمر بسيطًا. إذًا ها هو الجزء الذي تنتظرونه جميعًا، كيف جرى الأمر؟ كانت النتيجة جيدة بصورةٍ مذهلة. نشرت صفحة الهبوط Landing Page الخاصة بالكتاب الإلكتروني على موقع Hacker News؛ وسرعان ما وصلَت إلى أعلى المراتب، وجَمَعَت أكثر من 300 صوتًا، بل ووصلَت للمرتبة الثانية على الصفحة الرئيسية لفترةٍ. حقَّق تدفُّق الزوَّار الهائل (22 ألف زائر في يومٍ واحد) مبيعات مذهلة؛ ففي أول 48 ساعة بعتُ 1476 نسخة من الكتاب، بإجمالي أرباح 6663 دولار. إذًا لا بد أنَّ نموذجي للتسعير كان ناجحًا، ولكن ما السّبب المُحدّد الذي يقف وراء ذلك؟ لحسن حظِّي، أطلعني بعض المُعلِّقين في موقع Hacker News على ما فكَّروا فيه؛ فقال أحدهم: «أريد أن أقول فقط أنَّ نقطة السعر 2.99 رائعة، فلم يبدُ أن دفع مبلغ 5.99 الذي يشمل ملفات فوتوشوب المصدرية أمرًا يحتاج إلى التفكير.» وقال آخر: «نموذج الأسعار مناسب لشيءٍ مثل هذا الكتاب، 2.99؟ لن أفكِّر كثيرًا قبل أن أدفع هذا المبلغ. 5.99 مقابل الحصول على خصائص إضافية؟ أنا حاليًا أدفع 2.99 دولار؛ ليس الفرق كبيرًا، كما أنَّني سأحصل على المزيد من المزايا؛ رائع!»؛ وقال ثالث: «أحبُّ طريقة هيكلة هذا الأمر. كان نموذج الأسعار مثاليًا تمامًا؛ خُذ أموالي». إذًا هناك أمران لهما دور هنا، الأوَّل أنّ نقطة السعر المنخفضة (2.99) كانت منخفضة بما يكفي لخلق دافعٍ للشراء ولم تُحفِّز آليات دفاع الناس المضادة للإنفاق. والثاني أن نقطة السعر الأعلى (5.99) كانت قريبة بما فيه الكفاية من النّقطة الأولى لجعل الناس يشعرون بأنَّهم طالما سيشترون الكتاب بأي حال، فعليهم أن يشتروا النسخة الأفضل. وتؤيِّد الإحصاءات ذلك، فعلى عكس ما توقَّعتُ اشترى أكثر الناس النسخة الفاخرة (758 نسخة، مقابل 718 من النسخ العادية). هكذا يعمل ارتساء الأسعار Price Anchoring، غالبًا ما يُقدِّم المُسوِّقون خيارات فاخرة بنقاط تسعير مرتفعة زائفة لجعل الخيار العادي يبدو أكثر جاذبيةً بالمقارنة معها (فكِّر في كل جداول خطط الأسعار ذات الخانة المُخصَّصة للشركات بسعر 1000 دولارٍ شهريًا، إلى جانب الخانة المُخصَّصة للمُستهلِك العادي بسعر 10 دولارات شهريًا). ولكن في حالتنا حدث العكس؛ فقد جعل تقارُب نقاط السعر الخيار الأعلى يبدو وكأنَّه صفقة رابحة. ومن ثمَّ أهديكم النظرية التالية في التّسعير: إذا كان الفرق بين السعرين كبيرًا جدًا، سيبدو السعر الأقلّ أكثر جاذبيةً، ولكن إذا كان الفرق صغيرًا، سيُصبِح السعر الأعلى الخيارَ الأفضل. من الصعب بالطبع تحديد حجم الدور الذي لعبه السّعر في نجاح الكتاب، وربما كنتُ سأجني أكثر إذا كانت تكلفة الكتاب الإلكتروني 0.99 دولارًا، أو إذا كانت 49.99 دولارًا، ولكنَّني سعيدٌ للغاية بالفعل بالمبيعات وبالمردود الذي حصلتُ عليه؛ لذا سأقاوم الرغبة المُغرية في طرح سؤال «ماذا لو؟»؛ فإذا أردتُ أن أعرف حقًا يمكنني دائمًا أن أؤلِّف كتابًا آخر. لذا أتمنَّى أن تُفكِّر للحظةٍ في الأسعار المُتاحة أمامك في المرة التالية التي تجد نفسك فيها مُستعدًّا للاشتراك في خطة برنامج حاسوب شهرية أو حتى للتسوُّق. ربما ستستطيع اكتشاف المنطق الخفي وراء تلك الأرقام. ترجمة -وبتصرّف- للمقال How Perfect Pricing got me 1500 Sales in 2 Days