التحديث 11/03/08: تأكد من قراءة هذا التعليق الممتاز ومفصلة من لونسفورد ديسي لهذا المنصب.

لقد كنت أعمل على مشروع تحرير تكنولوجيا سرية لكتاب القادمة ومن مراجع هذا بلوق دخول تايلر بتلر على بلوق MSDN إدارة المحتوى في المؤسسة. وهذه هي المرة الأولى قرأت شخصيا وضع تعريف واضح لمعنى "الوصول المحدود". هنا هو لحوم تعريف:

في SharePoint, المستخدمون المجهولون’ تتحدد حقوق مستوى إذن "الوصول المحدود". وصول محدود هو مستوى أذونات خاصة التي لا يمكن تعيين إلى مستخدم أو مجموعة مباشرة. أنها موجودة والسبب أنه إذا كان لديك مكتبة أو موقع فرعي التي قد كسرت توريث الأذونات, ويمكنك السماح لمستخدم/مجموعة وصول إلى فقط أن المكتبة/فرعي, من أجل عرض محتوياته, يجب أن يكون المستخدم/المجموعة بعض الوصول إلى موقع ويب الجذر. وإلا سيكون المستخدم/المجموعة غير قادر على استعراض المكتبة/فرعي, على الرغم من أن لديهم حقوق هناك, لأن هناك أشياء في صفحة ويب الجذر أن هناك حاجة إلى تقديم موقع أو مكتبة. ولذلك, عند إعطاء أذونات مجموعة فقط إلى موقع فرعي أو المكتبة التي يتم كسر توريث الأذونات, سيعطي SharePoint تلقائياً "وصول محدود" لتلك المجموعة أو المستخدم على موقع ويب الجذر.

يأتي هذا السؤال الآن، وبعد ذلك في منتديات MSDN وكانت دائماً غريبة (ولكن غريبة لا يكفي ذلك الرقم قبل اليوم :)).

</نهاية>

الاشتراك في بلادي بلوق.

اتبعني على التغريد في http://www.twitter.com/pagalvin

في إشارة إلى أن "الحوسبة الاجتماعية" هو بداية للإقلاع مع SharePoint, أرى زيادة عدد الأسئلة نوع "الموقع الخاص بي". سؤال مشترك واحد غنى شيئا من هذا القبيل:

"أنا مسؤول، بحاجة لأن تكون قادرة على الوصول إلى كل" الموقع الخاص بي ". كيف نفعل ذلك?"

الحيلة هنا أن كل "موقع بلدي" هو مجموعة الموقع الخاصة به. الأمن SharePoint عادة تدار على مستوى مجموعة الموقع وهذه الرحلات حتى العديد من مسؤول SharePoint. عادة, وقالت أنها لديها بالفعل الوصول تكوين الأمان بصورة رئيسية "" موقع مجموعات وقد لا يدركون أن هذا لا يعمل تلقائياً "المواقع الخاصة بي".

تعيش مجموعات الموقع جماعياً داخل حاوية أكبر, وهو تطبيق ويب. مزرعة المسؤولين يمكن يمكن تكوين الأمان على مستوى التطبيق ويب وهذا كيف المشرفين يمكن منح أنفسهم الوصول إلى أي مجموعة موقع في تطبيق ويب. ويصف هذا بلوق دخول واحدة من تجربتي الشخصية مع سياسات تطبيق ويب. أنا تعريف سياسة تطبيق ويب عن طريق الصدفة: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

سياسات تطبيق ويب يمكن أن تكون خطيرة، واقترح أنه يمكن استخدام ماما. إذا كان لي من قبل مسؤول (والحمد لله أنا لا), أنا سوف إنشاء حساب منفصل لإعلان المسمى شيئا مثل "مسؤول التطبيق ويب SharePoint" وإعطاء دور الأمان تطبيق ويب فإنه يحتاج أن حساب واحد. غير أن تكوين هذا النوع من الشيء لمسؤول المزرعة العادية أو مدراء مجموعة الموقع الفردية. سوف تميل إلى إخفاء المشاكل المحتملة لأن دور التطبيق ويب يتجاوز أية إعدادات أمان مستوى أقل.

</نهاية>

الاشتراك في بلادي بلوق.

