Base solution for your next web application

Activities of "fabiovalerio"

Hi @ismcagdas, I just copied it and replaced what affecting to my plugin namespaces and classes. More, I put my TestModule under Dependency with the auto-generated ANZ TestModule

I made a PR that implements a more simple way to accomplish thoose needs. Please take a look at https://github.com/aspnetboilerplate/aspnetboilerplate/pull/5613

Hi @mailming,

I'm on .net core version.

Thanks for your reply! What you suggest, is to make a custom Hub inherting OnlineClientHubBase! It is correct, but is what I don't like to do, because it constraints me to reference my own dll inside Web.Host project to map the custom hub.

I'd like to maintain my customized logic inside a Plugin, and load it dynamically with ABP plugin system!

My question was if there are any automatic ways to populate OnlineClient.Properties from Querystring!

If not, I will open a feature request on GitHub, or better, make a PR with this implementation :D

no Ideas?

Hi @maliming, thanks for your reply.

Not only returning true was the fix, either replacing NativeMessageHandler with HttpClientHandler was the real trick!

Maybe ModernHttpClient's class implementation avoid calling ServerCertificateCustomValidationCallback!

If there are no controindications, I suggest to apply this fix in the ANZ codebase!

As Workaround I edited ModernHttpClientFactory.cs as following:

 
         public override HttpMessageHandler CreateMessageHandler()
         {
-            return new AuthenticationHttpHandler(new NativeMessageHandler
+            return new AuthenticationHttpHandler(new HttpClientHandler
             {
-                AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
+                AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate,
+                ServerCertificateCustomValidationCallback = (message, cert, chain, errors) =>
+                {
+                    if (cert.Issuer.Equals("CN=localhost"))
+                        return true;
+                    return errors == System.Net.Security.SslPolicyErrors.None;
+                }
             })
             {
                 OnSessionTimeOut = OnSessionTimeOut,
``

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!

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?

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?

Hi guys... I just did a retry to @ismcagdas's suggestion... and all works like a charm!

Maybe when I did try for the first time something was wrong in my implementation.

Thank you @ismcagdas and @aaron too!

Showing 1 to 10 of 21 entries