I have implemented IErrorHandler in my WCF service to determine what should be sent to a client (ProvideFault) and for logging the exception (HandleError).
As part of this process I want to:
Send the client an error code with some standard text to hide the internal exception details.
Log the error with the same error code so that I can match up the entry in the log file with the error report from the client.
I have been looking into this and cannot find a way where the same error code will be guaranteed to be used in both methods as HandleError will be called at some time in the future on a separate thread. This would seem to rule out having some kind of class level counter as ProvideFault could be called twice before HandleError is called.
Has anyone come up against the same situation and worked out a solution/pattern to use in this scenario?
Related
For compliance reasons, we need to change the error returned from a failed token validation from invalid_grant to invalid_request.
The logic that drives this is in TokenRequestValidator.cs specifically the method ValidateResourceOwnerCredentialRequestAsync. If you peruse the code you will see that everything it returns is OidcConstants.TokenErrors.InvalidGrant.
My first thought for this was to override the event sink to look for a TokenIssuedFailureEvent with an Error equal to invalid_grant. You can see that the event is dispatched when there is an error in TokenEndpoint.cs but when the event is raised, the error is wrapped in the TokenIssuedFailureEvent and the error is copied by value which means that this approach won't work.
Is there a way that I can alter this behaviour without having to make a code change to IdentityServer4 itself?
Thanks in advance!
Title asks it all.
Is there ever, and if so when, would ILogger not log an uncaught exception?
Reason I am asking is; am configuring Rollbar and it logs everything ILogger logs plus uncaught exceptions. This creates 2 logs. I am considering disabling Rollbar's log uncaught exceptions with the belief that ILogger catches them all already.
This question isn't about Rollbar tho :)
No. ILogger is an interface. It doesn't do anything. Rather, implementations of ILogger should log uncaught exceptions. It sounds like Rollbar is already doing your logging so you should continue to use that for logging your uncaught exceptions, or switch to a different library like NLog, Serilog, or log4net.
Personally, I have found that some libraries do miss messages in different cases, so it's important to test your logging library. It's not enough to just have faith that the messages are being correctly written. You can write unit tests to make sure that your code is logging exceptions correctly with Moq. Here is an example from this article.
_loggerMock.Verify
(
l => l.Log
(
//Check the severity level
LogLevel.Error,
//This may or may not be relevant to your scenario
It.IsAny<EventId>(),
//This is the magical Moq code that exposes internal log processing from the extension methods
It.Is<It.IsAnyType>((state, t) =>
//This confirms that the correct log message was sent to the logger. {OriginalFormat} should match the value passed to the logger
//Note: messages should be retrieved from a service that will probably store the strings in a resource file
CheckValue(state, LogTest.ErrorMessage, "{OriginalFormat}") &&
//This confirms that an argument with a key of "recordId" was sent with the correct value
//In Application Insights, this will turn up in Custom Dimensions
CheckValue(state, recordId, nameof(recordId))
),
//Confirm the exception type
It.IsAny<NotImplementedException>(),
//Accept any valid Func here. The Func is specified by the extension methods
(Func<It.IsAnyType, Exception, string>)It.IsAny<object>()),
//Make sure the message was logged the correct number of times
Times.Exactly(1)
);
But, even this doesn't guarantee that Rollbar or some other logger will definitely get your message to the log location. You can only confirm this by observing the output of the logger.
You should also see this section of the ILogger documentation which explains how to configure logging and potentially filter them.
I have a Back-to-Back call from caller to our ucma server to client/operator. When doing a transfer on the leg from caller to ucma, there are a few different results which can happen; the transfer target answers, doesn't answer or ignores the call (ignore/busy button).
I want to differentiate between the later two; busy and no answer. In the ucma application I only get a FailureRequestException with text "The transfer operation failed. For more information, refer to the message data in the exception."
I cannot figure out anywhere in the exception or otherwise how to know the difference between busy and no answer. Both generates the same exception with no obvious parameter saying whichever it is.
Is there any way I can know the reason the transfer failed in this scenario?
I'm not sure if this will help, but if you can get the final non-provisional status code for the invite, a "ignore" end will be a 603. A no answer will be a "480" - altho a 480 (Temporarily Unavailable) can be returned for lots of other reasons.
Also the situation can be confused if the user has more than one endpoint (e.g. Desktop Lync Client and Mobile Lync Client). So you end up with forked requests / responses with only one overall response back to you. Then you may not always be able to tell exactly why the call was terminated.
I actually find it funny you are saying you get a FailureRequestException.
I would be expecting a FailureResponseException. With a FailureResponseException exception you can pull out the status code.
From the UCMA 4.0 exception model msdn page:
FailureResponseException
Thrown when a 4xx, 5xx, or 6xx response was received for a request. This exception contains the ResponseData property, which
contains the complete response including response code, reason text,
headers, and message body. In some rare cases, this may also be thrown
when an error other than a 4xx, 5xx, or 6xx response occurred. In such
cases the ResponseData property is null.
I have an application instance, backed by a web service using OIM Webservices Connector.
This connector is used in a synchronous manner by OIM, so when I create a new account in OIM for this application instance, the webservice calls the partner link's method.
Until the method ends its execution, the OIM screen hangs (as expected).
What seems strange to me is that, no matter the partner link's method executes successfully or not (when it does not execute properly, it throws an exception), the OIM operation actually ignores the exception and completes the operation.
Even if I explicitly throw an exception in the BPEL, I can see the error in the webservice log in weblogic, but the OIM method completes anyway.
What one would expect from a situation like this, I guess, is that OIM could just give an error message on the screen, because the operation failed. But no, OIM ignores the errors and go on.
Then I've tried to change the process definition in Design Console to force the process to stop on any error, setting the flag "required for completion" below
So I think I am missing something here
How can I make OIM abort some operation when the webservice connector throws an exception?
Assuming you're throwing a ConnectorException, check in the 'Responses' tab that you have that exception mapped, and in the 'Task to Object Status Mapping' you're setting the desired target Object Status for the object status setted before.
Let's say that a request is sent to server via xhrPost and server finds that request needs more information to be processed (for example a variable is missing), so, a response is sent back to client informing that request may have not been completely processed and this message is shown in a dialog box.
I was doing it sending from server an HTTP 202 status code, which I believe is not correct, and treating it on load function, where this message was displayed on a dialog box. But if I respond with some HTTP error code (ex: 400) the error is displayed in console (Note: in this case the message is treated in error function), as well as in my dialog box.
What is the best and correct way to do it?
Note that it is called a load handler, not a success handler.
The load hander is for valid, well formatted responses. These can contain a verity of status codes generated by your server side app that indicates success, failure, or something in between.
The error is just that, the server blew up while trying to process the request and whatever you get back is probably not something your widget was written to expect. For this reason, I recommend using the same error handler across your whole app.
The dojo documentation states:
Sometimes xhrGet calls will fail. Often these are 404 errors or server errors such as 500. The error parameter is another callback function that is only invoked when an error occurs. This allows you to control what happens when an error occurs without having to put a lot of logic into your load function to check for error conditions. The first parameter passed to the error function is a JavaScript Error object indicating what the failure was. Dojo doc