# Dashboard returns 403 on stats call **URL:** \ **Category:** question\ **Tags:** dashboard\ **Created:** [September 28, 2020, 9:38pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831 "2020-09-28T21:38:49Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Jeff\_Posey](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/jeff_posey/32/1892_2.png) [@Jeff\_Posey](https://discuss.hangfire.io/u/Jeff_Posey)\ **Post date:** [September 28, 2020, 9:38pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/1 "2020-09-28T21:38:49Z")
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? ---
**Author:** ![Andrew\_Borland](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/andrew_borland/32/1889_2.png) [@Andrew\_Borland](https://discuss.hangfire.io/u/Andrew_Borland)\ **Post date:** [October 13, 2020, 11:52pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/2 "2020-10-13T23:52:09Z")
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. ---
**Author:** ![Minh](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/minh/32/2296_2.png) [@Minh](https://discuss.hangfire.io/u/Minh)\ **Post date:** [November 3, 2020, 3:24pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/3 "2020-11-03T15:24:03Z")
@Andrew_Borland doing gods work, thank you! ---
**Author:** ![abusubha](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/abusubha/32/2486_2.png) [@abusubha](https://discuss.hangfire.io/u/abusubha)\ **Post date:** [March 16, 2021, 9:01am UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/4 "2021-03-16T09:01:59Z")
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, ---
**Author:** ![TomasMalecek](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/tomasmalecek/32/4052_2.png) [@TomasMalecek](https://discuss.hangfire.io/u/TomasMalecek)\ **Post date:** [December 11, 2025, 6:10pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/5 "2025-12-11T18:10:27Z")
Antiforgery tokens in [ASP.NET](http://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](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/web-farm) . 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). ---
**Author:** ![TomasMalecek](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/tomasmalecek/32/4052_2.png) [@TomasMalecek](https://discuss.hangfire.io/u/TomasMalecek)\ **Post date:** [December 11, 2025, 6:49pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/6 "2025-12-11T18:49:24Z")
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. ---
**Author:** ![TomasMalecek](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/tomasmalecek/32/4052_2.png) [@TomasMalecek](https://discuss.hangfire.io/u/TomasMalecek)\ **Post date:** [December 11, 2025, 7:10pm UTC](https://discuss.hangfire.io/t/dashboard-returns-403-on-stats-call/7831/7 "2025-12-11T19:10:24Z")
Found related threads… > [@HTTP 403 error remote](https://discuss.hangfire.io/t/http-403-error-remote/4932): > > In Global.asax HangfireBootstrapper.Instance.Start(); in Startup public void Configuration(IAppBuilder app) { ConfigureAuth(app); app.UseHangfireServer(); app.UseHangfireDashboard(); app.UseHangfireDashboard("/hangfire", new DashboardOptions { Authorization = new[] { new NoAuthorizationFilter() } }); } public class NoAuthorizationFilter : IDashboardAuthorizationFilter { public NoAuthorizationFilter( ) { } public bool Authorize ( DashboardContext dash… > [@Getting a 403 when accessing on a server](https://discuss.hangfire.io/t/getting-a-403-when-accessing-on-a-server/9250): > > Hi, I setup an oidc implementation ages ago for a hangfire dashboard I have, but never really used it. Anyway I’ve picked up again, upgraded the project to .net 6 and reworked a few bits and bobs, but I’m having a weird issue where by it works with oidc locally, but when I deploy it to my server and access remotely, it flows through the auth fine and redirects back to the signedIn controller, but then when it redirects with a fully authenticated user, it returns a 403. This is my DashboardAuth… It seems a very similar issue is caused by trying to add the dashboard multiple times using the same path.