فعالسازی GitHub Action مخصوص NET Core.
در ادامه قصد داریم از این قابلیت جدید، جهت Build خودکار پروژههای NET Core. و در آخر ارسال خودکار بستههای نیوگت متناظر آنها به سایت nuget.org، استفاده کنیم. برای این منظور به برگهی Actions مخزن کد خود مراجعه کنید (تصویر فوق). سپس در این صفحه، بر روی لینک Work flows for … more کلیک کنید:
تا امکان انتخاب گردش کاری متناظر با NET Core. ظاهر شود:
در اینجا بر روی دکمهی «Set up this workflow» کلیک کنید تا صفحهی ویرایشی این گردش کاری که با فرمت yml است، ظاهر شود.
محتویات آنرا برای نمونه میتوانید به صورت زیر تغییر دهید:
name: .NET Core Build on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Setup .NET Core uses: actions/setup-dotnet@v1 with: dotnet-version: 3.0.100-preview9-014004 - name: Build DNTCaptcha.Core lib run: dotnet build ./src/DNTCaptcha.Core/DNTCaptcha.Core.csproj --configuration Release
پس از تکمیل محتوای فایل yml در این مرحله، در کنار صفحه بر روی لینک start commit کلیک کنید، تا این فایل را به صورت خودکار در مسیر github\workflows\aspnetcore.yml ذخیره کند. بدیهی است تغییرات آنرا در قسمت commits مخزن کد نیز میتوانید مشاهده کنید.
این فایل on: [push] کار میکند. یعنی اگر تغییری را به مخزن کد اعمال کردید، همانند یک تریگر عمل کرده و عملیات Build را به صورت خودکار آغاز میکند.
اضافه کردن نماد گردش کاری GitHub به پروژه
هر گردش کاری تعریف شده را میتوان با یک نماد یا badge در فایل readme.md پروژه نیز نمایش داد:
فرمول آن نیز به صورت زیر است:
https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg
![Github tags](https://github.com/VahidN/DNTCaptcha.Core/workflows/.NET%20Core%20Build/badge.svg)
تکمیل گردش کاری Build، جهت تولید خودکار و ارسال یک بستهی نیوگت
برای ارسال خودکار حاصل Build به سایت نیوگت، نیاز است یک API Key داشته باشیم. به همین جهت به صفحهی مخصوص آن در سایت nuget پس از ورود به سایت آن، مراجعه کرده و یک کلید API جدید را صرفا برای این پروژه تولید کنید (در قسمت Available Packages بستهی پیشینی را که دستی آپلود کرده بودید انتخاب کنید).
پس از کپی کردن کلید تولید شدهی در سایت nuget:
به قسمت settings -> secrets مخزن کد خود مراجعه کرده و این کلید را به صورت زیر وارد کنید:
در ادامه برای دسترسی به این کلید با نام NUGET_API_KEY، میتوان از روش {{ secrets.NUGET_API_KEY }}$ در اسکریپت گردش کاری استفاده کرد.
اکنون که مخزن کد به همراه کلید API نیوگت است، میتوان مراحل dotnet pack (برای تولید فایل nupkg) و سپس dotnet nuget push (برای انتشار خودکار فایل nupkg) را به صورت زیر، به گردش کاری خود اضافه نمود:
name: .NET Core Build on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Setup .NET Core uses: actions/setup-dotnet@v1 with: dotnet-version: 3.0.100-preview9-014004 - name: Build DNTCaptcha.Core lib run: dotnet build ./src/DNTCaptcha.Core/DNTCaptcha.Core.csproj --configuration Release - name: Build NuGet Package run: dotnet pack ./src/DNTCaptcha.Core/DNTCaptcha.Core.csproj --configuration Release - name: Deploy NuGet Package run: dotnet nuget push ./src/DNTCaptcha.Core/bin/Release/*.nupkg -k ${{ secrets.NUGET_API_KEY }} -s https://api.nuget.org/v3/index.json
ارتباطات بلادرنگ و SignalR
در اینجا کلمه بلادرنگ به معنای ارسال اطلاعات از طرف سرور به کلاینتها با فاصله زمانی بسیار کوتاهی از به روز رسانی اطلاعات صورت گرفته در سمت سرور است.
نمونهای از این برنامهها شامل موارد ذیل هستند:
- اطلاع رسانی همزمان به گروهی از کاربران
- جستجوهای زنده و به روز رسانیهایی از این دست
- نمایش بلادرنگ قیمتها و وضعیت تجاری محصولات و سهامها
- بازیهای تعاملی
- برنامههای گروهی و تعاملی (مانند برنامههای Chat)
- برنامههای شبکههای اجتماعی (برای مثال پیام جدیدی دارید؛ شخص خاصی آنلاین یا آفلاین شد و امثال آن)
بنابراین به صورت خلاصه قصد داریم به ارائه بازخوردها و اطلاع رسانیهای بلادرنگ یا نسبتا سریع و به روز از سمت سرور به کلاینتها برسیم.
برای مثال یک دیتاگرید را درنظر بگیرید. دو کاربر در شبکه صفحه یکسانی را گشودهاند و یکی از آنها مشغول به ویرایش و یا حذف اطلاعات است. در ارتباطات بلادرنگ کاربر یا کاربران دیگر نیز باید (یا بهتر است) در زمانیکه گرید یکسانی را گشودهاند، بلافاصله آخرین تغییرات را ملاحظه کنند. یا حتی حالتی را درنظر بگیرید که شخصی SQL Server management studio را گشوده و در آنجا مشغول به تغییر اطلاعات گردیده است. در این حالت نیز بهتر است آخرین تغییرات بلافاصله به اطلاع کاربران رسانده شوند.
معرفی الگوی Push service
البته باید دقت داشت که الگوی push service یک الگوی رسمی ذکر شده در گروههای مرسوم الگوهای طراحی نیست، اما مفهوم آن سرویسی است که چندین کار ذیل را انجام میدهد:
الف) پذیرش اتصالات از چندین مصرف کننده. مصرف کنندهها در اینجا الزاما محدود به کلاینتهای وب یا دسکتاپ نیستند؛ میتوانند حتی یک سرور یا سرویس دیگر نیز باشند.
ب) قادر است اطلاعات را به مصرف کنندههای خود ارسال کند. این سرویس میتواند یک برنامه ASP.NET باشد یا حتی یک سرویس متداول ویندوز.
ج) در اینجا چندین منبع خارجی مانند یک بانک اطلاعاتی یا تغییرات رخ داده توسط یک سخت افزار که میتوانند سبب بروز رخدادهایی در push service گردند نیز میتواند وجود داشته باشند. هر زمان که تغییری در این منابع خارجی رخ دهد، مایل هستیم تا مصرف کنندهها را مطلع سازیم.
پروتکل HTTP و ارتباطات بلادرنگ
پروتکلی که در ارتباطات بلادرنگ مبتنی بر SignalR مورد استفاده قرار میگیرد، HTTP است و از قابلیتهای Request و Response آن در اینجا بیشترین بهره برده میشود. پیاده سازی Push عموما بر مبنای یکی از روشهای متداول زیر است:
1) Periodic polling
به این معنا که مثلا هر 10 ثانیه یکبار، کاری را انجام بده؛ مانند ارسال متناوب: آیا تغییری رخ داده؟ آیا تغییری رخ داده؟ و .... به همین ترتیب. این روش اصلا بهینه نبوده و منابع زیادی را خصوصا در سمت سرور مصرف خواهد کرد. برای مثال:
function getInfo() { $.ajax("url", function ( newInfo){ if ( newInfo != null) { // do something with the data } }); // poll again after 20 seconds setTimeout(getInfo,20000); } // start the polling loop getInfo();
2) Long polling
به آن HTTP Streaming یا Comet هم گفته میشود. این روش نسبتا هوشمند بوده و کلاینت اتصالی را به سرور برقرار خواهد کرد. سرور در این حالت تا زمانیکه اطلاعاتی را در دسترس نداشته باشد، پاسخی نخواهد داد. برای نمونه:
function getNewInfo(){ $.ajax("url", function (newinfo) { // do something with the data // start the new request getNewINfo(); }); } // start the polling loop getNewInfo();
این روش نسبت به حالت Periodic polling بهینهتر است اما نیاز به اتصالات زیادی داشته و همچنین تردهای بسیاری را در سمت سرور به خود مشغول خواهد کرد.
3) Forever frame
فقط در IE پشتیبانی میشود. در این روش یک Iframe مخفی توسط مرورگر تشکیل شده و از طریق آن درخواستی به سرور ارسال میشود. سپس سرور متناوبا با تزریق اسکریپتهایی به این Iframe سبب فراخوانی مجدد وضعیت خود میگردد. در این روش نیز به ازای هر درخواست و پاسخ، ارتباطات گشوده و بسته خواهند شد.
4) Server Sent Events یا SSE
این مورد جزو استاندارد HTML5 است. در اینجا اتصالی برقرار شده و دادهها از طریق اتصالات HTTP منتقل میشوند.
var eventSrc = new EventSource("url"); // register event handler for the message eventSrc.addEventListener( "message",function (evt) { //process the data });
تنها تفاوت آن با حالت long polling در این است که پس از ارائه پاسخ به کلاینت، اتصال را قطع نمیکند. Long polling نیز اتصال را باز نگه میدارد، اما این اتصال را بلافاصله پس از ارائه پاسخ، میبندد.
5) Web sockets
Web sockets در سکوی کاری ویندوز، تنها در ویندوزهای 8، ویندوز سرور 2012 و دات نت 4 و نیم پشتیبانی میشود. هرچند این روش در حال حاضر به عنوان بهترین روش Push مطرح است اما به دلیل محدودیتی که یاد شد، مدتی طول خواهد کشید تا استفاده گستردهای پیدا کند.
var socket = new WebSocket("url"); socket.onmessage = function (msg) { var newInfo = msg.data; // do something with the data } // client can also send request to server socket.send(.... )
بلی. اگر به وضعیت فعلی سکوی کاری ASP.NET نگاه کنیم:
SignalR را میتوان مشاهده کرد که در گروه ساخت سرویسهای آن قرار گرفته است. همانطور که ملاحظه میکنید، این سرویس جدید آنچنان وابستگی به سایر اجزای آن نداشته و میتواند خارج از ASP.NET نیز مورد استفاده قرار گیرد.
SignalR چیست؟
SignalR راه حلی است سمت سرور برای نوشتن push services. همچنین به همراه کتابخانههای سمت کاربری است که ارتباطات push services را در انواع و اقسام سکوهای کاری میسر میسازد. SignalR سورس باز بوده و برای اعمال غیرهمزمان (asynchronous) بهینه سازی شده است.
SignalR بر اساس مدل ذهنی اتصالات ماندگار (persistent connections) طراحی شده است. اتصالات ماندگار را باید به عنوان اتصالاتی سریع و غیرطولانی درنظر گرفت. در اینجا Signal یک اتصال است که اطلاعاتی به آن ارسال میگردد و هدف، انتقال قطعات کوچکی از اطلاعات است و هدف، ارسال حجم عظیمی از اطلاعات نیست. برای مثال اطلاع رسانی سریعی صورت گیرد که تغییراتی رخ داده است و سپس ادامه کار و دریافت اطلاعات واقعی توسط فرآیندهای متداول مثلا HTTP GET انجام شود. البته باید دقت داشت SignalR نیز نهایتا از یکی از 5 روش push بررسی شده در این قسمت استفاده میکند. اما بر اساس تواناییهای کلاینت و سرور، به صورت هوشمند بهترین و بهینهترین انتخاب را به کاربر ارائه میدهد.
اتصالات ماندگار قسمت سطح پایین SignalR را تشکیل میدهند. سطح بالاتر آن که این مفاهیم را به شکلی کپسوله شده ارائه میدهد، Hubs نام دارد که پایه اصلی دوره جاری را تشکیل خواهد داد.
همانطور که عنوان شد، SignalR سورس باز بوده و دارای مخزن کدی عمومی در GitHub است. همچنین بستههای تشکیل دهندهی آن از طریق NuGet نیز قابل دریافت هستند. این بستهها شامل هسته SignalR و کلاینتهای آن مانند کلاینتهای WinRT، سیلورلایت، jQuery، ویندوز فون8 و امثال آن هستند.
شروع کار با SignalR
تیم SignalR مثالی مقدماتی از نحوه کار با SignalR را به صورت یک بسته NuGet ارائه دادهاند که از طریق آدرس و فرمان ذیل قابل دریافت است:
PM> Install-Package Microsoft.AspNet.SignalR.Sample
پس از دریافت مثال، یکبار پروژه را کامپایل کرده و سپس بر روی فایل StockTicker.html آن کلیک راست نموده و گزینه مشاهده در مرورگر را انتخاب کنید. همچنین برای اینکه این مثال را بهتر مشاهده کنید، بهتر است دو وهله از مرورگر را باز کرده و آدرس باز شده را در آن بررسی کنید تا اعمال تغییرات همزمان به کلاینتهای متفاوت را بهتر بتوان بررسی و مشاهده کرد.
10 Points to Secure Your ASP.NET Core MVC Applications
Broken authentication and session management
Sensitive Data Exposure & Audit trail
Cross-Site Scripting (XSS) attacks
Malicious File Upload
Security Misconfiguration (Error Handling Must Setup Custom Error Page)
Version Discloser
Cross-Site Request Forgery (CSRF)
XML External Entities (XXE)
Insecure Deserialization
SQL Injection Attack
public class XamAppExceptionHandler : BitExceptionHandler { public override void OnExceptionReceived(Exception exp, IDictionary<string, string> properties = null) { #if DEBUG System.Diagnostics.Debugger.Break(); #endif base.OnExceptionReceived(exp, properties); } }
BitExceptionHandler.Current = new XamAppExceptionHandler();
حال برای لاگ کردن این خطاها، میتوانید از Microsoft's AppCenter استفاده کنید. استفاده از امکانات App Center رایگان بوده و برای استفادهی در ایران محدودیتی ندارد. ابتدا در سایت مربوطه ثبت نام کنید و سپس سه بار Add New app را بزنید و به نامهای XamApp_Windows، XamApp_iOS و XamApp_Android سه برنامه را بسازید و برای Android و iOS گزینهی Xamarin را انتخاب و برای ویندوز نیز UWP را انتخاب کنید.
سپس پکیجهای Microsoft.AppCenter.Crashes و Microsoft.AppCenter.Analytics را بر روی XamApp نصب نموده و کد زیر را در سه فایل AppDelegate.cs/MainActivity.cs/App.xaml.cs برای iOS/Android/Windows کپی کنید:
AppCenter.Start("copy-your-guid-key-for-iOS-Android-Windows-here", typeof(Crashes), typeof(Analytics));
برای هر یک از برنامههای Android/iOS/Windows یک Guid متفاوت دارید که در قسمت Getting Started در سایت App Center میتوانید آنها را مشاهده کنید. هر بار که این کد را کپی میکنید، مقدار Guid درست را بگذارید.
برای گزارش کردن خطاهای برنامه، کافی است کد زیر را به XamAppExceptionHandler.cs که در ابتدای این قسمت در موردش صحبت کرده بودیم اضافه کنید:
Crashes.TrackError(exp, properties);
حال اگر برنامه را اجرا و شروع به تست کنید و یا آن را در اختیار تسترها و مشتریها بگذارید، نه تنها گزارش تمامی خطاها و کرشها را خواهید داشت که حتی آمار استفاده کنندههای برنامه (شامل کشور و مشخصات دستگاه و ...) را نیز خواهید داشت.
حال در یک کد ده خطی، اگر در خط پنجم خطایی رخ دهد، اگر چه باعث بسته شدن برنامه نمیشود و لاگ نیز میشود، ولی در مواقعی خیلی خاص، شاید بخواهید در صورت رخ دادن خطا، چند خط کد بعدی کماکان اجرا شوند. در این حالت شما Try/Catch مینویسید که برای عبور کردن از خطا از آن استفاده کردهاید. در این صورت، ترجیحا آن را به شکل زیر بنویسید:
// code 1... try { // code 2... } catch (Exception ex) { BitExceptionHandler.Current.OnExceptionReceived(ex, new Dictionary<string, string> { { "SomeData", "2" } }); } // code 3...
در این کد مثال، فرض کنیم که برخی اوقات در code 2 خطایی رخ میدهد که برای ما مهم نیست و میخواهیم حتی در صورت رخ دادن خطا، code 3 اجرا شود. توصیه میکنیم در این موارد که در برنامه خیلی هم نباید متداول باشد، لااقل خطا را با کمک کد BitExceptionHandler.Current.OnExceptionReceived لاگ کنید و همچنین با داشتن یک Dictionary میتوانید حتی دیتای بیشتری را نیز به AppCenter فرستاده و در پرتال مربوطه مشاهده کنید.
به صورت کلی بهتر است از این نوع Try/Catchها پرهیز کنید و حتی اگر جایی Catch ای نوشتید، در نهایت دوباره خطا را throw کنید.
try { // some codes... } catch { // Do something related to exception... // for example, show some alerts to the user. throw; // You don't need to call BitExceptionHandler.Current.OnExceptionReceived... }
در مثال فوق، قصد داریم وقتی خطایی رخ داد، پیامی را به کاربر اطلاع دهیم. در این صورت، پس از نمایش پیام مربوطه، مجددا خطا را throw کنید. در این صورت، نیازی به فراخوانی BitExceptionHandler.Current.OnExceptionReceieved نیز نیست.
البته AppCenter در زمینه پابلیش کردن برنامه و همچنین Push Notification و ... نیز دارای امکاناتی هست که به موضوع این قسمت ارتباطی ندارند.
- XAML designer for UWP - control properties not displayed
- UWP XAML designer doesn't update elements on updating XAML code
- XAML properties and document structure
- Properties window not showing the properties when clicking an object
- Unable to see properties of any items
- Installation error when trying to connect to the Mac: "The Xamarin.iOS version installed on 'x' (12.8.0.2) is newer than your version".
- Fixed right click solution name in titlebar VS crash bug.
- Improved performance for customers with the Azure workload installed.
- Corrected errors during restore and build on SDK-based projects that use 3rd party SDKs to target UWP platforms.
- Fixed a bug in C# compiler where it was not properly warning customers about incomplete interface implementations.
- Improved error messaging in Visual Studio Tools for Kubernetes.
- Fixed error when adding a comment in PR for SymbolCheck.