Now, I deployed the app to Azure Container Apps: there basically the app run in HTTP, and the infrastructure handles the https thing. Nothing worked until I added this to Program.cs:
Now, when I try to login, I get a weird error when auth0 tries to go to the callback url: it simply throws a HTTP ERROR 431 and my Chrome stays kinda black.
It takes FOREVER to return from the login page in auth0.
If I check the code of my server, all the time it is taking forever, something like this is displayed in the log all the time:
The cookie '.AspNetCore.OpenIdConnect.Nonce.CfDxxxxxxxxxx' has set 'SameSite=None' and must also set 'Secure'.
And no idea what to do after that.
Thanks
(BTW, no idea how to select the proper tags… I was trying to get dotnet and blazor)
Hi @psantosl,
I’m not familiar with Azure Container Apps, but I don’t think it’s a specific problem with Auth0 and Blazor as much as it is with the configuration of an ASP.NET Core application within a container.
I can confirm that you need to forward headers. Not sure if forwarding just the protocol is enough. Have a look here to learn more.
Not sure if the HTTP 431 status code can depend on the correct header forwarding configuration. Otherwise, you can take a look at this article, which seems to address Kestrel’s configuration (not sure).
Finally, I would see if the previous investigations and fixes might also fix the cookie issue.
The official examples use a .cshtml page to implement the login (and logout). Since cshtml wasn’t loaded by the Blazor app (no idea how to make it work, never worked), we implemented a Login.razor as follows:
For some reason I don’t know, this provoked the infinite loop. The login “seemed to work” but when returning to the callback, it stayed there forever, loading some Nounce cookie again and again until the error was that the headers were too long.