در اکثر موراد مطرح شده فوق ، فایل‌های آپلود شده وابسته بوند به یک رکورد که ابتدا می‌بایست رکورد مورد نظر درج تا بتوان فایل را با آن کلید آپلود و ذخیره نمود .
ولی در توضیح آقای ربال ، فرض کنید همین ادیتور سایت فعلی ، شما قصد نوشتن یک مقاله را دارید و لابه لای متون نیاز به قراردادن عکس هم دارید ، در این حالت سایت فعلی عکس مورد نظر ذخیره نموده و فقط آدرس آن برگشت داده میشود و داخل تگ src قرار داده می‌شود تا فایل نمایش داده شود . در این حالت فقط مشخص می‌شود که کاربر x فایل y  را آپلود کرده است .

- services.AddDataProtection یعنی همان مقدمه‌ی بحث؛ یا ذخیره سازی کلیدها در حافظه به صورت پیش‌فرض. مابقی بحث جهت دائمی کردن این کلیدها است. البته دائمی کردن هم طول عمری دارد.
- در سرورهای اشتراکی یا از روش «یک نکته‌ی تکمیلی: روش ذخیره سازی کلید موقتی تولید شده در بانک اطلاعاتی بجای حافظه‌ی سرور » استفاده کنید، یا با هاست تماس بگیرید و تنظیم گزینه‌ی 2 یا همان Load user profile به true را به آن‌ها اعلام کنید (چون تنظیمات برنامه‌های ASP.NET Core با نگارش‌های قبلی یکی نیست؛ این یک مورد را هم بهتر است به لیست تنظیمات اولیه‌ی برنامه اضافه کنند).
- در حالت سوم، ذکر Certificate برای رمزنگاری اطلاعات ضروری است؛ در غیراینصورت این کلیدها به صورت معمولی و واضح ذخیره خواهند شد.

در تکمیل قسمت « استفاده از اطلاعات منابع در DataAnnotations »
عموما برای بومی سازی DataAnnotations، نیاز به قید resource name و resource type است. در اینجا resource name همان نام کلید منبع تعریف شده‌است و resource type به کلاس Designer.cs آن منبع اشاره می‌کند. برای تولید خودکار آن، نیاز است نام فایل منبع را «بدون قید نام زبان آن» درنظر گرفت؛ برای مثال Controllers.HomeController.resx. در این حالت به صورت خودکار فایل Controllers.HomeController.Designer.cs تولید خواهد شد که از نام کلاس آن (Controllers_HomeController) می‌توان به عنوان مقدار resource type استفاده کرد. پس از آن فایل Controllers.HomeController.fa-IR.resx را ایجاد کنید تا به عنوان منبع زبان فارسی متناظر آن استفاده شود.  

با سلام

به نکته بسیار خوبی اشاره کردین ولی بهتره به جای چک کردن ModelState یک خصوصیت به جدید به ActionFilter خودمون اضافه کنیم و بعد در صورتیکه نتیجه عملیات موفقیت آمیز بود اون رو True کنیم در نهایت در خود ActionFilter پس از اجرای اکشن چک میکنیم اگر این خصوصیت false بود یعنی چیزی ثبت نشده و کلید رو از کش حذف می‌کنیم و کاربر میتونه باز فرم رو ارسال کنه و تنها زمانی محدود میشه که واقعا چیزی ثبت شده باشه.
در کل روند رو می‌تونیم در دست خودمون بگیرم و هروقت که بخواهیم بگیم که محدودیت اعمال بشه یا خیر.
با توجه به نکاتی که در کامنت‌ها ذکر شد در مکانیزم تغییراتی داده شد و به پست اصلی ضمیمه کردم.

سلام .ممنون از مطالب .
"الان مشکلی که هست یک جدول تگ برای هر دو در نظر گرفته که اینطوری هم متوجه نمیشیم که کلید مربوطه مال جدول page میشه یا article؟ در این حالت من باید کلاس تگ رو برای هر کدوم جداگانه بنویسم که دو جدول بسازه؟  "
  به نظر من  اگه از نگاشت TPT استفاده کنی مشکلی پیش نیمیاد ، چون هیچ دو Id تکراری در Page,Article نخواهیم داشت ، به این دلیل میگم که Id‌های کلاس‌های Articleو Page از کلاس والد گرفته میشن که در کلاس والد Identity هستش .

- راه حل‌های مبتنی بر سشن، از Classics ASP دهه نود به ارث رسیده‌اند. عملا با پیشرفت‌هایی که حاصل شده نیازی به بسیاری از آن‌ها نیست. مصرف حافظه بالایی دارند و همچنین با ری‌استارت شدن برنامه در سرور، تمام سشن‌ها از بین خواهند رفت. این مشکلات در Forms Authentication وجود ندارند.
- قدمت Forms Authentication به ASP.NET 1.x بر می‌گردد. می‌توانید در این مورد در سایت‌های دیگر نیز بیشتر تحقیق کنید که آیا مشکل حادی از سال 2001 تا الان گزارش شده یا خیر.
- کلید رمزنگاری این کوکی‌ها در سمت سرور قرار دارد و تنها یک راه برای دسترسی به آن‌ها هست؛ دسترسی به سرور. در این حالت عملا کل سیستم مورد حمله قرار گرفته و یک کوکی شاید اهمیت خاصی نداشته باشد.
- ضمنا طول مدت زمان معتبر بودن اطلاعات Forms Authentication و دائمی بودن و نبودن کوکی‌های آن قابل تنظیم است (بحث شده در مطلب فوق).

همونطور که دوستمون اشاره کرد DKP-14997 تو سایت دیجی کالا کلید محصولاته.