این مطلب و نظرات آن‌را مطالعه کنید.

سلام؛ آیا استفاده از IProtectionProvider جهت درج اطلاعات در بخش Payload یک JWT Token را پیشنهاد میکنید؟

یک نکته‌ی تکمیلی: در تنظیمات کوکی‌های سایت جدید، SameSite به Strict تنظیم شده بود:

options.Cookie.SameSite = SameSiteMode.Strict;

این موضوع سبب شده بود که اگر کاربری در سایت لاگین کرده بود و ایمیلی را دریافت می‌کرد، پس از کلیک بر روی ایمیل دریافتی و ورود به سایت، اعتبارسنجی نشده تلقی می‌شد و برای مثال امکان ارسال پاسخی را نداشت؛ چون حالت Strict به این معنا است که کوکی‌های سایت (منجمله کوکی‌ اعتبارسنجی کاربر)، فقط به درخواست‌های رسیده‌ی از طریق خود سایت، به صورت خودکار توسط مرورگرها ارسال می‌شوند و نه در حالتیکه یک redirect از سایت دیگری وجود داشته باشد. برای تعدیل این تنظیم می‌توان از حالت Lax استفاده کرد:

options.Cookie.SameSite = SameSiteMode.Lax;

در اصل، حالت Lax با حالت Strict، تفاوت آنچنانی ندارد و هنوز هم کوکی‌ها را فقط به درخواست‌های رسیده‌ی از طریق دومین جاری ارسال می‌کند. اما در این حالت اگر redirect ای نیز به دومین برنامه، از نوع GET وجود داشته باشد، آن‌را امن حساب کرده و کوکی‌های برنامه را در اختیار آن درخواست قرار می‌دهد.

پ.ن.

برای دریافت کوکی‌های جدید از نوع Lax، باید یکبار از برنامه خارج شوید و مجددا به آن وارد شوید تا کوکی‌های جدید را دریافت کنید.

سایتی برای بررسی CSP تنظیم شده

احتمالا به خاطر استفاده از AddDbContextPool هست چون با AddDbContextPool حتی یکبار هم خطایی رخ نداده و 6 ماه هم میشه که پروژه پابلیش شده و بدون مشکل کار میکنه.

اگر در یک صفحه، سه کامپوننت به این صورت وجود داشته باشند:

<ComponentA/>
<ComponentB/>
<ComponentC/>

پردازش این‌ها در Blazor SSR، ترتیبی نیست و موازی است (هر کدام، بر روی یک ترد مجزا پردازش می‌شوند). اما اگر کامپوننت B، داخل کامپوننت A باشد، این‌ها با هم و در طی یک ترد پردازش می‌شوند. هرچند این بحث پردازش موازی هم در صورت فراهم بودن منابع سیستمی و سخت‌افزاری، تردهای آزاد در thread-pool و موارد دیگر، ممکن است رخ‌دهد یا خیر. بنابراین گاهی از اوقات، در طول مدتی، خطایی را مشاهده نمی‌کنید؛ اما ... اگر به لاگ‌های سیستم در طول یک روز مراجعه کنید، وجود این خطاها کاملا مشخص است. بنابراین بهتر است بر اساس «شانس» کار نکنید. inject AppDbContext appDbContext@ به این معنا است که فقط یک نمونه از DbContext، در طول درخواست جاری (از این لحاظ، Blazor SSR با ASP.NET Core یکسان رفتار می‌کند) بین تمام اجزای در حال پردازش صفحه‌ی در حال رندر، به اشتراک گذاشته شود. «ممکن است» در صورت عدم وجود پردازش موازی، هیچ خطایی را دریافت نکنید و یا ... به صورت «اتفاقی» و با مهیا بودن شرایط سیستمی و سخت‌افزاری، خطای یاد شده را مشاهده کنید.

من با همین یک خط در فایل Imports.razor_ دی بی کانتکس رو به کامپوننت ها اینجکت میکنم و استفاده میکنم و به این ارور هم نمیخورم :

@inject AppDbContext appDbContext

Program.cs :

builder.Services.AddDbContextPool<AppDbContext>(options =>options.UseSqlServer(AppConnectionString));

در یک صفحه هم خود کامپوننت صفحه کوئری میزنه، هم یک کامپوننت share که داخل صفحه اضافه شده کوئری میزنه.

یک مطلب تکمیلی: «مشکل همزمانی خواندن و به روز رسانی اطلاعات در برنامه‌های وب»

با سلام و تشکر از ارسال مطلب.

اگر ستون Email در Database بصورت Unique تعریف شود آیا مشکل حل میشه یا ضرورتا باید از مکانیزم Lock استفاده کنیم؟ چون نمیدونم ویژگی RequireUniqueEmail روی جدول در بانک اطلاعاتی تاثیر میذاره یا اینکه صرفا در سطح Application منحصربفرد بودن Email را چک میکنه.

تشکر

یک نکته‌ی تکمیلی: گوگل برای مواجه شدن با یک چنین مشکلاتی،‌ در حال پیاده سازی «device bound sessions» است. همچنین نحوه‌ی رمزنگاری اطلاعات کوکی‌های کروم نیز در ویندوز به‌روز خواهد شد و دیگر صرفا از API خود ویندوز استفاده نمی‌کنند.