Hi all,
I’m running HF in .net core 3.1 and when I navigate to the dashboard it will load correctly, but all calls to the /stats endpoint returns 403. I have setup the authorization filter to always return true and have disabled the UseAuthorization from the configuration.
Has anyone else faced this issue?
Are you going through a load balancer? The .net core dashboard has anti forgery tokens which cause this (if the request to /stats doesn’t go to the original server that issued the token you get a 403 response).
If this is the case, there is an option in startup to remove this, IgnoreAntiforgeryToken, in the UseHangfireDashboard setup.
@Andrew_Borland doing gods work, thank you!
Hello Andrew,
could you please provide me with more details, because I am currently using SSL Offloading on our production servers and we have an .Net Core Web App that works behind a load balancer and the SSL is being granted through the load balancer.
Kind Regards,
Antiforgery tokens in ASP.NET Core are tied to a single node of a web server farm by default but when Data Protection API is configured to use a storage shared among all the nodes, they should work OK. See Host ASP.NET Core in a web farm | Microsoft Learn .
However, I can observe this behavior even then, and moreover, I can observe it even in a single-node setup. Sometimes, it returns 403, sometimes 500. Usually, during the first load of the dashboard, a red bar informs about the failure of the async request (“Unable to refresh the statistics: the server responded with 403 (Forbidden). Try reloading the page manually, or wait for automatic reload that will happen in a minute.“) and no more async requests for stats are sent till the refresh of the whole page. After a minute, an automatic refresh happens or I can refresh myself, as the message says. That usually fixes the issue and further requests succeed (a request to stats is sent periodically).
I believe clearing the cookies fixes the issue. It is likely caused by leftover cookies from times when the storage for Data Protection API was not configured correctly (in-memory storage was used, which caused the keys used tor antiforgery tokens protection not to be shared among the nodes). Maybe some configuration changes over the time were able to break even the single-node setup.
Found related threads…
It seems a very similar issue is caused by trying to add the dashboard multiple times using the same path.