1

I have a page in which I am using a jQuery ajax method to call a simple Webservice which will get some data from the database and bind it to some controls in the page. The ajax method is called on the onchange event of select (here the HTTP request is POST). Following is the jQuery ajax method

function CallAjax(url, jsonData, SucessFunction, FailurFunction) {
$.ajax({
    type: "POST",
    url: url,
    data: jsonData,
    contentType: "application/json; charset=utf-8",
    dataType: "json",
    success: SucessFunction,
    error: function(){
       alert('error occured');
    }
});

}

The URL for above method is somepage.aspx/getDataFromDatabse where getDataFromDatabse is the webservice method. Our testers are testing the page using burp suite. When they are directly tying to access the url(www.example.com/somepage.aspx/getDataFromDatabse) in the browser, the HTTP method shown in burp suite is GET and an error is raised and the user is getting redirected to the appropriate page. But when they are directly accessing the above URL and intercepting the request in burp suite and changing GET request to POST request the following error message is displayed directly in the browser:

{"Message":"There was an error processing the request.","StackTrace":"","ExceptionType":""}

The "error" in the above ajax function is not getting executed and the alert box is not shown and we are able to handle the error. How to handle such an error and redirect the user to a custom page?

1 Answer 1

1

It would appear that the response from your server is a valid JSon response, despite the fact that it contains what (to you) reads as an error. As such the $.ajax(...) call is handling the response as a success, not an error.

You can return a valid JSon response and within that response indicate whether there was an error or not, along with any additional info such as a user-friendly error message, a redirect URL, etc.

The error: handler of the $.ajax(...) call should be used for real server response errors (i.e. unhandled 500 errors, timeouts etc.)

For example, your successful JSon response could be something like:

{
    success: true,
    errorMessage: null,
    errorRedirectUrl: null,
    data: { .... your successful data response .... }
}

and your failed JSon response (e.g. due to validation problems, not server failures) would look like this:

{
    success: false,
    errorMessage: 'There was an error processing the request.',
    errorRedirectUrl: 'http://....someurl...',
    data: null
}

Then you check for response.success == true in the success: option of the $.ajax(....) call, and handle appropriately.

By having a single, consistent structure the success: option handles all ajax requests which complete and then determines whether there was a handled error and what to do with it, such as display an alert to the user, redirect them to a URL, etc...

In contrast, the error: option handles only those ajax requests which didn't come back with a response you can use.

Update:

On your server you are already handling the difference between receiving a GET http request and a POST http request. So, I think your problem is that you also need to detect whether the POST request contains valid data in the format the webservice method needs.

So, your web service needs to decide if the POSTed data in the http request is in a format it expects to receive and if not return an HTTP redirect response (302) rather than returning the error.

You could do this in 2 ways:

  1. Using a Try... Catch... block. Your webservice method already appears to be throwing an exception and returning it, so catch it and then instead of returning it, set up and return a 302 response instead.

  2. If genuine calls to the webservice can generate exceptions under normal operations (this is usually bad!) you'll need to validate the data received in the request to see if it is what the webservice method expects to receive (was data received? was it the right structure as would be sent by the ajax request? etc.)

Note: if the request does contain valid data then there is no easy way to detect whether this came from a genuine source (the ajax call) or a forged request by some other means. There are solutions to this, but they are involved and can require multiple calls for authentication etc.

Sign up to request clarification or add additional context in comments.

6 Comments

the ajax method is getting called only on the onchange js event of a select (dropdownlist) html control. But when the url of the service method (www.example.com/somepage.aspx/getDataFromDatabse) is is directly entered in the browser and accessed and GET type is changed to POST through burp suite, it is returning a valid JSON result as you said, but no jquery ajax method is getting called to handle this JSON result and the JSON result is directly displayed by the browser in plain text. How to handle this?
@ghouse - If I am understanding you correctly, as you are entering the URL into the browser (and changing the method to POST) the jquery $.ajax(...) is never being called, so it will not be listening for a response. Perhaps I am not understanding your question fully?
you are correct, because the jquery $.ajax(...) is called only on onchange, it is not called when the URL is accessed directly in the browser and since GET is changed to POST, it is directly displaying the above message in the browser in JSON format.
Ok good. So this is expected behaviour. Are you trying to achieve something else? If so, could you clarify your question further? Or if your question is now answered, feel free to accept.
I want to redirect the user to another page and not display this message {"Message":"There was an error processing the request.","StackTrace":"","ExceptionType":""} directly in the browser, how can I achieve this?
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.