Activities of "mrbrl"

• ABP Framework version: v8.0

• ABP Studio version: v0.6

• UI Type:Blazor WASM

• Database System: EF Core (SQL Server)

• Steps to reproduce the issue:

1. Opened ABP Studio and navigated to 'File > Initialize Existing Solution' to open a MicroService Template Solution initially generated with ABP Suite.
2. Observed that a new Web Project was added in the Solution Explorer.
3. Manually removed the new Web Project by editing the .abpmdl and .abpsln files.

Current Behavior:

• After the initialization , the Solution Runner tree remains consistently empty.
• All tabs within the Solution Runner (Overall, Browse, etc.) are empty when the solution is not running.
• The same empty state persists in the Solution Runner tree and tabs even when running the solution with Tye.

Expected Behavior:

• The Solution Runner tree should display relevant project components.
• Tabs within the Solution Runner (Overall, Browse, etc.) should show appropriate information and functionality, both when the solution is and is not running.

To be clear, is it a distributed cache problem, whereas we need to have a central cache location otherwise permission can be lost. Or is it a data protection concern, whereas the keys need to be cached on a shared drive or a caching provider like Redis?

please clarify.

• ABP Framework version: v5.3.x
• UI type: Blazor Server
• DB provider: EF Core \
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace: Could not find IdentityClientConfiguration for AbpMvcClient. Either define a configuration for AbpMvcClient or set a default configuration. [23:31:00 INF] Authorization failed. These requirements were not met: PermissionRequirement: ...
• Steps to reproduce the issue:" Run the application. Occasionally, the UI as well as some Menu items does not render. after a few minutes or refreshes, it may resolve to normal The issue happens both in developments (all apps in same box) and prod ( 1 box per each app - IDS, Blazor Server WAF, Web API)

We disabled Redis (ie not using) We have seen the threads: https://support.abp.io/QA/Questions/2633/Could-not-find-IdentityClientConfiguration-for-AbpMvcClientWhy and https://support.abp.io/QA/Questions/1627/How-can-I-persist-ASPNET-Core-Data-Protection-Keys-to-the-database

Both do not provide enough details to be conclusive.

Could you let us know what may be the root cause of the issue? Is it possibly because we are not using Redis ?

Thanks.

Yes, we were hoping to possibly reusing ABP auth components instead of client authentication reimplementation. Thanks

The issue at hand is the database cannot be accessible by the blazor app - relying on API app on another server. Hence we cannot add IDS to the blazor web app as it would require database connectivity.

**Blazor WAF: **

• displays authentication UI (login/logout...)
• consumes Authentication API on IDS
• manages the authentication identifier
• has no database access
• can only consume APIs
• accessible to end-users

IDS:

• Exposes API's required for user authentication flow
• Support local users
• Supports LDAP
• has database connectivity
• not accessible to end-users

Thanks

**ABP Framework version: v5.3.0 Commercial

UI type: Blazor Server

DB provider: EF Core

Tiered : Blazor Web , IDS, web API**

Use Case:

Blazor Server App hosted in 'WebServer' Identity Server hosted in 'AppServer' End Users may only access 'WebServer'

With the default authentication flow and UI residing on Identity Server, when authenticating on Blazor Server App (on WebServer - which users can access), the flow redirects to Identity Server (on AppServer which users cannot access) - and therefore authentication cannot proceed.

The Authentication is leveraging both local (to IDS database), and LDAP (which defaults to local authentication when failing to connect) authentication.

What would solve the problem is to have the authentication UI on the Blazor Server App, which would leverage the ABP-fronted IDS APIs to allow login, logout, token issuance and refresh, cookie, and LDAP authentication.

I did not find any conclusive documentation on this and would be grateful for directions on this - as to avoid recreating a whole wheel.

Thanks a ton!

Thanks for your reply. I have read the thread and glad to know support for IDS 4x will continue even as it hits end of support, as long as .net 7+ does not break it.

If Duende IDS 5+ integration is the same or very similar to that of IDS 4+, would it be a case to support the IDS5+ integration provided the road ahead is smooth and does not burn too much resources?

I read the chat ABP had with Duende, and understand the incompatibility that is largely due to business model differences. With that, if the integration effort is more or less the same as keeping IDS4 alive, without tapping on new features that Duende has in stock and provided the API remains largely the same for the ABP use cases, then why not?

Thanks - i did see the very informative thread about the migration after posting this. https://github.com/abpframework/abp/issues/11989 I understand that the platform should be able to plug any identity mechanism. that said - as IDS is already implemented albeit in a tightly coupled fashion that is slowly turning into a loose one, it may be sustainable to port the current IDS option to the new pluggable identity provider mechanism without breaking too much sweat, and leave the option to you grateful userbase to use it for their existing projects for instance - which would continue to benefit from ABP updates. New project may either use the soon to be the supported and free (for now) OpenIdDict - or IDS v4 (even after eos), or IDS 5+ (community or not), or minting custom providers (basic authentication :) )

• ABP Framework version: v5.3.0 Commercial
• UI type: Blazor
• DB provider: EF Core
• Tiered

We are heavily relying on the IDS and LDAP integration in ABP, one of the main reasons we picked the framework. We attempted to update to the last 5.3.0 version today and noticed the LDAP integration has substantially changed, likely in anticipation to remove IDS from the platform. We have a number of projects relying on both IDS and LDAP and the prospect of having it possibly removed from the platform means that we won't be may not be able to update to future ABP versions.

Could you please let us know :

• What are the migration steps for LDAP in 5.3.x
• Is LDAP Integration here to stay in future ABP versions?
• Any plans to keep the IDS support option?
• Any plans for Commercial IDS support?

Thanks!

announcement below: *'We have announced the plan of replacing the IdentityServer. ABP currently uses IdentityServer4 to add OAuth features as built-in on the server-side. However, since IdentityServer4's support ends at the end of the year 2022. Its replacement is Duende IdentityServer, which is not a free software anymore. (see more)

Therefore, we've decided to completely drop the IdentityServer4 from the ABP platform and implement the OpenIddict and install onto the startup templates.

We've implemented both open source and commercial OpenIddict modules, we plan to remove Identity Server and replace it with OpenIddict for template projects in ABP v6.0. Please check #12084 to see the development made on the open-source side.

We're creating the documentation for the OpenIddict Module, if you want to have general knowledge about this module, you can check the documentation from here. Currently, this is a draft documentation but it gives overall knowledge about the OpenIddict Module, we'll complete this documentation in ABP v6.0 and you'll be able to read it completely.

Currently, we are also working on Keycloak integration possibilities in parallel to the OpenIddict integration research and we've prepared some samples that you can examine. You can see #154 and #158.'*