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

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.

يمكنني القول بصراحةٍ أنني موظفٌ من النوع الذي يجب أن يُحاط بزملاءٍ يُكِنُّ لهم المودة حتى يؤديَ عمله بشكل أفضل؛ إن العمل بين أُناسٍ أُحبهم بصدق يجعل عملي أسهل بألفِ مرة. إني أرى أنّ وُجود أصدقاءٍ جيّدين في العمل يمكنُ أن تكونَ له فائدةٌ كبيرة، فهذا أمرٌ قد يُخفِّفُ بعضًا من التّوترِ الناتجِ عن ساعاتِ العملِ الطِّوال كما يمكن أن يُسهِّل التعامل مع الحالات والمواقف ذات الضغط العالي. لقد وجدنا إحصائيات رائعة تُثبتُ أنّ العمل مع مجموعة جيدة من الأصدقاء ليس فقط أمرًا جميلًا الحصولُ عليه بل يُمكن أن يجعل الجميع يعمل بشكل أفضل. 1. حياةٌ عمليّةٌ أفضل كثيرًا ما تكلمت سابقًا عن ضرورة موازنة حياتك في العمل مع حياتك خارجه وهذا لأنك إن استطعت فعل هذا، فسَتُخفف من وطأة التوتر بدرجةٍ كبيرة وسيصير المزجُ بين الحياتيْنِ سلِسًا، فكأنك المُحارب في ساحات الوغى تخوضُ كلما أشرقت الشمس معركةً ثم تخوض بعد ذلك مع زملائك في العمل دردشةً ليست بالضرورة مرتبطةً به. هذه الطبقة الإضافية من الراحة تجعل عملك أسهل. أنصحك أيضًا بقراءة كيف سيتغير مكان العمل خلال العقود المقبلة. 2. وجودُ الأصدقاء سيُحسّنُ من نسبة الاحتفاظ بالموظفين لن تهجُر مجموعة أصدقاءٍ تُحبهم صحيح؟ لن تقبل بعملٍ حتى ولو كان بأجرٍ مُرتفعٍ إن كنت لن تتآلف مع زملائك في العمل، مُعظم الذين جرت عليهم الدراسة بيّنوا أن قيمة العمل مع مجموعةٍ جميلةٍ متآلفةٍ من الأصحاب تعلو قيمة الأجرِ المرتفع. يمكنني القول إذن أن تكوين علاقات صداقة وثيقة داخل مكان العمل مع بناء ثقافة شركة جيدة أمرٌ جميل لاستبقاء الموظفين لديك، ومن أجل هذا احرص على أن تبذل قُصارى جُهدك في توظيف أشخاصٍ يتمتعون بملائمة ثقافية كبيرة. 3. تزيدُ من رضا الموظفين كما ترفع معنوياتهم عندما تكونُ بين الأصدقاء، ستعمل بشكلٍ أفضل وسترتفع معونياتك كما أنك ستجد نفسك قادرًا على أن تكون أكثر إنتاجيةً في العمل. أعتقد أن مجرد حقيقة أنه يمكنك مُداولةُ العمل باللعب مرةً سيجعلك أكثر إنتاجية، فمثلا أنا وشريكي التأسيسي دان نعملُ بجدٍّ كل يوم ولكننا لا ننسَ أخذ استراحةٍ قصيرة في منتصف النهار للاستمتاع قليلًا؛ أحيانًا تجدُنا نلعبُ تنس الطاولة وأحيانًا ألعاب الفيديو وأحيانًا أخرى نتكلم عما حدث ونتدارك ما فاتنا من أخبارٍ وشؤون حياةِ كلٍ منّا الشخصية، هذا يُخفف من شدة الإرهاق العقليّ الناتج عن الجلوس أمام الحاسوب طوال اليوم. 4. أصدقاءٌ أفضل = بناء ثقافة أفضل في الشركة كما أشرت سابقًا، كلما زاد عدد الأصدقاء في العمل، كانت ثقافة الشركة أو المكتب أفضل. يُمكن القولُ إذن أن كل العلاقات التي تعقدها في مكان العمل لا تجعل حياتك أفضل فحسب بل تُحسن بطريقة غير مباشرة ثقافة شركتك. 5. أفضل علاقات الصداقة تبدأ من مكان العمل فمثلا نحن مدمني العمل في مكتبنا كوّنا صداقاتٍ مع زملائنا في المكتب، ويمكنني القول أن جميع أفراد الفريق مقربون لبعضهم بعضًا ويربطنا رباطٌ وثيقٌ جدا. كان هناك فترةٌ من الزمنِ اعتقدت فيها أن مجموعة أصدقائي قد اكتملت في الكلية ولكني كُنت مخطئًا تمامًا، فتكوين الصداقات في العمل أمرٌ رائعٌ، لأنه على أعضاء الفريق التعرف على بعضهم بعضًا جيدًا حتى يَسهُل عليهم حلُّ المشكلات وإتمام العمل. 6. ثناءٌ أكثر من الزملاء كلما زاد عدد أصدقائك في مكان العمل، زاد الثناء. ثناءُ الزُّملاء يفعل العجب عندما يتعلق الأمر بالاعتراف بمجهوداتك المبذولة، وبدلًا من أن يأتي الثناءُ من الإدارة، يأتي من زُملائك من حولك، طبعا هذا لا يأخذ مكان إعتراف الإدارة فقيمة ثناءها لها وزنٌ أكبر ولكن اعتراف الزُّملاء يخدُمُ غرضًا قيِّمًا أيضًا. 7. وجود أصدقاء في مكان العمل أمرٌ جيدٌ لتنمية شخصك وجود أصدقاء في مكان العمل يُساعدك على النموّ كشخص وكمِهني، هذا طبعًا لوجود أشخاص يُحفِّزونك ويُشعرونك بالراحة أيضًا. لذلك أبقِ أصدقاءك في العمل قريبًا منك لأنهم يُساعدونك في النمو كشخص وكموظف. 8. جودةُ عملٍ أفضل نعم هذا صحيح، العمل مع الأصدقاء يُحسّنُ من جودة عملك. سأفترض أن هذا يحدُث بسبب مراجعة ونقد أقرانك في العمل كما يمكن أن يحدُث لأنك تُريدُ أن تُريَهم بأن أدائك جيد فتتفوق في أداء المهمات الموكلة إليك، فآخر شيءٍ تُريده هو أن تكونَ أنت العضو المترهّل في المجموعة. من المؤكد إذن أن وُجود أصدقاءٍ في العمل سيُساعدك على التفوق وتقديم أفضل ما لديك. 9. ستتلقّى ردود فعلٍ أكثر على الأقل هنا في مكتبنا، نُبقي ردودَ الفعلِ مستمرة؛ فإن وجدنا شيئًا يُمكنُ تحسينه، نبذل قُصارى جهدنا في إصلاحه واختباره. هنا في المكتب، نستخدم ملاحظات الموظفين للحفاظ على سيرِ الأمور، أراه من المهم جدًّا الحصول على رأي وملاحظات أقرانك لتتفوق وتُنجز أكثر، لقد اكتشفنا أننا بالمحافظة على النقد المستمر نحن أكثر حماسًا وإبداعًا وابتكارًا. 10. كسبُ احترامٍ أكبر من الزُّملاء لأنك تعملُ بين الأصدقاء، ستميل إلى احترامهم، ولن تسوء الأمور إلا إذا كنتم تتابعون نفس دوري كرة القدم، ولكن عدا هذا ستكون الأمور على ما يُرام. فأنت عندما تعمل مع زُملاءٍ تُحبهم سيكون الاحترامُ متبادلًا؛ تمنحه وتتلقاه، وإذا طلبت من أحدهم إتمام مهمة فكأنك طلبت منه إسداء خدمةٍ أو معروفٍ إليك، لذلك أبقِ بيئة العمل وكأن مجموعة من الأصدقاء يعملون على مشروعٍ مشترك. 11. ستستمتع أكثر وأنت في العمل أكثر من ضعف الأشخاص الذين تمت عليهم الدراسة قالوا أنه لديهم الفرصة لتقديم أفضل ما لديهم كل يوم. إن المعادلة بسيطة؛ عندما تعمل مع الأصدقاء فإنك ستستمتع أكثر بهذه الوظيفة، ولا يوجد أي عيبٍ في هذا. لنتكلم بصراحة، كثيرٌ من الوظائفِ مملةٌ ومرهقة ولكن إن نحن خُضناها مع الأصدقاء فستصير أسهل. لماذا قد تقضي وقتك في عملٍ لا تستمتع به؟ أو مع زملاءٍ لا تُحبهم حقًّا؟ ابدأ في تكوين صداقاتٍ في مكان عملٍ واخلق بيئة رائعة وممتعة تُسهّل على الجميع العمل. ترجمة بتصرف لمقال Why Having Friends at Work is Important للكاتب Jeff Fermin

