.NET Tips | جستجوها: نتایج مشابه «نوشتن افزونه برای مرورگرها: قسمت دوم : کروم»، صفحه: ۶۰

مطالب

کار با یک مخزن کد GitHub‌ از طریق VSCode

VSCode به همراه امکانات یکپارچه‌ای، جهت کار با یک مخزن کد مبتنی بر Git است و در ادامه بررسی خواهیم کرد که اگر مخزنی در GitHub وجود داشت، چگونه می‌توان آن‌را تبدیل به یک پروژه‌ی VSCode کرد و سپس با آن کار نمود.

ایجاد یک مخزن کد آزمایشی در GitHub

برای تکمیل و بررسی مباحث این مطلب، یک مخزن کد جدید را در GitHub آغاز می‌کنیم:

در مرحله‌ی بعد، آدرس Clone این مخزن کد را کپی می‌کنیم:

ایجاد یک Clone از مخزن موجود GitHub توسط VSCode

پس از طی مراحلی که عنوان شد، یک پوشه‌ی جدید را ایجاد کرده و سپس با دستور خط فرمان . code، سبب اجرای VSCode و آغاز آن در این پوشه خواهیم شد.
سپس دکمه‌های ctrl+shift+p را فشرده و در منوی ظاهر شده، عبارت Git را جستجو کنید:

در اینجا گزینه‌ی Git: Clone را انتخاب نمائید. بلافاصله آدرس مخزن کد مدنظر را درخواست می‌کند:

در این قسمت همان آدرسی را که از طریق دکمه‌ی سبز رنگ Clone or Download گیت‌هاب دریافت کردیم، وارد می‌کنیم. پس از آن محل ذخیره سازی فایل‌ها را درخواست می‌کند:

در اینجا می‌توان هر پوشه‌ی دلخواهی را وارد کرد و یا همان پوشه‌ی جدیدی را که ایجاد کردیم، مسیردهی خواهیم کرد.

در آخر هم سؤال می‌کند که آیا می‌خواهید این مخزن را گشوده و مشغول به کار با آن شوید؟ با انتخاب گزینه‌ی open repository، این پوشه در VSCode باز خواهد شد.

اعمال تغییرات و ارسال آن‌ها به گیت‌هاب

پس از Clone یک مخزن کد، اکنون می‌توان با آن شروع به کار کرد. برای مثال اگر کلمه‌ای را به فایل readme آن اضافه کنیم، بلافاصله در برگه‌ی Git آن ظاهر خواهد شد:

در اینجا با کلیک بر روی هر کدام از تغییرات تشخیص داده شده، می‌توان نگارش فعلی را با آخرین نگارش مخزن کد مقایسه کرد. در سمت چپ، نگارش موجود در گیت‌هاب نمایش داده شده‌است و در سمت راست، نگارشی که ما مشغول به کار بر روی آن هستیم.

اگر از انجام این تغییر پشیمان شده‌اید، فقط کافی است بر روی دکمه‌ی discard changes آن کلیک کنید تا این فایل را به مرحله‌ی قبلی آن بازگشت دهد:

آیکن M در اینجا به معنای Modified است. اگر به Explorer آن برگشته و این فایل را حذف کنیم:

در تغییرات Git نمایش داده شده، اینبار آیکون D به معنای Deleted ظاهر می‌شود و اگر قصد بازیابی این فایل را داشته باشیم، باز هم می‌توان بر روی Discard changes آن کلیک کرد.

در همینجا در نوار ابزار بالای قسمت Git، دکمه‌ی check-mark برای ارسال تغییرات به مخزن کد است. دکمه‌ی refresh برای هماهنگی با مخزن کد و سه نقطه‌ی موجود، یک منوی تکمیلی را ظاهر می‌کند:

در همینجا اگر علاقمند بودید تا دستوراتی را که VSCode در پشت صحنه صادر می‌کند مشاهده کنید، بر روی گزینه‌ی Show Git Output کلیک کنید.

در آخر توضیحی را نوشته و بر روی دکمه‌ی commit کلیک می‌کنیم:

کاری که در اینجا صورت می‌گیرد، یک commit محلی است. اکنون اگر به status bar آن دقت کنید:

مشاهده می‌کنید که عدد 1 و صفر ظاهر شده‌اند. عدد 1 در اینجا به معنای آماده بودن ارسال یک commit به سرور و عدد صفر به معنای عدم تغییری در مخزن کد، توسط سایر توسعه دهنده‌ها است و نیازی به هماهنگی با آن نیست.

در ادامه یا می‌توان بر روی همین آیکن در status bar کلیک کرد و تغییرات را به سرور ارسال نمود و یا روش دیگر آن، همان کلیک بر روی دکمه‌ی سه نقطه‌ای قسمت Git که در بالا تصویر آن نمایش داده شد و سپس انتخاب گزینه‌ی push آن است.

پس از این هماهنگی با سرور، آیکن‌های 1 و صفر نمایش داده شده‌ی در status bar محو می‌شوند. به علاوه این تغییرات را در GitHub هم می‌توان مشاهده کرد:

هماهنگ سازی با تغییرات انجام شده‌ی توسط سایر کاربران

در همانجا در GitHub می‌توان یک فایل را دستی هم ویرایش کرد:

اینکار را از این جهت انجام می‌دهیم تا بتوان تغییرات انجام شده‌ی توسط سایر کاربران را شبیه سازی کرد. در ادامه اگر به status bar موجود در VSCode دقت کنید، اعداد صفر و یک نمایش داده می‌شوند. یعنی آیتمی برای ارسال به سرور وجود ندارد؛ اما یک تغییر در سمت سرور رخ داده‌است که نیاز است با آن هماهنگ شویم:

اینبار برای دریافت این تغییرات نیاز است گزینه‌ی pull را انتخاب کنیم:

‫۷ سال و ۵ ماه قبل، یکشنبه ۷ خرداد ۱۳۹۶، ساعت ۱۹:۵۰

زمانی فرهاد

مطالب

ایجاد یک راهنما برای کنترل تعداد کاراکترهای نوشته شده در یک خط

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

در ادامه باید بر روی Solution یک فایل جدید را به نام editorconfig. ایجاد کنید و تنظیمات مربوط به حداکثر کاراکترهای یک خط را وارد نمایید.

[*.{cs}]
guidelines = 80

در تنظیمات بالا مشخص شده‌است که در فایل‌هایی با پسوند cs. که همان فایلهای سی‌شارپ هستند، در کاراکتر 80، یک راهنما ایجاد شود تا زمانیکه توسعه دهنده به کاراکتر 80 رسید، متوجه شود باید در خط بعد ادامه کدهای خود را بنویسد. به صورت پیشفرض رنگ راهنمای ایجاد شده قرمز می‌باشد و برای تغییر رنگ آن باید در مسیر زیر

