I have created a route that via a splitter does multiple lookups, aggregates the responses and returns the list of objects.
I use a remote proxy to invoke the route.
Given that there are multiple branches on the route it is possible that some will succeed and some will fail. How can I get all the returned results but also a list of failures, with reasons for failures, from the remote proxy?
I can think of 3 options, but hope there is something cleaner
Use a header structure that is passed in with remote proxy call to collect errors
Wrap the return value of the remote proxy in structure that contains results and errors
Route errors to some error endpoint (not sure how to correlate with my request though)
Are there any other options?
I would go with option 3. Route all the errors to a generic error endpoint where you log the errors and return some default response. That way you can refer to that generic error endpoint from all your branches ensuring they will all react the same way whenever they encounter an error.
You should be able to get exception details in Aggregation strategy class and accordingly take action.
It depends on what you want to achieve from overall design. As a general practice, if you want consumer of your remote practice to fail on errors, it should get the exception details immediately. If your remote proxy is a REST Endpoint, it can return with 500 error. And similar strategy can be followed for other protocols.
Related
I am interested in the best practice for handling errors in the Google Action SYNC handler.
I see in the docs that I can return an errorCode in the SYNC response, however, none of the documented error codes seem to be compatible with the SYNC handler, only QUERY, EXECUTE, etc.
I see that the SYNC response must contain a userAgentId or the Action service deems it an invalid response, however, what happens when I am unable to authenticate the user and I am unable to determine and ID for them?
In that case, should I simply provide an empty string for that property?
Should I just response with an empty object {} in the response when I encounter an error?
Any info is helpful, thanks.
Of all the listed error codes, not all of them may make sense but some like relinkRequired could be useful.
More specifically for you, in the case that the authentication process fails that error should come from the OAuth link. Your account linking, when presented with an incorrect user, should fail at that point and not proceed with sending a SYNC response.
I understand that Azure standard Stateful Logic app workflow runs Asynchronously but can i use stateful standard logic app for the below scenario:
We want to receive Json data from the third party in a HTTP post request, then process it and store it in Azure data lake. But the problem is since Azure standard stateful workflow runs asynchronously as soon the http trigger is hit it returns Status 202 Accepted. I want to send the caller end status of the request. For example- I want to send 500 Internal server error when the request was valid but still the workflow failed due to an internal error. If the data was processed successfully i want to send the caller HTTP Status 200 Ok. I dont want to send always HTTP status 202 Accepted to the caller. I want the caller to know what exactly happened to their HTTP request. Is it possible through standard logic app? I dont want to use consumption Logic app because of security reasons.
You can achieve this using runafter configuration by enabling this configuration it runs even after the whole workflow is getting failed.
Go to your work flow and select Menu for the action you want to run regardless if the previous one is about to fail, timeout, or skip. It's Condition in my case, and then 'Configure run after'.
For instance here is my logic app
Here is how my code view looks like :
OUTPUT:
UPDATED ANSWER
In that case, too you can use the same runafter concept with the condition having status code is not equal to 200 as a true statement and continue the flow
Here is the logic app
Here is the output
This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)
I have the following tiny dilemma: I have a backbone app, which is almost entirely route based, i.e. if I do to nameoftheapp/photos/1/edit I should go to the edit page for a given photo. The problem is, since my view logic happens almost 100% on the client side (I use a thin service-based server for storage and validation) how do I avoid issues of the sort of an unauthorized user reaching that page? Of course, I can make the router do the check if the user is authorized, but this already leads to duplication of efforts in terms of validation. Of course, I cannot leave the server side without validation, because then the API would be exposed to access of any sort.
I don't see any other way for now. Unless someone comes up with a clever idea, I guess I will have to duplicate validation both client and server-side.
The fundamental rule should be "never trust the client". Never deliver to the client what they're not allowed to have.
So, if the user goes to nameoftheapp/photos/1/edit, presumably you try to fetch the image from the server.
The server should respond with a HTTP 401 response (unauthorized).
Your view should have an error handler for this and inform the user they're not authorized for that - in whatever way you're interested in - an error message on the edit view, or a "history.back()" to return to the previous "page".
So, you don't really have to duplicate the validation logic - you simply need your views to be able to respond meaningfully to the validation responses from the server.
You might say, "That isn't efficient - you end up making more API calls", but those unauthorized calls are not going to be a normal occurrence of a user using the app in any regular fashion, they're going to be the result of probing, and I can find out all the API calls anyway by watching the network tab and hit the API directly using whatever tools I want. So, there really will be no more API traffic then if you DID have validation in the client.
I encountered the same issue a while ago, and it seems the best practice is to use server-side validation. My suggestion... Use a templating engine like Underscore, which is a dependency of Backbone, design the templates, and for those routes that only authenticated users or those with rights to do so, can access... you ask the server for the missing data (usually small pieces of json data) based on some CSRF token, or session_id, or both, (or any other server-side validation method you choose), and you render the template... otherwise you render a predefined error with the same template... Logic is simple enough...
Right now I've got Spring Security protecting an application using basic authentication. The user details are coming from a JDBC source. If the database goes down, the internals of the user loading mechanism will throw a DataAccessException. The default authentication provider class, DaoAuthenticationProvider, catches the exception and maps it back to an AuthenticationServiceException. The end result of such a mapping is that the browser/client receives HTTP code 401.
What I want to do is to handle database unavailability in a different way. At the very least, I want this to be handled by responding with HTTP 503 but I would prefer if it redirected to an error page. How can I achieve this?
EDIT: Ritesh's solution was partially correct. The missing steps apart from implementing your own Basic entry point is to also use v3.0.3 of the security schema so that the <http-basic/> element has the entry-point-ref attribute. If you don't use this special attribute, the default Basic filter will always use its own Basic entry point implementation.
The BasicAuthenticationEntryPoint sends 401 for AuthenticationException. You can create your own custom entry point to handle AuthenticationServiceException and send out 503.
Other option is not to do anything in entry point and use SimpleMappingExceptionResolver and/or implement your own HandlerExceptionResolver.