Base solution for your next web application
Open Closed

Disable all internal exception handling for custom API #6470


User avatar
0
deventerprise created

I need to be able to disable all the middleware for calls being made to a certain application service class.

The service is an API for a mobile application and constantly responds with a HTML page for 500 status errors. This includes bearer tokens expiring throwing 500's with socket exceptions and and repository validation errors also bubbling to the client as HTML pages with a 500 status. This makes it impossible to determine what a genuine server errors where it could simply be a 400 for bad input or a 401 for expired tokens etc.

Hoe do I stop all issues being a 500, and how to I stop a web API fom responding with an HTML page?


9 Answer(s)
  • User Avatar
    0
    ryancyq created
    Support Team

    Hi, what is your ANZ version? Angular or Jquery?

  • User Avatar
    0
    deventerprise created

    6.5.0 ASP.NET Core MVC with JQuery

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @deventerprise

    Could you share your AppService class ? Normally AppServices shouldn't return html response.

  • User Avatar
    0
    deventerprise created
    [DontWrapResult]
    public class MobileAppService : MyAppServiceBase, IMobileAppService
    {
      [AbpAuthorize]
      public async Task<MobileApiOutput> GetStuff()
      {
        // When the auth token has expired then it never gets here, so can't try/catch and wrap in custom MobileApiOutput.
      }
    
      [DisableValidation]
      [AbpAuthorize]
      public async Task<MobileApiOutput> PostStuff(MobileModel model)
      {
        // This try block is useless if anything happens in the middleware, you get an HTML "Internal Server Error" page instead.
        try
        {
          // Do stuff...     
          return new MobileApiOutput() { Success = true };
        }
        catch (UserFriendlyException ex)
        {
          return new MobileApiOutput() { Message = ex.Message, Success = false };
        }
    
        return new MobileApiOutput() { Message = L("AnErrorOccurred"), Success = false };
      }
    }
    

    I really just want to catch any internal errors (socket exception being caused by invalid tokens, auth failures etc) so that I can wrap with my own object. Is that not possible?

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @deventerprise

    When you use [DontWrapResult] ABP doesn't catch exceptions and leave it to ASP.NET. If you can share your solution via email or a reproduction project, we can work on it for you.

  • User Avatar
    0
    deventerprise created

    Not really prepared to share my client's IP to debug an issue. You can create an application service exactly as described and use an invalid bearer token or even a valid bearer token for a tenant that does not exist (throws and exception too in the middleware somewhere). Anything in the action pipeline that throws and exception seems to result in a 500 with a HTML response, this is very easy to test with PostMan.

    For now the mobile app detects the HTML response and parses out the exception... pretty nasty.

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @deventerprise

    Have you solved the problem ?

  • User Avatar
    0
    deventerprise created

    Unfortunately not, I still get HTML responses for unhandled exceptions. I simply wrap every mething in a try catch so I can provide my own wrapped response to the clients as I showed in the example.

  • User Avatar
    0
    ryancyq created
    Support Team

    Hi, did you use any custom status code page or exception handling mentioned (excep ExceptionFilter) in https://docs.microsoft.com/en-us/aspnet/core/fundamentals/error-handling ?

    There might be problem configuring the mvc to always show non html response.

    It is due to Api and Mvc controllers are the same type of controller in asp .net core.

    Wrapping all unexpected exception for mvc controllers to show custom error page might be good for the ux. However it might also wrap the api response when unexpected excpetion is thrown in api controller