Tools > Options > Environment > Font and Colors > Guideline

مقدار رنگ قرمز را به رنگ مورد نظر خود تغییر دهید. سپس اگر یک فایل با پسوند cs را باز کنید، در کاراکتر 80، نقطه چین ایجاد شده به صورت عمودی را مشاهده می‌کنید که برای راهنمایی شما ایجاد شده است تا کدهای شما بیشتر از 80 کاراکتر در یک خط نشود.

منابع مرتبط:

‫۲ سال و ۳ ماه قبل، یکشنبه ۲۲ خرداد ۱۴۰۱، ساعت ۰۴:۱۵

وحید نصیری

مطالب

Angular CLI - قسمت پنجم - ساخت و توزیع برنامه

ساخت و توزیع برنامه‌های Angular یکی از مهم‌ترین و بحث برانگیزترین قسمت‌های نگارش‌های جدید آن است و به ازای هر پروژه و قالبی که برای آن توسط گروه‌های مختلف ارائه شده‌است، روش‌های متفاوتی را شاهد خواهید بود. در ادامه روش توصیه شده‌ی توسط تیم Angular را که مبتنی است بر webpack و به صورت خودکار توسط Angular CLI مدیریت می‌شود، بررسی خواهیم کرد.

ساخت (Build) برنامه‌های Angular

Angular CLI کار ساخت و کامپایل برنامه را به صورت خودکار انجام داده و خروجی را در مسیری مشخص درج می‌کند. در اینجا می‌توان گزینه‌هایی را بر اساس نوع کامپایل مدنظر مانند کامپایل برای حالت توسعه و یا کامپایل برای حالت توزیع نهایی، انتخاب کرد. همچنین مباحث bundling و یکی کردن تعداد بالای ماژول‌های برنامه در آن لحاظ می‌شوند تا برنامه در حالت توزیع نهایی، سبب 100ها رفت و برگشت به سرور برای دریافت ماژول‌های مختلف آن نشود. به علاوه مباحث uglification (به نوعی obfuscation کدهای جاوا اسکریپتی نهایی) و tree-shaking (حذف کدهایی که در برنامه استفاده نشده‌اند؛ یا کدهای مرده) نیز پیاده سازی می‌شوند. با انجام tree-shaking‌، نه تنها اندازه‌ی توزیع نهایی به کاربر کاهش پیدا می‌کند، بلکه مرورگر نیز حجم کمتری از کدهای جاوااسکریپتی را باید تفسیر کند.
برای شروع می‌توان از دستور ذیل برای مشاهده‌ی تمام گزینه‌های مهیای ساخت برنامه استفاده کرد:

> ng build --help

ذکر تنهای دستور ng build‌، بدون هیچ گزینه‌ای، برای حالت «توسعه‌ی» برنامه بسیار ایده‌آل است (و دقیقا به معنای صدور دستور ng build --dev است). در این حالت خروجی کامپایل شده‌ی برنامه در پوشه‌ی dist تولید می‌شود. اگر از قسمت دوم این سری به خاطر داشته باشید، نام این پوشه‌ی خروجی، جزئی از تنظیمات فایل angular-cli.json. است:

