Improper Authentication and Session Management
Most web applications have an authentication module, and we should be careful when writing code for it. We could make mistakes like not removing the authentication cookies after a successful logout. This kind of mistake allows attackers to steal user credentials such as cookies and session values, and may result in attackers being able to access the complete application and cause major negative impacts.
نحوه اضافه کردن چند پروژه در vs code
Visual Studio Code doesn't support solution files, whereas Visual Studio does. In Visual Studio we use solution files to link multiple projects together, and at first I thought that this was going to be a deal breaker for Visual Studio Code - but it's not at all. Many people aren't aware that Visual Studio Code, although lightweight, is a powerful editor that can do most of the things you need.
بهینه سازی ضروری تصاویر
We should all be automating our image compression.
In 2017, image optimization should be automated. It’s easy to forget, best practices change, and content that doesn’t go through a build pipeline can easily slip. To automate: Use imagemin or libvips for your build process. Many alternatives exist.
Most CDNs (e.g. Akamai) and third-party solutions like Cloudinary, imgix, Fastly’s Image Optimizer, Instart Logic’s SmartVision or ImageOptim API offer comprehensive automated image optimization solutions.
In this post, I want to compare “DNTFrameworkCore” with “ABP Framework”.
ABP is one of most popular and well documented frameworks with high level abstraction that I learned a lot from it. It has many other features that I don’t list them in this post, because, DNTFrameworkCore has not them actually. Behind of ABP, there is a team. It has 123 contributors in GitHub. Also, all of features have related unit-tests.
In other side, DNTFrameworkCore is lightweight with low level abstraction. It is personal open-source project without any contributor and has unit-tests for small part.
I wrote this post to prove that thinking behind of DNTFrameworkCore completely different from ABP (at least in most sections)
npm install @aspnet/signalr-client --save
بررسی محتوای پوشهی node_modules\@aspnet\signalr-client
پس از نصب بستهی «aspnet/signalr-client@»، در مسیر node_modules\@aspnet\signalr-client\dist دو پوشهی src و browser را خواهید یافت. پوشهی src حاوی منبع کامل این کلاینت و همچنین فایلهای Typings مخصوص تایپاسکریپت است.
و پوشهی browser آن شامل دو گروه فایل است:
- در اینجا گروهی از فایلها، حاوی عبارت ES5 هستند و تعدادی خیر. SignalR JavaScript بر اساس ES 6 یا EcmaScript 2015 تهیه شدهاست و از مفاهیمی مانند Promises و arrow functions استفاده میکند. باید دقت داشت که تعدادی از مرورگرها مانند IE از این قابلیتها پیشتیبانی نمیکنند. در بین این فایلها، آنهایی که حاوی عبارت ES5 نیستند، یعنی بر اساس ES 6 تهیه شدهاند. سایر فایلها توسط قابلیت Transpile مربوط به TypeScript به ES5 ترجمه شدهاند. به علاوه حجم این فایلها نیز بیشتر میباشد؛ چون حاوی تعاریف وابستگیهایی هستند که در ES 5 وجود خارجی ندارند. بنابراین بسته به نوع مرورگر مدنظر، یکی از این دو گروه را باید انتخاب کرد؛ ES 6 برای مرورگرهای جدید و ES 5 برای مرورگرهای قدیمی.
- به علاوه در اینجا تعدادی از فایلها حاوی عبارت msgpackprotocol هستند. نگارش جدید SignalR از پروتکلهای هاب سفارشی مانند پروتکلهای باینری نیز پشتیبانی میکند. همچنین حاوی یک پیاده سازی توکار از پروتکلهای باینری بر اساس MessagePack نیز هست. چون حجم کدهای پشتیبانی کنندهی از این پروتکل ویژه بالا است، آنرا به یک فایل مجزا انتقال دادهاند تا در صورت نیاز مورد استفاده قرار گیرد. بنابراین اگر از این پروتکل استفاده نمیکنید، نیازی هم به الحاق آن در صفحات خود نخواهید داشت. فایل third-party-notices.txt نیز مربوط است به یادآوری مجوز استفادهی از MessagePack که MIT میباشد.
- در هر گروه نیز، دو فایل min و معمولی قابل مشاهدهاست. فایلهای min برای توزیع نهایی مناسب هستند و فایلهای غیرفشرده شده برای حالت دیباگ.
استفاده از کلاینت جاوا اسکریپتی SignalR Core
برای کار با کلاینت جاوا اسکریپتی SignalR Core از همان فایلهای موجود در پوشهی node_modules/@aspnet/signalr-client/dist/browser استفاده میکنیم. تفاوت این کلاینت با نگارش قبلی SignalR به صورت یک ذیل است:
1) ارجاع به فایل قدیمی signalR-2.2.1.min.js با فایل جدید signalR-client-1.0.0-alpha1.js جایگزین میشود. اگر میخواهید مرورگرهای قدیمی را پشتیبانی کنید، نگارش ES5 آنرا لحاظ کنید.
2) پروکسیها با new HubConnection جایگزین شدهاند.
3) برای ثبت callbackهای سمت کلاینت، از متد جدید on استفاده میشود.
4) بجای متد done مربوط به jQuery، در اینجا از متد then مربوط به ES6 کمک گرفته شدهاست.
5) کار فراخوانی متدهای هاب توسط متد invoke انجام میشود.
یک مثال: بازنویسی قسمت سمت کلاینت مثال «کار با SignalR Core از طریق یک کلاینت Angular» با jQuery
هرچند کلاینت جدید SignalR Core وابستگی به jQuery ندارد، اما جهت سهولت کار با DOM، کدهای سمت کلاینت مثال قبلی را با jQuery بازنویسی میکنیم. تمام کدهای سمت سرور این مثال با مطلب «کار با SignalR Core از طریق یک کلاینت Angular» یکی است؛ مانند ایجاد هاب، فعالسازی SiganlR در فایل آغازین برنامه و ثبت مسیرهاب. بنابراین در اینجا، این قسمت از کدهای سمت سرور را مجددا تکرار نمیکنیم و تمام نکات آن یکی هستند.
برای کار با کلاینت جاوا اسکریپتی SignalR Core، اینبار دستور ذیل را در ریشهی پروژهی وب اجرا میکنیم (یا هر پروژهای که قرار است مدیریت فایلهای سمت کلاینت و Viewهای برنامه را انجام دهد):
npm init npm install @aspnet/signalr-client --save bower install
مرحلهی بعدی کار، تنظیمات فایل bundleconfig.json است؛ تا تمام اسکریپتهای مورد نیاز جمعآوری و یکی شوند:
[ { "outputFileName": "wwwroot/css/site.min.css", "inputFiles": [ "wwwroot/lib/bootstrap/dist/css/bootstrap.min.css", "wwwroot/css/site.css" ] }, { "outputFileName": "wwwroot/js/site.min.js", "inputFiles": [ "wwwroot/lib/jquery/dist/jquery.min.js", "wwwroot/lib/bootstrap/dist/js/bootstrap.min.js", "node_modules/@aspnet/signalr-client/dist/browser/signalr-client-1.0.0-alpha1-final.min.js", "wwwroot/lib/jquery-validation/dist/jquery.validate.min.js", "wwwroot/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js", "wwwroot/lib/jquery-ajax-unobtrusive/jquery.unobtrusive-ajax.min.js", "wwwroot/js/site.js" ], "minify": { "enabled": false, "renameLocals": false }, "sourceMap": false } ]
با توجه به خروجیهای نهایی فایل bundleconfig.json، تنها نیاز است مداخل ذیل را به فایل layout برنامه اضافه کرد:
<link href="~/css/site.min.css" rel="stylesheet" asp-append-version="true" /> <script src="~/js/site.min.js" type="text/javascript" asp-append-version="true"></script>
مرحلهی بعد، تغییر نام متد send قسمت قبل به broadcastMessage است:
public class MessageHub : Hub { public Task Send(string message) { return Clients.All.InvokeAsync("broadcastMessage", message); } }
در ادامه یک کنترلر ساده را به نام JsClientController با View ذیل ایجاد میکنیم:
<form method="post" asp-action="Index" asp-controller="Home" data-ajax="true" role="form"> <div class="form-group"> <label label-for="message">Message: </label> <input id="message" name="message" class="form-control"/> </div> <button class="btn btn-primary" type="submit">Send To Home/Index</button> <button class="btn btn-success" id="sendmessageDirect" type="button">Send To /message hub directly</button> </form> <div id="discussion"> </div>
از اولین دکمه برای ارسال یک پیام به کنترلر Home که در آن توسط <IHubContext<MessageHub پیامی به تمام کلاینتها ارسال میشود، استفاده شدهاست. دومین دکمه متد Send هاب را مستقیما فراخوانی میکند؛ با این کدهای سمت کلاینت:
@section Scripts { <script type="text/javascript" asp-append-version="true"> $(function() { var connection = new signalR.HubConnection('/message'); connection.on('broadcastMessage', function (message) { // Add the message to the page. var encodedMsg = $('<div />').text(message).html(); $('#discussion').append('<li>' + encodedMsg + '</li>'); }); connection.start().then(function () { console.log('connected.'); $('#sendmessageDirect').click(function () { // Call the Send method on the hub. connection.invoke('send', $('#message').val()); }); }); }); </script> }
- سپس در متد on هست که مشخص میکنیم متد سمت کلاینتی که قرار است از سمت سرور فراخوانی شود، چه نامی دارد. نام آنرا در این مثال broadcastMessage درنظر گرفتهایم. در اینجا پارامتر message از سمت سرور دریافت شده و سپس در صفحهی جاری نمایش داده میشود.
بدیهی است متد Send میتواند تعداد پارامترهای بیشتری را بپذیرد و همچنین متد broadcastMessage نیز محدودیتی از لحاظ تعداد پارامتر ندارد. اگر پارامترهای بیشتری را تعریف کردید، در همینجا باید قید شوند.
- در ادامه کار شروع این اتصال آغاز میشود. در متد then هست که باید کار اتصال دکمهی sendmessageDirect صورت گیرد. چون عملیات اتصال ممکن است زمانبر باشد و connection ارسالی هنوز آغاز نشده باشد. در اینجا نحوهی فراخوانی مستقیم متد Send سمت سرور را با یک پارامتر ملاحظه میکنید. این متد نیز میتواند بر اساس امضای متد Send سمت سرور، تعداد پارامترهای بیشتری را قبول کند.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: SignalRCore2WebApp02.zip
برای اجرا آن باید این دستورات را به ترتیب وارد کنید:
dotnet restore npm install npm install -g bower bower install dotnet watch run
در NET Core 2.0. از یک اصطلاحا «compatibility shim» مخصوص استفاده میشود که امکان افزودن ارجاعات به full framework libraryها را بدون نیاز به تغییر target framework برنامه میسر میکند. یعنی در اینجا میتوان یک کتابخانهی قدیمی دات نتی را در برنامههای مبتنی بر NET Core. بر روی لینوکس نیز اجرا کرد و در این حالت نیازی به تبدیل اجباری این کتابخانه به نسخهی NET Core. آن نیست.
NET Core 2.0. پیاده سازی کنندهی NET Standard 2.0. است
NET Standard. در حقیقت یک قرار داد است که سکوهای کاری مختلف دات نتی مانند Full .NET Framework ، Xamarin ، Mono ، UWP و غیره میتوانند آنرا پیاده سازی کنند. یک نمونهی دیگر این پیاده سازیها نیز NET Core. است. برای مثال دات نت 4.6.1، استاندارد و قرار داد شمارهی 2 دات نت را پیاده سازی میکند. به همین صورت NET Core 2.0. نیز پیاده سازی کنندهی این استاندارد شماره 2 است.
با تغییرات اخیر، اکنون NuGet میتواند کتابخانههای مبتنی بر NET Standard 2. را در برنامههای مبتنی بر سکوهای کاری که آنرا پیاده سازی میکنند، بدون مشکل اضافه کند. برای مثال میتوان اسمبلیهای دات نت 4.6.1 را به برنامههای ASP.NET Core 2.0 اضافه کرد (کاری که در نگارش 1x آن به صورت مستقیم میسر نیست) و یا میتوان اسمبلیهای کامپایل شدهی برای دات نت استاندارد 2 را به برنامههای مبتنی بر دات نت 4.6.1 اضافه کرد.
آیا واقعا کتابخانههای قدیمی دات نتی توسط برنامههای NET Core 2.0. در لینوکس نیز اجرا خواهند شد؟
دات نت استاندارد، بیش از یک قرار داد چیزی نیست و پیاده سازی کنندگان آن میتوانند سطح بیشتری را نسبت به این قرار داد نیز لحاظ کنند. برای مثال دات نت 4.6.1 شامل سطح API بیشتری از دات نت استاندارد 2 است.
به همین جهت باید درنظر داشت که امکان اضافه کردن یک بستهی نیوگت از یک کتابخانهی نوشته شدهی برای دات نت کامل در برنامههای دات نت Core به معنای تضمینی برای کار کردن آن در زمان اجرا نخواهد بود. از این جهت که دات نت کامل، به همراه قسمتهایی است که در NET Standard. وجود خارجی ندارند. بنابراین اگر کتابخانهی استفاده شده صرفا این API مشترک را هدف قرار دادهاست، هم قابلیت اتصال و هم قابلیت اجرا را خواهد داشت؛ اما اگر برای مثال کسی بستهی NServiceBus را به پروژهی ASP.NET Core 2.0 اضافه کند، بدون مشکل کامپایل خواهد شد. اما از آنجائیکه این کتابخانه از MSMQ استفاده میکند که خارج از میدان دید این استاندارد است، در زمان اجرا با شکست مواجه خواهد شد.
«compatibility shim» در NET Standard 2.0. چگونه کار میکند؟
در NET Core.، پیاده سازی Object در System.Runtime قرار دارد و کد تولید شدهی توسط آن یک چنین ارجاعی را [System.Runtime]System.Object تولید میکند. اما در دات نت کلاسیک، System.Object در mscorlib قرار دارد. به همین جهت زمانیکه سعی کنید اسمبلیهای دات نت کلاسیک را در NET Core 1.x. استفاده کنید، پیام یافتن نشدن نوعها را دریافت خواهید کرد. اما در NET Core 2.0. یک پیاده سازی صوری (facade) از mscorlib وجود دارد که کار آن هدایت نوع درخواستی، به نوع واقعی پیاده سازی شدهی در NET Core. است.
در این تصویر استفادهی از یک کتابخانهی ثالث را مشاهده میکنید که ارجاعی را به [mscorlib]Microsoft.Win32.RegistryKey دارد (مبتنی بر دات نت کلاسیک است). همچنین یک mscorlib مشخص شدهی به صورت facade را نیز مشاهده میکنید. کار آن هدایت درخواست نوع واقع شدهی در mscorlib، به نوع موجود [Microsoft.Win32.Registry] Microsoft.Win32.RegistryKey است و تنها زمانی کار خواهد کرد که Microsoft.Win32.RegistryKey.dll وجود خارجی داشته باشد. به این معنا که رجیستری، یک مفهوم ویندوزی است و این کتابخانه بر روی ویندوز بدون مشکل کار میکند. اما تحت لینوکس، این قسمت خاص با پیام PlatformNotSupportedException خاتمه خواهد یافت. اما اگر قسمتهایی از این کتابخانه را استفاده کنید که در تمام سکوهای کاری وجود داشته باشند، بدون مشکل قادر به استفادهی از آن خواهید بود.
یک مثال: استفاده از کتابخانهی رمزنگاری اطلاعات Inferno
آخرین نگارش کتابخانهی رمزنگاری اطلاعات Inferno مربوط به NET 4.5.2. است. مراحل ذیل را پس از نصب SDK جدید NET Core 2.0. در خط فرمان طی میکنیم:
الف) ایجاد پوشهی UseNET452InNetCore2 و سپس ایجاد یک پروژهی کنسول جدید
dotnet new console
ب) افزودن بستهی نیوگت Inferno به پروژه
dotnet add package Inferno
log : Installing Inferno 1.4.0. warn : Package 'Inferno 1.4.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project. info : Package 'Inferno' is compatible with all the specified frameworks in project 'D:\UseNET452InNetCore2\UseNET452InNetCore2.csproj'. info : PackageReference for package 'Inferno' version '1.4.0' added to file 'D:\UseNET452InNetCore2\UseNET452InNetCore2.csproj'.
ج) استفاده از کتابخانهی Inferno جهت تولید یک عدد تصادفی thread safe
using System; using SecurityDriven.Inferno; namespace UseNET452InNetCore2 { class Program { static CryptoRandom random = new CryptoRandom(); static void Main(string[] args) { Console.WriteLine($"rnd: {random.NextLong()}"); } } }
د) اجرای برنامه
در ادامه اگر دستور dotnet run را صادر کنیم، ابتدا اخطاری را صادر میکند که این بسته ممکن است دارای قسمتهایی باشد که با NET core 2.0. سازگار نیست و سپس خروجی نهایی را بدون مشکل اجرا کرده و نمایش میدهد.
>dotnet run warning NU1701: This package may not be fully compatible with your project. rnd: 8167886599578111106
معرفی NativeScript
ساخت برنامههای چند سکویی موبایل با JavaScript و TypeScript. مخرن کد آن و native بودن آن به معنای دسترسی کامل به Platform API مورد استفادهاست. مقالهای در مورد نحوهی استفاده از آن.