IdentityServer4 Exception Handling - asp.net-core

I have an ASP.Net Core 3.1 MVC Application that makes use of OIDC authentication provided by IdentityServer4.
In the Identity Project (also ASP.Net Core 3.1) the login process sometimes fails on the following routes with the following errors:
/connect/token fails with Invalid authorization code
/connect/authorize fails with Request validation failed or client_id is missing or too long
These result in the general Exception page being returned to the user. I suspect that these stem from users that are using bad browser shortcuts (but I'm not 100% sure about this, so any advice on the source of these would be appreciated). But my actual question is... What exception handling can I put in place to return a more meaningful message to the user, something like an error response that says
please check the browser shortcut you used to access this logon page!

You have several options here, you can use the
app.UseExceptionHandler("/Home/Error");
or create your own middleware to capture the exceptions thrown by the authentication middleware in ASP.NET Core to present the user with a meaningful errors.
Some errors/events can also be caught and handled using the OpenID Connect middleware event model

Related

OIDC challenge is the browser history for ASP.Net Core client

I use IdentityServer (aka Duende) ver. 6 and ASP.Net Core client as a BFF provider for the frontend with standard .Net Core Microsoft OIDC middleware .AddOpenIdConnect for the Authorization Code flow. Everything works nice except one small thing: browser history entry for the OIDC challenge which looks like https://myserver/connect/authorize/callback?client_id... It must be the same for any OIDC provider because this call must be done in a browser and cannot be replaced by AJAX.
It's just looking untidy with long URL and no page title in the history. If user hits back in a browser, it leads to the error because the challenge code is not valid anymore. The problem was precisely explained here and the solution history.replace was even implemented for the IdentityServer's JS client as a config parameter but I can't find anything similar for the .Net Core.
The solution for the browser back button is implemented on the IdentityServer side in their "QuickStart" sample and I also handle an error on the client but still this long untidy URL in the browser offends my eye. I would prefer replacing history instead.
The idea is to handle some event from the OIDC middleware and inject javascript with history.replace to the http context there. Maybe someone already has ready-to-go solution?

SSO Throwing CORS Preflight exception

I have developed .Net Core (5.0) application and its have SSO Login functionality.
This application is deployed on PCF and its having multiple instance
Now issue is while calling .Net Core methods using ajax call its giving below exception
Look 1st request goes in 1st instance and 2nd request goes in 2nd instance but 2nd instance not able to process the request how can we resolve this?

ServiceStack translates HttpError.Unauthorized from backend into ArgumentNullException on client ("Value cannot be null. (Parameter 'RefreshToken')")

I have an ASP.NET Core 3.1 application which serves as API to mobile client written written Xamarin Forms.
An API has a TryAuthenticate method which expects userName and password to perform authentication. If credentials are incorrect, it throws HttpError.Unauthorized(validationResult.Message) exception.
On mobile client though for some reason it is being translated into ArgumentNullException with error message: "Value cannot be null. (Parameter 'RefreshToken')".
Client version: ServiceStack.Client 5.9.0.
Client classes that are used:
JsonServiceClient
JsonHttpClient
Both have the same behavior.
What is even more wild, is that when calling authentication endpoint with Postman, providing invalid credentials, it return correct (expected) response:
Would really appreciate any answer or suggestion, as working with ServiceStack gets only more difficult and unpredictable over time.

Difference between Elmah and Elmah.Contrib.WebApi

I am confused between Elmah and Elmah.Contrib.WebApi. And which one is best option for Web API. Iam already using Nlog for exception logging along with Tracing in Web API. So How Elmah is different from all of them. What is the exact need to going for Elmah??
Thanks in Advance
I find that it is useful for catching errors that you did not catch and log yourself. I am using it for a MVC application and it sends me an email when I have an issue that I need to resolve. I can be proactive and I am working on errors before I can hear from the user.
Elmah addresses your default application error logging. However when you're using Web API, for example ASP.NET MVC Web API, you need some extra logic to log your Web API errors within your Elmah data store.
There are a few ways to address this requirement, one being to use the Elmah.Contrib.WebApi package.
Once the package is imported to your project remember to follow any implementation requires, i.e. startup filter registry (as noted here)

Returning a 401 Unauthorized from WCF Web API in an MVC 3 App

I'm using the WCF Web API (the latest version, which I think is 0.5, obtained from the VS2010 Ultimate integrated package dependency GUI).
I've got a simple API class exposed and in each method I'm making a call that performs authorization against the user. When the user is unauthorized, I throw an HttpResponseException with the 401/unauthorized code.
This works, and you can see that at some point in the Http Handler chain, the 401 was trapped. The problem is that the site in which the API resides contains ASP.NET Forms authentication... and so when it sees the 401, it tries to forward my client request to the logon page.
How do I disable this behavior for a particular sub-directory within my site? I've tried setting a location of "api" always allowing users... but I still throw a 401 which still causes ASP.NET to try and redirect me to the logon page.
I'm sure I'm just missing a simple configuration setting that tells forms auth to ignore requests for the /api/* directories, but I can't find any information on it.
I have described the problem and it's solution here (with Preview4): Basic Authentication with WCF Web API hosted in IIS / Getting a 404 - Disable Forms Authentication Redirection