سؤال

لقد وجدت ذلك SPContext.Current.Web.CurrentUser لا يمكن الاعتماد عليها حقا.واحد من كل عشرة يطلب أن يعود هذا الكائن كما هو null.

هل هناك بديل ل SPContext.Current.Web.CurrentUser?

هل رأى أي شخص آخر عدم الموثوقية هذا؟

هل هناك حل هناك؟

هل كانت مفيدة؟

المحلول

سيكون رائعا إذا قمت بنشر الرمز المخالف والمناطق المحيطة بها، ولكن بعض الأشياء التي يجب مراعاتها من رأس رأسي:

  1. قد تحصل على الكائن في وقت مبكر جدا في دورة الحياة (قل الأساليب المتكررة ومثل هذه، أو httpmodule إلخ)
  2. قد تقطع خط الأنابيب القيام بأشياء مثل تحديد httpcontext إلى NULL (لقد رأيت ذلك في SharePoint Parlesarounds من قبل)
  3. قد تكون وراء وكيل عكسي مثل Apache أو Nginx يجعل Keepalives الخاص بك يجري مجنونا، حاول اختبار الرمز خارج بيئتك
  4. وبعضها "هو الضوء الأخضر" لقضايا الأجهزة، تجمع التطبيقات التي تصل إلى ذاكرة الوصول العشوائي إلى صندوق البريد أو عدم وجودها، SQL Server مشغول
  5. قد تستخدم بعض الانتحال بين pinvoke يجعل المصادقة المتكاملة تذهب الموزين
  6. إذا كنت تستخدم FBA إعدادات الموفر والتوافر الخلفي (ملف إعلان XML أو عضوية SQL) قد تفشل - ولكن هذا غير مرجح لأنه سيكون خطأ مختلفا.
  7. افسدت حول قسم httpModules يحب كسر الأشياء أيضا، هل حاولت في WebApplication جديد مع تغييرات صفرية؟
  8. أحب الرقم الثامن، لذلك اعتقدت أنني يجب أن أعطيها ثمانية أفكار غامضة

    tl؛ Dr: نشر الرمز الخاص بك :)

نصائح أخرى

لقد واجهت هذا فقط عندما نسيت أنني أسميه خارج السياق.

هل أنت متأكد من أنك لا تحاول الاتصال بهذا في الداخل SPSecurity.RunWithElevatedPrivileges() ?

plz حاول مع هذا .. giveacodicetagpre.

أو giveacodicetagpre.

plz حاول أيضا مع RunwithelevatedPreviliges () ...

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى sharepoint.stackexchange
scroll top