"apps": [
{
   "outDir": "dist",

زمانیکه دستور ng build‌ صادر شود، این فایل‌ها را در پوشه‌ی dist خواهید یافت:

فایل	توضیح
inline.bundle.js	WebPack runtime از آن برای بارگذاری ماژول‌های برنامه و چسباندن قسمت‌های مختلف به یکدیگر استفاده می‌شود.
main.bundle.js	شامل تمام کدهای ما است.
polyfills.bundle.js	Polyfills - جهت پشتیبانی از مرورگرهای مختلف.
styles.bundle.js	شامل بسته بندی تمام شیوه نامه‌های برنامه است
vendor.bundle.js	کدهای کتابخانه‌های ثالث مورد استفاده و همچنین خود Angular، در اینجا بسته بندی می‌شوند.

روشی برای بررسی محتوای bundleهای تولید شده

تولید bundleها در جهت کاهش رفت و برگشت‌های به سرور و بالا بردن کارآیی برنامه ضروری هستند؛ اما دقیقا این بسته بندی‌ها شامل چه اطلاعاتی می‌شوند؟ این اطلاعات را می‌توان از فایل‌های source map تولیدی استخراج کرد و برای این منظور می‌توان از برنامه‌ی source-map-explorer استفاده کرد.

روش نصب عمومی آن:

 > npm install -g source-map-explorer

روش اجرا:

 > source-map-explorer dist/main.bundle.js

پس از آن یک گزارش HTML ایی از محتوای bundle مدنظر تولید می‌شود.

یک مثال: ساخت برنامه‌ی مثال قسمت چهارم - تنظیمات مسیریابی در حالت dev

در ادامه، کار Build همان مثالی را که در قسمت قبل توضیح داده شد، بررسی می‌کنیم. برای این منظور از طریق خط فرمان به ریشه‌ی پوشه‌ی اصلی پروژه وارد شده و دستور ng build را صادر کنید. یک چنین خروجی را مشاهده خواهید کرد:

 D:\Prog\angular-routing>ng build
Hash: 123cae8bd8e571f44c31
Time: 33862ms
chunk {0} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 158 kB {4} [initial] [rendered]
chunk {1} main.bundle.js, main.bundle.js.map (main) 14.7 kB {3} [initial] [rendered]
chunk {2} styles.bundle.js, styles.bundle.js.map (styles) 9.77 kB {4} [initial] [rendered]
chunk {3} vendor.bundle.js, vendor.bundle.js.map (vendor) 2.34 MB [initial] [rendered]
chunk {4} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

و اگر فایل index.html تولیدی آن‌را بررسی کنید، تنها الحاق همین 4 فایل js تولیدی را مشاهده می‌نمائید:

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>AngularRouting</title>
  <base href="/">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/x-icon" href="favicon.ico">
</head>
<body>
  <app-root>Loading...</app-root>
<script type="text/javascript" src="inline.bundle.js">
</script><script type="text/javascript" src="polyfills.bundle.js">
</script><script type="text/javascript" src="styles.bundle.js">
</script><script type="text/javascript" src="vendor.bundle.js">
</script><script type="text/javascript" src="main.bundle.js"></script>
</body>
</html>

یک نکته: زمانیکه دستور ng serve -o صادر می‌شود، در پشت صحنه دقیقا همین دستور ng build صادر شده و اطلاعات را درون حافظه تشکیل می‌دهد. اما اگر کار ng build را دستی انجام دهیم، اینبار ng serve -o اطلاعات را از پوشه‌ی dist دریافت می‌کند. بنابراین در حین کار با ng serve -o نیازی به build دستی پروژه نیست.

سؤال: چرا حجم فایل endor.bundle.js اینقدر بالا است و شامل چه اجزایی می‌شود؟
نکته‌ای که در اینجا وجود دارد، حجم بالای فایل vendor.bundle.js آن است که 2.34 MB می‌باشد:

چون دستور ng build بدون پارامتری ذکر شده‌است، برنامه را برای حالت توسعه Build می‌کند و به همین جهت هیچگونه بهینه سازی در این مرحله صورت نخواهد گرفت. برای بررسی محتوای این فایل می‌توان دستور ذیل را در ریشه‌ی اصلی پروژه صادر کرد:

 > source-map-explorer dist/vendor.bundle.js

پس از اجرای این دستور، بلافاصله مرورگر پیش فرض سیستم اجرا شده و گزارشی را ارائه می‌دهد.

همانطور که مشاهده می‌کنید، در حالت بهینه سازی نشده و Build برای توسعه، کامپایلر Angular حدود 41 درصد حجم فایل vendor.bundle.js را تشکیل می‌دهد. به علاوه ماژول‌ها و قسمت‌هایی را ملاحظه می‌کنید که اساسا برنامه‌ی فعلی مثال ما از آن‌ها استفاده نمی‌کند؛ مانند http، فرم‌ها و غیره.

سفارشی سازی Build برای محیط‌های مختلف

اگر به پروژه‌ی تولید شده‌ی توسط Angular CLI دقت کنید، حاوی پوشه‌ای است به نام src\environments

هدف از فایل‌های environment برای نمونه تغییر آدرس توزیع برنامه در حالت توسعه و ارائه نهایی است.
همچنین در اینجا می‌توان نحوه‌ی بهینه سازی فایل‌های تولیدی را توسط Build Targets مشخص کرد و اینکار توسط ذکر پرچم prod-- (مخفف production) صورت می‌گیرد.
در ادامه، تفاوت‌های دستورهای ng build و ng build --prod را ملاحظه می‌کنید:
- با اجرای ng build، از فایل environment.ts استفاده می‌شود؛ برخلاف حالت اجرای ng build --prod که از فایل environment.prod.ts استفاده می‌کند.
- Cache-busting در حالت ارائه‌ی نهایی، به تمام اجزای پروژه اعمال می‌شود؛ اما در حالت توسعه فقط برای تصاویر قید شده‌ی در فایل‌های css.
- فایل‌های source map فقط برای حالت توسعه تولید می‌شوند.
- در حالت توسعه، cssها داخل فایل‌های js تولیدی قرار می‌گیرند؛ اما در حالت ارائه‌ی نهایی به صورت فایل‌های css بسته بندی می‌شوند.
- در حالت توسعه برخلاف حالت ارائه‌ی نهایی، کار uglification انجام نمی‌شود.
- در حالت توسعه برخلاف حالت ارائه‌ی نهایی، کار tree-shaking یا حذف کدهای مرده و بدون ارجاع، انجام نمی‌شود.
- در حالت توسعه برخلاف حالت ارائه‌ی نهایی، کار AOT انجام نمی‌شود. در اینجا AOT به معنای Ahead of time compilation است.
- در هر دو حالت توسعه و ارائه‌ی نهایی کار bundling و دسته بندی فایل‌ها انجام خواهد شد.

به همین جهت است که ng build سریع است؛ اما حجم بالاتری را هم تولید می‌کند. چون بسیاری از بهینه سازی‌های حالت ارائه‌ی نهایی را به همراه ندارد.

دستورات build برای حالت توسعه و ارائه‌ی نهایی

برای حالت توسعه، هر 4 دستور ذیل یک مفهوم را دارند و به همین جهت مورد ng build متداول‌تر است:

>ng build --target=development --environment=dev
>ng build --dev -e=dev
>ng build --dev
>ng build

برای حالت ارائه‌ی نهایی، هر 3 دستور ذیل یک مفهوم را دارند و به همین جهت مورد ng build --prod متداول‌تر است:

>ng build --target=production --environment=prod
>ng build --prod -e=prod
>ng build --prod

همچنین هر کدام از این دستورات را توسط پرچم‌های ذیل نیز می‌توان سفارشی سازی کرد:

پرچم	مخفف	توضیح
sourcemap--	sm-	تولید سورس‌مپ
aot--		Ahead of Time compilation
watch--	w-	تحت نظر قرار دادن فایل‌ها و ساخت مجدد
environment--	e-	محیط ساخت
target--	t-	نوع ساخت
dev--		مخفف نوع ساخت جهت توسعه
prod--		مخفف نوع ساخت جهت ارائه نهایی

برای مثال در حالت prod، سورس‌مپ‌ها تولید نخواهند شد. اگر علاقمندید تا این فایل‌ها نیز تولید شوند، پرچم souremap را نیز ذکر کنید.
و یا اگر برای حالت dev می‌خواهید AOT را فعالسازی کنید، پرچم aot-- را در آنجا قید کنید.

یک مثال: ساخت برنامه‌ی مثال قسمت چهارم - تنظیمات مسیریابی در حالت prod

تا اینجا خروجی حالت dev ساخت برنامه‌ی قسمت چهارم را بررسی کردیم. در ادامه دستور ng build --prod را در ریشه‌ی پروژه صادر می‌کنیم:

 D:\Prog\angular-routing>ng build --prod
Hash: f5bd7fd555a85af8a86f
Time: 39932ms
chunk {0} polyfills.18173234f9641113b9fe.bundle.js (polyfills) 158 kB {4} [initial] [rendered]
chunk {1} main.c6958def7c5f51c45261.bundle.js (main) 50.3 kB {3} [initial] [rendered]
chunk {2} styles.d41d8cd98f00b204e980.bundle.css (styles) 69 bytes {4} [initial] [rendered]
chunk {3} vendor.b426ba6883193375121e.bundle.js (vendor) 1.37 MB [initial] [rendered]
chunk {4} inline.8cec210370dd3af5f1a0.bundle.js (inline) 0 bytes [entry] [rendered]

همانطور که ملاحظه می‌کنید، اینبار نه تنها حجم فایل‌ها به میزان قابل ملاحظه‌ای کاهش پیدا کرده‌اند، بلکه این نام‌ها به همراه یک سری hash هم هستند که کار cache-busting (منقضی کردن کش مرورگر، با ارائه‌ی نگارشی جدید) را انجام می‌دهند.

در ادامه اگر بخواهیم مجددا برنامه‌ی source-map-explorer را جهت بررسی محتوای فایل‌های js اجرا کنیم، به خطای عدم وجود sourcemapها خواهیم رسید (چون در حالت prod، به صورت پیش فرض غیرفعال هستند). به همین‌جهت برای این مقصود خاص نیاز است از پرچم فعالسازی موقت آن استفاده کرد:

> ng build --prod --sourcemap
> source-map-explorer dist/vendor.b426ba6883193375121e.bundle.js

همانطور که در تصویر نیز مشخص است، اینبار کامپایلر Angular به همراه تمام ماژول‌هایی که در برنامه ارجاعی به آن‌ها وجود نداشته‌است، حذف شده‌اند و کل حجم بسته‌ی Angular به 366 KB کاهش یافته‌است.

بررسی دستور ng serve

تا اینجا برای اجرای برنامه در حالت dev از دستور ng serve -o استفاده کرده‌ایم. کار ارائه‌ی برنامه توسط این دستور، از محتوای کامپایل شده‌ی درون حافظه با مدیریت webpack انجام می‌شود. به همین جهت بسیار سریع بوده و قابلیت live reload را ارائه می‌دهد (نمایش آنی تغییرات در مرورگر، با تغییر فایل‌ها).
همانند تمام دستورات دیگر، اطلاعات بیشتری را در مورد این دستور، از طریق راهنمای آن می‌توان به دست آورد:

 > ng serve --help

که شامل این موارد هستند (علاوه بر تمام مواردی را که در حالت ng build می‌توان مشخص کرد؛ مثلا ng serve --prod -o):

پرچم	مخفف	توضیح
open--	o-	بازکردن خودکار مرورگر پیش فرض. حالت پیش فرض آن گشودن مرورگر توسط خودتان است و سپس مراجعه‌ی دستی به آدرس برنامه.
port--	p-	تغییر پورت پیش فرض مانند ng server -p 8626
live-reload--	lr-	فعال است مگر اینکه آن‌را با false مقدار دهی کنید.
ssl--		ارائه به صورت HTTPS
proxy-config--	pc-	Proxy configuration file

استخراج فایل تنظیمات webpack از Angular CLI

Angular CLI برای مدیریت build، در پشت صحنه از webpack استفاده می‌کند. فایل تنظیمات آن نیز جزئی از فایل‌های توکار این ابزار است و قرار نیست به صورت پیش فرض و مستقیم توسط پروژه‌ی جاری ویرایش شود. به همین جهت آن‌را در ساختار پروژه‌ی تولید شده، مشاهده نمی‌کنید.
اگر علاقمند به سفارشی سازی بیشتر این تنظیمات پیش فرض باشید، ابتدا باید آن‌را اصطلاحا eject کنید و سپس می‌توان آن‌را ویرایش کرد:

 > ng eject
Ejection was successful.

To run your builds, you now need to do the following commands:
- "npm run build" to build.
- "npm run test" to run unit tests.
- "npm start" to serve the app using webpack-dev-server.
- "npm run e2e" to run protractor.

Running the equivalent CLI commands will result in an error.
============================================
Some packages were added. Please run "npm install".

همانطور که مشاهده می‌کنید عنوان کرده‌است که از این پس خودتان باید بسیاری از مسایل را به صورت دستی مدیریت کنید و Angular CLI دیگر آن‌ها را به صورت خودکار مدیریت نمی‌کند و دیگر دستورات ng build و ng serve کار نخواهند کرد (این تغییرات در فایل package.json درج می‌شوند).
در این حالت است که فایل webpack.config.js به ریشه‌ی پروژه جهت سفارشی سازی شما اضافه خواهد شد. همچنین فایل‌های .angular-cli.json، package.json نیز جهت درج این تغییرات ویرایش می‌شوند.

و اگر در این لحظه پشیمان شده‌اید (!) فقط کافی است تا این مرحله‌ی جدید commit شده‌ی به مخزن کد را لغو کنید و باز هم به همان Angular CLI قبلی می‌رسید.

‫۷ سال و ۶ ماه قبل، پنجشنبه ۲۴ فروردین ۱۳۹۶، ساعت ۱۸:۳۰

مهران موسوی

نظرات مطالب

ایجاد شناسه ی منحصر به فرد برای هر سیستم

افزونه‌ی مذکور رو میتونید از سایت رسمی خودش دریافت کنید .

محتوای این پست صرفا مرتبط است با عنوان پست .

تعدادی از اجزای مهم سیستم امنیتی این افزونه شامل :

1 ) ارتباط با وب سرویس سایت سازنده و دریافت کد فعال سازی موقت مختص به سیستم شما و ثبت اطلاعات سیستم شما در بانک اطلاعاتی سایت است برای جلوگیری استفاده مجدد از نسخه‌ی ازمایشی بعد از 21 روز . ( البته بعد از 21 روز فقط تعدای از قابلیت‌ها غیر فعال میشوند و بقیه رایگان هستند از جمله دیباگینگ php در vs !) .

2 ) ایجاد کد منحصر به فرد هر سیستم .

