Yes - the issue has been encountered on three different client machines.
Hi Aaron,
It can be as little as two/three tabs, and more easily produced with more tabs than that.
Hi All,
We've recently encountered an issue wherein when our .Net Zero application is ruinning on a domain (but not in LocalHost) using Chrome, if you have several tabs open all to the same domain app instance, loading tabs and/or calls to the application hang, and Chrome displays a notification in the bottom left hand corner, saying "Waiting for avalible socket". When this is present, the app comes to a standstill on the client, and remains this way until tabs are closed, freeing up sockets and allowing the waiting calls to process.
We've investigated as to what was blowing out Chromes socket connection allowances, and as far as we can tell, it's SignalR's requests that are largly responsible for consuming the avalible sockets. Disabling the Chat feature (which uses SignalR) and disabling the following to SignalR scripts:
<script src="@(ApplicationPath)lib/@@aspnet/signalr/dist/browser/signalr.min.js/signalr.min.js" asp-append-version="true"></script>
<script src="@(ApplicationPath)lib/abp-web-resources/Abp/Framework/scripts/libs/abp.signalr-client.js" asp-append-version="true"></script>
Seems to have stopped the issue, and our app can be used with as many requests as we like, without encountering the socket availability issue, albeit at the cost of any functionality that uses SignalR.
Has this been encountered by anyone else, and therefore, does someone know how to resolve this without removing SignalR, or is this a new issue?
@ismcsgdas no I haven't - the behaviour isn't consistent, and isn't handled gracefully one way or another (either crashing completely as a 500 error or as the 401 that breaks the BlockUI and provides no details)
Hi @ryancyq
In going back to get the stack trace, something has changed and in the debug console it now shows a 401 Unauthorised being returned, instead of the 500 it was before.
Something I still note is that when the 401 is thrown due to failed feature check (on tenant) this is displayed to the user:
and the blockUI crashes as well, requiring a page refresh to carry on. The above message is not self-explanitory, but no other information can be gathered, as the audit log doesn't show any error to have occured.
If one manually throws an AbpAuthorizationException, then it can come up like so:
Can the same be done when errors are thrown by the feature checker?
Hi @ryancyq
It happens when logged in as a host user, which is explained by the thread in the link you shared, but unfortunately, it's happening for tenant users as well, which is why I raised this question.
Hi @Maliming
We're running .Net Core v6.3.0
Implementing the RequiresFeature attribute on either an MVC controller or Application Service class or method throws a 500 Internal Server Error when the current user doesn't have the required feature, rather than throwing an AbpAuthorizationException, as the ABP documentation states that it should:
This method is executed only if the "ExportToExcel" feature is enabled for the current tenant (current tenant is obtained from IAbpSession). If it's not enabled, an AbpAuthorizationException is thrown automatically.
I've implemented the RequiresFeature attribute in the same way as shown by the documentation:
Abp Implementation
[RequiresFeature("ExportToExcel")] public async Task<FileDto> GetReportToExcel(...) { ... }
My Implementation
[RequiresFeature("App.RoleManagement")] public async Task<GetRoleForEditOutput> GetRoleForEdit(...) { ... }
@hikalkan thank you for your response.
Something like IgnoreFeatureCheckForHostUserswould be amazing to have, so that we have the option of allowing host users through feature checks.
As for permissions, if I am understanding you correctly, we've had no issues with AbpAuthorize/AbpMvcAuthorize attributes on classes/methods as host users, as the host users have roles and permissions assigned and can access authorised areas without issue.
Having both a permission check and a feature check on a given class/method shouldn't be an issue for a host user so long as the feature check can be bypassed and they have the right permission assigned?
Thank you @Alper
