Base solution for your next web application
Open Closed

v4.1.0: problem with authorisation #4937


User avatar
0
fabiovalerio created

Hi all, we currently use ANZ 4.1.0 to serve a WebAPI access to a 3d party. Sometimes, counterpart says that API calls go in HTTP 401. We checked JWT for validity with <a class="postlink" href="http://jwt.io">http://jwt.io</a> and all seems ok. What we noticed, is the authentication pass successfully but authorization (permissions) seems not correctly retrieved. Since counterpart can't implement a retry mechanism, we have to figure out how to solve this issue on our side. Thanks!


7 Answer(s)
  • User Avatar
    0
    aaron created
    Support Team

    You did not provide any information to work on. There does not seem to be any similar issues regarding permission retrieval. You should use the latest version of ABP (currently v3.5) and check that you assigned the correct permissions in your instance.

  • User Avatar
    0
    fabiovalerio created

    Hi @aaron, it is difficult to provide further info on that issue ... since it is related to an in-depth feature of ABP. BTW, following scenario could help you to understand the facts:

    1. A third party software, log in to our API obtaining a JWT
    2. Next, it uses that JWT to perform some operation against API.
    3. our AppService respond to a request at step 2 with a 401 error regardless missing permissions on that logged user

    What we noticed is that when this issue happening, Audit Log shows correctly it as a 401 error, but without showing username.

    We also tried to debugging some calls with JWT obtained at step 1, and it's correctly identified as authenticated by JwtTokenMiddleware, but when request is managed by AuthotizationFilter it goes in 401 due to - apparently - insufficient permission; but the user already have right permissions!

    Lastly, we also tried to perform another login just after the bad one, and all works perfectly!

    If we upgrade to ABP 3.5 ... we have to make some changes on ANZ 4.1?

  • User Avatar
    0
    aaron created
    Support Team

    If we upgrade to ABP 3.5 ... we have to make some changes on ANZ 4.1?

    Yes. You can check for Breaking Changes in ABP releases. You probably only need to upgrade SweetAlert to v2.0.8.

  • User Avatar
    0
    fabiovalerio created

    Hi aaron,

    I'm updating this thread only to inform that after upgraded to ABP 3.5, issue still present!

    Just for recap, we are encountering problem with ABP Authorizations against a custom AppService, used by a third party service.

    Even if the logged-in user has right permissions, sometimes WebApi Layer goes into 401 or simply reply with 200 but raising an Abp.Authorization.AbpAuthorizationException.

    Are there someone facing the same issue?

  • User Avatar
    0
    aaron created
    Support Team

    Can you reproduce that on a fresh project?

  • User Avatar
    0
    fabiovalerio created

    Hi aaron, thanks for your reply.

    We cannot reproduce issue in a systematic way ... it is happening sometimes ! More, we cannot reproduce issue with a fresh project, because the only way to test is with a huge traffic on API so ... in production environment.

    I think that, the best option we have, could be answer to this question: in which case ABP cannot recognise current user and their permission event if user is correctly authenticated with a well-formed JWT token?

    Please note that our solution is deployed in a IIS WebFarm with ARR and Load balancing. To ensure session persistence, we enabled RedisCache.

    Many thanks!

  • User Avatar
    0
    aaron created
    Support Team

    in which case ABP cannot recognise current user and their permission event if user is correctly authenticated with a well-formed JWT token?

    In no case, if user is correctly authenticated with a well-formed JWT token.