اشتراکها
Firebug 2.0 منتشر شد
کمی بالاتر با 2 مثال توضیح دادم: «روش ارتقاء به EF Core 2.0»
یک نکتهی تکمیلی: پشتیبانی توکار ASP.NET Core 2.0 از Range headers
ادامهی بحث در اینجا: «فعالسازی Windows Authentication در برنامههای ASP.NET Core 2.0»
در حال به روز رسانی پروژهی فعلی به ASP.NET Core 2.0 هستم. حجم تغییرات آن خیلی زیاد است. کمی صبر کنید. به زودی ...
اولین مرحلهی ارتقاء به Angular 6، به روز رسانی Angular CLI 1.x به نگارش 6 آن است. این شماره نگارش نیز با شماره نگارش Angular یکی شدهاست و دیگر 1x نیست. CLI 6.0 فقط پروژههای Angular 5.x و 6x را پشتیبانی میکند و برای نصب آن نیاز به حداقل NodeJS 8.9 و NPM 5.5 را خواهید داشت. بنابراین ابتدا دستورات زیر را صادر کرده و اگر هنوز از نگارشهای قدیمی این ابزارها استفاده میکنید، قبل از هر کاری باید آنها را به روز رسانی کنید:
این نگارش از CLI در پشت صحنه از Webpack 4 استفاده میکند که نسبت به نگارشهای پیشین آن بسیار سریعتر است، tree-shaking بهتری را انجام میدهد و در نهایت سبب تولید برنامههایی با حجم کمتر و با سرعت build بیشتری خواهد شد.
فایل پیشین angular-cli.json حذف و فایل جدید angular.json بجای آن معرفی شدهاست
یکی از مهمترین تغییرات CLI 6.0 نسبت به نگارشهای قبلی آن، پشتیبانی از چندین پروژه است و به همین منظور ساختار فایل تنظیمات آنرا به طور کامل تغییر دادهاند و اگر دستور ng new project1 را صادر کنید، دیگر از فایل پیشین angular-cli.json خبری نبوده و بجای آن فایل جدید angular.json قابل مشاهدهاست:
در اینجا ساختار ابتدای فایل angular.json را مشاهده میکنید که در آن مفهوم projects (و یا workspace در اینجا) به همراه project1 جدیدی که ایجاد کردیم، به عنوان زیر مجموعهی آن قابل مشاهدهاست.
مزیت مهم این قابلیت، امکان ایجاد libraries است که به صورت توکار از این نگارش پشتیبانی میشود و میتوان اجزایی مانند components ،directives ،pipes و services اشتراکی را در یک یا چندین کتابخانه قرار داد و سپس از آنها در پروژهی اصلی و یا چندین پروژهی متصل استفاده کرد.
نگارش 6 در پشت صحنه، پروژهی موفق ng-packagr را به مجموعهی CLI اضافه کردهاست و از این پس توسط خود CLI میتوان کتابخانههای استاندارد Angular را تولید کرد. این مورد، مزیت استاندارد سازی کتابخانههای npm حاصل را نیز به همراه دارد؛ مشکلی که گاهی از اوقات به علت عدم رعایت این ساختار، با بستههای فعلی npm مخصوص Angular وجود دارند. برای مثال بدون استفادهی از این ابزار، نیاز است مستندات 13 صفحهای ساخت کتابخانههای Angular را سطر به سطر پیاده سازی کنید که توسط CLI 6.0، به صورت خودکار ایجاد و مدیریت میشود.
بنابراین اکنون سؤال مهمی که مطرح میشود این است: آیا باید فایل angular-cli.json پیشین را به صورت دستی به این فایل جدید به روز رسانی کرد و چگونه؟
به روز رسانی تمام بستههای سراسری سیستم
در ادامه پیش از هر کاری نیاز است تمام بستههای سراسری npm ایی را که هر از چندگاهی به سیستم خود اضافه کردهاید، به روز رسانی کنید. برای مشاهدهی لیست موارد تاریخ مصرف گذشتهی آنها، دستور زیر را صادر کنید:
و برای به روز رسانی یکجای آنها نیاز است دستور زیر اجرا شود:
به روز رسانی خودکار ساختار فایل angular-cli.json
این به روز رسانی توسط CLI 6.0 به صورت خودکار پشتیبانی میشود و شامل این مراحل است:
ابتدا نیاز است بستهی سراسری آنرا به روز رسانی کرد:
سپس وارد پوشهی اصلی پروژهی خود شده و این دستور را به صورت محلی نیز وارد کنید:
با اینکار بستهی CLI محلی پروژه به روز شده و اکنون میتوانیم از قابلیت جدید آن که ng update نام دارد، استفاده کنیم. برای این منظور دستورات ذیل را به ترتیب اجرا کنید:
دستور اول کار تبدیل خودکار فایل angular-cli.json قدیمی را به ساختار جدید آن انجام میدهد؛ با این لاگ:
دستور دوم بستههای هستهی angular را به روز رسانی میکند و دستور سوم کار به روز رسانی کتابخانهی rxjs را انجام میدهد.
لیست سایر بستههایی را که میتوان توسط این دستور به روز رسانی کرد، با اجرا دستور ng update میتوانید مشاهده کنید. برای مثال اگر از Angular Material نیز استفاده میکنید، دستور به روز رسانی آن به صورت زیر است:
مشکل! دستور ng update کار نمیکند!
اگر پروژهی شما صرفا مبتنی بر بستههای اصلی Angular باشد، مراحل یاد شدهی فوق را با موفقیت به پایان خواهید رساند. اما اگر از کتابخانههای ثالثی استفاده کرده باشید، منهای دستور «ng update @angular/cli» که کار تولید فایل جدید angular.json را انجام میدهد، مابقی با خطاهایی مانند «incompatible peer dependency» و یا «Invalid range:>=2.3.1 <3.0.0||>=4.0.0» متوقف میشوند.
در یک چنین حالتی نیاز است ابتدا وابستگیهای محلی پروژه را به روز کرد و سپس دستورات ng update را تکرار نمود. برای این منظور ابتدا بستهی npm-check-updates را نصب کنید:
کار آن به روز رسانی خودکار بستههای npm یک پروژه است. پس از آن دستورات زیر را صادر نمائید:
دستور اول تمام شماره نگارشهای بستههای موجود در فایل package.json را به صورت خودکار به آخرین نگارش آنها روز رسانی میکند و دستور دوم این بستههای جدید را دریافت و نصب خواهد کرد.
اکنون تمام وابستگیهای محلی پروژهی شما به صورت خودکار به آخرین نگارش آنها به روز رسانی شدهاند و اینبار اگر دستورات ذیل را اجرا کنید، با خطاهای یاد شده مواجه نخواهید شد:
البته اگر در این حالت برنامه را کامپایل کنید، کار نخواهد کرد. علت اصلی آن به بهروز رسانی rxjs به نگارش 6 آن مرتبط میشود که در مطلب بعدی پیگیری خواهد شد و این نگارش شامل حذفیات بسیاری است در جهت کاهش حجم آن، یکپارچکی و یک دست شدن syntax آن و همچنین بهبود قابل ملاحظهی کارآیی آن. البته پیشنیاز الزامی آن آشنایی با pipe-able operators است. علت دیگر کامپایل نشدن برنامه هم میتواند عدم استفاده از HttpClient نگارش 4.3 به بعد باشد.
خاموش کردن اخطار «TypeScript version mismatch»
اگر نگارش TypeScript نصب شدهی در سیستم به صورت سراسری، با نگارش محلی پروژهی شما یکی نباشد، اخطار «TypeScript version mismatch» را دریافت میکنید. روش خاموش کردن آن در CLI جدید با اجرای دستور زیر است:
البته نگارش 6 نیاز به TypeScript 2.7.2 ذکر شدهی در package.json پروژهی محلی را دارد؛ وگرنه اصلا شروع به کامپایل برنامه نمیکند:
بهترین راه برای یافتن این شماره، اجرای دستور ng new projet1 در یک پوشهی خالی است و سپس مقایسهی محتوای فایل package.json آن با فایل پروژهی موجود.
تغییرات ng build در نگارش 6
در نگارش 6، مفهوم پیشین environments به configurations تغییر یافتهاست و اینبار در فایل جدید angular.json تنظیم میشوند:
و پیشتر اگر برای تنظیم محیط build از سوئیچ env استفاده میشد:
اکنون این سوئیچ به configuration تغییر یافتهاست و نام آن از مداخل configurations فایل angular.json، مانند مثال فوق که «production» نام دارد، باید دریافت و تنظیم شود:
و یا برای مثال دستور «ng build --env=prod» دیگر اجرا نمیشود و env=prod حذف شدهاست و اکنون اجرای ng build --prod مانند اجرای دستور ng build --configuration=prod است.
تغییرات نامهای نهایی تولیدی
در CLI 6.0، نامهای نهایی تولیدی دیگر به همراه bundle و یا chunk نیستند. برای مثال دستور ng build یک چنین خروجی را تولید میکند:
و هشهای حالت prod به صورت زیر تولید و به نام فایل اضافه میشوند:
ساده شدن افزودن وابستگیهای ثالث به پروژههای CLI
برای نصب یک کتابخانهی ثالث، پیشتر میبایستی ابتدا بستهی npm آن جداگانه نصب و سپس فایل config برنامه، جهت معرفی مداخل آن، ویرایش میشد. اکنون دستور جدید ng add تمام این مراحل را به صورت خودکار انجام میدهد:
برای نمونه دستور فوق نه تنها فایلهای Angular Material را دریافت میکند، بلکه فایلهای CSS و ماژولهای مرتبط با آنرا نیز import خواهد کرد. البته این مورد از کلید ng-add فایل package.json بستهی در حال نصب دریافت و تنظیم میشود و کتابخانههای جدید باید خود را بر این اساس وفق دهند.
node -v npm -v
فایل پیشین angular-cli.json حذف و فایل جدید angular.json بجای آن معرفی شدهاست
یکی از مهمترین تغییرات CLI 6.0 نسبت به نگارشهای قبلی آن، پشتیبانی از چندین پروژه است و به همین منظور ساختار فایل تنظیمات آنرا به طور کامل تغییر دادهاند و اگر دستور ng new project1 را صادر کنید، دیگر از فایل پیشین angular-cli.json خبری نبوده و بجای آن فایل جدید angular.json قابل مشاهدهاست:
{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", "version": 1, "newProjectRoot": "projects", "projects": { "project1": {
مزیت مهم این قابلیت، امکان ایجاد libraries است که به صورت توکار از این نگارش پشتیبانی میشود و میتوان اجزایی مانند components ،directives ،pipes و services اشتراکی را در یک یا چندین کتابخانه قرار داد و سپس از آنها در پروژهی اصلی و یا چندین پروژهی متصل استفاده کرد.
نگارش 6 در پشت صحنه، پروژهی موفق ng-packagr را به مجموعهی CLI اضافه کردهاست و از این پس توسط خود CLI میتوان کتابخانههای استاندارد Angular را تولید کرد. این مورد، مزیت استاندارد سازی کتابخانههای npm حاصل را نیز به همراه دارد؛ مشکلی که گاهی از اوقات به علت عدم رعایت این ساختار، با بستههای فعلی npm مخصوص Angular وجود دارند. برای مثال بدون استفادهی از این ابزار، نیاز است مستندات 13 صفحهای ساخت کتابخانههای Angular را سطر به سطر پیاده سازی کنید که توسط CLI 6.0، به صورت خودکار ایجاد و مدیریت میشود.
بنابراین اکنون سؤال مهمی که مطرح میشود این است: آیا باید فایل angular-cli.json پیشین را به صورت دستی به این فایل جدید به روز رسانی کرد و چگونه؟
به روز رسانی تمام بستههای سراسری سیستم
در ادامه پیش از هر کاری نیاز است تمام بستههای سراسری npm ایی را که هر از چندگاهی به سیستم خود اضافه کردهاید، به روز رسانی کنید. برای مشاهدهی لیست موارد تاریخ مصرف گذشتهی آنها، دستور زیر را صادر کنید:
npm outdated -g --depth=0
npm update -g
به روز رسانی خودکار ساختار فایل angular-cli.json
این به روز رسانی توسط CLI 6.0 به صورت خودکار پشتیبانی میشود و شامل این مراحل است:
ابتدا نیاز است بستهی سراسری آنرا به روز رسانی کرد:
npm i -g @angular/cli
npm install --save-dev @angular/cli@latest
ng update @angular/cli ng update @angular/core ng update rxjs
DELETE .angular-cli.json CREATE angular.json (4273 bytes) UPDATE karma.conf.js (1008 bytes) UPDATE src/tsconfig.spec.json (322 bytes) UPDATE package.json (2076 bytes) UPDATE tslint.json (3217 bytes)
لیست سایر بستههایی را که میتوان توسط این دستور به روز رسانی کرد، با اجرا دستور ng update میتوانید مشاهده کنید. برای مثال اگر از Angular Material نیز استفاده میکنید، دستور به روز رسانی آن به صورت زیر است:
ng update @angular/material
مشکل! دستور ng update کار نمیکند!
اگر پروژهی شما صرفا مبتنی بر بستههای اصلی Angular باشد، مراحل یاد شدهی فوق را با موفقیت به پایان خواهید رساند. اما اگر از کتابخانههای ثالثی استفاده کرده باشید، منهای دستور «ng update @angular/cli» که کار تولید فایل جدید angular.json را انجام میدهد، مابقی با خطاهایی مانند «incompatible peer dependency» و یا «Invalid range:>=2.3.1 <3.0.0||>=4.0.0» متوقف میشوند.
در یک چنین حالتی نیاز است ابتدا وابستگیهای محلی پروژه را به روز کرد و سپس دستورات ng update را تکرار نمود. برای این منظور ابتدا بستهی npm-check-updates را نصب کنید:
npm install npm-check-updates -g
ncu -u npm install
اکنون تمام وابستگیهای محلی پروژهی شما به صورت خودکار به آخرین نگارش آنها به روز رسانی شدهاند و اینبار اگر دستورات ذیل را اجرا کنید، با خطاهای یاد شده مواجه نخواهید شد:
ng update @angular/core ng update rxjs
البته اگر در این حالت برنامه را کامپایل کنید، کار نخواهد کرد. علت اصلی آن به بهروز رسانی rxjs به نگارش 6 آن مرتبط میشود که در مطلب بعدی پیگیری خواهد شد و این نگارش شامل حذفیات بسیاری است در جهت کاهش حجم آن، یکپارچکی و یک دست شدن syntax آن و همچنین بهبود قابل ملاحظهی کارآیی آن. البته پیشنیاز الزامی آن آشنایی با pipe-able operators است. علت دیگر کامپایل نشدن برنامه هم میتواند عدم استفاده از HttpClient نگارش 4.3 به بعد باشد.
خاموش کردن اخطار «TypeScript version mismatch»
اگر نگارش TypeScript نصب شدهی در سیستم به صورت سراسری، با نگارش محلی پروژهی شما یکی نباشد، اخطار «TypeScript version mismatch» را دریافت میکنید. روش خاموش کردن آن در CLI جدید با اجرای دستور زیر است:
ng config cli.warnings.typescriptMismatch false
{ "devDependencies": { "typescript": "~2.7.2" } }
تغییرات ng build در نگارش 6
در نگارش 6، مفهوم پیشین environments به configurations تغییر یافتهاست و اینبار در فایل جدید angular.json تنظیم میشوند:
{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", "version": 1, "newProjectRoot": "projects", "projects": { "angular-template-driven-forms-lab": { "configurations": { "production": { "optimization": true, "outputHashing": "all", "sourceMap": false, "extractCss": true, "namedChunks": false, "aot": true, "extractLicenses": true, "vendorChunk": false, "buildOptimizer": true, "fileReplacements": [ { "replace": "src/environments/environment.ts", "with": "src/environments/environment.prod.ts" } ] } } },
ng build --env staging
ng build --configuration staging
تغییرات نامهای نهایی تولیدی
در CLI 6.0، نامهای نهایی تولیدی دیگر به همراه bundle و یا chunk نیستند. برای مثال دستور ng build یک چنین خروجی را تولید میکند:
>ng build --watch Date: 2018-05-05T09:10:50.158Z Hash: a43eab94ff01539b8592 Time: 31733ms chunk {main} main.js, main.js.map (main) 9.38 kB [initial] [rendered] chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 226 kB [initial] [rendered] chunk {runtime} runtime.js, runtime.js.map (runtime) 5.4 kB [entry] [rendered] chunk {styles} styles.js, styles.js.map (styles) 15.6 kB [initial] [rendered] chunk {vendor} vendor.js, vendor.js.map (vendor) 3.05 MB [initial] [rendered]
و هشهای حالت prod به صورت زیر تولید و به نام فایل اضافه میشوند:
>ng build --prod --watch Date: 2018-05-05T09:17:01.803Z Hash: f25fd6788a4969c52b70 Time: 73279ms chunk {0} runtime.6afe30102d8fe7337431.js (runtime) 1.05 kB [entry] [rendered] chunk {1} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered] chunk {2} polyfills.6c08419970f9e4781b69.js (polyfills) 59.4 kB [initial] [rendered]
ساده شدن افزودن وابستگیهای ثالث به پروژههای CLI
برای نصب یک کتابخانهی ثالث، پیشتر میبایستی ابتدا بستهی npm آن جداگانه نصب و سپس فایل config برنامه، جهت معرفی مداخل آن، ویرایش میشد. اکنون دستور جدید ng add تمام این مراحل را به صورت خودکار انجام میدهد:
ng add @angular/material
در مورد «امکانات توکار تزریق وابستگیها در ASP.NET Core» پیشتر بحث شد. همچنین «نحوهی تعریف Context، تزریق سرویسهای EF Core و تنظیمات رشتهی اتصالی آن» را نیز بررسی کردیم. به علاوه مباحث «به روز رسانی ساختار بانک اطلاعاتی» و «انتقال مهاجرتها به یک اسمبلی دیگر» نیز مرور شدند. بنابراین در این قسمت برای لایه بندی برنامههای EF Core، صرفا یک مثال را مرور خواهیم کرد که این قسمتها را در کنار هم قرار میدهد و عملا نکتهی اضافهتری را ندارد.
تزریق مستقیم کلاس Context برنامه، تزریق وابستگیها نام ندارد!
در همان قسمت اول سری شروع به کار با EF Core 1.0، مشاهده کردیم که پس از انجام تنظیمات اولیهی آن در کلاس آغازین برنامه:
Context برنامه را در تمام قسمتهای آن میتوان تزریق کرد و کار میکند:
این روشی است که در بسیاری از مثالهای گوشه و کنار اینترنت قابل مشاهدهاست. یا کلاس Context را مستقیما در سازندهی کنترلرها تزریق میکنند و از آن استفاده میکنند (روش فوق) و یا لایهی سرویسی را ایجاد کرده و مجددا همین تزریق مستقیم را در آنجا انجام میدهند و سپس اینترفیسهای آن سرویس را در کنترلرهای برنامه تزریق کرده و استفاده میکنند. به این نوع تزریق وابستگیها، تزریق concrete types و یا concrete classes میگویند.
مشکلاتی را که تزریق مستقیم کلاسها و نوعها به همراه دارند به شرح زیر است:
- اگر نام این کلاس تغییر کند، باید این نام، در تمام کلاسهایی که به صورت مستقیم از آن استفاده میکنند نیز تغییر داده شود.
- اگر سازندهای به آن اضافه شد و یا امضای سازندهی موجود آن، تغییر کرد، باید نحوهی وهله سازی این کلاس را در تمام کلاسهای وابسته نیز اصلاح کرد.
- یکی از مهمترین دلایل استفادهی از تزریق وابستگیها، بالابردن قابلیت تست پذیری برنامه است. زمانیکه از اینترفیسها استفاده میشود، میتوان در مورد نحوهی تقلید (mocking) رفتار کلاسی خاص، مستقلا تصمیم گیری کرد. اما هنگامیکه یک کلاس را به همان شکل اولیهی آن تزریق میکنیم، به این معنا است که همواره دقیقا همین پیاده سازی خاص مدنظر ما است و این مساله، نوشتن آزمونهای واحد را با مشکل کردن mocking آنها، گاهی از اوقات غیرممکن میکند. هرچند تعدادی از فریم ورکهای پیشرفتهی mocking گاهی از اوقات امکان تقلید رفتار کلاسها و نوعها را نیز فراهم میکنند، اما با این شرط که تمام خواص و متدهای آنها را virtual تعریف کنید؛ تا بتوانند متدهای اصلی را با نمونههای مدنظر شما بازنویسی (override) کنند.
به همین جهت در ادامه، به همان طراحی EF Code First #12 با نوشتن اینترفیس IUnitOfWork خواهیم رسید. یعنی کلاس Context برنامه را با این اینترفیس نشانه گذاری میکنیم (در انتهای لیست تمام اینترفیسهای دیگری که ممکن است در اینجا ذکر شده باشند):
و سپس اینترفیس IUnitOfWork را به لایه سرویس برنامه و یا هر لایهی دیگری که به Context آن نیاز دارد، تزریق خواهیم کرد.
طراحی اینترفیس IUnitOfWork
برای اینکه دیگر با کلاس ApplicationDbContext مستقیما کار نکرده و وابستگی به آنرا در تمام قسمتهای برنامه پخش نکنیم، اینترفیسی را ایجاد میکنیم که تنها قسمتهای مشخصی از DbContext را عمومی کند:
توضیحات
- در این طراحی شاید عنوان کنید که DbSet، اینترفیس نیست. تعریف DbSet در EF Core به صورت زیر است و در حقیقت همانند اینترفیسها یک abstraction به حساب میآید:
علت اینکه در پروژههای بزرگی مانند EF، تمایل زیادی به استفادهی از کلاسهای abstract وجود دارد (بجای اینترفیسها) این است که اگر این نوع پرکاربرد را به صورت اینترفیس تعریف کنند، با تغییر متدی در آن، باید تمام کدهای خود را به اجبار بازنویسی کنید. اما در حالت استفادهی از کلاسهای abstract، میتوان پیاده سازی پیش فرضی را برای متدهایی که قرار است در آینده اضافه شوند، ارائه داد (یکی از تفاوتهای مهم آنها با اینترفیسها)، بدون اینکه تمام استفاده کنندگان از این کتابخانه، با ارتقاء نگارش EF خود، دیگر نتوانند برنامهی خود را کامپایل کنند.
- این اینترفیس به عمد به صورت IDisposable تعریف شدهاست. این مساله به IoC Containers کمک خواهد کرد که بتوانند پاکسازی خودکار نوعهای IDisposable را در انتهای هر درخواست انجام دهند و برنامه مشکلی نشتی حافظه را پیدا نکند.
- اصل کار این اینترفیس، تعریف DbSet و متدهای SaveChanges است. سایر متدهایی را که مشاهده میکنید، صرفا جهت بیان اینکه چگونه میتوان قابلیتی از DbContext را بدون عمومی کردن خود کلاس DbContext، در کلاسهایی که از اینترفیس IUnitOfWork استفاده میکنند، میسر کرد.
پس از اینکه این اینترفیس تعریف شد، اعمال آن به کلاس Context برنامه به صورت ذیل خواهد بود:
در ابتدا اینترفیس IUnitOfWork به کلاس Context برنامه اعمال شدهاست:
و سپس متدهای آن منهای پیاده سازی اینترفیس IDisposable اعمالی به IUnitOfWork :
پیاده سازی شدهاند. علت اینجا است که چون کلاس پایه DbContext از همین اینترفیس مشتق میشود، دیگر نیاز به پیاده سازی اینترفیس IDisposable نیست.
در مورد تزریق IConfigurationRoot به سازندهی کلاس Context برنامه، در مطلب اول این سری در قسمت «یک نکته: امکان تزریق IConfigurationRoot به کلاس Context برنامه» پیشتر بحث شدهاست.
ثبت تنظیمات تزریق وابستگیهای IUnitOfWork
پس از تعریف و پیاده سازی اینترفیس IUnitOfWork، اکنون نوبت به معرفی آن به سیستم تزریق وابستگیهای ASP.NET Core است:
در اینجا هم ApplicationDbContext و هم IUnitOfWork با طول عمر Scoped به تنظیمات IoC Container مربوط به ASP.NET Core اضافه شدهاند. به این ترتیب هر زمانیکه وهلهای از نوع IUnitOfWork درخواست شود، تنها یک وهله از ApplicationDbContext در طول درخواست وب جاری، در اختیار مصرف کننده قرار میگیرد و همچنین مدیریت Dispose این وهلهها نیز خودکار است. به همین جهت اینترفیس IUnitOfWork را با IDisposable علامتگذاری کردیم.
استفاده از IUnitOfWork در لایه سرویسهای برنامه
اکنون لایه سرویس برنامه و فایل project.json آن چنین شکلی را پیدا میکند:
در اینجا ارجاعاتی را به اسمبلیهای موجودیتها و DataLayer برنامه مشاهده میکنید. در مورد این اسمبلیها در مطلب «شروع به کار با EF Core 1.0 - قسمت 3 - انتقال مهاجرتها به یک اسمبلی دیگر» پیشتر بحث شد.
پس از تنظیم وابستگیهای این اسمبلی، اکنون یک کلاس نمونه از لایه سرویس برنامه، به شکل زیر خواهد بود:
در اینجا اکنون میتوان IUnitOfWork را به سازندهی کلاس سرویس Blog تنظیم کرد و سپس به نحو متداولی از امکانات EF Core استفاده نمود.
استفاده از امکانات لایه سرویس برنامه، در دیگر لایههای آن
خروجی لایه سرویس، توسط اینترفیسهایی مانند IBlogService در قسمتهای دیگر برنامه قابل استفاده و دسترسی میشود.
به همین جهت نیاز است مشخص کنیم، این اینترفیس را کدام کلاس ویژه قرار است پیاده سازی کند. برای این منظور همانند قبل در متد ConfigureServices کلاس آغازین برنامه این تنظیم را اضافه خواهیم کرد:
پس از آن، امضای سازندهی کلاس کنترلری که در ابتدای بحث عنوان شد، به شکل زیر تغییر پیدا میکند:
در اینجا کنترلر برنامه تنها با اینترفیسهای IUnitOfWork و IBlogService کار میکند و دیگر ارجاع مستقیمی را به کلاس ApplicationDbContext ندارد.
تزریق مستقیم کلاس Context برنامه، تزریق وابستگیها نام ندارد!
در همان قسمت اول سری شروع به کار با EF Core 1.0، مشاهده کردیم که پس از انجام تنظیمات اولیهی آن در کلاس آغازین برنامه:
public void ConfigureServices(IServiceCollection services) { services.AddDbContext<ApplicationDbContext>(ServiceLifetime.Scoped);
public class TestDBController : Controller { private readonly ApplicationDbContext _ctx; public TestDBController(ApplicationDbContext ctx) { _ctx = ctx; } public IActionResult Index() { var name = _ctx.Persons.First().FirstName; return Json(new { firstName = name }); } }
مشکلاتی را که تزریق مستقیم کلاسها و نوعها به همراه دارند به شرح زیر است:
- اگر نام این کلاس تغییر کند، باید این نام، در تمام کلاسهایی که به صورت مستقیم از آن استفاده میکنند نیز تغییر داده شود.
- اگر سازندهای به آن اضافه شد و یا امضای سازندهی موجود آن، تغییر کرد، باید نحوهی وهله سازی این کلاس را در تمام کلاسهای وابسته نیز اصلاح کرد.
- یکی از مهمترین دلایل استفادهی از تزریق وابستگیها، بالابردن قابلیت تست پذیری برنامه است. زمانیکه از اینترفیسها استفاده میشود، میتوان در مورد نحوهی تقلید (mocking) رفتار کلاسی خاص، مستقلا تصمیم گیری کرد. اما هنگامیکه یک کلاس را به همان شکل اولیهی آن تزریق میکنیم، به این معنا است که همواره دقیقا همین پیاده سازی خاص مدنظر ما است و این مساله، نوشتن آزمونهای واحد را با مشکل کردن mocking آنها، گاهی از اوقات غیرممکن میکند. هرچند تعدادی از فریم ورکهای پیشرفتهی mocking گاهی از اوقات امکان تقلید رفتار کلاسها و نوعها را نیز فراهم میکنند، اما با این شرط که تمام خواص و متدهای آنها را virtual تعریف کنید؛ تا بتوانند متدهای اصلی را با نمونههای مدنظر شما بازنویسی (override) کنند.
به همین جهت در ادامه، به همان طراحی EF Code First #12 با نوشتن اینترفیس IUnitOfWork خواهیم رسید. یعنی کلاس Context برنامه را با این اینترفیس نشانه گذاری میکنیم (در انتهای لیست تمام اینترفیسهای دیگری که ممکن است در اینجا ذکر شده باشند):
public class ApplicationDbContext : IUnitOfWork
طراحی اینترفیس IUnitOfWork
برای اینکه دیگر با کلاس ApplicationDbContext مستقیما کار نکرده و وابستگی به آنرا در تمام قسمتهای برنامه پخش نکنیم، اینترفیسی را ایجاد میکنیم که تنها قسمتهای مشخصی از DbContext را عمومی کند:
public interface IUnitOfWork : IDisposable { DbSet<TEntity> Set<TEntity>() where TEntity : class; void AddRange<TEntity>(IEnumerable<TEntity> entities) where TEntity : class; void RemoveRange<TEntity>(IEnumerable<TEntity> entities) where TEntity : class; EntityEntry<TEntity> Entry<TEntity>(TEntity entity) where TEntity : class; void MarkAsChanged<TEntity>(TEntity entity) where TEntity : class; void ExecuteSqlCommand(string query); void ExecuteSqlCommand(string query, params object[] parameters); int SaveAllChanges(); Task<int> SaveAllChangesAsync(); }
- در این طراحی شاید عنوان کنید که DbSet، اینترفیس نیست. تعریف DbSet در EF Core به صورت زیر است و در حقیقت همانند اینترفیسها یک abstraction به حساب میآید:
public abstract class DbSet<TEntity> : IQueryable<TEntity>, IEnumerable<TEntity>, IEnumerable, IQueryable, IAsyncEnumerableAccessor<TEntity>, IInfrastructure<IServiceProvider> where TEntity : class
- این اینترفیس به عمد به صورت IDisposable تعریف شدهاست. این مساله به IoC Containers کمک خواهد کرد که بتوانند پاکسازی خودکار نوعهای IDisposable را در انتهای هر درخواست انجام دهند و برنامه مشکلی نشتی حافظه را پیدا نکند.
- اصل کار این اینترفیس، تعریف DbSet و متدهای SaveChanges است. سایر متدهایی را که مشاهده میکنید، صرفا جهت بیان اینکه چگونه میتوان قابلیتی از DbContext را بدون عمومی کردن خود کلاس DbContext، در کلاسهایی که از اینترفیس IUnitOfWork استفاده میکنند، میسر کرد.
پس از اینکه این اینترفیس تعریف شد، اعمال آن به کلاس Context برنامه به صورت ذیل خواهد بود:
public class ApplicationDbContext : DbContext, IUnitOfWork { private readonly IConfigurationRoot _configuration; public ApplicationDbContext(IConfigurationRoot configuration) { _configuration = configuration; } //public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) //{ //} public virtual DbSet<Blog> Blog { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer( _configuration["ConnectionStrings:ApplicationDbContextConnection"] , serverDbContextOptionsBuilder => { var minutes = (int)TimeSpan.FromMinutes(3).TotalSeconds; serverDbContextOptionsBuilder.CommandTimeout(minutes); } ); } protected override void OnModelCreating(ModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); } public void AddRange<TEntity>(IEnumerable<TEntity> entities) where TEntity : class { base.Set<TEntity>().AddRange(entities); } public void RemoveRange<TEntity>(IEnumerable<TEntity> entities) where TEntity : class { base.Set<TEntity>().RemoveRange(entities); } public void MarkAsChanged<TEntity>(TEntity entity) where TEntity : class { base.Entry(entity).State = EntityState.Modified; // Or use ---> this.Update(entity); } public void ExecuteSqlCommand(string query) { base.Database.ExecuteSqlCommand(query); } public void ExecuteSqlCommand(string query, params object[] parameters) { base.Database.ExecuteSqlCommand(query, parameters); } public int SaveAllChanges() { return base.SaveChanges(); } public Task<int> SaveAllChangesAsync() { return base.SaveChangesAsync(); } }
public class ApplicationDbContext : DbContext, IUnitOfWork
public interface IUnitOfWork : IDisposable
در مورد تزریق IConfigurationRoot به سازندهی کلاس Context برنامه، در مطلب اول این سری در قسمت «یک نکته: امکان تزریق IConfigurationRoot به کلاس Context برنامه» پیشتر بحث شدهاست.
ثبت تنظیمات تزریق وابستگیهای IUnitOfWork
پس از تعریف و پیاده سازی اینترفیس IUnitOfWork، اکنون نوبت به معرفی آن به سیستم تزریق وابستگیهای ASP.NET Core است:
public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IConfigurationRoot>(provider => { return Configuration; }); services.AddDbContext<ApplicationDbContext>(ServiceLifetime.Scoped); services.AddScoped<IUnitOfWork, ApplicationDbContext>();
استفاده از IUnitOfWork در لایه سرویسهای برنامه
اکنون لایه سرویس برنامه و فایل project.json آن چنین شکلی را پیدا میکند:
{ "version": "1.0.0-*", "dependencies": { "Core1RtmEmptyTest.DataLayer": "1.0.0-*", "Core1RtmEmptyTest.Entities": "1.0.0-*", "Core1RtmEmptyTest.ViewModels": "1.0.0-*", "Microsoft.Extensions.Configuration.Abstractions": "1.0.0", "Microsoft.Extensions.Options": "1.0.0", "NETStandard.Library": "1.6.0" }, "frameworks": { "netstandard1.6": { "imports": "dnxcore50" } } }
پس از تنظیم وابستگیهای این اسمبلی، اکنون یک کلاس نمونه از لایه سرویس برنامه، به شکل زیر خواهد بود:
namespace Core1RtmEmptyTest.Services { public interface IBlogService { IReadOnlyList<Blog> GetPagedBlogsAsNoTracking(int pageNumber, int recordsPerPage); } public class BlogService : IBlogService { private readonly IUnitOfWork _uow; private readonly DbSet<Blog> _blogs; public BlogService(IUnitOfWork uow) { _uow = uow; _blogs = _uow.Set<Blog>(); } public IReadOnlyList<Blog> GetPagedBlogsAsNoTracking(int pageNumber, int recordsPerPage) { var skipRecords = pageNumber * recordsPerPage; return _blogs .AsNoTracking() .Skip(skipRecords) .Take(recordsPerPage) .ToList(); } } }
استفاده از امکانات لایه سرویس برنامه، در دیگر لایههای آن
خروجی لایه سرویس، توسط اینترفیسهایی مانند IBlogService در قسمتهای دیگر برنامه قابل استفاده و دسترسی میشود.
به همین جهت نیاز است مشخص کنیم، این اینترفیس را کدام کلاس ویژه قرار است پیاده سازی کند. برای این منظور همانند قبل در متد ConfigureServices کلاس آغازین برنامه این تنظیم را اضافه خواهیم کرد:
public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IConfigurationRoot>(provider => { return Configuration; }); services.AddDbContext<ApplicationDbContext>(ServiceLifetime.Scoped); services.AddScoped<IUnitOfWork, ApplicationDbContext>(); services.AddScoped<IBlogService, BlogService>();
public class TestDBController : Controller { private readonly IBlogService _blogService; private readonly IUnitOfWork _uow; public TestDBController(IBlogService blogService, IUnitOfWork uow) { _blogService = blogService; _uow = uow; }
AuthenticationMiddleware در ASP.NET Core 2.0، فقط مختص به کار با کوکیها جهت اعتبارسنجی کاربران نیست. از این میانافزار میتوان برای اعتبار سنجیهای مبتنی بر JSON Web Tokens نیز استفاده کرد. مطلبی را که در ادامه مطالعه خواهید کرد دقیقا بر اساس نکات مطلب «پیاده سازی JSON Web Token با ASP.NET Web API 2.x» تدارک دیده شدهاست و به همراه نکاتی مانند تولید Refresh Tokens و یا غیرمعتبر سازی توکنها نیز هست. همچنین ساختار جداول کاربران و نقشهای آنها، سرویسهای مرتبط و قسمت تنظیمات Context آن با مطلب «اعتبارسنجی مبتنی بر کوکیها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity» یکی است. در اینجا بیشتر به تفاوتهای پیاده سازی این روش نسبت به حالت اعتبارسنجی مبتنی بر کوکیها خواهیم پرداخت.
همچنین باید درنظر داشت، ASP.NET Core Identity یک سیستم اعتبارسنجی مبتنی بر کوکیها است. دقیقا زمانیکه کار AddIdentity را انجام میدهیم، در پشت صحنه همان services.AddAuthentication().AddCookie قسمت قبل فراخوانی میشود. بنابراین بکارگیری آن با JSON Web Tokens هرچند مشکلی را به همراه ندارد و میتوان یک سیستم اعتبارسنجی «دوگانه» را نیز در اینجا داشت، اما ... سربار اضافی تولید کوکیها را نیز به همراه دارد؛ هرچند برای کار با میانافزار اعتبارسنجی، الزامی به استفادهی از ASP.NET Core Identity نیست و عموما اگر از آن به همراه JWT استفاده میکنند، بیشتر به دنبال پیاده سازیهای پیشفرض مدیریت کاربران و نقشهای آن هستند و نه قسمت تولید کوکیهای آن. البته در مطلب جاری این موارد را نیز همانند مطلب اعتبارسنجی مبتنی بر کوکیها، خودمان مدیریت خواهیم کرد و در نهایت سیستم تهیه شده، هیچ نوع کوکی را تولید و یا مدیریت نمیکند.
تنظیمات آغازین برنامه جهت فعالسازی اعتبارسنجی مبتنی بر JSON Web Tokens
اولین تفاوت پیاده سازی یک سیستم اعتبارسنجی مبتنی بر JWT، با روش مبتنی بر کوکیها، تنظیمات متد ConfigureServices فایل آغازین برنامه است:
در اینجا در ابتدا تنظیمات JWT فایل appsettings.json
به کلاسی دقیقا با همین ساختار به نام BearerTokensOptions، نگاشت شدهاند. به این ترتیب میتوان با تزریق اینترفیس <IOptionsSnapshot<BearerTokensOptions در قسمتهای مختلف برنامه، به این تنظیمات مانند کلید رمزنگاری، مشخصات صادر کننده، مخاطبین و طول عمرهای توکنهای صادر شده، دسترسی یافت.
سپس کار فراخوانی services.AddAuthentication صورت گرفتهاست. تفاوت این مورد با حالت اعتبارسنجی مبتنی بر کوکیها، ثوابتی است که با JwtBearerDefaults شروع میشوند. در حالت استفادهی از کوکیها، این ثوابت بر اساس CookieAuthenticationDefaults تنظیم خواهند شد.
البته میتوان متد AddAuthentication را بدون هیچگونه پارامتری نیز فراخوانی کرد. این حالت برای اعتبارسنجیهای دوگانه مفید است. برای مثال زمانیکه پس از AddAuthentication هم AddJwtBearer را ذکر کردهاید و هم AddCookie اضافه شدهاست. اگر چنین کاری را انجام دادید، اینبار باید درحین تعریف فیلتر Authorize، دقیقا مشخص کنید که حالت مبتنی بر JWT مدنظر شما است، یا حالت مبتنی بر کوکیها:
اگر متد AddAuthentication، مانند تنظیمات فوق به همراه این تنظیمات پیشفرض بود، دیگر نیازی به ذکر صریح AuthenticationSchemes در فیلتر Authorize نخواهد بود.
بررسی تنظیمات متد AddJwtBearer
در کدهای فوق، تنظیمات متد AddJwtBearer یک چنین مفاهیمی را به همراه دارند:
- تنظیم SaveToken به true، به این معنا است که میتوان به توکن دریافتی از سمت کاربر، توسط متد HttpContext.GetTokenAsync در کنترلرهای برنامه دسترسی یافت.
در قسمت تنظیمات TokenValidationParameters آن:
- کار خواندن فایل appsettings.json برنامه جهت تنظیم صادر کننده و مخاطبین توکن انجام میشود. سپس IssuerSigningKey به یک کلید رمزنگاری متقارن تنظیم خواهد شد. این کلید نیز در تنظیمات برنامه قید میشود.
- تنظیم ValidateIssuerSigningKey به true سبب خواهد شد تا میانافزار اعتبارسنجی، بررسی کند که آیا توکن دریافتی از سمت کاربر توسط برنامهی ما امضاء شدهاست یا خیر؟
- تنظیم ValidateLifetime به معنای بررسی خودکار طول عمر توکن دریافتی از سمت کاربر است. اگر توکن منقضی شده باشد، اعتبارسنجی به صورت خودکار خاتمه خواهد یافت.
- ClockSkew به معنای تنظیم یک تلرانس و حد تحمل مدت زمان منقضی شدن توکن در حالت ValidateLifetime است. در اینجا به صفر تنظیم شدهاست.
سپس به قسمت JwtBearerEvents میرسیم:
- OnAuthenticationFailed زمانی فراخوانی میشود که اعتبارسنجهای تنظیمی فوق، با شکست مواجه شوند. برای مثال طول عمر توکن منقضی شده باشد و یا توسط ما امضاء نشدهباشد. در اینجا میتوان به این خطاها دسترسی یافت و درصورت نیاز آنها را لاگ کرد.
- OnChallenge نیز یک سری دیگر از خطاهای اعتبارسنجی را پیش از ارسال آنها به فراخوان در اختیار ما قرار میدهد.
- OnMessageReceived برای حالتی است که توکن دریافتی، توسط هدر مخصوص Bearer به سمت سرور ارسال نمیشود. عموما هدر ارسالی به سمت سرور یک چنین شکلی را دارد:
اما اگر توکن شما به این شکل استاندارد دریافت نمیشود، میتوان در رخداد OnMessageReceived به اطلاعات درخواست جاری دسترسی یافت، توکن را از آن استخراج کرد و سپس آنرا به خاصیت context.Token انتساب داد، تا به عنوان توکن اصلی مورد استفاده قرار گیرد. برای مثال:
- OnTokenValidated پس از کامل شدن اعتبارسنجی توکن دریافتی از سمت کاربر فراخوانی میشود. در اینجا اگر متد context.Fail را فراخوانی کنیم، این توکن، به عنوان یک توکن غیرمعتبر علامتگذاری میشود و عملیات اعتبارسنجی با شکست خاتمه خواهد یافت. بنابراین میتوان از آن دقیقا مانند CookieValidatorService قسمت قبل که جهت واکنش نشان دادن به تغییرات اطلاعات کاربر در سمت سرور مورد استفاده قرار دادیم، در اینجا نیز یک چنین منطقی را پیاده سازی کنیم.
تهیه یک اعتبارسنج توکن سفارشی
قسمت OnTokenValidated تنظیمات ابتدای برنامه به این صورت مقدار دهی شدهاست:
TokenValidatorService سفارشی ما چنین پیاده سازی را دارد:
در اینجا بررسی میکنیم:
- آیا توکن دریافتی به همراه Claims تنظیم شدهی درحین لاگین هست یا خیر؟
- آیا توکن دریافتی دارای یک Claim سفارشی به نام SerialNumber است؟ این SerialNumber معادل چنین فیلدی در جدول کاربران است.
- آیا توکن دریافتی دارای user-id است؟
- آیا کاربر یافت شدهی بر اساس این user-id هنوز فعال است و یا اطلاعات او تغییر نکردهاست؟
- همچنین در آخر کار بررسی میکنیم که آیا اصل توکن دریافتی، در بانک اطلاعاتی ما پیشتر ثبت شدهاست یا خیر؟
اگر خیر، بلافاصله متد context.Fail فراخوانی شده و کار اعتبارسنجی را با اعلام شکست آن، به پایان میرسانیم.
در قسمت آخر، نیاز است اطلاعات توکنهای صادر شده را ذخیره کنیم. به همین جهت نسبت به مطلب قبلی، جدول UserToken ذیل به برنامه اضافه شدهاست:
در اینجا هشهای توکنهای صادر شدهی توسط برنامه و طول عمر آنها را ذخیره خواهیم کرد.
از اطلاعات آن در دو قسمت TokenValidatorService فوق و همچنین قسمت logout برنامه استفاده میکنیم. در سیستم JWT، مفهوم logout سمت سرور وجود خارجی ندارد. اما با ذخیره سازی هش توکنها در بانک اطلاعاتی میتوان لیستی از توکنهای صادر شدهی توسط برنامه را تدارک دید. سپس در حین logout فقط کافی است tokenهای یک کاربر را حذف کرد. همینقدر سبب خواهد شد تا قسمت آخر TokenValidatorService با شکست مواجه شود؛ چون توکن ارسالی به سمت سرور دیگر در بانک اطلاعاتی وجود ندارد.
سرویس TokenStore
در قسمت آخر اعتبارسنج سفارشی توکن، بررسی وجود توکن دریافتی، توسط سرویس TokenStore فوق صورت میگیرد. از این سرویس برای تولید، ذخیره سازی و حذف توکنها استفاده خواهیم کرد.
پیاده سازی کامل این سرویس را در اینجا میتوانید مشاهده کنید.
تولید Access Tokens و Refresh Tokens
پس از تنظیمات ابتدایی برنامه، اکنون میتوانیم دو نوع توکن را تولید کنیم:
تولید Access Tokens
این امکانات در اسمبلی زیر قرار دارند:
در اینجا ابتدا همانند کار با سیستم اعتبارسنجی مبتنی بر کوکیها، نیاز است یک سری Claim تهیه شوند. به همین جهت SerialNumber، UserId و همچنین نقشهای کاربر لاگین شدهی به سیستم را در اینجا به مجموعهی Claims اضافه میکنیم. وجود این Claims است که سبب میشود فیلتر Authorize بتواند نقشها را تشخیص داده و یا کاربر را اعتبارسنجی کند.
پس از تهیهی Claims، اینبار بجای یک کوکی، یک JSON Web Toekn را توسط متد new JwtSecurityTokenHandler().WriteToken تهیه خواهیم کرد. این توکن حاوی Claims، به همراه اطلاعات طول عمر و امضای مرتبطی است.
حاصل آن نیز یک رشتهاست که دقیقا به همین فرمت به سمت کلاینت ارسال خواهد شد. البته ما در اینجا دو نوع توکن را به سمت کلاینت ارسال میکنیم:
accessToken همان JSON Web Token اصلی است. refreshToken فقط یک Guid است. کار آن ساده سازی و به روز رسانی عملیات Login بدون ارائهی نام کاربری و کلمهی عبور است. به همین جهت است که نیاز داریم تا این اطلاعات را در سمت بانک اطلاعاتی برنامه نیز ذخیره کنیم. فرآیند اعتبارسنجی یک refreshToken بدون ذخیره سازی این Guid در بانک اطلاعاتی مسیر نیست که در اینجا در فیلد RefreshTokenIdHash جدول UserToken ذخیره میشود.
جهت بالا رفتن امنیت سیستم، این Guid را هش کرد و سپس این هش را در بانک اطلاعاتی ذخیره میکنیم. به این ترتیب دسترسی غیرمجاز به این هشها، امکان بازیابی توکنهای اصلی را غیرممکن میکند.
پیاده سازی Login
پس از پیاده سازی متد CreateJwtTokens، کار ورود به سیستم به سادگی ذیل خواهد بود:
ابتدا بررسی میشود که آیا کلمهی عبور و نام کاربری وارد شده صحیح هستند یا خیر و آیا کاربر متناظر با آن هنوز فعال است. اگر بله، دو توکن دسترسی و به روز رسانی را تولید و به سمت کلاینت ارسال میکنیم.
پیاده سازی Refresh Token
پیاده سازی توکن به روز رسانی همانند عملیات لاگین است:
با این تفاوت که در اینجا فقط یک Guid از سمت کاربر دریافت شده، سپس بر اساس این Guid، توکن و کاربر متناظر با آن یافت میشوند. سپس یک توکن جدید را بر اساس این اطلاعات تولید کرده و به سمت کاربر ارسال میکنیم.
پیاده سازی Logout
در سیستمهای مبتنی بر JWT، پیاده سازی Logout سمت سرور بیمفهوم است؛ از این جهت که تا زمان انقضای یک توکن میتوان از آن توکن جهت ورود به سیستم و دسترسی به منابع آن استفاده کرد. بنابراین تنها راه پیاده سازی Logout، ذخیره سازی توکنها در بانک اطلاعاتی و سپس حذف آنها در حین خروج از سیستم است. به این ترتیب اعتبارسنج سفارشی توکنها، از استفادهی مجدد از توکنی که هنوز هم معتبر است و منقضی نشدهاست، جلوگیری خواهد کرد:
آزمایش نهایی برنامه
در فایل index.html، نمونهای از متدهای لاگین، خروج و فراخوانی اکشن متدهای محافظت شده را مشاهده میکنید. این روش برای برنامههای تک صفحهای وب یا SPA نیز میتواند مفید باشد و به همین نحو کار میکنند.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
همچنین باید درنظر داشت، ASP.NET Core Identity یک سیستم اعتبارسنجی مبتنی بر کوکیها است. دقیقا زمانیکه کار AddIdentity را انجام میدهیم، در پشت صحنه همان services.AddAuthentication().AddCookie قسمت قبل فراخوانی میشود. بنابراین بکارگیری آن با JSON Web Tokens هرچند مشکلی را به همراه ندارد و میتوان یک سیستم اعتبارسنجی «دوگانه» را نیز در اینجا داشت، اما ... سربار اضافی تولید کوکیها را نیز به همراه دارد؛ هرچند برای کار با میانافزار اعتبارسنجی، الزامی به استفادهی از ASP.NET Core Identity نیست و عموما اگر از آن به همراه JWT استفاده میکنند، بیشتر به دنبال پیاده سازیهای پیشفرض مدیریت کاربران و نقشهای آن هستند و نه قسمت تولید کوکیهای آن. البته در مطلب جاری این موارد را نیز همانند مطلب اعتبارسنجی مبتنی بر کوکیها، خودمان مدیریت خواهیم کرد و در نهایت سیستم تهیه شده، هیچ نوع کوکی را تولید و یا مدیریت نمیکند.
تنظیمات آغازین برنامه جهت فعالسازی اعتبارسنجی مبتنی بر JSON Web Tokens
اولین تفاوت پیاده سازی یک سیستم اعتبارسنجی مبتنی بر JWT، با روش مبتنی بر کوکیها، تنظیمات متد ConfigureServices فایل آغازین برنامه است:
public void ConfigureServices(IServiceCollection services) { services.Configure<BearerTokensOptions>(options => Configuration.GetSection("BearerTokens").Bind(options)); services .AddAuthentication(options => { options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultSignInScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(cfg => { cfg.RequireHttpsMetadata = false; cfg.SaveToken = true; cfg.TokenValidationParameters = new TokenValidationParameters { ValidIssuer = Configuration["BearerTokens:Issuer"], ValidAudience = Configuration["BearerTokens:Audience"], IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Configuration["BearerTokens:Key"])), ValidateIssuerSigningKey = true, ValidateLifetime = true, ClockSkew = TimeSpan.Zero }; cfg.Events = new JwtBearerEvents { OnAuthenticationFailed = context => { var logger = context.HttpContext.RequestServices.GetRequiredService<ILoggerFactory>().CreateLogger(nameof(JwtBearerEvents)); logger.LogError("Authentication failed.", context.Exception); return Task.CompletedTask; }, OnTokenValidated = context => { var tokenValidatorService = context.HttpContext.RequestServices.GetRequiredService<ITokenValidatorService>(); return tokenValidatorService.ValidateAsync(context); }, OnMessageReceived = context => { return Task.CompletedTask; }, OnChallenge = context => { var logger = context.HttpContext.RequestServices.GetRequiredService<ILoggerFactory>().CreateLogger(nameof(JwtBearerEvents)); logger.LogError("OnChallenge error", context.Error, context.ErrorDescription); return Task.CompletedTask; } }; });
{ "BearerTokens": { "Key": "This is my shared key, not so secret, secret!", "Issuer": "http://localhost/", "Audience": "Any", "AccessTokenExpirationMinutes": 2, "RefreshTokenExpirationMinutes": 60 } }
سپس کار فراخوانی services.AddAuthentication صورت گرفتهاست. تفاوت این مورد با حالت اعتبارسنجی مبتنی بر کوکیها، ثوابتی است که با JwtBearerDefaults شروع میشوند. در حالت استفادهی از کوکیها، این ثوابت بر اساس CookieAuthenticationDefaults تنظیم خواهند شد.
البته میتوان متد AddAuthentication را بدون هیچگونه پارامتری نیز فراخوانی کرد. این حالت برای اعتبارسنجیهای دوگانه مفید است. برای مثال زمانیکه پس از AddAuthentication هم AddJwtBearer را ذکر کردهاید و هم AddCookie اضافه شدهاست. اگر چنین کاری را انجام دادید، اینبار باید درحین تعریف فیلتر Authorize، دقیقا مشخص کنید که حالت مبتنی بر JWT مدنظر شما است، یا حالت مبتنی بر کوکیها:
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
بررسی تنظیمات متد AddJwtBearer
در کدهای فوق، تنظیمات متد AddJwtBearer یک چنین مفاهیمی را به همراه دارند:
- تنظیم SaveToken به true، به این معنا است که میتوان به توکن دریافتی از سمت کاربر، توسط متد HttpContext.GetTokenAsync در کنترلرهای برنامه دسترسی یافت.
در قسمت تنظیمات TokenValidationParameters آن:
- کار خواندن فایل appsettings.json برنامه جهت تنظیم صادر کننده و مخاطبین توکن انجام میشود. سپس IssuerSigningKey به یک کلید رمزنگاری متقارن تنظیم خواهد شد. این کلید نیز در تنظیمات برنامه قید میشود.
- تنظیم ValidateIssuerSigningKey به true سبب خواهد شد تا میانافزار اعتبارسنجی، بررسی کند که آیا توکن دریافتی از سمت کاربر توسط برنامهی ما امضاء شدهاست یا خیر؟
- تنظیم ValidateLifetime به معنای بررسی خودکار طول عمر توکن دریافتی از سمت کاربر است. اگر توکن منقضی شده باشد، اعتبارسنجی به صورت خودکار خاتمه خواهد یافت.
- ClockSkew به معنای تنظیم یک تلرانس و حد تحمل مدت زمان منقضی شدن توکن در حالت ValidateLifetime است. در اینجا به صفر تنظیم شدهاست.
سپس به قسمت JwtBearerEvents میرسیم:
- OnAuthenticationFailed زمانی فراخوانی میشود که اعتبارسنجهای تنظیمی فوق، با شکست مواجه شوند. برای مثال طول عمر توکن منقضی شده باشد و یا توسط ما امضاء نشدهباشد. در اینجا میتوان به این خطاها دسترسی یافت و درصورت نیاز آنها را لاگ کرد.
- OnChallenge نیز یک سری دیگر از خطاهای اعتبارسنجی را پیش از ارسال آنها به فراخوان در اختیار ما قرار میدهد.
- OnMessageReceived برای حالتی است که توکن دریافتی، توسط هدر مخصوص Bearer به سمت سرور ارسال نمیشود. عموما هدر ارسالی به سمت سرور یک چنین شکلی را دارد:
$.ajax({ headers: { 'Authorization': 'Bearer ' + jwtToken },
const string tokenKey = "my.custom.jwt.token.key"; if (context.HttpContext.Items.ContainsKey(tokenKey)) { context.Token = (string)context.HttpContext.Items[tokenKey]; }
تهیه یک اعتبارسنج توکن سفارشی
قسمت OnTokenValidated تنظیمات ابتدای برنامه به این صورت مقدار دهی شدهاست:
OnTokenValidated = context => { var tokenValidatorService = context.HttpContext.RequestServices.GetRequiredService<ITokenValidatorService>(); return tokenValidatorService.ValidateAsync(context); },
public class TokenValidatorService : ITokenValidatorService { private readonly IUsersService _usersService; private readonly ITokenStoreService _tokenStoreService; public TokenValidatorService(IUsersService usersService, ITokenStoreService tokenStoreService) { _usersService = usersService; _usersService.CheckArgumentIsNull(nameof(usersService)); _tokenStoreService = tokenStoreService; _tokenStoreService.CheckArgumentIsNull(nameof(_tokenStoreService)); } public async Task ValidateAsync(TokenValidatedContext context) { var userPrincipal = context.Principal; var claimsIdentity = context.Principal.Identity as ClaimsIdentity; if (claimsIdentity?.Claims == null || !claimsIdentity.Claims.Any()) { context.Fail("This is not our issued token. It has no claims."); return; } var serialNumberClaim = claimsIdentity.FindFirst(ClaimTypes.SerialNumber); if (serialNumberClaim == null) { context.Fail("This is not our issued token. It has no serial."); return; } var userIdString = claimsIdentity.FindFirst(ClaimTypes.UserData).Value; if (!int.TryParse(userIdString, out int userId)) { context.Fail("This is not our issued token. It has no user-id."); return; } var user = await _usersService.FindUserAsync(userId).ConfigureAwait(false); if (user == null || user.SerialNumber != serialNumberClaim.Value || !user.IsActive) { // user has changed his/her password/roles/stat/IsActive context.Fail("This token is expired. Please login again."); } var accessToken = context.SecurityToken as JwtSecurityToken; if (accessToken == null || string.IsNullOrWhiteSpace(accessToken.RawData) || !await _tokenStoreService.IsValidTokenAsync(accessToken.RawData, userId).ConfigureAwait(false)) { context.Fail("This token is not in our database."); return; } await _usersService.UpdateUserLastActivityDateAsync(userId).ConfigureAwait(false); } }
- آیا توکن دریافتی به همراه Claims تنظیم شدهی درحین لاگین هست یا خیر؟
- آیا توکن دریافتی دارای یک Claim سفارشی به نام SerialNumber است؟ این SerialNumber معادل چنین فیلدی در جدول کاربران است.
- آیا توکن دریافتی دارای user-id است؟
- آیا کاربر یافت شدهی بر اساس این user-id هنوز فعال است و یا اطلاعات او تغییر نکردهاست؟
- همچنین در آخر کار بررسی میکنیم که آیا اصل توکن دریافتی، در بانک اطلاعاتی ما پیشتر ثبت شدهاست یا خیر؟
اگر خیر، بلافاصله متد context.Fail فراخوانی شده و کار اعتبارسنجی را با اعلام شکست آن، به پایان میرسانیم.
در قسمت آخر، نیاز است اطلاعات توکنهای صادر شده را ذخیره کنیم. به همین جهت نسبت به مطلب قبلی، جدول UserToken ذیل به برنامه اضافه شدهاست:
public class UserToken { public int Id { get; set; } public string AccessTokenHash { get; set; } public DateTimeOffset AccessTokenExpiresDateTime { get; set; } public string RefreshTokenIdHash { get; set; } public DateTimeOffset RefreshTokenExpiresDateTime { get; set; } public int UserId { get; set; } // one-to-one association public virtual User User { get; set; } }
از اطلاعات آن در دو قسمت TokenValidatorService فوق و همچنین قسمت logout برنامه استفاده میکنیم. در سیستم JWT، مفهوم logout سمت سرور وجود خارجی ندارد. اما با ذخیره سازی هش توکنها در بانک اطلاعاتی میتوان لیستی از توکنهای صادر شدهی توسط برنامه را تدارک دید. سپس در حین logout فقط کافی است tokenهای یک کاربر را حذف کرد. همینقدر سبب خواهد شد تا قسمت آخر TokenValidatorService با شکست مواجه شود؛ چون توکن ارسالی به سمت سرور دیگر در بانک اطلاعاتی وجود ندارد.
سرویس TokenStore
public interface ITokenStoreService { Task AddUserTokenAsync(UserToken userToken); Task AddUserTokenAsync( User user, string refreshToken, string accessToken, DateTimeOffset refreshTokenExpiresDateTime, DateTimeOffset accessTokenExpiresDateTime); Task<bool> IsValidTokenAsync(string accessToken, int userId); Task DeleteExpiredTokensAsync(); Task<UserToken> FindTokenAsync(string refreshToken); Task DeleteTokenAsync(string refreshToken); Task InvalidateUserTokensAsync(int userId); Task<(string accessToken, string refreshToken)> CreateJwtTokens(User user); }
پیاده سازی کامل این سرویس را در اینجا میتوانید مشاهده کنید.
تولید Access Tokens و Refresh Tokens
پس از تنظیمات ابتدایی برنامه، اکنون میتوانیم دو نوع توکن را تولید کنیم:
تولید Access Tokens
private async Task<string> createAccessTokenAsync(User user, DateTime expires) { var claims = new List<Claim> { // Unique Id for all Jwt tokes new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()), // Issuer new Claim(JwtRegisteredClaimNames.Iss, _configuration.Value.Issuer), // Issued at new Claim(JwtRegisteredClaimNames.Iat, DateTime.UtcNow.ToUnixEpochDate().ToString(), ClaimValueTypes.Integer64), new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()), new Claim(ClaimTypes.Name, user.Username), new Claim("DisplayName", user.DisplayName), // to invalidate the cookie new Claim(ClaimTypes.SerialNumber, user.SerialNumber), // custom data new Claim(ClaimTypes.UserData, user.Id.ToString()) }; // add roles var roles = await _rolesService.FindUserRolesAsync(user.Id).ConfigureAwait(false); foreach (var role in roles) { claims.Add(new Claim(ClaimTypes.Role, role.Name)); } var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_configuration.Value.Key)); var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256); var token = new JwtSecurityToken( issuer: _configuration.Value.Issuer, audience: _configuration.Value.Audience, claims: claims, notBefore: DateTime.UtcNow, expires: expires, signingCredentials: creds); return new JwtSecurityTokenHandler().WriteToken(token); }
<ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="2.0.0" /> </ItemGroup>
پس از تهیهی Claims، اینبار بجای یک کوکی، یک JSON Web Toekn را توسط متد new JwtSecurityTokenHandler().WriteToken تهیه خواهیم کرد. این توکن حاوی Claims، به همراه اطلاعات طول عمر و امضای مرتبطی است.
حاصل آن نیز یک رشتهاست که دقیقا به همین فرمت به سمت کلاینت ارسال خواهد شد. البته ما در اینجا دو نوع توکن را به سمت کلاینت ارسال میکنیم:
public async Task<(string accessToken, string refreshToken)> CreateJwtTokens(User user) { var now = DateTimeOffset.UtcNow; var accessTokenExpiresDateTime = now.AddMinutes(_configuration.Value.AccessTokenExpirationMinutes); var refreshTokenExpiresDateTime = now.AddMinutes(_configuration.Value.RefreshTokenExpirationMinutes); var accessToken = await createAccessTokenAsync(user, accessTokenExpiresDateTime.UtcDateTime).ConfigureAwait(false); var refreshToken = Guid.NewGuid().ToString().Replace("-", ""); await AddUserTokenAsync(user, refreshToken, accessToken, refreshTokenExpiresDateTime, accessTokenExpiresDateTime).ConfigureAwait(false); await _uow.SaveChangesAsync().ConfigureAwait(false); return (accessToken, refreshToken); }
جهت بالا رفتن امنیت سیستم، این Guid را هش کرد و سپس این هش را در بانک اطلاعاتی ذخیره میکنیم. به این ترتیب دسترسی غیرمجاز به این هشها، امکان بازیابی توکنهای اصلی را غیرممکن میکند.
پیاده سازی Login
پس از پیاده سازی متد CreateJwtTokens، کار ورود به سیستم به سادگی ذیل خواهد بود:
[AllowAnonymous] [HttpPost("[action]")] public async Task<IActionResult> Login([FromBody] User loginUser) { if (loginUser == null) { return BadRequest("user is not set."); } var user = await _usersService.FindUserAsync(loginUser.Username, loginUser.Password).ConfigureAwait(false); if (user == null || !user.IsActive) { return Unauthorized(); } var (accessToken, refreshToken) = await _tokenStoreService.CreateJwtTokens(user).ConfigureAwait(false); return Ok(new { access_token = accessToken, refresh_token = refreshToken }); }
پیاده سازی Refresh Token
پیاده سازی توکن به روز رسانی همانند عملیات لاگین است:
[AllowAnonymous] [HttpPost("[action]")] public async Task<IActionResult> RefreshToken([FromBody]JToken jsonBody) { var refreshToken = jsonBody.Value<string>("refreshToken"); if (string.IsNullOrWhiteSpace(refreshToken)) { return BadRequest("refreshToken is not set."); } var token = await _tokenStoreService.FindTokenAsync(refreshToken); if (token == null) { return Unauthorized(); } var (accessToken, newRefreshToken) = await _tokenStoreService.CreateJwtTokens(token.User).ConfigureAwait(false); return Ok(new { access_token = accessToken, refresh_token = newRefreshToken }); }
پیاده سازی Logout
در سیستمهای مبتنی بر JWT، پیاده سازی Logout سمت سرور بیمفهوم است؛ از این جهت که تا زمان انقضای یک توکن میتوان از آن توکن جهت ورود به سیستم و دسترسی به منابع آن استفاده کرد. بنابراین تنها راه پیاده سازی Logout، ذخیره سازی توکنها در بانک اطلاعاتی و سپس حذف آنها در حین خروج از سیستم است. به این ترتیب اعتبارسنج سفارشی توکنها، از استفادهی مجدد از توکنی که هنوز هم معتبر است و منقضی نشدهاست، جلوگیری خواهد کرد:
[AllowAnonymous] [HttpGet("[action]"), HttpPost("[action]")] public async Task<bool> Logout() { var claimsIdentity = this.User.Identity as ClaimsIdentity; var userIdValue = claimsIdentity.FindFirst(ClaimTypes.UserData)?.Value; // The Jwt implementation does not support "revoke OAuth token" (logout) by design. // Delete the user's tokens from the database (revoke its bearer token) if (!string.IsNullOrWhiteSpace(userIdValue) && int.TryParse(userIdValue, out int userId)) { await _tokenStoreService.InvalidateUserTokensAsync(userId).ConfigureAwait(false); } await _tokenStoreService.DeleteExpiredTokensAsync().ConfigureAwait(false); await _uow.SaveChangesAsync().ConfigureAwait(false); return true; }
آزمایش نهایی برنامه
در فایل index.html، نمونهای از متدهای لاگین، خروج و فراخوانی اکشن متدهای محافظت شده را مشاهده میکنید. این روش برای برنامههای تک صفحهای وب یا SPA نیز میتواند مفید باشد و به همین نحو کار میکنند.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.