Search code examples
c#asp.net-coreauthenticationasp.net-identityblazor-server-side

ASP.NET Core Identity redirection breaks when using postgres?


I've got a small Blazor Server app running with Asp.net Core Identity through EntityFramework 7. I had been using a SQL server, until today when I tried to switch hosting providers. When I try to do the exact same thing with the NpgSql data connector for Entity Framework, the application behaves very strangely. When I log in, the result is a success, but then the redirect from MVC back to the Blazor app times out. If I then refresh the page, I'm still on the Login page, but now signed in, and can use the application as normal. What could be my issue here?

I would share more of my code, but the only difference is going from

builder.Services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer("<string>"));

to

builder.Services.AddDbContext<ApplicationDbContext>(options => options.UseNpgsql("<string>"));

My first thought was that there's some part of EfCore that's still trying to use Sql server data providers, but then why would I be correctly signed in on refresh?

EDIT: Just discovered another symptom- apparently, all blazor functions (state change, redirects from methods) are now nonfunctional. It's like if the blazor.server.js file isn't being loaded- but it is being loaded correctly, and no JS errors are happening. Feel like I'm going crazy here.


Solution

  • EDIT

    Turns out I was having a threading issue elsewhere in my program. I was using this code

    currentUser = UserManager.FindByNameAsync(authState.User.Identity.Name).Result;
    

    I had used .Result() here instead of awaiting the method in thinking this would run synchronously- I now realize this is bad practice, as using .Result() in this way is a deadlock waiting to happen. Somehow, this code was fine when using the SQL Server data provider for Entity Framework- My guess is that the cold start time for the SQL server was a bit faster than the Postgres server I'm now using, and because of this the method was taking a fraction of a second longer- then running into a deadlock.

    I refactored the code to properly await the method, and now everything works perfectly.