Contents
ObsoleteAttribute
Setting a default value for C# Auto-implemented properties via DefaultValueAttribute
DebuggerBrowsableAttribute
?? Operator
Curry and Partial methods
WeakReference
Lazy
BigInteger
__arglist __reftype __makeref __refvalue
Environment.NewLine
ExceptionDispatchInfo
Environment.FailFast
Debug.Assert, Debug.WriteIf and Debug.Indent
Parallel.For and Parallel.Foreach
IsInfinity
گذشته از اینها بحث مدل سازی هم هست. نگاشتهای کلاسها و خواص اونها به جداول بانک اطلاعاتی در ORMهای مختلف 100 درصد با هم متفاوت هست. حداقل EF و NH روشهای خاص خودشون رو دارند که انطباقی با هم ندارن. یعنی این Persistence Ignorance محدود نیست به روکش کشیدن روی insert/update/delete. اینجا صحبت از یک سیستم هست که اجزای هماهنگ زیادی داره که باید درنظر گرفته بشه؛ از نگاشتها تا اعتبارسنجیهای خاص تا قابلیتهای ویژه و صددرصد اختصاصی. به این میگن تا خرخره فرو رفتن!
اگر در یک صفحه، سه کامپوننت به این صورت وجود داشته باشند:
<ComponentA/> <ComponentB/> <ComponentC/>
پردازش اینها در Blazor SSR، ترتیبی نیست و موازی است (هر کدام، بر روی یک ترد مجزا پردازش میشوند). اما اگر کامپوننت B، داخل کامپوننت A باشد، اینها با هم و در طی یک ترد پردازش میشوند. هرچند این بحث پردازش موازی هم در صورت فراهم بودن منابع سیستمی و سختافزاری، تردهای آزاد در thread-pool و موارد دیگر، ممکن است رخدهد یا خیر. بنابراین گاهی از اوقات، در طول مدتی، خطایی را مشاهده نمیکنید؛ اما ... اگر به لاگهای سیستم در طول یک روز مراجعه کنید، وجود این خطاها کاملا مشخص است. بنابراین بهتر است بر اساس «شانس» کار نکنید. inject AppDbContext appDbContext@ به این معنا است که فقط یک نمونه از DbContext، در طول درخواست جاری (از این لحاظ، Blazor SSR با ASP.NET Core یکسان رفتار میکند) بین تمام اجزای در حال پردازش صفحهی در حال رندر، به اشتراک گذاشته شود. «ممکن است» در صورت عدم وجود پردازش موازی، هیچ خطایی را دریافت نکنید و یا ... به صورت «اتفاقی» و با مهیا بودن شرایط سیستمی و سختافزاری، خطای یاد شده را مشاهده کنید.
بهبود صفحهی بارگذاری اولیه در Blazor WASM
اگر یک برنامهی جدید blazor wasm را در دات نت 7، برای مثال با دستور dotnet new blazorwasm --hosted ایجاد کنیم، با اجرای آن، یک progress-bar حلقوی نمایش میزان درصد بارگذاری اولیهی برنامه ظاهر میشود که به نوعی پیاده سازی توکار نکات مطلب جاری است. این پیاده سازی از اجزای زیر تشکیل شدهاست:
الف) تغییرات فایل index.html برنامه
برای این منظور، فایل Client\wwwroot\index.html به صورت زیر تغییر کردهاست:
<body> <div id="app"> <svg class="loading-progress"> <circle r="40%" cx="50%" cy="50%" /> <circle r="40%" cx="50%" cy="50%" /> </svg> <div class="loading-progress-text"></div> </div>
ب) تغییرات فایل app.css برنامه
کلاسهای progress-bar را به این صورت در فایل Client\wwwroot\css\app.css اضافه کردهاند:
.loading-progress { position: relative; display: block; width: 8rem; height: 8rem; margin: 20vh auto 1rem auto; } .loading-progress circle { fill: none; stroke: #e0e0e0; stroke-width: 0.6rem; transform-origin: 50% 50%; transform: rotate(-90deg); } .loading-progress circle:last-child { stroke: #1b6ec2; stroke-dasharray: calc(3.141 * var(--blazor-load-percentage, 0%) * 0.8), 500%; transition: stroke-dasharray 0.05s ease-in-out; } .loading-progress-text { position: absolute; text-align: center; font-weight: bold; inset: calc(20vh + 3.25rem) 0 auto 0.2rem; } .loading-progress-text:after { content: var(--blazor-load-percentage-text, "Loading"); }
روش سفارشی سازی این progress-bar بر اساس دو CSS variable فوق صورت میگیرد:
--blazor-load-percentage: درصد بارگذاری جاری را مقدار دهی میکند.
--blazor-load-percentage-text: متن Loading نمایش داده شده را مشخص میکند.
برای مثال اگر علاقمند باشیم بجای SVG پیشفرض از progress-bar توکار خود فریمورک بوتاسترپ استفاده کنیم، روش کار به صورت زیر خواهد بود:
<body> <div id="app"> <div class="progress"> <div class="progress-bar progress-bar-striped progress-bar-animated" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100" style="width: var(--blazor-load-percentage, 0%)"> <div class="loading-text"></div> </div> </div>
.loading-text:after { content: var(--blazor-load-percentage-text, "Loading"); }
<CascadingValue Value="this" IsFixed="true"> main </CascadingValue>
Failed to load project file BlazorServer.App.csproj. C:\Program Files\dotnet\sdk\5.0.103\Sdks\Microsoft.NET.Sdk.Razor\build\netstandard2.0\Microsoft.NET.Sdk.Razor.Component.targets(107,5): Error: The specified task executable location "C:\Program Files\dotnet\dotnet.exe /M" is invalid.
در برنامهی backend این سری (که از انتهای مطلب قابل دریافت است)، به Controllers\MoviesController.cs مراجعه کرده و متدهای Get/Delete/Create آنرا با فیلتر [Authorize] مزین میکنیم تا دسترسی به آنها، تنها به کاربران لاگین شدهی در سیستم، محدود شود. در این حالت اگر به برنامهی React مراجعه کرده و برای مثال سعی در ویرایش رکوردی کنیم، اتفاقی رخ نخواهد داد:
علت را نیز در برگهی network کنسول توسعه دهندگان مرورگر، میتوان مشاهده کرد. این درخواست از سمت سرور با Status Code: 401، برگشت خوردهاست. برای رفع این مشکل باید JSON web token ای را که در حین لاگین، از سمت سرور دریافت کرده بودیم، به همراه درخواست خود، مجددا به سمت سرور ارسال کنیم. این ارسال نیز باید به صورت یک هدر مخصوص با کلید Authorization و مقدار "Bearer jwt" باشد.
به همین جهت ابتدا به src\services\authService.js مراجعه کرده و متدی را برای بازگشت JWT ذخیره شدهی در local storage به آن اضافه میکنیم:
export function getLocalJwt(){ return localStorage.getItem(tokenKey); }
import * as auth from "./authService"; axios.defaults.headers.common["Authorization"] = "Bearer " + auth.getLocalJwt();
مشکل! اگر برنامه را در این حالت اجرا کنید، یک چنین خطایی را مشاهده خواهید کرد:
Uncaught ReferenceError: Cannot access 'tokenKey' before initialization
برای رفع این خطا باید ابتدا مشخص کنیم که کدامیک از این ماژولها، اصلی است و کدامیک باید وابستهی به دیگری باشد. در این حالت httpService، ماژول اصلی است و بدون آن و با نبود امکان اتصال به backend، دیگر authService قابل استفاده نخواهد بود.
به همین جهت به httpService مراجعه کرده و import مربوط به authService را از آن حذف میکنیم. سپس در همینجا متدی را برای تنظیم هدر Authorizationاضافه کرده و آنرا به لیست default exports این ماژول نیز اضافه میکنیم:
function setJwt(jwt) { axios.defaults.headers.common["Authorization"] = "Bearer " + jwt; } //... export default { // ... setJwt };
http.setJwt(getLocalJwt());
تا اینجا اگر تغییرات را ذخیره کرده و سعی در ویرایش یکی از رکوردهای فیلمهای نمایش داده شده کنیم، اینکار با موفقیت انجام میشود؛ چون اینبار درخواست ارسالی، دارای هدر ویژهی authorization است:
روش بررسی انقضای توکنها در سمت کلاینت
اگر JWT قدیمی و منقضی شدهی از روز گذشته را آزمایش کنید، باز هم از سمت سرور، Status Code: 401 دریافت خواهد شد. اما اینبار در لاگهای برنامهی سمت سرور، OnChallenge error مشخص است. در این حالت باید یکبار logout کرد تا JWT قدیمی حذف شود. سپس نیاز به لاگین مجدد است تا یک JWT جدید دریافت گردد. میتوان اینکار را پیش از ارسال اطلاعات به سمت سرور، در سمت کلاینت نیز بررسی کرد:
function checkExpirationDate(user) { if (!user || !user.exp) { throw new Error("This access token doesn't have an expiration date!"); } user.expirationDateUtc = new Date(0); // The 0 sets the date to the epoch user.expirationDateUtc.setUTCSeconds(user.exp); const isAccessTokenTokenExpired = user.expirationDateUtc.valueOf() < new Date().valueOf(); if (isAccessTokenTokenExpired) { throw new Error("This access token is expired!"); } }
محدود کردن حذف رکوردهای فیلمها به نقش Admin در Backend
تا اینجا تمام کاربران وارد شدهی به سیستم، میتوانند علاوه بر ویرایش فیلمها، آنها را نیز حذف کنند. به همین جهت میخواهیم دسترسی حذف را از کاربرانی که ادمین نیستند، بگیریم. برای این منظور، در سمت سرور کافی است در کنترلر MoviesController، ویژگی [Authorize(Policy = CustomRoles.Admin)] را به اکشن متد Delete، اضافه کنیم. به این ترتیب اگر کاربری در سیستم ادمین نبود و درخواست حذف رکوردی را صادر کرد، خطای 403 را از سمت سرور دریافت میکند:
در برنامهی مثال backend این سری، در فایل Services\UsersDataSource.cs، یک کاربر ادمین پیشفرض ثبت شدهاست. مابقی کاربرانی که به صورت معمولی در سایت ثبت نام میکنند، ادمین نیستند.
در این حالت اگر کاربری ادمین بود، چون در توکن او که در فایل Services\TokenFactoryService.cs صادر میشود، یک User Claim ویژهی از نوع Role و با مقدار Admin وجود دارد:
if (user.IsAdmin) { claims.Add(new Claim(ClaimTypes.Role, CustomRoles.Admin, ClaimValueTypes.String, _configuration.Value.Issuer)); }
{ // ... "http://schemas.microsoft.com/ws/2008/06/identity/claims/role": "Admin", // ... }
نکته 1: اگر در اینجا چندین بار یک User Claim را با مقادیر متفاوتی، به لیست claims اضافه کنیم، مقادیر آن در خروجی نهایی، به شکل یک آرایه ظاهر میگردند.
نکته 2: پیاده سازی سمت سرور backend این سری، یک باگ امنیتی مهم را دارد! در حین ثبت نام، کاربران میتوانند مقدار خاصیت isAdmin شیء User را:
public class User : BaseModel { [Required, MinLength(2), MaxLength(50)] public string Name { set; get; } [Required, MinLength(5), MaxLength(255)] public string Email { set; get; } [Required, MinLength(5), MaxLength(1024)] public string Password { set; get; } public bool IsAdmin { set; get; } }
راه حل اصولی مقابلهی با آن، داشتن یک DTO و یا ViewModel خاص قسمت ثبت نام و جدا کردن مدل متناظر با موجودیت User، از شیءای است که اطلاعات نهایی را از کاربر، دریافت میکند. شیءای که اطلاعات را از کاربر دریافت میکند، نباید دارای خاصیت isAdmin قابل تنظیم در حین ثبت نام معمولی کاربران سایت باشد. یک روش دیگر حل این مشکل، استفاده از ویژگی Bind و ذکر صریح نام خواصی است که قرار است bind شوند و نه هیچ خاصیت دیگری از شیء User:
[HttpPost] public ActionResult<User> Create( [FromBody] [Bind(nameof(Models.User.Name), nameof(Models.User.Email), nameof(Models.User.Password))] User data) {
نکته 3: اگر میخواهید در برنامهی React، با مواجه شدن با خطای 403 از سمت سرور، کاربر را به یک صفحهی عمومی «دسترسی ندارید» هدایت کنید، میتوانید از interceptor سراسری که در قسمت 24 تعریف کردیم، استفاده کنید. در اینجا status code = 403 را جهت history.push به یک آدرس access-denied سفارشی و جدید، پردازش کنید.
نمایش یا مخفی کردن المانها بر اساس سطوح دسترسی کاربر وارد شدهی به سیستم
میخواهیم در صفحهی نمایش لیست فیلمها، دکمهی new movie را که بالای صفحه قرار دارد، به کاربرانی که لاگین نکردهاند، نمایش ندهیم. همچنین نمیخواهیم اینگونه کاربران، بتوانند فیلمی را ویرایش و یا حذف کنند؛ یعنی لینک به صفحهی جزئیات ویرایشی فیلمها و ستونی که دکمههای حذف هر ردیف را نمایش میدهد، به کاربران وارد نشدهی به سیستم نمایش داده نشوند.
در قسمت قبل، در فایل app.js، شیء currentUser را به state اضافه کردیم و با استفاده از ارسال آن به کامپوننت NavBar:
<NavBar user={this.state.currentUser} />
<Route path="/movies" render={props => <Movies {...props} user={this.state.currentUser} />} />
پس از این تغییر به فایل src\components\movies.jsx مراجعه کرده و شیء user را در متد رندر، دریافت میکنیم:
class Movies extends Component { // ... render() { const { user } = this.props; // ...
{user && ( <Link to="/movies/new" className="btn btn-primary" style={{ marginBottom: 20 }} > New Movie </Link> )}
در این تصویر همانطور که مشخص است، کاربر هنوز به سیستم وارد نشدهاست؛ بنابراین به علت null بودن شیء user، دکمهی New Movie را مشاهده نمیکند.
روش دریافت نقشهای کاربر وارد شدهی به سیستم در سمت کلاینت
همانطور که پیشتر در مطلب جاری عنوان شد، نقشهای دریافتی از سرور، یک چنین شکلی را در jwtDecode نهایی (یا user در اینجا) دارند:
{ // ... "http://schemas.microsoft.com/ws/2008/06/identity/claims/role": "Admin", // ... }
function addRoles(user) { const roles = user["http://schemas.microsoft.com/ws/2008/06/identity/claims/role"]; if (roles) { if (Array.isArray(roles)) { user.roles = roles.map(role => role.toLowerCase()); } else { user.roles = [roles.toLowerCase()]; } } }
export function isAuthUserInRoles(user, requiredRoles) { if (!user || !user.roles) { return false; } if (user.roles.indexOf(adminRoleName.toLowerCase()) >= 0) { return true; // The `Admin` role has full access to every pages. } return requiredRoles.some(requiredRole => { if (user.roles) { return user.roles.indexOf(requiredRole.toLowerCase()) >= 0; } else { return false; } }); } export function isAuthUserInRole(user, requiredRole) { return isAuthUserInRoles(user, [requiredRole]); }
در این کدها، adminRoleName به صورت زیر تامین شدهاست:
import { adminRoleName, apiUrl } from "../config.json";
{ "apiUrl": "https://localhost:5001/api", "adminRoleName": "Admin" }
اکنون که امکان بررسی نقشهای کاربر لاگین شدهی به سیستم را داریم، میخواهیم ستون Delete ردیفهای لیست فیلمها را فقط به کاربری که دارای نقش Admin است، نمایش دهیم. برای اینکار نیاز به دریافت شیء user، در src\components\moviesTable.jsx وجود دارد. یک روش دریافت کاربر جاری وارد شدهی به سیستم، همانی است که تا به اینجا بررسی کردیم: شیء currentUser را به صورت props، از بالاترین کامپوننت، به پایینتر کامپوننت موجود در component tree ارسال میکنیم. روش دیگر اینکار، دریافت مستقیم کاربر جاری از خود src\services\authService.js است و ... اینکار سادهتر است! به علاوه اینکه همیشه بررسی تاریخ انقضای توکن را نیز به صورت خودکار انجام میدهد و در صورت انقضای توکن، کاربر را در قسمت catch متد getCurrentUser، از سیستم خارج خواهد کرد.
بنابراین در src\components\moviesTable.jsx، ابتدا authService را import میکنیم:
import * as auth from "../services/authService";
class MoviesTable extends Component { columns = [ ... ]; // ... deleteColumn = { key: "delete", content: movie => ( <button onClick={() => this.props.onDelete(movie)} className="btn btn-danger btn-sm" > Delete </button> ) };
constructor() { super(); const user = auth.getCurrentUser(); if (user && auth.isAuthUserInRole(user, "Admin")) { this.columns.push(this.deleteColumn); } }
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-28-backend.zip و sample-28-frontend.zip
C# 6 - Expression-Bodied Members
روش محافظت از مسیریابیهای تعریف شدهی در برنامه
شبیه به روشی را که در قسمت قبل، برای انتقال شیء user، به مسیریابی کامپوننت Movies استفاده کردیم:
<Route path="/movies" render={props => <Movies {...props} user={this.state.currentUser} />} />
<Route path="/movies/:id" component={MovieForm} />
<Route path="/movies/:id" render={props => { if (!this.state.currentUser) { return <Redirect to="/login" />; } return <MovieForm {...props} />; }} />
اکنون اگر این تغییرات را ذخیره کرده و در حالت Logout، مسیر http://localhost:3000/movies/new را مستقیما درخواست دهیم، به صفحهی لاگین هدایت خواهیم شد.
ایجاد کامپوننتی با قابلیت استفادهی مجدد، برای محافظت از مسیریابیها
هرچند روشی که تا اینجا برای محافظت از مسیریابیها معرفی شد، بدون مشکل کار میکند، اما اگر قرار باشد برای تمام مسیریابیهای اینگونه، استفاده شود، به تکرار بیش از اندازهی کدهای یکسانی خواهیم رسید. به همین جهت میتوان این منطق را تبدیل به یک کامپوننت با قابلیت استفادهی مجدد کرد؛ تا دیگر نیازی به تکرار این if/elseها نباشد. برای این منظور، فایل جدید src\components\common\protectedRoute.jsx را ایجاد میکنیم. کامپوننت جدید protectedRoute را هم در پوشهی common قرار دادهایم؛ چون وابستگی به دومین این برنامه نداشته و میتواند در سایر برنامه نیز مورد استفاده قرار گیرد. سپس با استفاده از میانبرهای imrc و sfc، یک کامپوننت تابعی بدون حالت را به نام ProtectedRoute ایجاد کرده و در آن، همان کامپوننت اصلی Route را بازگشت میدهیم. بنابراین هر زمانیکه از ProtectedRoute استفاده شود، خروجی آن، همان کامپوننت استاندارد Route خواهد بود که اینبار قرار است از وضعیت کاربر جاری وارد شدهی به سیستم، مطلع باشد. به همین جهت در اولین قدم، همان قطعه کد Route فوق را که به همراه if/else نوشتیم، از فایل app.js کپی کرده و به اینجا، داخل متد رندر کامپوننت، منتقل میکنیم. سپس شروع میکنیم به متغیر کردن عباراتی که در آن به صورت صریح و ثابت، مقدار دهی شدهاند تا به یک کامپوننت با قابلیت استفادهی مجدد برسیم:
import React from "react"; import { Route, Redirect } from "react-router-dom"; import * as auth from "../../services/authService"; const ProtectedRoute = ({ path, component: Component, render, ...rest }) => { return ( <Route {...rest} render={props => { if (!auth.getCurrentUser()) return ( <Redirect to={{ pathname: "/login", state: { from: props.location } }} /> ); return Component ? <Component {...props} /> : render(props); }} /> ); }; export default ProtectedRoute;
- در این کامپوننت نیاز است اطلاعات کاربر جاری وارد شدهی به سیستم در دسترس باشد. یا میتوان آنرا به عنوان یکی از خواص props دریافت کرد و یا همانند این مثال، امکان دریافت مستقیم آن از authService نیز وجود دارد.
- در ادامه اگر CurrentUser مقدار دهی نشده باشد، کامپوننت Redirect را که کاربر را به صفحهی لاگین هدایت میکند، بازگشت میدهیم. در غیراینصورت نیاز است یک کامپوننت را بجای برای مثال MovieForm، بازگشت دهیم. علت استفادهی از component: Component این است که React انتظار دارد، کامپوننتها با نام بزرگ شروع شوند. به همین جهت خاصیت component را از props دریافت کرده و آنرا به Component تغییر نام میدهیم.
- زمانیکه از کامپوننت Route استاندارد استفاده میشود، یا از ویژگی component آن استفاده میشود و یا از ویژگی render آن که یک تابع است، تا بتوان داخل آن، کدهای پویایی را درج کرد. به همین جهت ممکن است که مقدار متغیر کامپوننت دریافت شده، نال باشد. بنابراین در اینجا بررسی میشود که آیا Component، مقدار دهی شدهاست یا خیر؟ اگر بله، همان کامپوننت را به همراه props آن بازگشت میدهیم. در غیراینصورت، متد render مقدار دهی شده را به همراه props ارسالی به آن، بازگشت خواهیم داد.
- علت وجود پارامتر rest نیز این است که این کامپوننت علاوه بر ویژگیهایی که تاکنون پیش بینی کردهایم، ممکن است در آینده ویژگیهای دیگری را نیز نیاز داشته باشد. به همین جهت مابقی آنها را توسط {rest...}، به صورت خودکار در اینجا درج میکنیم. برای نمونه در اینجا ذکر path={path} را مشاهده نمیکنید؛ چون توسط همان {rest...} به صورت خودکار تامین میشود.
اکنون به app.js بازگشته و کدهای قبلی را با این کامپوننت جدید ProtectedRoute، جایگزین میکنیم:
import ProtectedRoute from "./components/common/protectedRoute"; // ... <ProtectedRoute path="/movies/:id" component={MovieForm} />
مدیریت بازگشت کاربران، پس از لاگین به سیستم
پس از خروج از برنامه، اگر سعی در ویرایش یکی از فیلمهای موجود کنیم، به صفحهی لاگین هدایت خواهیم شد. پس از لاگین موفق، مجددا به ریشهی سایت بازگشت داده میشویم و نه به صفحهای که پیش از لاگین، مدنظر کاربر بودهاست. برای رفع این مشکل نیاز است بتوان به آدرس قبلی درخواستی، دسترسی یافت و این مورد توسط سیستم مسیریابی، به کامپوننتها به صورت خودکار تزریق میشود. برای مثال اگر در کامپوننت ProtectedRoute، مقدار شیء props دریافتی را لاگ کنیم:
return ( <Route {...rest} render={props => { console.log(props);
همانطور که مشخص است، شیء location دریافتی از props، به همراه اطلاعات آدرسی است که پیش از هدایت خودکار به صفحهی لاگین، درخواست کرده بودیم. به همین جهت یک چنین تنظیمی، در تعاریف کامپوننت ProtectedRoute درنظر گرفته شدهاند:
<Redirect to={{ pathname: "/login", state: { from: props.location } }} />
اکنون که این شیء، به کامپوننت لاگین، پس از Redirect خودکار ارسال میشود، نیاز است به src\components\loginForm.jsx مراجعه کرده و تغییرات زیر را اعمال کنیم:
doSubmit = async () => { try { const { data } = this.state; await auth.login(data.username, data.password); const { state } = this.props.location; window.location = state ? state.from.pathname : "/"; } catch (ex) { //...
تا اینجا اگر برنامه را ذخیره کرده، از سیستم خارج شویم و سعی در ویرایش اولین رکورد موجود در لیست فیلمها کنیم، ابتدا به صفحهی لاگین هدایت میشویم. پس از لاگین موفق، اینبار بجای مشاهدهی ریشهی سایت که در اینجا به لیست فیلمها تنظیم شده، دقیقا صفحهی ویرایش جزئیات اولین فیلم را مشاهده خواهیم کرد.
عدم نمایش مجدد صفحهی لاگین، به کاربران وارد شدهی به سیستم
آخرین تغییری را که در اینجا اعمال خواهیم کرد، رفع مشکل امکان مشاهدهی مجدد صفحهی لاگین، با وارد کردن مستقیم آدرس آن در مرورگر، پس از ورود موفقیت آمیز به سیستم است. برای این منظور، ابتدای متد رندر کامپوننت فرم لاگین را به صورت زیر تغییر میدهیم تا اگر کاربر، پیشتر به سیستم وارد شده بود، به صورت خودکار به ریشهی سایت هدایت شده و مجددا فرم لاگین برای او رندر نشود:
import { Redirect } from "react-router-dom"; //... render() { if (auth.getCurrentUser()) return <Redirect to="/" />;
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-29-backend.zip و sample-29-frontend.zip