الشير بوينت هو منصّة تشاركيّة تعمل كتطبيق ويب. يمكن لأيّ شركة تستخدم شير بوينت في عملها إنشاء مواقع ويب websites خاصّة بها متاحة للعموم على الإنترنت، أو مخصّصة لموظّفيهما على الإنترانت intranet أو مزيج بينهما. يمكن من خلال أيّ موقع في شيربوينت مشاركة الملفات والصور والمستندات بمختلف أنواعها بين مستخدمي هذا الموقع، والتحكّم بإصداراتها من خلال ميّزة سجل الإصدار Version History التي سنتحدّث عنها لاحقًا في هذا المقال. كما يسمح شير بوينت بالاستغناء عن التعاملات الورقيّة ضمن الشركة، وذلك من خلال مستويات الصلاحيّات التي يوفّرها للمستخدمين، ودعمه مهام سير العمل Workflow الذي يسمح بإجراء موافقات متسلسلة على معاملة أو طلب إجرائي خاص بالشركة. كما تدعم مواقع ويب المُنشأة بواسطة شير بوينت المهام الروتينيّة التي تتمتّع بها أنظمة إدارة المحتوى. سنتناول في هذه السلسلة طريقة تنصيب شير بوينت لاستثماره بالشكل الأمثل. وهي عمليّة ليست بسيطة كعمليّة تنصيب تطبيق عادي. حيث سنمرّ بسلسلة من الإجراءات والعمليّات التي ستجري على أكثر من خادوم لتحقيق هذه المهمّة. تُعتبر هذه السلسلة موجّهة إلى مسؤولي تقنيّة المعلومات الذين يحتاجون إلى تنصيب شير بوينت على الخواديم الخاصّة بشركاتهم. ومن الممكن أن يستفيد من هذه السلسلة أيضًا الأشخاص المهتمّون بشير بوينت والذين لا يمتلكون بنية عتاديّة مناسبة لتصيبه، حيث يمكن استخدام آلات افتراضيّة virtual machines لهذا الغرض مثل VMware (وهو الأفضل برأيي) أو VirtualBox أو Hyper-V (يأتي مع Windows Server 2012 ولكنّه يحتاج إلى تفعيل)، ولكن ينبغي أن يكون الحاسوب الذي سيشغّل هذه الآلات الافتراضيّة ذا مواصفات جيّدة، أنصح بالحدّ الأدنى أن يكون المعالج Intel Core i5 الجيل السادس أو الخامس، والذاكرة 16 GB. يمكن استخدام مواصفات أقل، ولكنّ ربما ستعاني من ضعف الأداء. يُعتبر التطبيق App حجر البناء الأساسي في مواقع شير بوينت. قد يكون التطبيق عبارة عن مكتبة صور أو مكتبة مستندات أو قائمة مهام أو قائمة جهات الاتصال، أو حتى من الممكن أن يكون عبارة عن قائمة قابلة للتخصيص يمكنك بناؤها بالشكل الذي ترغبه (تشبه القائمة المخصّصة إلى حدٍّ كبير بنية جدول في قاعدة بيانات). جميع أنواع التطبيقات الذي ذكرناها قبل قليل هي تطبيقات افتراضية يمكن إضافتها إلى الموقع بعد إنشائه. يمكنك بالطبع إنشاء أكثر من تطبيق من التطبيقات السابقة في موقع شير بوينت بحسب الحاجة. كما أنّه من الممكن الحصول على تطبيقات من مصادر أخرى توفّر المزيد من المزايا، وقد تكون هذه التطبيقات مجّانيّة أو مدفوعة. قسم من المحتويّات الافتراضية لموقع شير بوينت. تطبيقات شير بوينت الأساسيّة سنتحدّث في هذه الفقرة عن عدد من التطبيقات الأساسيّة الافتراضيّة المهمّة في شير بوينت، والتي ستحتاج في الغالب إلى أحدها بصرف النظر عن نوع الموقع الذي ستنشئه. القوائم الافتراضيّة هناك عدّة قوائم من أهمّها: قائمة جهات الاتصال، وقائمة الإعلانات، وقائمة المهام، وقائمة التعقّب issue tracking وغيرها. يمكن من خلال قائمة جهات الاتصال تخزين البيانات الشخصيّة وبيانات الاتصال لأيّ موظّف في الشركة أو لأيّ زبون لها، كما يمكن ربط هذه القائمة مع تطبيقات أخرى مثل Microsoft Outlook وMicrosoft Access للحصول على بيانات موجودة مسبقًا دون الحاجة لإعادة إدخالها. تفيد قائمة الإعلانات في وضع إعلانات مخصّصة لأعضاء الموقع، فعندما نريد الإعلان عن أمر ما يخصّ الشركة، فليس من الضروري إرسال رسائل البريد الإلكتروني إلى الموظّفين، حيث من الممكن وضع إعلان ضمن قائمة الإعلانات ليشاهده الجميع، كما تحتوي هذه القائمة على حقل انتهاء الصلاحيّة للإعلان، وحقل يوضّح المستخدم الذي أنشأ الإعلان وحقل أيضًا للمستخدم الذي عدّله (في حال قم أحد ما بتعديله). بالنسبة لقائمة المهام فيمكن من خلالها إسناد المهام لموظّفي الشركة فيما يتعلّق بإنجاز مهمّة أو مشروع ما. حيث من الممكن إسناد الأولويّة في تنفيذ المهمّة ونسبة الإنجاز المحقّقة لها. أمّا قائمة التعقّب فاستخدامها مفيد في المهام التي تتطلّب المتابعة. المكتبات الافتراضيّة تضمّ عدّة مكتبات مثل مكتبات المستندات والنماذج والصور. بالنسبة لمكتبة المستندات فمن الممكن أن تعتبرها كمجلّد عادي من مجلّدات نظام التشغيل Windows، ولكنّها تتمتّع بمزايا مهمّة. حيث يمكن حماية أي مستند من خلال تحديد صلاحيّات الوصول والتعديل والقراءة لهذا المستند. توجد أيضًا ميزة السحب check-out وميزة الإيداع check-in للمستند. تضمن هاتان الميّزتان أنّ هناك مستخدم واحد فقط يُعدّل المستند في لحظة ما. يمنع ذلك المشاكل التي قد تنجم عن تعديل المستند من قِبَل عدّة مستخدمين بنفس الوقت. ملاحظة تسمح ميزة سجل الإصدار Version History بالاحتفاظ بنسخة كاملة من التعديلات التي أُجريت على أيّ ملف أو مُدخَل مع تحديد المستخدم والتوقيت والتعديل الذي قام به، مع إمكانيّة استعادة أي نسخة قديمة منهما. وهذه الميزة مشتركة بين القوائم والمكتبات مهام سير العمل Workflow يمكن استخدام مهام سير العمل ضمن تطبيقات شير بوينت، وهي تسمح بالتحكّم في آلية العمل ضمن التطبيقات التي نضيفها إلى مواقع شير بوينت. فيمكن على سبيل المثال أن نُرسل بريدًا إلكترونيًّا عند إضافة مُدخل لإحدى القوائم، أو أن نضيف بعض البيانات بشكل تلقائيّ على مُدخلٍ في قائمة أخرى. أي شيء يشبه البرمجة ولكن بدون أن تكون لك خبرة مسبقة بأيّ لغة برمجة، فكل ما تحتاجه هو تطبيق SharePoint Designer الذي يسمح لك بالتعامل مع مهام سير العمل، وتجهيزها ونشرها إلى أيّ موقع ضمن منصّة شير بوينت. كما يسمح لك هذا التطبيق بإنشاء وتعديل أيّ جزء من الموقع، بما فيها صفحات الموقع. يأتي هذا التطبيق بشكل منفصل ويمكن تنصيبه والاستفادة من المزايا التي يوفّرها. من الممكن أيضًا دمج ميّزة الموافقات Approvals مع مهام سير العمل، بحيث يصبح من السهل التحكّم بالعمليّات الإداريّة التي تحدث ضمن شركة ما، وذلك من خلال تجهيز الموافقات لتتوافق مع البنية الهرميّة الإداريّة للشركة. ملاحظة من الممكن أيضًا التحكّم في آلية عمل مواقع شير بوينت بشكل تفصيليّ دقيق من خلال كتابة تطبيقات مخصّصة لشير بوينت باستخدام لغة البرمجة سي شارب C# وتطبيق Visual Studio من مايكروسوفت. يوجد شرح في موقع أكاديميّة حسّوب حول شهادة MCSD – مطوّر حلول باستخدام شير بوينت، وكذلك سلسلة دروس خاصّة بتعليم لغة سي شارب. وضع شير بوينت بالنسبة لعالم الأعمال في الحقيقة لا يمكن مقارنة شير بوينت من حيث عدد المواقع التي تستخدمه مع أنظمة إدارة محتوى أخرى مثل WordPress وJoomla وDrupal. فهذه الأنظمة تتفوّق عليه بسهولة (في الوقت الراهن) من ناحية الاستخدام. إلّا أنّ شير بوينت يتّجه إلى أن يكون مسيطرًا في الشركات الكبيرة، والتي تتطلّب مواقعها حركة مرور كبيرة. مثل هذه الشركات الكبيرة تدفع بالتأكيد رواتب ممتازة! فيما يخص المنطقة العربية، تُعتبر أسواق مجلس التعاون الخليجي نهمةً لمنصّة شير بوينت، وهي ترغب بكلّ تأكيد برفد طواقمها بخبراء في شير بوينت. يمكنك باستطلاع بسيط في بوابات التوظيف الكبيرة التي تغطّي أسواق العمل في الخليج، لترى مدى الطلب عليه. يُصنّف العمل في شير بوينت في عدّة اتجاهات من أهمّها: اتجاه الإدارة والصيانة Administration واتجاه التطوير البرمجي Development والتخصيص Customization، وغيرها من الاتجاهات الأخرى. إصدارات SharePoint النسخة الأحدث من شير بوينت هي SharePoint 2016 لكنّها حديثة جدًّا (عمرها بضعة أسابيع فقط) ولا يبدو أنّ الشركات ستنتقل إليها مباشرةً في المدى القريب، لأنّ الانتقال عمليّة تحتاج إلى تخطيط وتجهيز وليست مجرّد ترقية عاديّة. الإصدار المهيمن حاليًا من شير بوينت هو SharePoint 2013 وهو المستَخدم في أغلب الشركات. يأتي هذا الإصدار بنسختين رئيسيّتين: إصدار SharePoint 2013 Foundation: وهو مجّاني يمكن تحميله من موقع مايكروسوفت. يضم هذا الإصدار المزايا الأساسيّة لشير بوينت. إصدار SharePoint 2013 Server: وهو مدفوع، لكن يمكن تحميله على سبيل التجريب لمدة ستة أشهر. يضم هذا الإصدار المزايا الكاملة لشير بوينت. يُعتبر شير بوينت تطبيقًا نهمًا للعتاد الصلب، ويتطلّب العمل مع شير بوينت وجود خادومين على الأقل، حيث تعود المتطلّبات الفعليّة للعتاد الصلب حسب حجم الشركة. في الحقيقة توفّر شركة مايكروسوفت حلًا جاهزة يتمثّل باستضافة منصّة شير بوينت على السحابة. حيث يتوفّر شير بوينت ضمن خدمة Office 365 السحابيّة. من الممكن للشركات الصغيرة أن تستفيد من هذا الحل الجيّد، وتتخلّص من تكاليف إنشاء وإدارة وشراء التراخيص اللازمة لتشغيل نسخة شير بوينت مخصّصة. أمّا بالنسبة للشركات المتوسّطة والكبيرة فقد يكون من المناسب أكثر اعتماد تشغيل منصة شير بوينت بشكل محلّي على خواديم مخصّصة. ملاحظة سنتناول في هذه السلسلة طريقة تنصيب الإصدار SharePoint 2013 Server. الخلاصة تعرّفنا في هذا الفصل على شير بوينت، ذلك التطبيق المهم الذي دخل عالم الأعمال من أوسع أبوابه. سنتناول تباعًا في هذه السلسلة طريقة تنصيبه خطوة بخطوة مع الشرح المفصّل مدعومًا بالصور، مع نصائح مهمّة ستجعلك مرتاحًا في المستقبل عند البدء باستثمار شير بوينت. ولكن قبل كلّ ذلك سيتناول المقال التالي البنية الهيكليّة لشير بوينت حيث سنتعرّف على الأشكال المحتملة لهذ التطبيق بمميّزاتها ومساوئها أثناء التشغيل في بيئة العمل.