Activities of "jogoertzen"

Thanks! I was not aware of that.

• ABP Framework version: v5.1.4
• UI type: Angular
• DB provider: EF Core
• Tiered (MVC) or Identity Server Separated (Angular): Identity Server Separated (Angular)
• Exception message and stack trace: N/A
• Steps to reproduce the issue:" N/A

This question is related to the Microservice Template.

The documentation here states that the MyProjectName_AdministrationService client is used by the administration service for requesting the user list in administration pages from the identity service, however I don't see the MyProjectName_AdministrationService client ever requesting an access token to do so in the logs. It seems like the MyProjectName_Angular client handles all requests to the identity service.

• Can I safely delete the MyProjectName_AdministrationService client from my application?
• Is the MyProjectName_AdministrationService client used in other startup templates (eg. Application Template) or UI types (eg. Blazor)?

I tried changing the client secret to see if anything breaks, but everything seems to work fine.

Thanks!

@gterdem

Thanks for the clarification. I had not tested bringing up the list of permissions for a user, but I see now that it does not work when the internal gateway is down.

Alright. Thanks for looking into it anyways.

@albert

We tried using the preview version of the application template with abp suite v4.3.3 which attempts to download the app-pro-4.4.0-rc.2 template, but our firewall blocks it again claiming it found the same Apple Safari WebKit Selections Use-After-Free Vulnerability, but this time the file it claims has the vulnerability is toastui-editor.js as opposed to tui-editor-Editor-full.js which was reported previously when downloading the app-pro-4.3.3 template.

So it seems the apparent false-positive is still there in v2.x of Toast UI.

We confirmed a third option exists: explicitly adding Microsoft.EntityFrameworkCore.Relational 5.0.8 to the Shared.Hosting project gets rid of the conflict.

Hi liangshiwei,

Was there a particular section of the documentation you linked to above that you would like me to focus on?

I believe I understand how the internal gateway is supposed to work, but it seems like the current version of the Microservice template does not actually use the internal gateway at all. In other words, the template seems to work fine even if the internal gateway is down.

Are you aware of this?

Hi maliming,

Unfortunately, installing the latest .NET SDK did not solve the problem; the same error occurs.

I did a little digging and it seems Volo.Abp.EntityFrameworkCore >= 4.3.3 still depends on Microsoft.EntityFrameworkCore 5.0.7, but there are several package references in the Microservice template 4.3.3 that specify a wildcard in the patch version number (ie. 5.0.*) for Microsoft.EntityFrameworkCore that started resolving to 5.0.8 as of 2021-07-13. This seems to be what is breaking the build.

It seems the only options right now are (1) to replace all instances of 5.0.* with 5.0.7 to match Volo.Abp.EntityFrameworkCore, or (2) wait for a new version of Volo.Abp.EntityFrameworkCore that depends on Microsoft.EntityFrameworkCore 5.0.8.

Is that an accurate assessment?

I am currently attempting to deploy v4.3.3 of the microservice template to OpenShift, and I realized that I had yet to properly configure the internal gateway routes (ie. it was still using the default configuration which points to various ports on localhost), but the overall application still seems to work fine. I even scaled the internal gateway deployment down to 0 pods and I still can't find anything that breaks as a result. The only thing I can find that even looks like it should talk to the internal gateway is the administration service which has the following default configuration pointing to 44302 (ie. the internal gateway port), but it would seem that the administration service doesn't use it.

// services\administration\src\MyProject.AdministrationService.HttpApi.Host\appsettings.json

{
  "RemoteServices": {
    "Default": {
      "BaseUrl": "https://localhost:44302/",
      "UseCurrentAccessToken": "false"
    }
  }
}

Am I missing something here? Does the internal gateway play a role at all in the microservice template? Thanks!

• ABP Framework version: v4.3.3
• UI type: Angular
• DB provider: EF Core
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace: N/A
• Steps to reproduce the issue:" N/A

Hi Albert,

Judging by the responses to the issue you created, it looks like upgrading to tui.editor v2.x is the recommended way to resolve this issue.

Is this something that can be done?