اتبعني على التغريد في http://www.twitter.com/pagalvin

التحديث (02/29/08): ويبدو هذا المشروع [كدبلاكس] جديدة لتوفير وسيلة لتأمين الأعمدة الفردية: http://www.codeplex.com/SPListDisplaySetting. إذا كان لديك أي خبرة في العمل معها, يرجى ترك تعليق.

ملصقات المنتدى كثيرا ما اسأل سؤالاً مثل هذا: "لقد رأي مدير وعرض قائمة موظفين. كيفية تأمين عرض إدارة حيث أن الموظفين لا يمكن استخدامه?"

أنها أيضا كثيرا ما اسأل سؤالاً ذات الصلة: "أريد أن يكفل عمود البيانات الفوقية محددة لكي يمكن للمدراء فقط يمكن تحرير هذا العمود بينما آخرون قد لا ترى حتى أنه."

هذه الإجابات التي تنطبق على كلا WSS 3.0 ومعايير العمل الأمنية الدنيا:

• SharePoint لا توفر الدعم خارج المربع للحصول على وجهات النظر.
• لا يوفر SharePoint خارج نطاق صندوق الدعم لأعمدة الأمن.

وهناك عدة تقنيات واحد يمكنك اتباعها لمواجهة هذه الأنواع من متطلبات الأمن. هنا ما يمكنني أن أفكر في:

• استخدام تأمين مستوى العنصر خارج منطقة الجزاء. تكريم وجهات النظر دائماً تكوين الأمان على مستوى الصنف. مستقبلات الأحداث و/أو سير العمل يمكن أتمتة المهمة الأمنية.
• استخدام طرق عرض شخصية "شرف" طرق عرض. هذه سهلة ما يكفي لإعداد. ومع ذلك, بسبب الشخصية "" طبيعة, وهذه تحتاج إلى تكوين لكل مستخدم. استخدام تكوين الأمان القياسية لمنع أي شخص آخر من إنشاء طريقة عرض شخصية.
• استخدم جزء ويب طريقة عرض بيانات وتنفيذ بعض نوع من الحل الأمني AJAXy التشذيب.
• لفة وظيفة عرض القائمة الخاصة بك وتتضمن اقتطاع للأمان على مستوى العمود.
• تعديل نماذج إدخال البيانات واستخدام جافا سكريبت بالتزامن مع نموذج الأمان لتطبيق أمان على مستوى المستخدم العمود التشذيب.
• استخدام نموذج InfoPath لإدخال البيانات. تطبيق اقتطاع الأمان على مستوى العمود عبر استدعاءات خدمة ويب SharePoint وافراجا مشروطاً إخفاء الحقول حسب الحاجة.
• لفة الخاصة بك وظيفة إدخال البيانات ASP.NET ينفذ التشذيب أمان مستوى العمود.

أيا من تلك الخيارات حقاً كبيرة, ولكن هناك على الأقل مسار لمتابعة إذا كنت بحاجة إلى, وحتى إذا كان من الصعب.

ملاحظة: إذا كنت اذهب إلى أسفل أي من هذه المسارات, لا تنسى حول "الإجراءات:-> فتح باستخدام مستكشف Windows ". تريد أن تتأكد من أن تقوم باختبار مع هذه الميزة للتأكد من أنها لا تعمل باب الخلفي "" وهزيمة نظام الأمن الخاص بك.

إذا كان لديك أفكار لأخرى أو تجارب مع تأمين الأعمدة أو وجهات النظر, الرجاء أرسل لي أو ترك تعليق وسوف أقوم بتحديث هذا الترحيل حسب الاقتضاء.

</نهاية>

الاشتراك في بلادي بلوق.

التحديث: نشرت هذه المسألة إلى MSDN هنا (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) والوشم Michael مايكروسوفت ورد بإجابة مختصرة.

أنا خلقت خدمة ويب بمثابة واجهة BDC صديقة إلى قائمة SharePoint. عند استخدام هذا من بلدي بيئة التطوير, عملت غرامة. عندما أنا هاجرت هذه إلى ملقم جديد, هذا خطأ:

هنا خط 69:

استخدام (موقع SPSite = SPSite جديد("http://localhost/sandbox"))

