- Identity server یک محصول کاملا مجزای از ASP.NET Core Identity است و توسط تیم دیگری خارج از مایکروسافت توسعه داده می‌شود و این دو ارتباطی به هم ندارند.

- هرچند امکان استفاده‌ی از ASP.NET Core Identity برای مدیریت کاربران Identity server هم وجود دارد.

- کاری که در این سری انجام شده، ابتدا در «قسمت چهارم - نصب و راه اندازی IdentityServer» فایل‌های Quick Start UI را به پروژه‌ی IDP اضافه کردیم (یعنی دقیقا از کدهای اصلی تیم Identity server استفاده شده). بعد در این قسمت، سایر کدهای اصلی بسته‌ی EF Core آن‌را (^ و ^) به پروژه اضافه و سفارشی سازی کرده و در قسمت‌های دیگر، این کدها را تکمیل کرده‌ایم. بنابراین در این سری از کدهای استاندارد خود  Identity server استفاده شده و سپس توسعه‌ی بیشتری پیدا کرده‌اند. برای نمونه کلاس‌های موجودیت‌های مثال این سری، از اینجا تامین شده‌اند.

- هدف این پروژه، ارائه‌ی یک سایت تمام فارسی برای کاربران فارسی زبان بوده. این هدف هم حاصل شده. هدف دیگری را هم پیگیری نمی‌کند و نخواهد کرد.

+ پروژه‌ی Identity، بومی‌سازی‌های ثالث را نمی‌پذیرد؛ از این جهت که اطمینانی به ترجمه‌های ثالث ندارند و برای یک شرکت بزرگ این مساله می‌تواند گران تمام شود. به همین جهت حالت پیش‌فرض آن، فقط زبان انگلیسی را پشتیبانی می‌کند.

+ مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 19 - بومی سازی » را باید پیگیری کنید. از این لحاظ که زیرساختی برای کار با فایل‌های منبع و انتخاب خودکار آن‌ها بر اساس زبان انتخابی کاربر جاری سیستم، توسط موتور بومی‌سازی توکار آن در ASP.NET Core وجود دارد.

سلام؛ در یک پروژه خاصی نقش کاربران وابسته به منطقه ای که انتخاب می‌کنند تغییر می‌کنه. برای مثال فرد الف در صورت لاگین و انتخاب شهر تهران نقش سرپرست دارد ولی در صورتی که شهر شیراز را انتخاب کند نقش بازرسی دارد. در این مثال از فرد الف بعد از لاگین پرسیده می‌شود که بین شهر تهران و شیراز انتخاب کند تا متناسب آن نقش آن تعیین گردد. همچنین در هر لحظه این امکان برای او وجود دارد با تغییر شهر به سطوح تعیین شده برای آن شهر دسترسی پیدا کند. برای پیاده سازی این کار توسعه کلاس UserRole کارایی لازم را ندارد چون به صورت پیشرفض کلید این جدول روی یوزر و نقش تنظیم شده است. در حالی که برای پیاده سازی این قسمت نیاز به یک کلید سه تایی از یوزر،نقش و منطقه می‌باشد. برای توسعه چنین ساختاری چه پیشنهادی می‌کنید؟

هدف ComplexType نظم بخشیدن به یک سری خاصیت است که در یک گروه قرار می‌گیرند؛ مثلا گروه اطلاعات تلفن‌های شخص؛ از تلفن منزل تا تلفن محل کار تا شماره موبایل و غیره یک شخص. یک روش نظم بخشیدن به آن‌ها، قرار دادن این خواص در یک ComplexType است. روش دیگر اینکار تعریف یک جدول جداگانه برای آن و اتصال آن به جدول کاربران از طریق یک کلید خارجی است. این نظم بخشیدن ارتباطی به ارث‌بری ندارد و در رده‌ی « بازسازی کد: جایگزینی داده با شیء (Replace data with object) » قرار می‌گیرد.

خطای 400، صرفا یک خطای عددی نیست. ظاهر آن یک عدد است، اما می‌تواند شامل ریز جزئیات خطاهای ارسالی از سمت سرور هم باشد:

bad requestها (یا خطای 400) همان return BadRequest‌های اعتبارسنجی اطلاعات (و یا سایر خطاهایی که خود فریم ورک ارسال می‌کند و نه اعتبارسنجی کاربران با خطای 401) هستند. مطلب « نمایش خطاهای اعتبارسنجی سمت سرور ASP.NET Core در برنامه‌های Angular » را مطالعه کنید تا با روش استخراج ریز جزئیات ارسالی این نوع خطاها از سمت سرور و نمایش آن‌ها به کاربر آشنا شوید. به علاوه لاگ‌های سمت سرور را هم مدنظر داشته باشید.

حداقل دو دلیل را می‌تواند داشته باشد:

- کاربر application pool برنامه (و یا کاربری که توسط آن به بانک اطلاعاتی متصل می‌شوید)، دسترسی مناسبی را به SQL Server ندارد. در قسمت مدیریت کاربران SQL Server، این کاربر باید حداقل دسترسی‌های db_datareader و db_dataweriter را بر روی دیتابیس شما داشته باشد.

- کوئری‌های شما بر اساس اسکیمای dbo صادر می‌شوند، اما اسکیمای واقعی بانک اطلاعاتی موجود در هاست، برای کاربر شما مثلا user1 است و نه dbo مدیریتی. در این حالت نمی‌توانید کوئری‌هایی مانند select * from dbo.table1 را صادر کنید. باید کوئری‌های شما با اسکیمای جدید select * from user1.table1 اجرا شوند.

این موارد در نظرات سری EF Code First بررسی شده‌اند و در اینجا هم تفاوتی نمی‌کنند؛ چون موارد پایه‌ای مدیریت دسترسی‌های SQL Server هستند.

- خیر. تنظیم این اعداد به مقادیر کوچک، کاربران عادی را هم از انجام کارهای ساده عاجز می‌کند.

- اطلاعات IPهای بسته شده توسط خود این ماژول لاگ می‌شود. اگر سیستم لاگر مبتنی بر دیتابیس را به برنامه اضافه کنید، این لاگ‌ها به صورت خودکار در بانک اطلاعاتی ذخیره خواهند شد. در آنجا آی‌دی کاربر یا هر اطلاعات دیگری را هم خودتان به ازای هر لاگ ارائه شده، ذخیره کنید. البته اگر از Shadow properties و یا سیستم Tracking استفاده می‌کنید، لاگر مبتنی بر دیتابیس  اطلاعات کاملی را از کاربر جاری ذخیره می‌کند و نیازی به کدهای اضافه‌تری ندارد.

و سوال دیگر:در کلاس استارت اپ پروژه ASPNETCore2JwtAuthentication.WebApp  چرا  آدرس را با http://localhost:4200 مقدار دهی کردین و همچنین "Issuer": "http://localhost:5000/" در BearerTokens چرا از پورت ثابت استفاده شده است.