A tiny, cross-platform, module based, MIT-licensed web server for .NET Framework and .NET Core
In the eighteen years that I’ve been doing Web development, a lot has changed. We started out creating HTML pages to present static information to our users. We then used classic ASP to get database data and incorporate that into our pages. To use both of these technologies, we had to know a lot about HTML, CSS, and JavaScript. Along came .NET and we started rendering everything on the server-side. We forgot a lot about HTML, CSS, and JavaScript as Web Forms wrapped up a lot of that for us. Web Forms’ architecture closely mimicked the way developers created desktop applications. This was great for helping developers move to the Web, but unfortunately hid a lot of the power of the Web, and also tended to be a little slow.
Micro Frontend چیست؟
micro frontend یک الگوی معماری (architecture pattern) می‌باشد؛ جایی که یک front-end app، به چند app کوچکتر تقسیم میشود و هر کدام از آنها به صورت مستقل توسعه داده و تست می‌شوند. مفهومی شبیه به مایکروسرویس‌ها است؛ اما برای سورس کدهای یکپارچه‌ی سمت کلاینت.
چرا؟
خیلی سخت است که بخواهیم روی سورس کدهای یکپارچه سمت کلاینت تست نویسی، به‌روز رسانی و هم چنین نگهداری کنیم. این در حالی است که توانایی تیم را به منظور مستقل کار کردن بر روی بخش‌های مختلفی از app، محدود می‌کند. شکستن یک app یکپارچه به micro frontendهای کوچکتر و قابل مدیریت، این امکان را فراهم میسازد که چندین تیم، به صورت مستقل کار کنند و از فریم ورک‌های ترجیحی خود استفاده کنند.
چگونه؟
اساسا 3 راه برای ادغام کردن ماژولهای micro frontend با container app وجود دارد.
1-Server integration
هر micro frontend در یک وب سرور احتمالا جداگانه هاست شده‌است که مسئول رندر کردن و خدمت دادن markupهای مربوطه می‌باشد. به محض دریافت درخواستی از سمت مرورگر، container app در خواست را برای markup، با برقراری تماس به سرور، برای micro frontend مربوطه انجام میدهد.
این یک روش ایده آل نمی‌باشد؛ به‌طوریکه چندین تماس به سرور برای رندر کردن محتوا در صفحه برقرار میشود و همچنین مستلزم پیاده سازی استراتژی cache، به منظور کاهش تاخیر است.
2-Compile time integration
container app دسترسی به کدهای micro frontendها را در طول توسعه و زمان کامپایل دارد. یکی از راه‌های انجام این روش این است که micro frontendها را به عنوان بسته‌های npm منتشر کنیم و سپس از آنها به عنوان یک وابستگی در container app استفاده کنیم.
در حالیکه راه اندازی و پیاده سازی، در این حالت ساده است، اما یک وابستگی محکم بین container app و micro frontend وجود دارد. هر زمانکه یک micro frontend بروزرسانی میشود، نیاز است که container app ، به منظور یکپارچه کردن بروز رسانی، دوباره استقرار یابد.
3-Run time integration
container app دسترسی به کدهای micro frontendها را زمانیکه در مرورگر اجرا می‌شوند، دارد. یکی از راه‌های انجام این روش، استفاده از پلاگین Module Federation مربوط به Webpack است که مراقب ساختن، در دسترس قرار دادن و استفاده از وابستگی‌ها در زمان اجرا می‌باشد (در ادامه، این حالت را با جزئیات بیشتری مورد بررسی قرار خواهیم داد).
در این حالت وابستگی بین container app و micro frontendها وجود ندارد و یکپارچگی در زمان اجرا اتفاق می‌افتد. هر micro frontend می‌تواند به صورت مستقل توسعه داده شود و استقرار یابد، بدون اینکه container app را دوباره استقرار دهیم.
در این حالت راه اندازی در مقایسه با compile-time integration پیچیده‌تر است.
Webpack Module Federation Plugin
پلاگین module federation در Webpack 5.0 معرفی شد که امکان توسعه appهای micro frontend را با بارگذاری پویای کدهای appهای micro frontend را در container app ، فراهم میسازد.
همچنین این امکان را فراهم می‌کند که dependency ها را بین remote appها و host app، به منظور جلوگیری از کدهای تکراری و کاهش دادن سایز build، به اشتراک بگذاریم.
در این مقاله ما یک مثال را بررسی خواهیم کرد که شامل دو micro frontend ساده می‌باشد و سپس آنها را در یک host app ادغام می‌کنیم.
ساختار نهایی به‌صورت زیر خواهد بود:
ایجاد کردن اولین Remote app
یک پوشه را به نام remote1 ایجاد کنید و سپس یک فایل را به نام package.json، در پوشه‌ی ایجاد شده، با دستور زیر ایجاد کنید.
npm init --yes
پوشه‌ی ایجاد شده را در code editor خود باز کنید (من از vs code استفاده می‌کنم) و سپس وابستگی‌های زیر را به فایل package.json اضافه کنید.
npm install html-webpack-plugin webpack webpack-cli webpack-dev-server --save
1) webpack/ webpack-CLI: برای استفاده از webpack و دستورات webpack CLI
2) html-webpack-plugin/webpack-devserver: سرور توسعه محلی با live reloading
و همچنین اسکریپت webpack serve را در بخش scripts، به منظور serve کردن application در مرورگر اضافه کنید.
اکنون فایل package.json شما همانند زیر می‌باشد:
{
"name": "remote1",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^5.3.2",
"webpack": "^5.57.0",
"webpack-cli": "^4.8.0",
"webpack-dev-server": "^4.3.1"
}
} <!DOCTYPE html>
<html>
<head>
<title>
Remote1(Localhost:7001)
</title>
</head>
<body>
<div id="dev-remote1"></div>
</body>
</html> در ادامه یک پوشه‌ی جدید را به نام src ایجاد کنید و دو فایل را با نام‌های index.js و startup.js در آن قرار دهید. در ادامه به این دو فایل برمیگردیم و کدهای لازم را در آن قرار میدهیم.
یک فایل جدید را به نام webpack.config.js در ریشه‌ی پروژه ایجاد می‌کنیم که در آن تنظیمات webpack را قرار میدهیم. در این فایل، دو پلاگین را به نام‌های Webpack و Module Federation، اضافه می‌کنیم.
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'development',
devServer: {
port: 7001,
},
plugins: [
new ModuleFederationPlugin({
name: 'remote1',
filename: 'remoteEntry.js',
exposes: {
'./RemoteApp1': './src/startup',
},
}),
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
}; فایل remoteEntry.js شامل یک لیست از فایلهای در معرض قرار داده شده‌ی توسط remote app به همراه مسیر‌های آنها می‌باشد. از این فایل در زمان ادغام کردن remote app در host app استفاده میشود.
index.js نقطه‌ی ورودی remote app ما می‌باشد. به منظور جلوگیری از eager loading، کدهای startup را در یک js فایل جداگانه به نام startup.js قرار میدهیم. از این رو فایل index.js شامل فقط یک import می‌باشد.
import('./startup'); در درون فایل startup.js ، یک تابع به نام mount را export می‌کنیم. این تابع یک element را دریافت می‌کند؛ جائیکه قرار است خروجی app در آن قرار گیرد. در حالت development، خروجی در یک div نگهدارنده با شناسه dev-remote1 در فایل محلی index.html قرار میگیرد.
const mount = (el) => {
el.innerHTML = '<div>Remote 1 Content</div>';
};
if (process.env.NODE_ENV === 'development') {
const el = document.querySelector('#dev-remote1');
if (el) {
mount(el);
}
}
export { mount }; 
ایجاد کردن دومین Remote app
در اینجا نیز مراحل، دقیقا شبیه به ایجاد remote app قبلی می‌باشد. یک پوشه را به نام remote2 در کنار پوشه‌ی remote1 ایجاد کنید و یک فایل را به نام package.json، با وابستگی‌های معرفی شده ایجاد کنید و سپس دستور npm install را بزنید تا وابستگی‌ها نصب شوند.
{
"name": "remote2",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^5.3.2",
"webpack": "^5.57.0",
"webpack-cli": "^4.8.0",
"webpack-dev-server": "^4.3.1"
}
} سپس یک فایل را با نام index.html و با محتوای زیر، در پوشه‌ی public ایجاد کنید:
<!DOCTYPE html>
<html>
<head>
<title>
Remote2(Localhost:7002)
</title>
</head>
<body>
<div id="dev-remote2"></div>
</body>
</html> در ادامه یک فایل را با نام webpack.config.js در ریشه‌ی پروژه‌ی remote2 ایجاد کنید و محتوای زیر را در آن قرار دهید. مطمئن باشید که پورت اجرایی برنامه 7002 می‌باشد.
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'development',
devServer: {
port: 7002,
},
plugins: [
new ModuleFederationPlugin({
name: 'remote2',
filename: 'remoteEntry.js',
exposes: {
'./RemoteApp2': './src/startup',
},
}),
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
}; فایل فایل index.js برای remote2
import('./startup'); فایل startup.js برای remote2
const mount = (el) => {
el.innerHTML = '<div>Remote 2 Content</div>';
};
if (process.env.NODE_ENV === 'development') {
const el = document.querySelector('#dev-remote2');
if (el) {
mount(el);
}
}
export { mount }; اکنون می‌توانید با اجرای دستور npm start برنامه را بر روی پورت 7002 اجرا کنید . ( http://localhost:7002 )
ایجاد کردن Host app و یکپارچه کردن آن با Remote app ها
یک پوشه‌ی جدید را به نام container در کنار دو پوشه‌ی قبلی (remote1, remote2) ایجاد کنید. در پوشه‌ی ایجاد شده، یک فایل را به نام package.json ایجاد کنید و محتوای زیر را در آن قرار دهید و سپس دستور npm install را بزنید تا لیست وابستگی‌ها دریافت شود.
{
"name": "container",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^5.3.2",
"webpack": "^5.57.0",
"webpack-cli": "^4.8.0",
"webpack-dev-server": "^4.3.1"
}
} اکنون یک پوشه را به نام public، در ریشه‌ی پروژه ایجاد کنید و یک فایل را به نام index.html، در آن قرار دهید. در این فایل دو div نگهدارنده به منظور هاست کردن محتوا، از هر remote app قرار دارد.
<!DOCTYPE html>
<html>
<head>
<title>Host App (Localhost:7000)</title>
</head>
<body>
<div id="remote1-app"></div>
<div id="remote2-app"></div>
</body>
</html> یک فایل را با نام webpack.config.js، با تنظیمات زیر در ریشه‌ی پروژه قرار دهید. در اینجا پورت اجرایی برنامه، 7000 تعیین شده‌است:
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'development',
devServer: {
port: 7000,
},
plugins: [
new ModuleFederationPlugin({
name: 'container',
remotes: {
remote1: 'remote1@http://localhost:7001/remoteEntry.js',
remote2: 'remote2@http://localhost:7002/remoteEntry.js',
},
}),
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
}; 
دقیقا مثل remote app ها، در فایل index.js مربوط به import ، host app زیر را انجام میدهیم:
import('./startup'); import { mount as remote1Mount } from 'remote1/RemoteApp1';
import { mount as remote2Mount } from 'remote2/RemoteApp2';
remote1Mount(document.querySelector('#remote1-app'));
remote2Mount(document.querySelector('#remote2-app')); در ادامه جهت مشاهده خروجی، app میزبان را با دستور npm start اجرا می‌کنیم. اکنون شما می‌توانید خروجی remote app ها را در host app ببینید. لازم به ذکر است که در هنگام اجرای دستور npm start برای host app ، هر دو remote app ایجاد شده باید در حالت اجرا باشند.
ملاحظات
Module federation در Webpack نسخه 5 به بالا، در دسترس قرار دارد. شما می‌توانید وابستگی‌های بین remote app و host app را به اشتراک بگذارید. این کار را با اضافه کردن آنها به تنظیمات پلاگین module federation برای remote app و host app انجام دهید.
new ModuleFederationPlugin({
name: 'remote1',
filename: 'remoteEntry.js',
exposes: {
'./RemoteApp1': './src/startup',
},
shared:['react', 'react-dom']
}), ارتباط بین host و remote app می‌تواند از طریق callbackها انجام شود.
با راه اندازی مجدد IIS مشکل رفع شد.
ممنون
ممنون
OpenID Connect یک لایه‌ی امنیتی بر روی OAuth 2.0 است. توسط آن عملیات Authentication به OAuth 2.0 که صرفا مختص به Authorization است، اضافه میشود.
سلام وقت بخیر...
ببخشید در مورد Claim Authorization چه مطالبی وجود داره ؟ رفرنس فارسی وجود داره ؟
<location path="content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<authentication mode="forms">
<forms loginurl="~/account/logon" slidingexpiration="true" timeout="2"/>
</authentication>
<authorization>
<!--<allow roles="?"/>-->
<deny users="?"/>
</authorization>
سلام آقای نصیری
ممنون از مطالب خوبتون
من تو این قسمت مشکل دارم تا اینجا درست کار میکنه که کسانی که authenticate نکردن برن به صفحه لاگین اما cssها رو با اینکه location هم گذاشتم نمیاره
بالای system.web هم می‌زنم
در Asp.net دو چرخه‌ی حیات مهم
وجود دارند که اساس چارچوب MVC را تشکیل می‌دهند
:
- چرخه‌ی حیات برنامه (Application)؛ از لحظه‌ای که برنامه برای اولین بار اجرا میشود و تا لحظه‌ی خاتمه‌ی آن را شامل میشود.
- چرخه‌ی حیات یک درخواست ( Request )؛ مسیری که یک درخواست طی می‌کند، اصطلاحا PipeLine نامیده میشود که همان چرخه‌ی حیات یک درخواست نیز هست و از لحظه‌ای که درخواست تحویل asp.net شده، تا زمانیکه درخواست ارسال میشود را شامل میشود.
تمرکز بنده بیشتر بر روی روند و مسیری است که یک درخواست طی می‌کند و قصد دارم با بهره گیری از کتاب Pro Asp.net Mvc 5 و دیگر منابع، چرخه‌ی حیات درخواست را در برنامه‌های Mvc بررسی کرده و در مقالات آتی ماژولها و هندلرها را بررسی کنم.
در asp.net ، برنامه global فایلهای شامل دو فایل Global.asax , Global.asax.cs است.
فایل Global.asax که هیچ گاه نیاز به ویرایش آن نداریم محتویاتی مانند زیر دارد:
<%@ Application Codebehind="Global.asax.cs" Inherits="YourAppName.MvcApplication" Language="C#" %>
در این مقاله منظور از فایل global فایل Global.asax.cs است که مشتق شده از کلاس System.Web.HttpApplication است:
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
...//
}
} Asp.net برای پاسخگویی به درخواستهای واصله، وهله‌هایی از کلاس MvcApplication را میسازد ولی این دو متد صرفا در نقاط شروع و پایان برنامه فراخوانی شده و عملا در وهله‌های یاد شده صدا زده نخواهند شد و به جای آنها رویدادهایی را که در ذیل آنها را معرفی می‌کنیم، فراخوانی شده و چرخه‌ی حیات درخواست را برای ما مشخص می‌سازند .
BeginRequest : به عنوان اولین رویداد، به محض وصول یک درخواست جدید رخ خواهد داد.AuthenticateRequest ,PostAuthenticateRequest : رویداد AuthenticateRequest برای شناسایی کاربر ارسال کننده درخواست، کاربرد دارد و پس از پردازش کلیه‌ی توابع، رویداد PostAuthenticateRequest صدا زده میشود.
AuthorizeRequest :به‌هنگام صدور مجوزهای یک درخواست رخ میدهد و مشابه رویداد بالا پس از پردازش کلیه‌ی توابع، رویداد PostAuthorizeRequest صدا زده خواهد شد.ResolveRequestCache : پس از صدور مجوزهای یک درخواست در رویداد authorization زمانیکه ماژولهای کش می‌خواهند اطلاعاتی را از کش سرور مطالبه کنند، رخ میدهد و به مانند دو رخداد قبلی، PostResolveRequestCache نیز پس از اتمام پردازش توابع رویداد رخ میدهد.
MapRequestHandler : زمانی که Asp.net می‌خواهد هندلری را برای پاسخگویی به درخواست واصله انتخاب کند رخ میدهد و PostMapRequestHandler نیز پس از این انتخاب، تریگر میشود.AcquireRequestState : جهت بدست آوردن داده‌هایی نظیر سشن و ... مرتبط با درخواست جاری کاربرد داشته و PostAcquireRequestState نیز پس از پردازش توابع رویداد رخ خواهد داد.
PreRequestHandlerExecute : بالافاصله قبل و همچنین بلافاصله بعد از این که یک هندلر بخواهد درخواستی را پردازش کند، رخ میدهد. PostRequestHandlerExecute نیز همانند دیگر رویدادهای گذشته، پس از اتمام پردازش توابع، این رویداد رخ خواهد داد.ReleaseRequestState : زمانی رخ میدهد که داده‌های مرتبط با درخواست جاری، در ادامه‌ی روند پردازش درخواست مورد نیاز نباشند و پس از پردازش توابع رویداد، PostReleaseRequestState رخ خواهد داد .
UpdateRequestCache : به جهت اینکه ماژولهای مسئول کش، توانایی به روز رسانی داده‌های خود، برای پاسخگویی به درخواستهای بعدی را داشته باشند، این رویداد رخ میدهد.
LogRequest : قبل از انجام عملیات لاگین برای درخواست جاری رخ میدهد و پس از پردازش توابع رویداد نیز PostLogRequest تریگر میشود.EndRequest : پس از پایان کار پردازش درخواست جاری و مهیا شدن پاسخ مرتبط جهت ارسال به مرورگر تریگر خواهد شد.
PreSendRequestHeaders : قبل از ارسال HTTP headers به مرورگر این رویداد رخ خواهد داد.
PreSendRequestContent : بعد از ارسال شدن هدرها و قبل از ارسال محتوای صفحه به مرورگر رخ میدهد.Error : هر زمان و در هر مرحله از پردازش درخواست، چنانچه خطایی صورت پذیرد این رویداد رخ خواهد داد.
فریم ورک Asp.net جهت مدیریت بهتر یک درخواست، در تمام مسیر پردازش، رویدادهای بالا را مهیا کرده است. در ادامه نحوه‌ی هندل کردن رویدادهای چرخه‌ی حیات درخواست را در فایل global توضیح می‌دهم. هر چند که استفاده از این فایل بدین منظور، صرفا برای مدیریت مسائل ابتدایی مناسب بوده و در یک پروژه‌ی بزرگ موجب به هم ریختگی فایل global با کدهای زیاد و خوانایی پایین بوده که قابلیت استفاده مجدد در دیگر پروژه‌ها را نیز ندارد.
Asp.net این مشکل را با معرفی ماژولها که در مقالات آتی توضیح خواهم داد، مرتفع کرده است.
در فایل global هر گاه متدی را با پیشوند Application_ و نام یکی از رویدادهای بالا بنویسید Asp.net آن را به عنوان هندلری برای رویداد مذکور می‌شناسد. به عنوان مثال متدی با نام Application_BeginRequest متد رویداد BeginRequest می‌باشد.
ابتدا یک پروژه‌ی MVC جدید را به نام SimpleApp ایجاد کرده و فایل global آن را مطابق ذیل تغییر میدهیم:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
namespace SimpleApp
{
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RouteConfig.RegisterRoutes(RouteTable.Routes);
}
protected void Application_BeginRequest()
{
RecordEvent("BeginRequest");
}
protected void Application_AuthenticateRequest()
{
RecordEvent("AuthenticateRequest");
}
protected void Application_PostAuthenticateRequest()
{
RecordEvent("PostAuthenticateRequest");
}
private void RecordEvent(string name)
{
List<string> eventList = Application["events"] as List<string>;
if (eventList == null)
{
Application["events"] = eventList = new List<string>();
}
eventList.Add(name);
}
}
} در اینجا متدی به نام RecordEvent را در کدهای ذکر شده مشاهده می‌کنید که نام یک رویداد را دریافت و جهت در دسترس قرار دادن در کل برنامه به خاصیت Application از کلاس HttpApplication نسبت داده و متد مذکور را از سه متد دیگر فراخوانی کرده‌ایم. این متدها در زمان رخ دادن رویدادهای BeginRequest, AuthenticateRequest, PostAuthenticateRequest صدا زده خواهند شد.
حال جهت نمایش اطلاعات رویداد نیاز است تغییراتی مشابه ذیل در کنترلر Home ایجاد نماییم.
using System.Web.Mvc;
namespace SimpleApp.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
return View(HttpContext.Application["events"]);
}
}
} ویوی مرتبط با اکشن متد index را مطابق کدهای ذیل بازنویسی می‌کنیم:
@model List<string>
@{
ViewBag.Title = "Events List";
}
<h5>Events</h5>
<table>
@foreach (string eventName in Model)
{
<tr>
<td>@eventName</td>
</tr>
}
</table> 
How to Turn Off the Phone-Home Option for Standard and Enterprise Edition
Enterprise customers may construct Group Policy to opt in or out of telemetry collection by setting a registry-based policy. The relevant registry key and settings are as follows:
Key = HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\130
RegEntry name = CustomerFeedback
Entry type DWORD: 0 is opt out, 1 is opt in
