Activities of "alexander.nikonov"

Front-end is an Angular app. The link to the log is shared (sent to your email).

I would still take my chance to troubleshoot and try to eliminate the given issue. Especially taking into consideration, that this error has appeared very rarely in v8.x and now - every time I invoke a request.

Hi. Please have a look below: ">>> [CONFIG] Incoming request" - I just tried to get more data about the request, it did not help me much. I cannot send an example or share the project, but I would gladly share more details which would assist us in troubleshooting this issue.

Ok, thank you. Anyway, we have some insight now about possible solutions. I will close the ticket now.

Maintaining yet another solution does not seem like a great idea to me. Nor is it great to add coupling from numerous solutions by adding a Domain.Shared reference to the management solution for the sake of localizing a page.

But as I understand, there is no other option. Well, actually one more - a trade-off option - could be to make API request to abp/application-localization of each solution (supposing that all of them will be running in the production system) and to create a client-side dictionary (dictionaries), then - to extract the display name by the given localization key...

We have a central management of permissions used across the solutions in one of the solutions. We use Redis to store the permissions and this part works fine.

The issue is that in order to display the localized names of permissions, we need to include DomainSharedModule of each solution into the management solution which does not seem right and creates coupling:

[DependsOn(typeof(OtherSolution1DomainSharedModule), typeof(...) ...)]
public class ManagementDomainSharedModule : AbpModule { ... }

• i.e. the resources from Solution1 are visible, but from Solution2, ... SolutionN - not.

How to avoid coupling, but still be able to display the localized names of all the permissions from the cache?

Outstanding! Thank you very much - it now works exactly as supposed to.

It's getting a bit complicated to synchronize a clean ABP framework test project and even a minimal customization.

We definitely might try what you suggest anyway, but now I even cannot make standard ABP pages work in the test project for the reason unknown to me. What i tried to do last was to switch from using 'http' in front-end to 'https' to make it as close to the original setup as possible (you may use some self-made SSL certificate if needed). I have modified OpenIddictApplications table accordingly (just for your information).

Could you please fix the test project uploaded (the linke has been sent to your email) - so adding a user and a link account feature would work - and zip the project back to me? I will take it from there. Thank you.

Replying this right away:

Some of them are Preflight requests, it's part of CQRS to pre-check if the server supports cross-domain requests.

Those are not prefetch. Please pay attention that both of them are with code 200. Prefetch is 204. So those are really duplicates for some reason...

Hi, thank you for the reopening.

I am afraid I do need your further assistance here. So I managed to eliminate extra API request at Home page which took place between /abp/application-configuration and /abp/application-localization and returning error 401 (for the reason still unknown to me):

However I still cannot figure out everything that followed /connect/token with 400 return code ('token_error'). Since I cannot share our code, and on the other hand it makes no sense to track things on a test example since it is a very simplified version of the code, I will kindly ask you to clarify how ABP works in this workflow and why exactly this way:

1. why there are duplicating /abp/application-configuration requests here? There are no our requests which might initiate them, so it looks like it is some inner ABP mechanism;
2. you cannot see it from the ticket, but during /abp/application-configuration request our current page is redirected after unsuccessful link account login change. Even if we are currently on Home page - we are still redirected to Home page again. I have been setting breakpoints in our code, thinking it might be caused by our global error handler, but it responds to other error codes, not 400. So I thought it might have something to do with the way ABP handles this;
3. when I try to initiate "Link Accounts" dialog from another page (not Home page) - I still see error 401 after 'token_error' response from API requests of this page - just before the mentioned redirects to Home page. Error 401 makes no sense to me in the failed switch link account scenario, because the current user is never unauthorized. I would like you to explain why this could happen. Also, during the aforementioned redirection to the Home page, I briefly see "Welcome to the application. This is a startup project based on the ABP framework. For more information, visit abp.io" markup - which might indicate that the current user is really unauthorized at some point (makes no sense to me).