اشتراکها
مشکل از این مثال یا این تقویم یا هیچکدوم نیست. مشکل از اینجا است که در حین Post، سیستم بایندینگ MVC میاد نگاه میکنه چه خواصی رو در کلاس PostViewModel داری (اسم این کلاس مهم نیست). زمانی که در اون خاصیت AddDate رو پیدا نکرد، خوب ... همه چیز تموم میشه. خاصیتی رو پیدا نکرده که اطلاعات دریافتی رو بهش بایند کنه، بنابراین خاصیتهای شیء تو در تویی که درست کردی، خالی باقی میمونه. این نوع View مدل بیشتر برای حالت Get استفاده میشه نه حالت Post. برای حالت Get ایی که قراره در یک صفحه چند منبع داده رو به قسمتهای مختلف اون بایند کنی.
البته MVC میتونه به یک شیء تو در تو هم اطلاعات رو در حالت Post بایند کنه. اینطوری model=> model.Post.AddDate (دو تا دات داره نه یکی). خودت باید دستی این چند سطح رو مشخص کنی (در متدهای For دار).
نظرات مطالب
اشتباهات متداول برنامهنویسهای دات نت
سلام
خبرخوان (تکست و گرافیکی)، لیست و فید وبلاگهای برنامهنویسی ارائه شده است که وبلاگ شما نیز جز آنها قرار گرفته است.
http://persianbloggers.blogspot.com/2009/03/programming-p.html
پرشین بلاگرز شما را به بازدید و استفاده از این خبرخوان و 23 خبرخوان تخصصی دیگر موجود دعوت میکند.
خبرخوان (تکست و گرافیکی)، لیست و فید وبلاگهای برنامهنویسی ارائه شده است که وبلاگ شما نیز جز آنها قرار گرفته است.
http://persianbloggers.blogspot.com/2009/03/programming-p.html
پرشین بلاگرز شما را به بازدید و استفاده از این خبرخوان و 23 خبرخوان تخصصی دیگر موجود دعوت میکند.
با سلام
در صورتی که بخواهیم به همراه هر فایل یک داده ارسال کنیم در سمت سرور چطور میشه داده مرتبط با فایل مربوطه رو واکشی کرد؟
مثلا به ازای هر فایل بخواهیم عنوان فایل و توضیحاتی راجع به فایل رو هم ارسال کنیم و در سمت سرور واکشی کرده و در دیتابیس ذخیره کنیم.
فرض کنید قصد داریم خاصیت htmlContent زیر را در قالب این کامپوننت نمایش دهیم:
اگر از روش متداول binding استفاده شود:
چنین خروجی حاصل خواهد شد:
همچنین اگر به کنسول developer tools مرورگر مراجعه کنیم، چنین اخطاری نیز درج شده است:
به این معنا که Angular به صورت توکار تمام خروجیها را به صورت encode شده نمایش میدهد و در مقابل حملات XSS مقاوم است. Sanitizing نیز در اینجا به معنای تغییر ورودی و تبدیل آن به مقداری است که جهت درج در DOM امن است.
روش نمایش HTML در برنامههای Angular
اما اگر خواستیم اطلاعات HTML ایی را به همان صورتی که هستند نمایش دهیم چطور؟ در این حالت باید از روش ویژهی ذیل استفاده کرد:
برای نمایش HTML نیاز است آنرا به ویژگی innerHTML متصل کرد؛ با این خروجی:
همانطور که مشاهده میکنید، هنوز هم عملیات پاکسازی قسمتهایی که ممکن است مخرب باشند صورت میگیرد (برای مثال تگ script حذف شدهاست). اما مابقی تگهای امن به همان حالتی که هستند نمایش داده خواهند شد.
روش دیگر کار با innerHTML، تعریف یک template reference variable در قالب کامپوننت است:
و سپس دسترسی به آن از طریق یک ViewChild و انتساب مقداری بهinnerHTML آن به صورت ذیل:
با این خروجی:
که اینبار قسمت script آن به طور کامل حذف شدهاست.
حالات مختلفی که Angular برنامه را از حملات XSS محافظت میکند
در ذیل، لیست مواردی را مشاهده میکنید که به صورت پیشفرض توسط Angular در مقابل حملات XSS محافظت میشوند و اطلاعات انتساب داده شدهی به آنها تمیزسازی خواهند شد:
تبدیل کردن یک HTML نا امن ورودی به یک HTML امن در Angular
بهتر است اطلاعات دریافتی از کاربران پیش از ارسال به سرور تمیز شوند. برای این منظور میتوان از سرویس ویژهای به نام DomSanitizer کمک گرفت. کار این سرویس، امن سازی اطلاعات نمایش داده شدهی در برنامههای Angular است.
در این حالت سرویس DomSanitizer به سازندهی کلاس تزریق شده و سپس میتوان از متدهای مختلف آن مانند sanitize استفاده کرد. خروجی آن صرفا حذف تگ اسکریپت و نگهداری کدهای درون آن است.
در این حالت میتوان موارد ذیل را کنترل کرد. برای مثال اگر مقدار دریافتی CSS است، میتوان از SecurityContext.STYLE استفاده کرد و سایر حالات آن مانند امن سازی HTML، اسکریپت و آدرسهای اینترنتی به شرح ذیل هستند:
غیرفعال کردن سیستم امنیتی Angular جهت نمایش کامل یک مقدار HTML ایی
اگر خواستیم اطلاعات HTML ایی را با فرض امن بودن آن، به همان نحوی که هست نمایش دهیم چطور؟
سرویس DomSanitizer شامل متدهای ذیل نیز میباشد:
اولین متد آن sanitize است که در مورد آن توضیح داده شد. سایر متدها، کار غیرفعال سازی سیستم امنیتی توکار Angular را انجام میدهند.
برای کار با آنها همانند مثال استفادهی از متد sanitize میتوان سرویس DomSanitizer را به سازندهی یک کامپوننت تزریق کرد و یا میتوان این عملیات تکراری فرمت اطلاعات ورودی را تبدیل به یک Pipe جدید کرد:
کار این Pipe غیرفعال کردن سیستم امنیتی Angular و نمایش html، style و غیره به همان صورتی که هستند، میباشد.
برای استفادهی از آن، ابتدا این Pipe به قسمت declarations ماژول مدنظر اضافه خواهد شد:
و سپس در قالب کامپوننت به نحو ذیل میتوان با آن کار کرد:
در این حالت متد bypassSecurityTrustHtml بر روی htmlContent، فراخوانی شده و نتیجهی نهایی نمایش داده خواهد شد.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
export class ShowHtmlComponent { htmlContent = "Template <script>alert(\"Hello!\")</script> <b>Syntax</b>"; }
<h3>Binding innerHTML</h3> <p>Bound value:</p> <p>{{htmlContent}}</p>
همچنین اگر به کنسول developer tools مرورگر مراجعه کنیم، چنین اخطاری نیز درج شده است:
WARNING: sanitizing HTML stripped some content (see http://g.co/ng/security#xss).
روش نمایش HTML در برنامههای Angular
اما اگر خواستیم اطلاعات HTML ایی را به همان صورتی که هستند نمایش دهیم چطور؟ در این حالت باید از روش ویژهی ذیل استفاده کرد:
<p>Result of binding to innerHTML:</p> <p [innerHTML]="htmlContent"></p>
همانطور که مشاهده میکنید، هنوز هم عملیات پاکسازی قسمتهایی که ممکن است مخرب باشند صورت میگیرد (برای مثال تگ script حذف شدهاست). اما مابقی تگهای امن به همان حالتی که هستند نمایش داده خواهند شد.
روش دیگر کار با innerHTML، تعریف یک template reference variable در قالب کامپوننت است:
<p #dataContainer></p>
export class ShowHtmlComponent implements OnInit { @ViewChild("dataContainer") dataContainer: ElementRef; ngOnInit() { this.dataContainer.nativeElement.innerHTML = "nativeElement <script>alert(\"Hello!\")</script> <b>Syntax</b>"; } }
که اینبار قسمت script آن به طور کامل حذف شدهاست.
حالات مختلفی که Angular برنامه را از حملات XSS محافظت میکند
در ذیل، لیست مواردی را مشاهده میکنید که به صورت پیشفرض توسط Angular در مقابل حملات XSS محافظت میشوند و اطلاعات انتساب داده شدهی به آنها تمیزسازی خواهند شد:
HTML Attributes – <div [innerHTML]="UNTRUSTED"></div> OR <input value="UNTRUSTED"> Style— <div [style]="height:UNTRUSTED"></div> URL — <a [href]="UNTRUSTED-URL"></a> OR <script [src]="UNTRUSTED-URL"></script> OR <iframe src="UNTRUSTED-URL" /> GET Parameter – <a href="/user?id=UNTRUSTED">link</a> JavaScript Variable – <script> var value='UNTRUSTED';</script>
تبدیل کردن یک HTML نا امن ورودی به یک HTML امن در Angular
بهتر است اطلاعات دریافتی از کاربران پیش از ارسال به سرور تمیز شوند. برای این منظور میتوان از سرویس ویژهای به نام DomSanitizer کمک گرفت. کار این سرویس، امن سازی اطلاعات نمایش داده شدهی در برنامههای Angular است.
export class ShowHtmlComponent implements OnInit { sanitizedHtml: string; constructor(private sanitizer: DomSanitizer) { } ngOnInit() { this.sanitizedHtml = this.sanitizer.sanitize(SecurityContext.HTML, "<b>Sanitize</b><script>attackerCode()</script>"); } }
در این حالت میتوان موارد ذیل را کنترل کرد. برای مثال اگر مقدار دریافتی CSS است، میتوان از SecurityContext.STYLE استفاده کرد و سایر حالات آن مانند امن سازی HTML، اسکریپت و آدرسهای اینترنتی به شرح ذیل هستند:
SecurityContext.NONE SecurityContext.HTML SecurityContext.STYLE SecurityContext.SCRIPT SecurityContext.URL SecurityContext.RESOURCE_URL
غیرفعال کردن سیستم امنیتی Angular جهت نمایش کامل یک مقدار HTML ایی
اگر خواستیم اطلاعات HTML ایی را با فرض امن بودن آن، به همان نحوی که هست نمایش دهیم چطور؟
سرویس DomSanitizer شامل متدهای ذیل نیز میباشد:
export enum SecurityContext { NONE, HTML, STYLE, SCRIPT, URL, RESOURCE_URL } export abstract class DomSanitizer implements Sanitizer { abstract sanitize(context: SecurityContext, value: SafeValue|string|null): string|null; abstract bypassSecurityTrustHtml(value: string): SafeHtml; abstract bypassSecurityTrustStyle(value: string): SafeStyle; abstract bypassSecurityTrustScript(value: string): SafeScript; abstract bypassSecurityTrustUrl(value: string): SafeUrl; abstract bypassSecurityTrustResourceUrl(value: string): SafeResourceUrl; }
برای کار با آنها همانند مثال استفادهی از متد sanitize میتوان سرویس DomSanitizer را به سازندهی یک کامپوننت تزریق کرد و یا میتوان این عملیات تکراری فرمت اطلاعات ورودی را تبدیل به یک Pipe جدید کرد:
import { Pipe, PipeTransform } from "@angular/core"; import { DomSanitizer, SafeHtml, SafeResourceUrl, SafeScript, SafeStyle, SafeUrl } from "@angular/platform-browser"; @Pipe({ name: "safe" }) export class SafePipe implements PipeTransform { constructor(protected sanitizer: DomSanitizer) { } public transform(value: any, type: string): SafeHtml | SafeStyle | SafeScript | SafeUrl | SafeResourceUrl { switch (type) { case "html": return this.sanitizer.bypassSecurityTrustHtml(value); case "style": return this.sanitizer.bypassSecurityTrustStyle(value); case "script": return this.sanitizer.bypassSecurityTrustScript(value); case "url": return this.sanitizer.bypassSecurityTrustUrl(value); case "resourceUrl": return this.sanitizer.bypassSecurityTrustResourceUrl(value); default: throw new Error(`Invalid safe type specified: ${type}`); } } }
برای استفادهی از آن، ابتدا این Pipe به قسمت declarations ماژول مدنظر اضافه خواهد شد:
@NgModule({ imports: [ // ... ], declarations: [ SafePipe] })
<p [innerHTML]="htmlContent | safe: 'html'"></p>
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
مطالب
ASP.NET MVC #2
MVC چیست و اساس کار آن چگونه است؟
الگوی MVC در سالهای اول دهه 70 میلادی در شرکت زیراکس توسط خالقین زبان اسمالتاک که جزو اولین زبانهای شیءگرا محسوب میشود، ارائه گردید. نام MVC از الگوی Model-View-Controller گرفته شده و چندین دهه است که در صنعت تولید نرم افزار مورد استفاده میباشد. هدف اصلی آن جدا سازی مسئولیتهای اجزای تشکیل دهنده «لایه نمایشی» برنامه است.
این الگو در سال 2004 برای اولین بار در سکویی به نام Rails به کمک زبان روبی جهت ساخت یک فریم ورک وب MVC مورد استفاده قرار گرفت و پس از آن به سایر سکوها مانند جاوا، دات نت (در سال 2007)، PHP و غیره راه یافت.
تصاویری را از این تاریخچه در ادامه ملاحظه میکنید؛ از دکتر Trygve Reenskaug تا شرکت زیراکس و معرفی آن در Rails به عنوان اولین فریم ورک وب MVC.
C در MVC معادل Controller است. کنترلر قسمتی است که کار دریافت ورودیهای دنیای خارج را به عهده دارد؛ مانند پردازش یک درخواست HTTP ورودی.
زمانیکه کنترلر این درخواست را دریافت میکند، کار وهله سازی Model را عهده دار خواهد شد و حاوی اطلاعاتی است که نهایتا در اختیار کاربر قرار خواهد گرفت تا فرآیند پردازش درخواست رسیده را تکمیل نماید. برای مثال اگر کاربری جهت دریافت آخرین اخبار به سایت شما مراجعه کرده است، در اینجا کار تهیه لیست اخبار بر اساس مدل مرتبط به آن صورت خواهد گرفت. بنابراین کنترلرها، پایه اصلی و مدیر ارکستر الگوی MVC محسوب میشوند.
در ادامه، کنترلر یک View را جهت نمایش Model انتخاب خواهد کرد. View در الگوی MVC یک شیء ساده است. به آن میتوان به شکل یک قالب که اطلاعاتی را از Model دریافت نموده و سپس آنها را در مکانهای مناسبی در صفحه قرار میدهد، نگاه کرد.
نتیجه استفاده از این الگو، ایزوله سازی سه جزء یاد شده از یکدیگر است. برای مثال View نمیداند و نیازی ندارد که بداند چگونه باید از لایه دسترسی به اطلاعات کوئری بگیرد. یا برای مثال کنترلر نیازی ندارد بداند که چگونه و در کجا باید خطایی را با رنگی مشخص نمایش دهد. به این ترتیب انجام تغییرات در لایه رابط کاربری برنامه در طول توسعه کلی سیستم، سادهتر خواهد شد.
همچنین در اینجا باید اشاره کرد که این الگو مشخص نمیکند که از چه نوع فناوری دسترسی به اطلاعاتی باید استفاده شود. میتوان از بانکهای اطلاعاتی، وب سرویسها، صفها و یا هر نوع دیگری از اطلاعات استفاده کرد. به علاوه در اینجا در مورد نحوه طراحی Model نیز قیدی قرار داده نشده است. این الگو تنها جهت ساخت بهتر و اصولی «رابط کاربری» طراحی شده است و بس.
تفاوت مهم پردازشی ASP.NET MVC با ASP.NET Web forms
اگر پیشتر با ASP.NET Web forms کار کرده باشید اکنون شاید این سؤال برایتان وجود داشته باشد که این سیستم جدید در مقایسه با نمونه قبلی، چگونه درخواستها را پردازش میکند.
همانطور که مشاهده میکنید، در وب فرمها زمانیکه درخواستی دریافت میشود، این درخواست به یک فایل موجود در سیستم مثلا default.aspx ارسال میگردد. سپس ASP.NET یک کلاس وهله سازی شده معرف آن صفحه را ایجاد کرده و آنرا اجرا میکند. در اینجا چرخه طول عمر صفحه مانند page_load و غیره رخ خواهد داد. جهت انجام این وهله سازی، View به فایل code behind خود گره خورده است و جدا سازی خاصی بین این دو وجود ندارد. منطق صفحه به markup آن که معادل است با یک فایل فیزیکی بر روی سیستم، کاملا مقید است. در ادامه، این پردازش صورت گرفته و HTML نهایی تولیدی به مرورگر کاربر ارسال خواهد شد.
در ASP.NET MVC این نحوه پردازش تغییر کرده است. در اینجا ابتدا درخواست رسیده به یک کنترلر هدایت میشود و این کنترلر چیزی نیست جز یک کلاس مجزا و مستقل از هر نوع فایل ASPX ایی در سیستم. سپس این کنترلر کار پردازش درخواست رسیده را شروع کرده، اطلاعات مورد نیاز را جمع آوری و سپس به View ایی که انتخاب میکند، جهت نمایش نهایی ارسال خواهد کرد. در اینجا View این اطلاعات را دریافت کرده و نهایتا در اختیار کاربر قرار خواهد داد.
آشنایی با قرارداد یافتن کنترلرهای مرتبط
تا اینجا دریافتیم که نحوه پردازش درخواستها در ASP.NET MVC بر مبنای کلاسها و متدها است و نه بر مبنای فایلهای فیزیکی موجود در سیستم. اگر درخواستی به سیستم ارسال میشود، در ابتدا، این درخواست جهت پردازش، به یک متد عمومی موجود در یک کلاس کنترلر هدایت خواهد شد و نه به یک فایل فیزیکی ASPX (برخلاف وب فرمها).
همانطور که در تصویر مشاهده میکنید، در ابتدای پردازش یک درخواست، آدرسی به سیستم ارسال خواهد شد. بر مبنای این آدرس، نام کنترلر که در اینجا زیر آن خط قرمز کشیده شده است، استخراج میگردد (برای مثال در اینجا نام این کنترلرProducts است). سپس فریم ورک به دنبال کلاس این کنترلر خواهد گشت. اگر آنرا در اسمبلی پروژه بیابد، از آن خواهد خواست تا درخواست رسیده را پردازش کند؛ در غیراینصورت پیغام 404 یا یافت نشد، به کاربر نمایش داده میشود.
اما فریم ورک چگونه این کلاس کنترلر درخواستی را پیدا میکند؟
در زمان اجرا، اسمبلی اصلی پروژه به همراه تمام اسمبلیهایی که به آن ارجاعی دارند جهت یافتن کلاسی با این مشخصات اسکن خواهند شد:
1- این کلاس باید عمومی باشد.
2- این کلاس نباید abstract باشد (تا بتوان آنرا به صورت خودکار وهله سازی کرد).
3- این کلاس باید اینترفیس استاندارد IController را پیاده سازی کرده باشد.
4- و نام آن باید مختوم به کلمه Controller باشد (همان مبحث Convention over configuration یا کار کردن با یک سری قرار داد از پیش تعیین شده).
برای مثال در اینجا فریم ورک به دنبال کلاسی به نام ProductsController خواهد گشت.
شاید تعدادی از برنامه نویسهای ASP.NET MVC تصور کنند که فریم ورک در پوشهی استانداردی به نام Controllers به دنبال این کلاس خواهد گشت؛ اما در عمل زمانیکه برنامه کامپایل میشود، پوشهای در این اسمبلی وجود نخواهد داشت و همه چیز از طریق Reflection مدیریت خواهد شد.
نظرات مطالب
سفارشی کردن صفحه بندی WebGrid در ASP.NET MVC
باتشکر.زمانی که از این روش به صورت Ajax ای استفاده میکنم آدرسهای تولید شده صفحه بندی بدین شکل تولید میشود :
که بر روی عملکرد دکمههای ویرایش و حذف تاثیر میگذاره و عملکردآنها غیر فعال میشود
href="/AreaName/CoontrollerName/ActionName?page=2&__swhg=1516731566998"
نظرات مطالب
Highlight کردن لینک صفحه جاری در ASP.NET MVC
یک نکتهی تکمیلی: برای Highlight کردن لینک صفحه جاری در بوت استرپ 3
$(document).ready(function () { $('ul.nav.navbar-nav, ul.list-group, ul.nav.nav-tabs').find('a[href="' + location.pathname + '"]') .closest('li') .addClass('active'); });
نظرات مطالب
مروری بر قابلیت جدید ASP.NET FriendlyUrls
من این رو اجرا میکنم توی صفحه ای به اسم viewSwitcher ارور میده
مشکلش چیه؟
هیچ کدوم از کلمات این خط رو نمیشناسه
<%: CurrentView %> view | <a href="<%: SwitchUrl %>" data-ajax="false">Switch to <%: AlternateView %></a>
حرف شما صحیحه.
فقط چند نکته:
من با اجازه خودتون یه سری آزمایش انجام دادم.
اول یه فابل رو به برنامه دادم تا پردازش کنه (نتایج A)
سپس همون فایل رو با یه برنامه پردازش صوت (Adobe Audition CS5.5) پردازش کردم (فقط از فیلتر Normalizer استفاده کردم تا سطح صدا بهتر بشه) جالب اینه که نتیجه (در حد 3-4 کلمه در - هر30-40 ثانیه) بهتر شد.
یه بار دیگه با استفاده از امکان Settings موجود در Windows Media Player Play Speed فایل رو کش آوردم (از نظر زمانی) بازهم نتایج عوض شد.
در صورت 0.8 (البته مطمئنا این عدد برای موارد مختلف متفاوت خواهد بود) نتیجه خارق العاده بود. تقریبا در 30 ثانیه 3-4 اشتباه داشت. (نسبت به 10-12 اشتباه).
قطعا شخص من کسی نیست که بتونه با شما در یک پروژه همکاری کنه، ولی به عنوان یه پیشنهاد فکر می کنم که اگه بتونید اطلاعات ورودی (فایل صوتی) رو با چند حالت پردازش کنید (سرعت بالاتر، پایینتر، نرمالایز شده و ...) فکر میکنم با فیوژه نتایج با هم میشه عدد 60 درصد رو به مقداری بالاتر رسوند.
ناگفته نمونه که فایل من لهجه US بود.
فقط چند نکته:
من با اجازه خودتون یه سری آزمایش انجام دادم.
اول یه فابل رو به برنامه دادم تا پردازش کنه (نتایج A)
سپس همون فایل رو با یه برنامه پردازش صوت (Adobe Audition CS5.5) پردازش کردم (فقط از فیلتر Normalizer استفاده کردم تا سطح صدا بهتر بشه) جالب اینه که نتیجه (در حد 3-4 کلمه در - هر30-40 ثانیه) بهتر شد.
یه بار دیگه با استفاده از امکان Settings موجود در Windows Media Player Play Speed فایل رو کش آوردم (از نظر زمانی) بازهم نتایج عوض شد.
در صورت 0.8 (البته مطمئنا این عدد برای موارد مختلف متفاوت خواهد بود) نتیجه خارق العاده بود. تقریبا در 30 ثانیه 3-4 اشتباه داشت. (نسبت به 10-12 اشتباه).
قطعا شخص من کسی نیست که بتونه با شما در یک پروژه همکاری کنه، ولی به عنوان یه پیشنهاد فکر می کنم که اگه بتونید اطلاعات ورودی (فایل صوتی) رو با چند حالت پردازش کنید (سرعت بالاتر، پایینتر، نرمالایز شده و ...) فکر میکنم با فیوژه نتایج با هم میشه عدد 60 درصد رو به مقداری بالاتر رسوند.
ناگفته نمونه که فایل من لهجه US بود.