هل يمكن تحديث إعدادات SPpersistedObject بواسطة المستخدمين العاديين إذا تم تشغيلها بامتيازات مرتفعة؟

Question

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

أنا أفكر في استخدام SPPersistedObject لتخزين معلومات مكتبة المستندات عندما ينقر المستخدم على أيقونة الشريط.ومع ذلك، يتطلب هذا امتيازات مسؤول المزرعة، مما يعني أن المستخدمين العاديين سيواجهون خطأً عند النقر فوق "تسجيل". هل يؤدي تشغيل التعليمات البرمجية التي تكتب SPPersistedObject بامتيازات مرتفعة إلى حل هذه المشكلة, ، أم أنه لا يزال من الممكن حدوث خطأ؟هذا ما اعنيه:

// Execute this code when a ribbon icon is clicked by a normal user
SPSecurity.RunWithElevatedPrivileges(delegate()
{
    // Write DocumentLibrary Id and Name to some custom SPPersistedObject
});

تقول MSDN ذلك RunWithElevatedPrivileges() "يعمل تحت هوية تجمع التطبيقات ، التي لديها امتيازات مسؤول جمع الموقع على جميع مجموعات الموقع التي استضافتها مجموعة التطبيقات." هل هذا يكفي للتحديث SPPersistedObject?

هل يجب أن أتجاوز SPPersistedObject.HasAdditionalUpdateAccess ليعود دائمًا صحيحًا، أم أن هذا لا يزال غير كافٍ للبيئات الأقل حظًا؟إذا لم يكن الأمر كذلك، ما هي الخيارات المتاحة لي لتخزين هذه المعلومات بخلاف قاعدة البيانات المخصصة؟

Answer 1

الامتيازات المرتفعة لا تكفي للكتابة إلى التكوين قاعدة بيانات.مع امتيازات مرتفعة سوف تستخدم الويب معرف تجمع تطبيقات التطبيق، الذي لديه إذن قراءة فقط تكوين ديسيبل افتراضيا.بالطبع المستخدم المسؤول (الذي يدير المركزي يجب أن يكون لدى المسؤول أذونات القراءة والكتابة).

انظر أكثر في: http://joelblogs.co.uk/2010/10/10/persisting-configuration-data-in-sharepoint-2010-with-sppersistedobject/

SPPersistedObject.HasAdditionalUpdateAccess

لا يزال بحاجة إلى انتحال هوية المستخدم المسؤول غير المزرعة إلى مستخدم مسؤول المزرعة.

الموضوع الأخير الذي يتطلب بعض التغطية هو الأمن.كما هو موضح في وقت سابق ، يوجد HOS في قاعدة بيانات تكوين المزرعة.بصرامة التحدث موجود لدعم الوظائف الإدارية مهما كان له استخدامات خارج هذا النطاق.على سبيل المثال ، إذا كنا نبني مخصصا وظيفة الموقت ونريد أن يكون لدينا القدرة على تقديم المهام إلى وظيفتنا للانتهاء.من المرجح أن تنشأ هذه المهام ضمن نطاق غير إداري.ربما كنتيجة لمستخدم النقر فوق زر على جزء ويب في بعض مجموعة مواقع مشتركة أخرى.مع الإصدارات السابقة من SharePoint ، لم يكن هذا ممكنا ببساطة.فقط يمكن لمسؤولي المزرعة تحديث HOS.ولكن مع شيربوينت 2010 ، تمت إضافة إلى قاعدة SPPersistedObject التي يفتح HOS للمستخدمين الآخرين.لنرى كيف يعمل هذا ، يمكننا تعديل وظيفتنا الرئيسية على النحو التالي:

using System;
using System.Runtime.InteropServices;
using System.Security.Principal;

namespace PersistedObjectDemo
{
    internal class Program
    {
        private const int LOGON_TYPE_INTERACTIVE = 2;
        private const int LOGON_TYPE_PROVIDER_DEFAULT = 0;

        [DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern bool LogonUser(string userName, string domain, string password, int logonType,
                                            int logonProvider, ref IntPtr accessToken);

        private static void Main(string[] args)
        {
            try
            {
                IntPtr accessToken = IntPtr.Zero;
                if (LogonUser("non-farm-admin-username", "your-domain-name", "your-password", LOGON_TYPE_INTERACTIVE,
                              LOGON_TYPE_PROVIDER_DEFAULT, ref accessToken))
                {
                    using (var identity = new WindowsIdentity(accessToken))
                    {
                        using (identity.Impersonate())
                        {
                            MyPersistedObject obj = MyPersistedObject.Local;
                   //delete existing object and recreate to keep things simple
                            obj.Delete();
                            obj = MyPersistedObject.Local;
                            obj.Foo = "Some updated value";
                            obj.Update();
                        }
                    }
                }

            }
            catch (Exception ex)
            {
                Console.Write(ex);
            }

            Console.WriteLine("Press return to exit");
            Console.ReadLine();
        }
    }
}

يحاكي هذا الرمز محاولة من قبل مستخدم مسؤول غير مزرعة لتحديث HOS.إذا قمنا بتشغيل هذا ، فسنرى الاستثناء التالي وهو مسكتك رقم 3:

System.Security.SecurityException:تم الرفض.في Microsoft.SharePoint.Administration.SPPersistedObject.BaseUpdate() at PersistedObjectDemo.MyPersistedObject.Update()

مما لا يثير الدهشة ، محاولة تحديث HOS باستخدام مستخدم مسؤول غير زراعي يلقي استثناء.ومع ذلك ، إذا أضفنا الكود التالي إلى MyPersistedObject.cs وتشغيل برنامجنا مرة أخرى ، يمكننا أن نرى أن ملف يتم تحديث HOS بشكل مناسب.

protected override bool HasAdditionalUpdateAccess()
{
    return true;
}

بالطبع ، في تطبيق واقعي ، ربما نرغب في إضافة بعض التحقق من الأمان في هذه الوظيفة بدلا من مجرد إرجاع true والسماح لأي شخص بتحديث كائننا ولكن نأمل أن يكون هذا يوضح النقطة بما فيه الكفاية.

هناك مسكتك أخرى فيما يتعلق بالأمان - عندما يكون SharePoint 2010 مثبت ، بشكل افتراضي فقط حساب مسؤول المزرعة لديه قراءة / كتابة الوصول إلى قاعدة بيانات التكوين.في تثبيت أقل امتياز ، كل شيء تطبيقات الويب الأخرى ثم الإدارة المركزية ، سيتم تشغيلها ضمن حساب الخدمة الخاص بهم ولن يكون لهذه الحسابات كتابة الوصول إلى قاعدة بيانات التكوين.وبالتالي، فإن إضافة وحذف و لن يكون تحديث الكائنات في HOS ممكنا.على الرغم من التجاوز يتيح لنا HasAdditionalUpdateAccess مزيدا من التحكم في من يمكنه قم بتحديث HOS ، إذا كان حساب تجمع التطبيقات الأساسي لا يحتوي على أذونات قاعدة البيانات المناسبة سنأتي غير عالقة بشكل جميل سرعه.

• انظر أكثر في: http://www.chaholl.com/archive/2011/01/30/the-skinny-on-sppersistedobject-and-the-hierarchical-object-store-in.aspx#sthash.YUJnw8Op.dpuf