Hello to the community,
We have a standard app based on example SuperOffice/devnet-oidc-razor-pages-webapi.
The setup process of the app has a problem: after logging in to two tenants, saving of group access to panels to the second tenant does not work.
We tested the example itself. For this, we only set the ClientId and ClientSecret in appsetting.json, logged in to two tenants in two different browsers, and tried to change the active user groups for a panel.
In the first one, we could see the panel list and save changed settings:
In the second opened tenant, after opening the panel list
When we tried to save the new setting for the user groups for one of the panels, we got an error identical to our app:
Do anyone experienced same problems?
Is this example project obsolete or it is a SuperOffice problem with rest web API for the user groups/rights?
All Replies (4)
I am not familiar with the example that you are using, but if you put a breakpoint on line 104 of the SoHttpRestClient class you should check the returned error information in the body property of the HTTP response. Usually it contains useful information about what actually went wrong at the server side.
Is the 'Use grouping and filtering by user group for this list' option enabled for the GUI - Webpanel 'list' in the admin for the second tenant?
If you check the Failures tab in the developer portal, you should be able to see exactly which API call that fails
https://docs.superoffice.com/en/developer-portal/howto/failures.html
If it still does not give you enough information to solve it, there's a nifty little button that creates a support request 
and includes the operation id so we can find the same in application insight here.
Hi Andrey,
Allow me to preface this with "All example applications on GitHub are not production ready". They are there to demonstrate the main API concepts, not necessarily multitenancy. In hindsight, I see how that is ironic considering the target audience of this particular example. Please accept my apologies for not ensuring it was multi-tenant friendly.
The problem of course is the DbContext classes, specifically the DbSets that act as caches, are never cleared between tenants. There are several ways to do that, and it seems like, according to the accompanying support case, you have come to the same conclusion and implemented a fix.
Please consider creating a github issue about this, and know that we would be very happy to receive a PR that addresses this issue:
https://github.com/SuperOffice/devnet-oidc-razor-pages-webapi/issues
Best regards.
Hello everyone,
Thank you for your approaches.
Tony, you are absolutely right. We should have been more careful when using the sample project. I simply overlooked the cached entities.
Yes, I fixed it in converting DBContext to a usual class and declaring it transient. So I can have caches, at least inside a request.
We will process the issue in github as soon as possible.
Best regards,
Andrey