حاولت الأشكال المختلفة على عنوان URL, بما في ذلك استخدام اسمه الحقيقي على الملقم, عنوان ip الخاص به, مائلين زائدة على عنوان URL, إلخ. حصلت دائماً على هذا الخطأ.

وكنت انتظر جوجل للبحث. الكثير من الناس يواجهون هذه المشكلة, أو صيغ مختلفة, ولكن لا أحد يبدو أن يكون حل.

موس تريكسي قدمت هذه مفصلة الخطأ الذي لم يحدث بالنسبة لي للتحقق من 12 سجلات خلية. في نهاية المطاف, حول 24 بعد ساعات من زميلي أوصى كنت تفعل ذلك, راجعت خارج 12 خلية السجل، ووجدت أن هذا:

حدث استثناء أثناء محاولة الحصول على المزرعة المحلية:
System.Security.SecurityException: غير مسموح بالوصول إلى التسجيل المطلوبة.
في System.ThrowHelper.ThrowSecurityException(الموارد اكسسيبتيونريسورسي) في Microsoft.Win32.RegistryKey.OpenSubKey(اسم السلسلة, منطقية للكتابة) في Microsoft.Win32.RegistryKey.OpenSubKey(اسم السلسلة) في Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() في Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() في Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& المزرعة, قيمة منطقية& إيسجوينيد)
وكانت المنطقة من الجمعية العامة بأن فشل:  جهاز الكمبيوتر

هذا وفتح آفاقاً جديدة للبحث, لذا فإنه يعود إلى Google. التي دفعتني إلى هذا وظيفة المنتدى: http://forums.codecharge.com/posts.php?post_id = 67135. أن لم تساعد حقاً لي ولكن يبدأ تجعلني أعتقد أن هناك مشكلة في قاعدة البيانات و/أو الأمن. أنا واظب و أندرو Connell نشر أخيرا المشغلة يعتقد أنه ينبغي أن أتأكد من أن حساب هوية تجمع التطبيق حق الوصول المناسب إلى قاعدة البيانات. وأعتقد أنه بالفعل. ومع ذلك, زميلي ذهب، وأعطى في التطبيق تجمع هوية حساب الوصول الكامل إلى SQL.

كما أدلت بهذا التغيير, كل شيء بدأ العمل.

ماذا حدث بعد أفضل محسوباً قصائد شعر الهايكو قصيدة:

مشاكل رفع أيديهم.
يمكنك سوينغ وملكة جمال. حاول مرة أخرى.
النجاح! لكن كيف? لماذا?

وقالت أنها لم أكن أريد ترك الأمور وحدها مثل هذا, مفضلة لإعطاء الإذن المطلوب الحد الأدنى (وربما مع التطلع إلى كتابة إدخال مذكرات على الويب; يضربها لكمه, موهاهاهاهاها!).

وقالت إزالة أذونات المتعاقبة من حساب هوية تجمع التطبيق حتى … لم تعد هناك أي إذن صريح لحساب هوية تجمع التطبيق على الإطلاق. تواصل خدمة ويب تعمل على ما يرام.

ذهبنا وتمهيد الملقمات. واصل كل شيء يعمل بشكل جيد.

حتى, باختصار: ونحن أعطت هوية تجمع التطبيق الوصول الكامل وثم استغرق بعيداً. خدمة ويب وبدأ عمله وابدأ توقفت عن العمل. غريبة.

إذا كان أحد يعرف لماذا التي ينبغي أن عملوا, يرجى ترك تعليق.

</نهاية>

كنت بحاجة للوفاء بمتطلبات الأمنية لنموذج InfoPath اليوم. وفي هذه الحالة التجارية, عدد قليل نسبيا من الأفراد مسموح بإنشاء نموذج InfoPath جديد وجمهور أوسع نطاقا بكثير مسموح لتحريره. (هذا هو تأجير جديد على الصعود النموذج المستخدمة من قبل الموارد البشرية التي تطلق سير العمل).