3 ) ترکیب کد منحصر به فرد با شماره pakage ای که بعد از نصب افزونه vs به ان اختصاص میدهد و ...

در کل نکات جالبی رو رعایت کرده بود و تعداد زیادی از کلاس‌ها رو پیاده سازی کرده بود که ارتباطاتی با هم داشتند فقط و فقط جهت سخت کردن debuging که از کارش خوشم اومد ...

‫۱۱ سال و ۹ ماه قبل، جمعه ۱۳ بهمن ۱۳۹۱، ساعت ۱۵:۵۵

وحید نصیری

نظرات مطالب

فعال سازی عملیات CRUD در Kendo UI Grid

- «Handling Server-Side Validation Errors In Your Kendo UI Grid»
خلاصه‌اش به این صورت است:
- ابتدا رخداد error مربوط به data source را باید مدیریت کرد:

 var dataSource = new kendo.data.DataSource({
            // ... 
            error: function (e) {
                window.SalesHub.OrderDetails_Error(e);
            },
            // ... 
        });

با این متد

window.SalesHub.OrderDetails_Error = function(args) {
    if (args.errors) {
        var grid = $("#orderDetailsGrid").data("kendoGrid");
        var validationTemplate = kendo.template($("#orderDetailsValidationMessageTemplate").html());
        grid.one("dataBinding", function(e) {
            e.preventDefault();

            $.each(args.errors, function(propertyName) {
                var renderedTemplate = validationTemplate({ field: propertyName, messages: this.errors });
                grid.editable.element.find(".errors").append(renderedTemplate);
            });
        });
    }
};

که از این قالب برای نمایش خطاها استفاده می‌کند:

<script type="text/x-kendo-template" id="orderDetailsValidationMessageTemplate">
    # if (messages.length) { #
        <li>#=field#
            <ul>
                # for (var i = 0; i < messages.length; ++i) { #
                    <li>#= messages[i] #</li>
                # } #
            </ul>
        </li>
    # } #
