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
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!
When an app fails to handle a Slack slash command, the text is brought back to allow the user to edit it and immediately send it again. I have a slash-command that searches, but might fail to find any results. In that case, I would like the user to immediately be able to modify their search. The Slack docs explain that I should always return a 200 HTTP status, but then Slack also erases the command and the user can't immediately try again. When I tried to respond with a 404 status, the users get an alarming message like failed with the error "http_client_error". Is there a way to fail but also provide a custom message to the user why?
Yes, but you must not use HTTP status codes to community a failed search.
Just always return HTTP OK 200 and then add a response message telling the user what went wrong. You can do that by directly replying to the request from Slack within 3 seconds, or alternatively by sending a message to the response_url.
This is also clearly expressed in the offical documentation for slash commands:
Sending Error Responses
There are going to be times when you need to let the user know that something went wrong - perhaps the user supplied an incorrect text parameter alongside the command, or maybe there was a failure in an API being used to generate the command response.
It would be tempting in this case to return an HTTP 500 response to
the initial command, but this isn't the right approach. The status
code returned as a response to the command should only be used to
indicate whether or not the request URL successfully received the data
payload - while an error might have occurred in processing and
responding to that payload, the communication itself was still
successful. (Source)
As far as I know it is not possible to signal Slack that the user should be able to edit his last command though.
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.
What is the difference between throw new Error and using Meteor.Error()? Is it simply that throw new Error will not be shown to the client, only on the server (the client will get a 500 Internal server error); and Meteor.Error will be sent to the client.
Are there any more differences? E.g. Does one break out of Fibers, stops downstream code?
The main thing with Meteor.Error is like you mentioned
A full stack trace (may not be given by Error always)
Possibility to send the error down to the client, in a limited non revealing form.
Hide the error from the server in certain cases (if its thrown in a method or publish method, and from hooks such as Accounts.onLoginAttempt)
The objects inside are EJSON serialised so a variety of data can be sent down to the client
When a Meteor.Error is thrown, because of the EJSON serialisation you get a bit more information on the server side.
Meteor displays the errors better.
Often you can get [Object object] as the reason to be displayed from ordinary errors when they come from ordinary Errors, from Meteor.wrapAsync
Theres not much else that's different, Meteor.Error is a a subclass of Error with the above changes.
So they'll both stop downstream code. When it comes to Fibers, if the ordinary one is thrown out of a Fiber in any way its likely to stop your app (on the server side & not in a method, startup, Meteor.setInterval, publish, etc)
Its definition is also quite small: https://github.com/meteor/meteor/blob/devel/packages/meteor/errors.js
i'm trying to follow the example code on google's website here, but it seems a little broken - the javascript references getting a list of people from the server, but in the server-side code there's no reference to calling those functions of the api, it just returns an HTTP status code and a text status, so i'm wondering if there's a step missing and i'm exchanging the wrong code at the wrong time.
my current flow is
login button button clicked, magic happens, my callback gets passed an object with a whole bunch of properties in it
I take the code property from that object, and post it back to my server in an ajax request
on my server, i run the following python, where auth_code_from_js is the data of my post request:
oauth_flow = client.flow_from_clientsecrets('client_secrets.json', scope='')
credentials = oauth_flow.step2_exchange(auth_code_from_js)
python throws a FlowExchangeError with the message invalid request and no other useful information
am i missing a step? is that initial 'code' property what i'm supposed to be passing in to the 'step2_exchange' method?