ولتحقيق هذا الهدف, أنا إنشاء مستويات إذن جديدة اثنين تم إنشاؤها ("إنشاء وتحديث" و "تحديث فقط"), كسرت الميراث في مكتبة النماذج، وتعيين الأذونات "إنشاء, التحديث" المستخدم ومنفصلة "تحديث فقط" المستخدم. وعملت جميع ميكانيكا, إلا أنه تبين أن إشراك أكثر قليلاً من المتوقع. (إذا كنت تشعر قليلاً هشة على أذونات SharePoint, تحقق من هذا بلوق وظيفة). تكوين الأمان المطلوبة لمستوى الإذن لم تكن واضحة مجموعة الأذونات الحبيبية. لإنشاء مستوى إذن التحديث فقط لنموذج InfoPath, لقد فعلت ما يلي:

1. إنشاء مستوى أذونات جديدة.
2. إزالة جميع الخيارات.
3. تحديد التالية فقط من "قائمة الأذونات":

• تحرير عناصر
• عرض العناصر
• عرض صفحات التطبيق

تحديد هذه الخيارات تسمح لمستخدم بتحديث نموذج, ولكن ليس بإنشائه.

وكان الخدعة لتمكين "عرض الصفحات التطبيق". ليس هناك أي فيرباجي على مستوى الإذن الذي يشير إلى أنه قد يلزم لنماذج InfoPath تحديث فقط, لكن يتحول إلى أنه هو.

إنشاء وتحديث كان أكثر غرابة. اتبعت نفس الخطوات, 1 من خلال 3 أعلاه. كان على وجه التحديد إضافة أذونات الموقع "" الخيار: "استخدام ميزات تكامل العميل". مرة أخرى, وصف هناك لا يجعل الأمر يبدو وكأنه يجب أن تكون مطلوبة من أجل نموذج InfoPath, ولكن هناك.

</نهاية>

التحديث 01/28/08: ويعالج هذا المشروع codeplex هذه المسألة: http://www.codeplex.com/AccessChecker. أنا لم تستخدم, ولكن تبدو واعدة إذا كانت هذه هي قضية تحتاج إلى معالجة في البيئة الخاصة بك.

التحديث 11/13/08: كتبت جويل Oleson وظيفة جيدة جداً على أكبر قضية إدارة الأمن هنا: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?قائمة = 0cd1a63d% 2D183c% 2D4fc2% 2 د ٪ 8320 2Dba5369008acb&معرف = 113. أنه يرتبط بعدد من موارد أخرى مفيدة.

منتدى المستخدمين والعملاء غالباً ما اطرح سؤالاً على طول هذه الخطوط: "كيف أنا توليد قائمة من كافة المستخدمين بالوصول إلى موقع" أو "كيف يمكن أنا تلقائياً تنبيه كافة المستخدمين الذين لديهم حق الوصول إلى قائمة حول التغييرات التي تم إجراؤها على قائمة?"

وهناك لا للخروج من مربع الحل لهذا. إذا كنت تفكر في ذلك للحظة واحدة, ليس من الصعب أن نفهم لماذا.

الأمن SharePoint مرن جداً. وهناك على الأقل أربع فئات رئيسية من المستخدمين:

• المستخدمون المجهولون.
• مستخدمي SharePoint ومجموعات.
• مستخدمي Active directory.
• مصادقة النماذج (FBA) المستخدمين.

المرونة تعني أن من منظور أمني, أي موقع SharePoint معينة سوف تكون مختلفة إلى حد كبير عن آخر. لإنشاء تقرير access قائمة, ويحتاج المرء للتأكد من كيفية تأمين الموقع, استعلام المستخدم مختلفة متعددة الشخصية مستودعات وثم تقديمها بطريقة مفيدة. وهذا مشكلة صعبة لحل عموما.

كيف تتعامل مع هذه المنظمات? أحب أن أسمع منكم في التعليقات أو البريد الإلكتروني.

</نهاية>

التحديث 12/18/07: انظر المادة بول ليبراند 's عن بعض النتائج التقنية لإزالة أو تعديل أسماء المجموعات الافتراضية (انظر تعليقه أدناه، فضلا عن).

نظرة عامة:

