مطالب دوره «مبانی Async در C# 5» را مطالعه کنید. با مفاهیمی مانند IO bound opertaions و CPU bound operations، مقیاس‌پذیری برنامه‌های وب، خالی کردن تردجاری، کار با برنامه‌های غیر وبی و امثال آن آشنا خواهید شد.

یک نکته‌ی تکمیلی: اگر از SQLite به همراه بسته‌ی Microsoft.EntityFrameworkCore.Sqlite استفاده می‌کنید ... موتور SQLite آن، کمی قدیمی است. برای به‌روز رسانی موتور خود SQLite، نیاز است بسته‌ی SQLitePCLRaw.bundle_e_sqlite3 را هم به لیست ارجاعات برنامه‌ی خود اضافه کنید (به صورت صریح). برای مثال نگارش 8.0.7 به همراه EF-Core هر چند ارجاعی را به SQLitePCLRaw.bundle_e_sqlite3 دارد، اما از نگارش 2.1.6 آن استفاده می‌کند که مربوط به سال قبل است.

مورد مشابه دیگری که نیاز به تنظیم دارد، کوکی‌های anti-forgery-token هستند. این‌ها هم به صورت خودکار به SameSiteMode.Strict تنظیم شده‌اند و اگر از طریق ایمیل، به فرمی مرتبط در سایت هدایت شوید و ... فرم را ارسال کنید، فقط یک صفحه‌ی سفید رنگ را با پیام خطای 400، مشاهده خواهید کرد که قابل سفارشی سازی هم نیست (و مطلقا هم از تمام فیلترهای سراسری خطایابی شما، رد نمی‌شود). هدایت به سایت (یعنی یک redirect از سایت ثالث)، با کوکی‌های از نوع Strict هم‌خوانی ندارد و مرورگر، آن‌ها را به سمت سرور ارسال نمی‌کند. به همین جهت این درخواست‌های اعتبارسنجی anti-forgery-token هم برگشت خواهند خورد. برای تعدیل آن می‌توان به صورت زیر عمل کرد:

services.Configure<AntiforgeryOptions>(opts => { opts.Cookie.SameSite = SameSiteMode.Lax; });

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

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

options.Cookie.SameSite = SameSiteMode.Strict;

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

options.Cookie.SameSite = SameSiteMode.Lax;

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

پ.ن.

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

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

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

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

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

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

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