</script>

‫۹ سال و ۶ ماه قبل، پنجشنبه ۱۷ اردیبهشت ۱۳۹۴، ساعت ۱۷:۲۰

رحمت اله رضایی

مطالب

PersianDatePicker یک DatePicker شمسی به زبان JavaScript که از تاریخ سرور استفاده می‌کند

PersianDatePicker یک DatePicker شمسی برای نمایش تاریخ شمسی در صفحات وب است.

مهمترین ویژگیها :

از تاریخ سرور برای نمایش روز جاری استفاده می‌کند.
به زبان جاوااسکریپت است و نیازی به سایر فریمورک‌ها مانند jQuery ندارد.
سبک و کم حجم است (3.5 کیلوبایت)
روزها به صورت عمودی لیست شده‌اند مانند برنامه هفتگی مدرسه که کاربران فارسی‌زبان با آن راحت‌ترند.

طرز استفاده :

PersianDatePicker.Show(textBox, today)

textBox : کنترلی است که DatePicker برای آن نمایش داده می‌شود.
today : تاریخ روز جاری است.

برای مثال :

<html>
<head>
    <script type="text/javascript" src="Scripts/PersianDatePicker.min.js"></script>
    <link type="text/css" rel="stylesheet" href="Content/PersianDatePicker.min.css" />
</head>
<body>
    <input type="text" onclick="PersianDatePicker.Show(this, '1392/03/22');" />
</body>
</html>

در ASP.NET Web Forms :

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="WebApplication4.WebForm1" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
    <script src="Scripts/PersianDatePicker.min.js"></script>
    <link href="Content/PersianDatePicker.min.css" rel="stylesheet" />
</head>
<body>
    <form id="form1" runat="server">
        <div>
            <asp:Label runat="server" Text="Label" AssociatedControlID="TextBox1">تاریخ : </asp:Label>
            <asp:TextBox  runat="server" ID="TextBox1"></asp:TextBox>
        </div>
    </form>
</body>
</html>

public partial class WebForm1 : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        var now = PersianDateTime.Now;
        var today = now.ToString(PersianDateTimeFormat.Date);

        TextBox1.Attributes["onclick"] = "PersianDatePicker.Show(this,'" + today + "');";
    }
}

در مثال بالا برای گرفتن تاریخ روز جاری از PersianDateTime استفاده شده است.

در ASP.NET MVC یا PHP یا هر زبان دیگری کافیست onclick کنترل متنی مورد نظر در سمت سرور مانند مثال بالا مقدار داده شود. یا می‌توان image کوچکی کنار textbox مورد نظر قرار داد و onclick آن تنظیم شود.

برای استفاده از PersianDatePicker می‌توانید آنرا از NuGet دریافت کنید :

PM> Install-Package PersianDatePicker

همچنین یک مثال کامل ASP.NET MVC آن‌را می‌توانید از اینجا دریافت کنید:
MvcAppPersianDatePicker.zip

‫۱۱ سال و ۵ ماه قبل، یکشنبه ۲۶ خرداد ۱۳۹۲، ساعت ۱۶:۳۵

وحید نصیری

مطالب

ارتقاء به ASP.NET Core 1.0 - قسمت 21 - بررسی تغییرات Bundling و Minification

زیرساخت یکی کردن و فشرده سازی اسکریپت‌ها و فایل‌های CSS نگارش پیشین ASP.NET MVC، به طور کامل از ASP.NET Core حذف شده‌است. در ابتدا (تا نگارش RC2)، روش استفاده‌ی از Gulp را توصیه کردند و در زمان ارائه‌ی نگارش RTM، توصیه‌ی رسمی آن‌ها به Bundler Minifier تغییر کرد (و دیگر Gulp را توصیه نمی‌کنند).

یکی کردن و فشرده سازی فایل‌های استاتیک در ASP.NET Core

هدف از یکی کردن و فشرده سازی فایل‌های استاتیک مانند اسکریپت‌ها و فایل‌های CSS، بهبود کارآیی برنامه با کاهش حجم نهایی ارائه‌ی آن و همچنین کاهش تعداد رفت و برگشت‌های به سرور برای دریافت فایل‌های متعدد مرتبط به آن است. در عملیات Bundling، چندین فایل، به یک تک فایل تبدیل می‌شوند تا اتصالات مرورگر به وب سرور، جهت دریافت آن‌ها به نحو چشمگیری کاهش پیدا کند و در عملیات Minification، مراحل متعددی بر روی کدهای نوشته شده صورت می‌گیرد تا حجم نهایی آن‌ها کاهش پیدا کنند. مایکروسافت در ASP.NET Core RTM، ابزاری را به نام BundlerMinifier.Core جهت برآورده کردن این اهداف ارائه کرده‌است. بنابراین اولین قدم، نصب وابستگی‌های آن است.
برای اینکار یک سطر ذیل را به فایل project.json اضافه کنید. این بسته باید به قسمت tools اضافه شود تا قابلیت فراخوانی از طریق خط فرمان را نیز پیدا کند:

"tools": {
    "BundlerMinifier.Core": "2.1.258"
},

در غیر اینصورت (ذکر آن در قسمت dependencies) خطاهای ذیل را دریافت خواهید کرد:

No executable found matching command "dotnet-bundle"
Version for package `BundlerMinifier.Core` could not be resolved.

اسکریپت نویسی برای کار با BundlerMinifier.Core

روش‌های زیادی برای کار با ابزار BundlerMinifier.Core وجود دارند؛ منجمله انتخاب فایل‌ها در solution explorer و سپس کلیک راست بر روی فایل‌های انتخاب شده و انتخاب گزینه‌ی bundler & minifier برای یکی کردن و فشرده سازی خودکار این فایل‌ها. برای این منظور افزونه‌ی Bundler & Minifier را نیاز است نصب کنید.
اما روشی که قابلیت خودکارسازی را دارد، استفاده از فایل ویژه‌ی bundleconfig.json این ابزار است. برای این منظور فایل جدید bundleconfig.json را به ریشه‌ی پروژه اضافه کرده و سپس محتوای ذیل را به آن اضافه کنید:

[
    {
        "outputFileName": "wwwroot/css/site.min.css",
        "inputFiles": [
            "wwwroot/css/site.css"
        ]
    },
    {
        "outputFileName": "wwwroot/js/site.min.js",
        "inputFiles": [
            "bower_components/jquery/dist/jquery.min.js",
            "bower_components/jquery-validation/dist/jquery.validate.min.js",
            "bower_components/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js"
        ],
        "minify": {
            "enabled": true,
            "renameLocals": true
        },
        "sourceMap": false
    }
]

