Activities of "richardghubert"

Hi, here is a FAQ regarding the new AspNetZero on .NET-Core-3.1 (great! we us it.).

https://aspnetboilerplate.com/Pages/Documents/v1.0.0.0/Dependency-Injection#asp-net-core-integration

ASP.NET Core Integration ASP.NET Core has already a built-in dependency injection system with Microsoft.Extensions.DependencyInjection package. ABP uses Castle.Windsor.MsDependencyInjection package to integrate it's dependency injection system with ASP.NET Core's. So, you don't have to think about it.

What are the caveats or plans here, since Windsor does not appear in the list of "supported" .NET-Core-3 IoC containers:

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.1#default-service-container-replacement

Thanks for any infos/futures.

Sincere thanks. We'll take a look and reopen if necessary. Best!

Ping ? :-) Thanks for any help on this.

Hello, We have a problem resetting Features (_tenantManager.ResetAllFeaturesAsync) for a Tenant (Edition is irrelevant here). We are using AspNetZero v6.5.0 .NET-Core 2.2 AspNet-Core MVC & JQuery (see below)

1. In the first case (see code example below and attached image V1) we Add a feature to the TenantID=1 get the expected result: the new value appears in the DB for TenantID=1 (no Edition associated). Method ChangeEditionV1 activates feature e521b74b-359a-4cd2-b3d7-0eb4034c0483. After method is executed the feature is available in database (ChangeEditionV1.PNG image).
2. In the second case we set (Add) two features to TenantID=1 and get an unexpected result: only the first of the two features appears correctly in the DB, the second one is “lost”. Method ChangeEditionV2 attempts to activate 2 features: 4b657e3a-9b27-4a32-874b-c72fc610fd01 and e521b74b-359a-4cd2-b3d7-0eb4034c0483. After execution of ChangeEditionV2 method, only one of these feature (4b657e3a-9b27-4a32-874b-c72fc610fd01) is seen in the DB (ChangeEditionV2.PNG image)

EXAMPLES:

// Case 1. Image V1. // This example works. Expected result. See attached Image V1. // [UnitOfWork] public async Task ChangeEditionV1() { try { List featuresData = new List(); // valid feature

featuresData.Add(new NameValue() { Name = "e521b74b-359a-4cd2-b3d7-0eb4034c0483", Value = "true" });

Tenant tenant = await _tenantManager.GetByIdAsync(1); if (tenant == null) throw new UserFriendlyException("Tenant does not exist!?");

await _tenantManager.ResetAllFeaturesAsync(1); // valid edition tenant.EditionId = 10; await _tenantManager.SetFeatureValuesAsync(1, featuresData.ToArray()); } catch(Exception ex) { throw new UserFriendlyException("Error: " + ex.Message); } }

=========================== // Case 2, Image V2. // This example does not work: only one of the two features appears in the DB. The second one is “lost in space”. Why? // [UnitOfWork] public async Task ChangeEditionV2() { try { List`` featuresData = new List``();

<br> // valid features featuresData.Add(new NameValue() { Name = "4b657e3a-9b27-4a32-874b-c72fc610fd01", Value = "true" }); featuresData.Add(new NameValue() { Name = "e521b74b-359a-4cd2-b3d7-0eb4034c0483", Value = "true" });

Tenant tenant = await _tenantManager.GetByIdAsync(1); if (tenant == null) throw new UserFriendlyException("Tenant does not exist!?");

await _tenantManager.ResetAllFeaturesAsync(1); // valid edition tenant.EditionId = 10; await _tenantManager.SetFeatureValuesAsync(1, featuresData.ToArray()); } catch (Exception ex) { throw new UserFriendlyException("Error: " + ex.Message); } }

IMAGE V1: Works.

<br> IMAGE V2: Does Not Work

Thanks, yes, this will save me some head-scratching time since I was still investigating code and documents to figure a way. So, correct me if I'm wrong: in the end, any Complex-Type that needs to be code-first (EF-Core) persistent must inherit from at compile time from the IEntity and be compiled into Abp to be "wired properly" for persistence. I'm still not sure why this is a do-or-die constraint, still ruminating on that!

