Activities of "hra"

Hi @hra

Thanks. Is it possible for you to create an issue on https://github.com/aspnetzero/aspnet-zero-core ? We can re-evaluate this.

Thanks, done: https://github.com/aspnetzero/aspnet-zero-core/issues/5084

Thanks @ismcagdas,

Just to be clear - please note that I changed my example to return a POCO instead of IActionResult - just to prove it actually makes no difference what the return type is - the problem remains.

Thanks for helping out here. What I am concerned about, is that while I've been building our product on ANZ, I have inadvertently caused the authentication behavior to deviate between ControllerBase and ApplicationServer. If you find that baseline ANZ correctly returns HTTP 402 for both ControllerBase and ApplicationService, then I'm going to need to figure out how I've broken it. If, however, you find that ControllerBase fails to return the same HTTP error code as an ApplicationService, when you have an invalid token - then I guess we can work together to fix both our code bases.

Of course, I'm quietly rooting for the latter :)

Note: A real easy way to test this without mucking around with tokens, is in ProductJwtSecurityTokenHandler.cs on line 45, simply throw exception.

Hi - thanks for the quick response,

Please note that my "hack" was just one way to reproduce this behavior. It could have just as easily occurred by a user account becoming unavailable (deletion?) during token refresh - or possibly there is another way for the user to not be found - the original author of TokenAuthController appears to have thought so when they wrote it.

Here's my thinking...

• whomever wrote TokenAuthController.Refresh was clearly intending to handle the case where a user could not be found for the user-id claim - because they are testing for "user == null"
• when "user == null" they are throwing a UserFriendlyException - which is great - it provides some insight to the end user - instead of just HTTP500.
• unfortunately, the code checking for null being returned from GetUserAsync will never evaluate to true - because GetUserAsync cannot return null (it throws an exception internally if null is detected).
• the ACTUAL result of a user not being found, is GetUserAsync throws an Exception, which is caught by the Refresh method catch-all handler, which then rethrows as a ValidationException, which then gets mapped to HTTP500 - a very unhelpful error.

Hopefully I've described my thinking clearly - I agree with the original intent of the code, to deliver useful information about the user not being found, to the end user - however the way it's implemented prevents that intent from being realised - with code that can never be reached by the instruction pointer...

Thanks @ismcagdas

Hi,

Does it make any difference if you use AbpAuthorize instead of AbpMvcAuthorize ?

No difference. Incidentally, I did originally use AbpAuthorize, I only recently switched it to AbpMvcAuthorize while I was trying to overcome this issue.

What is your answer to

1. I am expecting that an expired token should trigger the same HTTP result code (401) if the client is calling a ControllerBase method, or an ApplicationService method. Currently that is not the case. Should I be expecting that?

Hi @ismcagdas,

The authorization filter never fires if I'm calling a ControllerBase method with an expired token - neither my customised one you recommended, nor the built-in ABP one - which is not surprising, because this specifically relates to an expired token that is being passed - so the MS auth middleware would be rejecting the request pretty early.

Calling an ApplicationService function with an expired token DOES execute the authorization filter however.

So, clearly the logic of the Authorization Filter is not the cause, because it never gets a chance to run.

When I disable the below code - the auth filter does fire, and I get the correct result back - but I already knew that. The "UseStatusCodePages" middleware appears to be the cause - but I didnt add that - it's part of ANZ.

            app.UseStatusCodePagesWithRedirects("~/Error?statusCode={0}");

So, a couple of core questions

1. I am expecting that an expired token should trigger the same HTTP result code (401) if the client is calling a ControllerBase method, or an ApplicationService method. Currently that is not the case. Should I be expecting that?
2. Assuming it IS a bug - where to from here. Clearly, the authorizationfilter log is good, because when it runs I get the correct result, when it never fires I get a bad result.

Thanks!

Hi, I get a failure with this example

namespace HRA.Portal.Web.Controllers
{
    [AbpMvcAuthorize]
    [Route("Sync/[action]")]
    [DisableAuditing]
    public class SyncController : PortalControllerBase
    {
        public SyncController()
        {
        }

        [HttpPost]
        public Task<MyResult> UploadFile()
        {
            return Task.FromResult(new MyResult());
        }
    }

    public class MyResult
    {

    }
}

Thanks @ismcagdas,

feature request created here: https://github.com/aspnetboilerplate/aspnetboilerplate/issues/6691

Hi @simplexsrl,

Did you get any traction on this? I find myself in the same position - because Flaticons.com generates a CSS which is hardcoded to the namespace "flaticon-", adding a second collection to the application causes a namespace conflict. Obviously this can be resolved by manually editing the CSS generating by Flaticons.com to change the namespace, however avoiding thi manual step would be preferable.

I have contact Keenthemes, awaiting their response also.

Thanks,

Hi @edarib - thanks, I'm clear on that much. It seems to me there is zero functional purpose of this role existing, out of the box - beyond demonstration.

I simply wish to confirm that point. Perhaps a question for the vendor to confirm.

Thanks,

Thanks @ismcagdas, I have done so here: https://github.com/aspnetzero/aspnet-zero-core/issues/4644