You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I apologise if this has been covered before, but i did google a lot and the best i could find was #7139 which somewhat touches on the issue. I've been using signalr 2.2 in production for a while now. Originally, we modified the "Invoke" function within DefaultHubDispatcher (Microsoft.AspNetCore.SignalR.Core) and added in a custom function to record the hub endpoint, user, arguments, a kick off a timer. Then wrapped the "ExecuteHubMethod" code in a try/catch, and recorded the eventual time taken. This allowed us to pipe the results (status code), which user executed what, how long it took, etc. etc. into our logging system. It worked great and eventually allowed for some funky stats such as the below:
I hope this kind of gives enough background information about the use-case. Now you can see the "GET" and "WS" prefixes. The GET was from a typical controller method which was using the standard http request middleware. However, i genuinely can't find a way to have something similar in signalr.
Ideally i'd want exactly the same functionality, a hub method is executed, before execution i am passed the name, arguments, or just the context itself, i can then pass this back, and get either a response object, or just a task success/failure. The issue i linked way back before this wall of text also asked about something similar. Without changing the source again, the only semi-solutions i have found at the moment are that the authorization middleware passes the method/args over (but obviously doesnt not record the outcome or time of the execution) and then i can comb through logging with debug logs enabled. Are there any plans to integrate a "traditional" middleware into signalr? Thanks again for all the awesome work to date.
The text was updated successfully, but these errors were encountered:
I've had a play around with your PR and it looks spot on. Really good timing and a great implementation that has everything that i'd need. Perfect timing too. Will close this now. For anyone else who ends up here via a search engine, the Startup.cs in SignalRSamples has an example filter (CustomHubFilter). Thanks for the quick reply/work!
Hi,
I apologise if this has been covered before, but i did google a lot and the best i could find was #7139 which somewhat touches on the issue. I've been using signalr 2.2 in production for a while now. Originally, we modified the "Invoke" function within DefaultHubDispatcher (Microsoft.AspNetCore.SignalR.Core) and added in a custom function to record the hub endpoint, user, arguments, a kick off a timer. Then wrapped the "ExecuteHubMethod" code in a try/catch, and recorded the eventual time taken. This allowed us to pipe the results (status code), which user executed what, how long it took, etc. etc. into our logging system. It worked great and eventually allowed for some funky stats such as the below:
I hope this kind of gives enough background information about the use-case. Now you can see the "GET" and "WS" prefixes. The GET was from a typical controller method which was using the standard http request middleware. However, i genuinely can't find a way to have something similar in signalr.
Ideally i'd want exactly the same functionality, a hub method is executed, before execution i am passed the name, arguments, or just the context itself, i can then pass this back, and get either a response object, or just a task success/failure. The issue i linked way back before this wall of text also asked about something similar. Without changing the source again, the only semi-solutions i have found at the moment are that the authorization middleware passes the method/args over (but obviously doesnt not record the outcome or time of the execution) and then i can comb through logging with debug logs enabled. Are there any plans to integrate a "traditional" middleware into signalr? Thanks again for all the awesome work to date.
The text was updated successfully, but these errors were encountered: