- در مورد اینکه چه استثناهایی باید مدیریت شوند یا خیر، مطلب «نکات کار با استثناءها در دات نت» را مطالعه کنید.
- علت عمل نکردن فیلتری که به آن لینک دادید (که من با آن موافق نیستم)، این است که دیگر نباید از میانافزار مدیریت استثناهای مخصوص توسعه دهندههای ASP.NET Core در این حالت استفاده کنید، چون با آن تداخل میکند و پیش از آن وارد عمل میشود. علت دریافت صفحهی HTML ایی که مشاهده میکنید، همین مورد است. این صفحه برای برنامههای ASP.NET Core دارای Viewهای Razor طراحی شدهاست و نه مخصوص حالت کار صرفا Web API آن.
- یکی از مشکلات آن فیلتر هم این است که به هیچ عنوان نباید اصل خطای رخدادهی در سمت سرور را به سمت کلاینت ارسال کرد و به کاربر نمایش داد. این مورد امکان دیباگ از راه دور برنامهی شما را توسط یک مهاجم سهولت میبخشد و از دیدگاه امنیتی اشتباه است. این موارد را فقط باید توسط امکانات Logging توکار ASP.NET Core ثبت و در سمت سرور با «دسترسی ادمین» بررسی کنید. کاربر هم فقط باید جملهی کلی «خطایی رخ دادهاست» را مشاهده کند و نه جزئیات آنرا.
- علت عمل نکردن فیلتری که به آن لینک دادید (که من با آن موافق نیستم)، این است که دیگر نباید از میانافزار مدیریت استثناهای مخصوص توسعه دهندههای ASP.NET Core در این حالت استفاده کنید، چون با آن تداخل میکند و پیش از آن وارد عمل میشود. علت دریافت صفحهی HTML ایی که مشاهده میکنید، همین مورد است. این صفحه برای برنامههای ASP.NET Core دارای Viewهای Razor طراحی شدهاست و نه مخصوص حالت کار صرفا Web API آن.
- یکی از مشکلات آن فیلتر هم این است که به هیچ عنوان نباید اصل خطای رخدادهی در سمت سرور را به سمت کلاینت ارسال کرد و به کاربر نمایش داد. این مورد امکان دیباگ از راه دور برنامهی شما را توسط یک مهاجم سهولت میبخشد و از دیدگاه امنیتی اشتباه است. این موارد را فقط باید توسط امکانات Logging توکار ASP.NET Core ثبت و در سمت سرور با «دسترسی ادمین» بررسی کنید. کاربر هم فقط باید جملهی کلی «خطایی رخ دادهاست» را مشاهده کند و نه جزئیات آنرا.