الأمن SharePoint سهلة لتكوين وإدارة. ومع ذلك, قد ثبت أن صعبة لبعض المسؤولين المرة الأولى حقاً التفاف أيديهم حوله. ليس هذا فقط, لقد رأيت بعض المسؤولين التوصل إلى فهم الكمال يوم الاثنين إلا فقدت يوم الجمعة لأنه لم يكن لديهم للقيام بأي تكوين في الفترة الفاصلة. (اعترف بوجود هذه المشكلة نفسي). هذا بلوق دخول نأمل أن يوفر تمهيدي أمن SharePoint مفيدة ويشير نحو تكوين الأمان بعض أفضل الممارسات.

ملاحظة هامة:

ويستند هذا الوصف من خارج منطقة الجزاء الأمن SharePoint. تجربتي الشخصية هي الموجه حول موس حيث قد يكون هناك بعض الأشياء المحددة موس هنا, ولكن أعتقد أنها دقيقة ل WSS. ويحدوني الأمل في أن أي شخص رؤية أي أخطاء أو إغفاﻻت وسوف نشير أنه في تعليقات أو أرسل لي. سوف يجعل تصحيحات وظيفة العجلة.

أساسيات:

لأغراض هذه النظرة العامة, وهناك أربعة جوانب أساسية للأمن: مستخدمون/مجموعات, الكائنات القابلة للتأمين, مستويات الأذونات والميراث.

المستخدمين والمجموعات كسر وصولاً إلى:

• المستخدمين الفرديين: انسحبت من النشطة دليل أو تم إنشاؤه مباشرة في SharePoint.
• المجموعات: تم تعيينها مباشرة من خدمة active directory أو التي تم إنشاؤها في SharePoint. المجموعات مجموعة من المستخدمين. المجموعات العالمية في مجموعة الموقع. أنهم ابدأ "مرتبطة" لكائن قابل للتأمين المحددة.

الكائنات القابلة للتأمين كسر وصولاً إلى مالا يقل عن:

• مواقع
• مكتبات المستندات
• العناصر الفردية في القوائم ومكتبات المستندات
• المجلدات
• إعدادات BDC مختلف.

هناك أخرى الكائنات القابلة للتأمين, ولكن يمكنك الحصول على الصورة.

مستويات الأذونات: باقة من الحبيبية / حقوق الوصول إلى مستوى منخفض تتضمن أشياء مثل إنشاء أو قراءة أو حذفها الإدخالات في القوائم.

الميراث: بشكل افتراضي الكيانات ترث إعدادات الأمان على الكائن التي تحتوي على. المواقع الفرعية ترث الأذونات من موقعها الأصل. مكتبات المستندات ترث من موقعهم. هكذا، وهكذا دواليك.

تتعلق بالمستخدمين والمجموعات للكائنات القابلة للتأمين عبر مستويات الأذونات والميراث.

قواعد الأمن الأكثر أهمية فهم, من أي وقت مضى 🙂 :

1. المجموعات مجرد مجموعات من المستخدمين.
2. المجموعات عالمي داخل مجموعة الموقع (الأول-هاء. لا يوجد أي شيء من هذا القبيل كمجموعة تعريفها على مستوى الموقع).
3. لا تحمل اسم المجموعة, مجموعات لا, في ومن أنفسهم, أي مستوى معين من الأمن.
4. لدى المجموعات الأمنية في سياق كائن قابل للتأمين المحددة.
5. قد يمكنك تعيين مستويات مختلفة من الأذونات للمجموعة نفسها لكل كائن قابل للتأمين.
6. سياسات تطبيق الويب تبز كل هذا (انظر أدناه).

مسؤولي الأمن فقدت في بحر قوائم المستخدم والمجموعة يمكن دائماً الاعتماد على هذه البديهيات إدارة وفهم على تكوين الأمان.

المخاطر الشائعة:

• أسماء المجموعة زورا يعني إذن: من خارج منطقة الجزاء, تعريف SharePoint مجموعة من مجموعات أسماؤها يعني مستوى الملازمة للأمن. النظر في مجموعة "المساهمين". واحد غير مألوف مع الأمن SharePoint قد ننظر في هذا الاسم جيدا ونفترض أن أي عضو من أعضاء هذا الفريق يمكن أن "يسهم" إلى أي موقع/قائمة/مكتبة في المدخل. قد يكون ذلك صحيحاً ولكن ليس لأن اسم المجموعة يحدث أن تكون "المساهم". هذا صحيح فقط من خارج منطقة الجزاء لأن الفريق قدم مستوى إذن تمكنهم من إضافة/تحرير/حذف المحتوى في الموقع الجذر. عن طريق الوراثة, أن المساهمين "" المجموعة قد أيضا إضافة/تحرير/حذف المحتوى في كل موقع فرعي. واحد يمكن أن "كسر" سلسلة الوراثة وتغير مستوى الأذونات من موقع فرعي من هذا القبيل أن أعضاء ما يسمى "المساهم" لا يمكن أن تسهم المجموعة على الإطلاق, ولكن للقراءة فقط (فعلى سبيل المثال). هذا لن يكون فكرة جيدة, ومن الواضح أن, نظراً لأنه سيكون مربكاً للغاية.
• لم يتم تعريف مجموعات على مستوى الموقع. فمن السهل أن يتم الخلط بين واجهة المستخدم. Microsoft توفر وصلة مريحة لإدارة المستخدم/المجموعة عبر "الأشخاص والمجموعات موقع كل" وصلة. فمن السهل أن نرى أنه عندما أكون في موقع "xyzzy" وإنشاء مجموعة من خلال الناس ل xyzzy، وربط المجموعات التي أنشأتها فقط مجموعة موجود فقط في xyzzy. وهذا ليس الحال. لقد قمت بإنشاء مجموعة لمجموعة الموقع كله فعلا.
• عضوية المجموعات لا تختلف حسب الموقع (الأول-هاء. أنه هو نفسه في كل مكان يتم استخدام المجموعة): النظر في مجموعة "مالك" وموقعين, "الموارد البشرية" و "تسويق". فإنه سيكون من الطبيعي أعتقد أن الشخصين منفصلة سوف تملك تلك المواقع — مالك الموارد بشرية ومالكا للنقل والإمداد. واجهة المستخدم يجعل من السهل بالنسبة لمسؤول أمن باضاعتها هذا السيناريو. إذا لم أكن أعرف أفضل, أنا يمكن الوصول إلى الارتباطات الشعب والمجموعات عن طريق موقع الموارد البشرية, حدد "الملاك" في المجموعة وإضافة بلدي مالك الموارد البشرية بهذه المجموعة. وبعد شهر, ويأتي اللوجستية على الخط. الوصول إلى الأشخاص والمجموعات من موقع الخدمات اللوجستية, إضافة سحب ما يصل أصحاب "" المجموعة. راجع مالك الموارد البشرية هناك، وإزالة لها, التفكير أن أنا إزالة لها من أصحابها في موقع الخدمات اللوجستية. في الحقيقة, أنا إزالة لها من مجموعة أصحاب العالمية. تستتبعه مرح.
• الفشل باسم المجموعات استناداً إلى دور محدد: "الموافقين" المجموعة مثال ممتاز. ما يمكن لأعضاء هذه المجموعة الموافقة? حيث أنها توافق عليه? هل حقاً نريد شعب الإدارة اللوجستية ليتمكن من الموافقة على وثائق حقوق الإنسان? بالطبع لا. دائماً اسم المجموعات استناداً إلى دورها داخل المنظمة. وهذا سوف يقلل من خطر أن المجموعة يتم تعيين مستوى إذن غير مناسبة لكائن معين قابل للتأمين. اسم المجموعات استناداً إلى دورها المقصود. في السيناريو السابق الموارد البشرية والسوقيات, وينبغي أن يكون تم إنشاؤها فريقين جديدين: "أصحاب الموارد البشرية" و "أصحاب النقل والإمداد" وتعيين مستويات أذونات معقولة لكل والحد الأدنى المطلوب لهؤلاء المستخدمين القيام بعملهم.

مراجع أخرى مفيدة:

• ويب تطبيق سياسة مسكتك: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• مركز تبادل المعلومات للأمن SharePoint: http://www.sharepointsecurity.com/
• وصلات من جويل Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

إذا كنت قد جعلت من هذا الآن:

واسمحوا لي أن أعرف أفكارك عن طريق التعليقات أو البريد الإلكتروني لي. إذا كنت تعرف غيرها من المراجع الجيدة, الرجاء القيام بنفس!