//...
.AddOpenIdConnect("oidc", options =>
                {
                    // ...
                    options.Events = new OpenIdConnectEvents
                    {
                        OnTokenValidated = async ctx =>
                        {
                          // how to access claims
                          var user = ctx.Principal;                    
                          var email = user.Claims.FirstOrDefault(claim => claim.Type == "email").Value;

                          // how to access services
                          var db = ctx.HttpContext.RequestServices.GetRequiredService<MyDb>();

                          // ....
                        }
                    };
                });
- callback مربوط هست به قسمت‌های 11 و 12 این سری .
- روش گرفتن خودکار اطلاعات کاربر از IDP مانند دسترسی به اطلاعات this.User.Claims کاربر وارد شده‌ی به سیستم، در قسمت بعدی بحث می‌شود. 
- روش گرفتن اطلاعات کاربر با کدنویسی و به صورت دستی در یک Web API و کار با UserInfo Endpoint در قسمت 7 بررسی می‌شود.
‫۴ سال و ۵ ماه قبل، پنجشنبه ۷ فروردین ۱۳۹۹، ساعت ۰۰:۰۹
- اگر توضیحات آن‌را مطالعه کنید، عنوان کرده کلاس rtl را باید خودتان به هر قسمتی که نیاز است، به صورت دستی اضافه کنید.
- برنامه‌ی این سری را که اجرا کنید (با اجرای فایل dotnet_run_all.bat آن)، برنامه‌ی IDP آن در آدرس https://localhost:6001 قرار دارد و برنامه‌ی MVC آن در آدرس https://localhost:5001 و برنامه‌ی Web API آن در آدرس https://localhost:7001. بنابراین مشکلی با redirect به آدرس‌های مختلف نیست و روش تنظیم آن در قسمت پنجم این سری بررسی شده؛ یا حتی حالت پیشرفته‌تر اعتبارسنجی دو مرحله‌ای آن در قسمت 13 آن بررسی شده و شامل اصلاحاتی در مورد این redirectها هم هست.
- Url.IsLocalUrl مرتبط با اعتبارسنجی دو مرحله‌ای قسمت 13 این سری است که کاربر را جهت وارد کردن کد دریافت شده‌ی برای مثال از طریق ایمیل یا SMS، به یک صفحه‌ی دیگر در همان IDP هدایت می‌کند و پس از اتمام آن، کار هدایت نهایی به برنامه‌ی کلاینت صورت خواهد گرفت.
- خیر.
- میزان تغییرات آن‌ها بسته به اینکه پروژه‌ی API یا MVC باشند، در قسمت‌های 5 تا هفتم این سری به تفصیل و جداگانه بحث شده‌اند و به همراه یک پروژه‌ی انجام شده که از قسمت دوم شروع می‌شود و تا قسمت آخر تکمیل شده، هست. این سری فقط دو کلاینت API و MVC را بررسی کرده. سایر کلاینت‌ها را باید به مثال‌های خودشان مراجعه کنید.
- بله و خیر. قرار نیست کلاینت‌ها دیگر اطلاعات کاربران را ثبت کنند و قرار نیست دیگر در بانک اطلاعاتی خودشان به دنبال آن‌ها بگردند. سطوح دسترسی و claims در اینجا (قسمت‌های 6 و 8 این سری)، کار مدیریت سطوح دسترسی و دریافت آن‌ها را از IDP انجام می‌دهند. یعنی IDP فقط کار لاگین را برای آن‌ها انجام نمی‌دهد (authentication)، بلکه قسمتی از پروسه‌ی Authorization (تامین اطلاعات مورد نیاز جهت برقرار سطوح دسترسی، یا همان قسمت 6) را به نام Claims هم انجام می‌دهد. برنامه‌ی کلاینت با این claims تمام دسترسی‌ها لازم را برای تامین سیاست‌های داخلی خودش، برقرار می‌کند (قسمت 8). تمام این موارد در پروژه‌ی این سری بررسی شده‌اند و حتما نیاز هست یکبار قدم به قدم بررسی شود.
- در قسمت سوم این مورد به تفصیل بررسی شده.
- فایلی که هم اکنون در کش مرورگر کاربر، وجود خارجی دارد، بالاخره به هر نحوی که شده، قابلیت ذخیره سازی هم پیدا می‌کند.
- آیا می‌توان قابلیت‌هایی مانند چاپ PDF و کپی متن را از آن گرفت؟ بله.
- آیا می‌توان این قابلیت‌هایی را که از فایل PDF گرفته شده، مجددا به آن باز گرداند؟ بله.

نتیجه گیری: وقت خودتان را تلف نکنید.
کارآیی React+MobX بهتر است از React + Redux


همچنین اندازه‌ی نهایی React+MobX کمتر است از React + Redux


تعداد سطرهای مورد نیاز برای نوشتن یک برنامه‌ی مشابه توسط React+MobX، کمتر است از پیاده سازی همان برنامه با React+Redux

‫۴ سال و ۶ ماه قبل، پنجشنبه ۲۲ اسفند ۱۳۹۸، ساعت ۱۷:۲۲
یک نکته‌ی تکمیلی
نام افزونه‌ی #C، از ms-vscode.csharp به ms-dotnettools.csharp تغییر یافته‌است. البته redirect آن به صورت خودکار انجام می‌شود و افزونه‌های قدیمی در اولین بار به روز رسانی، به آدرس جدید هدایت خواهند شد.