0

I keep getting the following error "Antiforgery token validation failed. The provided antiforgery token was meant for a different claims-based user than the current user." The environment I'm using is load balanced and we are persisting the keys to SQL Server.

Its a .NET Core 3 application and I'm using Role based authentication instead of policy. I have a custom role provider which gets the users roles from a webservice call. I've implemented the code found here https://gist.github.com/DamienBraillard/4dbd6aa2c56edf5a8e57c59b6e08da94 with my custom role provider. This works fine and everything is good until i hit an environment with a load balancer. I cant understand why I'm getting this error as I'm the same user on both nodes. I've provided the SQL Server anti forgery code below incase it may be something to do with that.

DataProtectionExtensions DataProtectionExtensions

SQLServerDataProtection SQLServerDataProtection

SqlServerXmlRepository SqlServerXmlRepository

user2661305
  • 311
  • 1
  • 4
  • 16
  • all of that has nothing to do with AntiForgey tokens in your we page. See here https://stackoverflow.com/questions/3419578/will-asp-net-mvcs-antiforgerytoken-method-work-with-load-balancers – Rex Henderson Mar 23 '21 at 18:15
  • 1
    @RexHenderson the servers already share the same machine key, but I'm pointing the application to persist keys to SQL because of a load balancer. Before I persisted to SQL i was getting the "Antiforgery token validation failed. The antiforgery cookie token and request token do not match." Hence why I went down this route – user2661305 Mar 23 '21 at 18:24
  • Understood. What's your load balance setup like? Is it a cloud solution? Could it be possible that the front end of your LB is not passing the anti forgery cookie to the backend server? Can you set up logging in your app to see if the cookie is getting received? – Rex Henderson Mar 23 '21 at 21:34
  • I guess I should be asking, how/where are you delivering the antiforgery components to the client. Cookie, hidden input, viewstate.... – Rex Henderson Mar 23 '21 at 21:55
  • No the solution isnt cloud based. The strange thing is that it only happens on 2 pages where a user has a list of data errors and they can click each one and it opens a new tab for them to be able to create the missing required data with it autofilled. When you hit submit on the new tab it works sporadically half the new tab requests work and half dont. Antiforgery is being held as a cookie and the AutoValidateAntiForgeryCookie filter is applied globally in start up. The infrastructure has alot of applications on it without issues hence why I ruled out the load balancer – user2661305 Mar 24 '21 at 09:44
  • Puzzling. Only happens on 2 pages. Do they perform any modifications to cookies or hidden elements in code such they may be interfering with the AF token or cookie? I assume you have inspected the loaded pages using browser dev tools and made sure the cookie and the AF token in the page are present. – Rex Henderson Mar 24 '21 at 18:16
  • Also, how are those new tabs generated? Do they get an AF token in their page? Can you page inspect and check the AF cookie and the AF token is present. – Rex Henderson Mar 24 '21 at 18:22
  • That "it works half the time" really sounds like an LB issue, but I have to admit if it's only two pages being affected I supposed it really can't be. The other variable to think about is if the LB is using sticky sessions, then it may just be the new tabs generating new sessions and getting sent to the other server....so it could look like everything else is working, but only because sticky sessions is sending everything to one server – Rex Henderson Mar 25 '21 at 00:56
  • Yea the 2 pages it happens on are the ones that open new tabs. When I inspect the pages the antiforgery tokens are present on the page and present in the cookie. There is no modifications done. The new tab pages have an antiforgery tokens on them and the cookie, they are opened via a link click with target "_blank". The servers arent using sticky sessions. I could be getting lucky that majority of requests stick to the one server and the anti forgery is then failing when it hits the second server. That could explain why it only happens on the new tab opening pages – user2661305 Mar 25 '21 at 10:02
  • There is no session state between the servers currently, I've just configured the anti forgery to store in a sql database. I'm near sure the sessionid is included in the antiforgery token, so could this be the issue because we dont have a sessionstate db or something to hold the session state at the server side? – user2661305 Mar 25 '21 at 11:26
  • Yea I would say this is an issue, if the token is embedded with session data and the servers are not sharing sessions. – Rex Henderson Mar 28 '21 at 21:34

0 Answers0