فرمت این فایل بسیار خوانا است. برای مثال در یک مدخل آن، در ذیل خاصیت inputFiles، لیست فایل‌های css ذکر می‌شوند و سپس در outputFileName، محل نهایی فایل تولیدی باید ذکر شود. این محل نیز باید از پیش وجود داشته باشد. یعنی باید پوشه‌های js و css را در پوشه‌ی عمومی wwwroot پیشتر ایجاد کرده باشید.
با ذخیره سازی این فایل، کار یکی سازی و فشرده کردن مداخل آن به صورت خودکار صورت خواهد گرفت.

خودکار سازی فرآیند یکی کردن و فشرده سازی فایل‌های استاتیک

برای خودکار سازی این فرآیند، می‌توان به صورت زیر عمل کرد. فایل project.json را گشوده و قسمت scripts آن‌را به نحو ذیل تغییر دهید:

"scripts": {
    "precompile": [
        "dotnet bundle"
    ],
    "prepublish": [
        "bower install"
    ],
    "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}

روش دستی کار با ابزار BundlerMinifier، مراجعه به خط فرمان و صدور دستور dotnet bundle است (ابتدا از طریق خط فرمان به ریشه‌ی پروژه وارد شده و سپس این دستور را صادر کنید). برای خودکار سازی آن می‌توان این دستور را در قسمت scripts فایل project.json نیز ذکر کرد تا پیش از کامپایل برنامه، کار یکی کردن، فشرده سازی و همچنین کپی فایل نهایی به پوشه‌ی wwwroot برنامه به صورت خودکار انجام شود.

یک نکته: به منوی Build گزینه‌ی Update all bundles نیز با نصب افزونه‌ی Bundler & Minifier اضافه می‌شود. همچنین اگر از منوی Tools گزینه‌ی Task runner explorer را انتخاب کنید، فایل bundleconfig.json توسط آن شناسایی شده و گزینه‌ی update all files را نیز در اینجا مشاهده خواهید کرد.

ساده سازی تعاریف فایل Layout برنامه

در یک چنین حالتی دیگر نباید در فایل layout شما، ارجاعات مستقیمی به پوشه‌ی مثلا bower_components وجود داشته باشند و یا در کلاس آغازین برنامه، نیازی نیست تا این پوشه را عمومی کنید. لیست مداخلی را که نیاز دارید، به ترتیب از پوشه‌های مختلفی تهیه و در فایل bundleconfig.json ذکر کنید تا یکی شده و خروجی js/site.min.js را تشکیل دهند. این مورد تنها مدخلی است که نیاز است در فایل layout برنامه ذکر شود (بجای چندین و چند مدخل مورد نیاز):

 <script src="~/js/site.min.js" asp-append-version="true" type="text/javascript"></script>

در مورد ویژگی asp-append-version نیز پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 12 - معرفی Tag Helpers» بحث شد و به آن مکانیزم cache busting می‌گویند. این ویژگی سبب خواهد شد تا یک کوئری استرینگ v=xyz? مانند، به انتهای آدرس اسکریپت یا فایل css یا هر فایل استاتیک دیگری اضافه شود. با تغییر محتوای این فایل، قسمت xyz به صورت خودکار تغییر خواهد کرد و به این ترتیب مرورگر همواره آخرین نگارش این فایل را دریافت می‌کند.

‫۸ سال و ۳ ماه قبل، چهارشنبه ۶ مرداد ۱۳۹۵، ساعت ۱۶:۰۵

ناصرنیازی

مطالب

IdentityServer قسمت دوم

پس از تلاش‌های اولیه برای راه اندازی که نیاز به گوگل کردن موارد مختلف دارد از جمله راه اندازی ssl و certification در لوکال هاست و تنظیم IIS برای استفاده از آن، می‌توان به راه اندازی اولیه آی‌دن‌تی‌تی سرور رسید .

پیش فرض این آموزش این نسخه از آی دنتیتی سرور است :

https://github.com/IdentityServer/IdentityServer2

نگاهی اجمالی به سورس:

IdentityServer2

Sampel----

AdfsIntegrationFullSample --------

AdfsIntegrationSampleClient --------

InMemoryHost --------

(MVC and WCF RP (SAML --------

(MVC and Web API (JWT --------

MembershipRebootUserRepository --------

OIDC --------

SelfHostConsoleHost --------

ServiceBus Integration --------

src----

Libraries --------

WebSite --------

Tests --------

از نام مثال‌ها کاملآ مشخص است که هر کدام چه بخشی را پوشش می‌دهند.

مثلآ پوشه‌ی MembershipRebootUserRepository، مربوط به مدیریت کاربران است و توابع غنی بسیار خوبی در آن استفاده شده‌است. خود MembershipReboot یک پروژه‌ی دیگر است برای مدیریت کاربران که توسط BrockAllen توسعه داده شده و مدیریت کاربران را بسیار آسان کرده‌است؛ برای مثال به راحتی می‌توان

BrockAllen.MembershipReboot 
BrockAllen.MembershipReboot.Ef   
BrockAllen.MembershipReboot  .Repository

از این آدرس را به سورس اصلی آی دنتیتی سرور اضافه کرد و از توابع مدیریت کاربران این پروژه استفاده کرد. چون کار را بسیار آسان کرده است.

برای مثال من برای ایجاد کاربر نیاز داشتم که علاوه بر درج کاربر در سرور آی دنتیتی، در بانک اطلاعاتی خودم هم کاربر درج شود. برای همین برای آی دنتیتی سرور صفحه‌ی ثبت نام نوشتم. برای اینکار فقط با یک شیء از membership به راحتی این تابع پیاده سازی شد:

          Membership.CreateUser(userName, password, email);  
          Roles.AddUserToRoles(userName, "IdentityServerUsers");

نمونه استفاده

این افزودن کاربر را می‌توان از هسته‌ی اصلی خود آی دنتیتی سرور استفاده کرد. ولی استفاده از آن به علت راحت بودن و توابع خیلی زیاد BrockAllen.MembershipReboot است و استفاده از آن بسیار کاربردی می‌تواند باشد.

برای استفاده از خود آی دنتیتی سرور برای ساخت یوزر، وارد قسمت سورس شوید و به کنترلر احراز هویت، یک تابع به نام رجیستر اضافه کنید؛ به این فایل:

https://github.com/IdentityServer/IdentityServer2/blob/master/src/OnPremise/WebSite/Controller/AccountController.cs

شکل تابع :

  [HttpPost]
public ActionResult Register(RegisterModel model)
 {
         UserRepository.CreateUser(model.userName,model.password,model.email);
         Roles.AddUserToRoles(userName, "IdentityServerUsers");
         return  View(model);
}

خود کلاس UserRepository یک کلاس پیاده سازی شده از اینترفیس IUserManagementRepository است که می‌توان خود آن‌را نیز با تزریق وابستگی‌ها تغییر داد و از Membership و بازنویسی توابع قدرتمند MembershipReboot آن استفاده کرد. لیست توابع این اینترفیس که می‌توانید استفاده کنید:

        void CreateUser(string userName, string password, string email = null);
        void DeleteUser(string userName);
        
        IEnumerable<string> GetUsers(int start, int count, out int totalCount);
        IEnumerable<string> GetUsers(string filter, int start, int count, out int totalCount);

        void SetPassword(string userName, string password);

        void SetRolesForUser(string userName, IEnumerable<string> roles);
        IEnumerable<string> GetRolesForUser(string userName);

        IEnumerable<string> GetRoles();
        void CreateRole(string roleName);
        void DeleteRole(string roleName);

آدرس اینترفیس

‫۹ سال و ۲ ماه قبل، سه‌شنبه ۳ شهریور ۱۳۹۴، ساعت ۰۵:۳۰

مهرداد کاهه

مطالب

پیاده سازی یک سیستم دسترسی Role Based در Web API و AngularJs - بخش سوم (پایانی)

در بخش پیشین به بررسی جزئی‌تر ایجاد پایگاه داده و همچنین توسعه Custom Filter Attribute پرداختیم که وظیفه تایید صلاحیت کاربر جاری و بررسی دسترسی وی به API Method مورد نظر را بررسی می‌کرد. در این مقاله به این بحث می‌پردازیم که در Filter Attribute توسعه داده شده، قصد داریم یک سرویس Access Control ایجاد نماییم.

این سرویس وظیفه تمامی اعمال مربوط به نقش‌ها و دسترسی‌های کاربر را بر عهده خواهد داشت. این سرویس به صورت زیر تعریف می‌گردد:

public class AccessControlService
{
        private DbContext db;

        public AccessControlService()
        {
            db = new DbContext();
        }

        public IEnumerable<Permission> GetUserPermissions(string userId)
        {
            var userRoles = this.GetUserRoles(userId);
            var userPermissions = new List<Permission>();
            foreach (var userRole in userRoles)
            {
                foreach (var permission in userRole.Permissions)
                {
                    // prevent duplicates
                    if (!userPermissions.Contains(permission))
                        userPermissions.Add(permission);
                }
            }
            return userPermissions;
        }
        public IEnumerable<Role> GetUserRoles(string userId)
        {
            return db.Users.FirstOrDefault(x => x.UserId == userId).Roles.ToList();
        }

        public bool HasPermission(string userId, string area, string control)
        {
            var found = false;
            var userPermissions = this.GetUserPermissions(userId);
            var permission = userPermissions.FirstOrDefault(x => x.Area == area && x.Control == control);
            if (permission != null)
                found = true;
            return found;
        }
{

همانطور که ملاحظه می‌کنید، ما سه متد GetUserPermissions، GetUserRoles و HasPermission را توسعه داده‌ایم. حال اینکه بر حسب نیاز، می‌توانید متدهای بیشتری را نیز به این سرویس اضافه نمایید. متد اول، وظیفه‌ی واکشی تمامی permissionهای کاربر را عهده دار می‌باشد. متد GetUserRoles نیز تمامی نقش‌های کاربر را در سیستم، بازمی‌گرداند و در نهایت متد سوم، همان متدی است که ما در Filterattribute از آن استفاده کرد‌ه‌ایم. این متد با دریافت پارامترها و بازگردانی یک مقدار درست یا نادرست، تعیین می‌کند که کاربر جاری به آن محدوده دسترسی دارد یا خیر.

تمامی حداقل‌هایی که برای نگارش سمت سرور نیاز بود، به پایان رسید. حال به بررسی این موضوع خواهیم پرداخت که چگونه این سطوح دسترسی را با سمت کاربر همگام نماییم. به طوری که به عنوان مثال اگر کاربری حق دسترسی به ویرایش مطالب یک سایت را ندارد، دکمه مورد نظر که او را به آن صفحه هدایت می‌کند نیز نباید به وی نشان داده شود. سناریویی که ما برای این کار در نظر گرفته‌ایم، به این گونه می‌باشد که در هنگام ورود کاربر، لیستی از تمامی دسترسی‌های او به صورت JSON به سمت کلاینت ارسال می‌گردد. حال وظیفه مدیریت نمایش یا عدم نمایش المان‌های صفحه، بر عهده زبان سمت کلاینت، یعنی AngularJs خواهد بود. بنابراین در ابتدایی‌ترین حالت، ما نیاز به یک کنترلر و متد Web API داریم تا لیست دسترسی‌های کاربر را بازگرداند. این کنترلر در حال حاضر شامل یک متد است. اما بر حسب نیاز، می‌توانید متدهای بیشتری را به کنترلر اضافه نمایید.

    [RoutePrefix("َAuth/permissions")]
    public class PermissionsController : ApiController
    {
        private AccessControlService _AccessControlService = null;
        public PermissionsController()
        {
            _AccessControlService = new AccessControlService();
        }

        [Route("GetUserPermissions")]
        public async Task<IHttpActionResult> GetUserPermissions()
        {
            if (!User.Identity.IsAuthenticated)
            {
                return Unauthorized();
            }
            return Ok(_AccessControlService.GetPermissions(User.Identity.GetCurrentUserId()));
        }        
    }

در متد فوق ما از متد سرویس Access Control که لیست تمامی permissionهای کاربر را باز می‌گرداند، کمک گرفتیم. متد GetUserPermissions پس از ورود کاربر توسط کلاینت فراخوانی می‌گردد و لیست تمامی دسترسی‌ها در سمت کلاینت، در rootScope انگیولار ذخیره سازی می‌گردد. حال نوبت به آن رسیده که به بررسی عملیات سمت کلاینت بپردازیم.

توسعه سرویس‌ها و فرآیندهای سمت وب کلاینت AngularJS

در ابتدا در سمت کلاینت نیاز به سرویسی داریم که دسترسی‌های سمت سرور را دریافت نماید. از این رو ما نام این سرویس را permissionService می‌نامیم.

'use strict';
angular.module('App').factory('permissionService', ['$http', '$q', function ($http, $q) {

    var _getUserPermissions = function () {
        return $http.get(serviceBaseUrl + '/api/permissions/GetUserPermissions/');
    }

    var _isAuthorize = function (area, control) {
        return _.some($scope.permissions, { 'area': area, 'control': control });
    }

    return {
        getUserPermissions: _getUserPermissions,
        isAuthorize: _isAuthorize
    };
}]);

اگر بخواهیم مختصری درباره‌ی این سرویس صحبت کنیم، متد اول که یک دستور GET ساده است و لیست دسترسی‌ها را از PermissionController دریافت می‌کند. متد بعدی که در آینده بیشتر با آن آشنا می‌شویم، عملیات تایید صلاحیت کاربر را به ناحیه مورد نظر، انجام می‌دهد (همان مثال دسترسی به دکمه ویرایش مطلب در یک صفحه). در این متد برای جستجوی لیست permissions از کتابخانه‌ای با نام Lodash کمک گرفته‌ایم. این کتابخانه کاری شبیه به دستورات Linq را در کالکشن‌ها و آرایه‌های جاوااسکریپتی، انجام می‌دهد. متد some یک مقدار درست یا نادرست را بازمی‌گرداند. بازگردانی مقدار درست، به این معنی است که کاربر به ناحیه‌ی مورد نظر اجازه‌ی دسترسی را خواهد داشت.

حال باید متد‌های این سرویس را در کنترلر لاگین فراخوانی نماییم. در این مرحله ما از rootScope dependency استفاده می‌کنیم. برای نحوه‌ی عملکرد rootScope میتوانید به مقاله‌ای در این زمینه در وب سایت toddomotto مراجعه کنید. در این مقاله ویژگی‌ها و اختلاف‌های scope و rootScope به تفصیل بیان شده است. مقاله‌ای دیگر در همین زمینه نوشته شده است که در انتهای مقاله به بررسی چند نکته در مورد کدهای مشترک پرداخته شده‌است. تکه کد زیر، متد login را نمایش می‌دهد که در loginController قرار گرفته است و ما در آن از نوشتن کل بلاک loginController چشم پوشی کرده‌ایم. متد savePermissions تنها یک کار را انجام می‌دهد و آن هم این است که در ابتدا، به سرویس permissionService متصل شده و تمامی دسترسی‌ها را واکشی می‌نماید و پس از آن، آنها را درون rootScope قرار می‌دهد تا در تمامی کنترلرها قابل دسترسی باشد.

    $scope.login = function () {
        authService.login($scope.loginData).then(function (response) {
            savePermissions();
            $location.path('/userPanel');
        },
         function (err) {
             $scope.message = err.error_description;
         });
    };

    var savePermissions = function () {
        permissionService.getUserPermissions().then(function (response) {
            $rootScope.permissions = response.data;
        },
        function (err) {
        });
    }
}

حال تمامی اطلاعات دسترسی، در سمت کلاینت نیز قابل دسترسی می‌باشد. تنها کاری که نیاز است، broadCast کردن متد isAuthorize است که آن هم باید در rootScope قرار بگیرد. ما برای این انتساب یک راهکار را ارائه کرده‌ایم. معماری سیستم کلاینت به این صورت است که تمامی کنترلرها درون یک parentController قرار گرفته‌اند. از این رو می‌توان در parentController این انتساب (ایجاد دسترسی عمومی برایisAuthorize) صورت گیرد. برای این کار در parentController تغییرات زیر صورت می‌گیرد:

App.controller('parentController', ['$rootScope', '$scope', 'authService', 'permissionService', function ($rootScope, $scope, authService, permissionService) {
        $scope.authentication = authService.authentication;

        // isAuthorize Method
        $scope.isAuthorize = permissionService.isAuthorize();

        // rest of codes
}]);

در کد فوق ما isAuthorize را درون scope قرار داده‌ایم. دلیل آن هم این است که هر چه که در scope قرار بگیرد، تمامی کنترلر‌های child نیز به آن دسترسی خواهند داشت. البته ممکن است که این بهترین نوع پیاده سازی برای به اشتراک گذاری یک منبع نباشد.

در گام بعدی کافیست المان‌های صفحه را بر اساس همین دسترسی‌ها فعال یا غیر فعال کنیم. برای این کار از دستور ng-if میتوان استفاده کرد. برای این کار به مثال زیر توجه کنید:

<div ng-controller="childController">
    <div ng-if="isAuthorize('articles', 'edit')" >
    <!-- the block that we want to not see unauthorize person -->
    </div>
</div>

همانطور که مشاهده می‌کنید، تمامی المان‌ها را می‌توان با دستور ساده ng-if، از دید کاربران بدون صلاحیت، پنهان نمود. البته توجه داشته باشید که شما نمی‌توانید تنها به پنهان کردن این اطلاعات اکتفا کنید. بلکه باید تمامی متدهای کنترلرهای سمت سرور را هم با همین روش (فیلتر کردن با Filter Attribute) بررسی نمایید. به ازای هر درخواست کاربر باید بررسی شود که او به منبع مورد نظر دسترسی دارد یا خیر.

تنها نکته‌ای که باقی می‌ماند این است که طول عمر scope و rootScope چقدر است؟! برای پاسخ به این سوال باید بگوییم هر بار که صفحه refresh می‌شود، تمامی مقادیر scope و rootScope خالی می‌شوند. برای این کار هم یک راهکار خیلی ساده (و شاید کمی ناشیانه) در نظر گرفته شده‌است. میتوان بلاک مربوط به پر کردن rootScope.permissions را که در loginController نوشته شده بود، به درون parentController انتقال داد و آن را با استفاده از emit اجرا کرد و در حالت عادی، در هنگام refresh شدن صفحه نیز چون parentController در اولین لحظه اجرا می‌شود، میتوان تمامی مقادیر rootScope.permissions را دوباره از سمت سرور دریافت کرد.

‫۸ سال و ۶ ماه قبل، یکشنبه ۱۲ اردیبهشت ۱۳۹۵، ساعت ۱۷:۲۰

علی ملکیان

نظرات مطالب

Ajax.BeginForm و ارسال فایل به سرور در ASP.NET MVC

سلام.
من هم مشکل شمارو داشتم و کدهای فایل ajaxfileupload.js رو بررسی کردم و به این تکه کد برخورد کردم:

  $("#" + formElementId + " > input[type='file']").each(function () {
            var oldElement = $(this);
            var newElement = jQuery(oldElement).clone();
            jQuery(oldElement).attr("id", fileId);
            jQuery(oldElement).before(newElement);
            jQuery(oldElement).appendTo(form);
        });

همونطور که میبینید با توجه به کاراکتر < مشخص شده که input هایی از نوع file انتخاب بشن که دقیقا در ریشه‌ی formElementId باشند. در صورتی که input‌های من در ریشه اصلی نبودن و اومدم این کاراکتر رو برداشتم و مشکل حل شد.

‫۸ سال و ۱۱ ماه قبل، جمعه ۶ آذر ۱۳۹۴، ساعت ۰۰:۳۰