Can you check websocket proxying ocelot at: https://ocelot.readthedocs.io/en/latest/features/websockets.html
As far as I understand, you have multiple handlers for the same event and you want to prevent adding the same data?
How about quering the database first if the data exist already so you can skip inserting it?
ABP uses default OpenIdConnect protocol for authentication. You can check microsoft docs for delegated authentication since we don't have any dedicated libraries about it.
If you used npm install for package restore, can you try yarn?
Microservices angular code need to developed in separate teams and its possible but you angular solution need to be updated to LaptonX every time we use ABP suite manually.
ABP Suite is does not support microservice development completely. If you want to build the UI separately, I recommend building modules (module template) first then convert to microservices.
When we generate ABP suite Microservice or module solution there is no option for mongoDB only solution so I had to convert Entire solution to MongoDB manually for microservice and Modules
Yes, we have the issue in our backlog however because of microservice complexity, it will take some time to implement it on our side. Currently, only way to use mongo db is manually configuring it unfortunately
Dynamic Permission was another issue which has been presented yesterday in ABp talk If any documentation on that will be welcomed..
Dynamic Permission system is a recent addition with ABP version 7. We are preparing documentation for it, please stay tuned.
All Charts on your theme are static. Evenif I create them will chart.js There is no style guide from ABP how to implement you LeptenX styles .
I do not have complete experience on LeptonX styling for charts but if you can create a specific issue based on a specific sample, we'll try to solve the issue.
It will be great if these microservice solution is designed to work with multiple independent teams working on same UI and separate module.
There are basically two ways of UI development for microservice development;
Multiple teams working in different repos of same module UI is not possible. Module can be hosted in a different repository and can be developed individually. That comes to the first question answer; I would recommend building modules first in different repositories then converting into microservices.
If we are going for enterprise level product we should have some way of custom defining these Abp suite templates or its a pain to keep updating them every time we generate them .
I am not sure what do you mean by custom defining suite templates but, suite will generate code nicely for modules considering it is has flaws for microservice code generation.
First of all, if they are using access tokens valid for a long time, they will become invalid and they will need to re-login.
I would recommend selecting a few of your customers and update them first as pilot customers step by step if possible. That should give the best idea.
Are there significant changes that occur, after the migration, that our customers need to report to their clients? Think about endpoint changes. Is there any difference in how tokens are handled?
Authorization endpoint stays same but the logout endpoint seems to be changed from /endsession (identityserver) to /logout. But I don't think you need to do something manually if you update the account module.
As far as we know, all clients follow the openid / oauth2 specs. We did not implement custom code on the ABP side.
It shouldn't be a problem. You can always report to us if anything we miss out on our migration guide.
Thanks for reporting. We have noticed there are errors on generated docker-compose files. We'll fix them as soon as possible.
I have refunded your credit.
- We have different types of "Tenant" that will have different data and different UI etc. Tenant data will be stored in a separate database to the main abp data. Some tenants will have their own dedicated dbs and some will share with other tenants (of the same type). Is this the best approach to add additional dbcontexts for each tenant type? I essentially want multiple separate "Applications/Products" within the same solution so that abp.io can manage the Tenants and Users centrally for all the "apps". Could something like this be achieved using modules?
Yes, you can set different connection strings for different tenants that will allow using different databases for the tenants of your choosing.
- Some users, not all, will need to access multiple tenants. The user account should only exists once (so one password etc) but if a users has permissions over multiple tenants, they should be able to switch tenant once logged in. What would be the best approach to provide this functionality? I dont want to mess up updates for abp.io commercial so Ideally I want it to sit on top of this, maybe as a module?
No, a user can not be a member of multiple tenants. You will need to create the same user in for all the tenants.
Yes, the user roles are added as claim to the access token when a user logs in. So, if you change a user role currently logged in, best you can do is to invalidate the access token to force to re-login.
To do that, you can use the UserSecurityStamp as explained here.
What do you mean by customers? Are they your tenants in your multi-tenant application? If so, tenants do not have access to openid-provider management (identityserver or openIddict).
IdentityServer or OpenIddict is not about user management, it is about application (client) management. So, users are managed by the Identity Module and they won't be affected. When you migrate to OpenIddict, you need to seed the applications (clients) only.