Thanks,

Actually it is our own set of POCOs that are C# classes based on https://github.com/protobuf-net/protobuf-net These POCOs must be shared across several systems and, as such, cannot depend on Abp/EF through inheritance.

Best regards! Richard

Hi,

We have a pretty common situation and I'd like to understand the best-practice or trade-offs in AspNetZero to handle this best.

We import a package (NuGet) of pure C# classes (POCO). These are shared across several system. In our AspNetZero server, we want these to be first class persistent objects. However, they can't inherit from Entity, since they come from the Nuget. What is the best practice here?

My ideas to date (not being the expert here, of course):

• If we were to use these classes as EF Navigation Properties in Apb Entities, i.e. always use them as complex-type properties of an Abp Entity class, it could do the trick. In this scenario, one would not even need to define a DbSet<POCO>, although one could (see: https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application )

• Alternatively, if we just reference these complex types from an Apb Entity, doesn't EF generate Entity-Proxies for these and automatically make them into EF Navigation Properties (see: https://blogs.msdn.microsoft.com/adonet/2009/12/22/poco-proxies-part-1/ ) or is this not an option the default Abp flow. We'd like to avoid too much custom code (risk).

• Any other way via delegation?

Thanks for any Tips/Example/Info!

@chris.tune Once you have a valid JWT, then you use it in your API calls to your server (Bearer). This is a big topic (lots of books and web sites doesn't make it simpler though), and is not ABP specific. In general your external (CORS) JS-client will need to use OpenID-Connect (via a JS-client-side-library or via another backend server) if it wants to send a valid, authentcated SSO JWT Bearer token to your server. Your server will then validate this token against the Identity Provider such as AAD B2C and cache it for a while.

If your JS-client is not external, i.e. it is same-origin, then you have served the page from your server where the user logged in: this is our scenario above. In this case, you could use the cookie for storage, or the JWT token in the Bearer Header. Both of them will contain all the claims that you (normally via AAD B2C) put in that signed, valid token. This JTW token can be read without a signature (see jwt.ms for example) anywhere, by anybody. It just can't be modified.

Hope that helps. More infos on stack exchange :-)

@chris.tune Yes, this is required by .NET-Core Identity. So if you don't want to modify the .NET sources, you had better use it :-) See above. However, it is not set by AAD B2C, that is the caveat I talk about above. In my code above, I define this claim and then set it to the user's email so that .NET does not reject the claim set. This will then be used as the AspNetZero username if I remember correctly, but that could be changed as well. The JWT(claimset) can be set in a cookie, you can check this in your browser's debugger, but cookie storage (the default I think) is only one option.

@konverto The return to the Login page is just the default behavior if the login fails. As such, this could be due to any number or a combination of small things. To get to the precise location of the problem, you'll need to put a breakpoint in the places above (see my codes above) and check what is happeing. On the AAD B2C-side, you'll also want to check a few things. Note that you can test your flows directly in the AAD B2C portal. Here are my thoughts:

1. In your code above: https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_login"; Be sure to replace "mytenant" with YOUR b2c tenant name. Also be sure that you have the B2C flow "b2c_1_login" defined in the AAD B2C portal. You can test this there.

2. be sure your browser cache and cookies storage are blanko-clean when testing. If not, you'll get all kinds of strange effects when debugging. Your case above could be due to an auto-login (SSO) due to a cookie in your browser that is then providing old state and results in a rejection.

3. Be sure that your claim "email" is getting found in your code. Just put a breakpoint there and check the result...

4. B2C Reply-URL example. All checkboxes are "yes" except for Native Client is "No", no optional required. it is optional. The URLs.

   1. https://localhost:44399/Home
   2. https://localhost:44399/signin-oidc (whereby this one is defaulted I believe, but I have it in there to be sure)

Good luck!