U4-5588 - Umbraco 7 intercepts my failed AngularJS HTTP requests

Created by Anders Bjerner 04 Oct 2014, 21:12:39 Updated by Shannon Deminick 23 Feb 2017, 04:50:31

Tags: Unscheduled PR

Umbraco 7 has an intercepter for all AngularJS requests made using the $http resource. If a 401, 403 or 404 (but not 500?) error occurs, Umbraco will use the notification service to inform the user about the failed request.

This works fine for most requests, but I have a scenario where my WebApi controller reflects the status code of an underlying API call. If the underlying API returns with a 404 status code, so does the method in my WebApi controller.

My intention is then to handle any errors in my controller to integrate the error response into my property editor. This is quite easy, but since I'm handling the error myself, I no longer want Umbraco to trigger a notification.

I haven't found a way to disable the notification without modifying the core JavaScript files of Umbraco. I could return a another status code, but IMO it will me most correctly to reflect the status code of the API call.

So this is my proposal

The intercepter is located in this file: https://github.com/umbraco/Umbraco-CMS/blob/eae00873073f20c60e355ec6e95ff6259ad2652b/src/Umbraco.Web.UI.Client/src/common/security/interceptor.js

At line 22, the following code could be added:

if (originalResponse.config.stayAwayFromMyRequest === true) return promise;

Then when I'm making my request, I could do something like the following:

var http = $http({
    method: 'GET',
    url: '/umbraco/api/MyController/GetUrlResponse',
    params: {
        url: $scope.url
    stayAwayFromMyRequest: true

Since this is something extra you will have to do for your requests, all existing calls will not be affected, but it gives developers some extra control.


Anders Bjerner 04 Oct 2014, 21:23:37

Created a pull request for the change: https://github.com/umbraco/Umbraco-CMS/pull/502

Anders Bjerner 28 Jul 2015, 17:40:56

@Shandem I can see that you initially set this as due in 7.3.0. Why isn't in so anymore?

I know that you guys want to test new things as best as possible before adding them to the core, but this is a tiny change that will give more control of AJAX requests to package developers. As far as I can see, this won't affect (break) existing solutions.

So I really hope this could make it to 7.3.0 :D

Anders Bjerner 16 Feb 2017, 18:24:55

I hadn't noticed that my pull request was closed - at least not until now :o

Since the pull request is still relevant, I've created a new pull request here: https://github.com/umbraco/Umbraco-CMS/pull/1761

Shannon Deminick 17 Feb 2017, 00:54:57

Why not just use the functionality that is already there and set a header: "x-umb-ignore-error" ?

Anders Bjerner 17 Feb 2017, 01:01:13

I thought about that. But isn't that checking against a header sent by the server? In most situations the developer will probably also have control over the endpoint being called, but checking against the $http config also lets developers ignore errors in situations where they're not in control of the endpoint being called.

Shannon Deminick 17 Feb 2017, 01:43:37

I don't think so, the notes say: "this will be based on an original header set" Also, if you use $http calls and handle your own error, does the interceptor even fire?

Anders Bjerner 17 Feb 2017, 12:40:01

@Shandem I had missed that. Did some more testing, and can confirm that it is the request headers, and not the response headers as I thought.

So technically the header solution does what I had in mind, and as such my pull request and this issue could be closed. But I also can't help to think that the header solution a bit wrong - eg. why send a header to the endpoint when we only need it locally?

Regarding your last question, Umbraco's error handler is triggered even though I have my own error handler (unless I need to handle errors in a different way). Eg. if you see my example below, I have added two error handlers to the premise, and both are invoked.

    url: '/umbraco/api/404',
    headers: {
        //"x-umb-ignore-error": "ignore"
    //umbIgnoreErrors: true
}).error(function() {
    console.log('OH NOES!');
}).error(function () {
    console.log('OH NOES!!!');

Shannon Deminick 20 Feb 2017, 02:32:23

The .error handlers in angular are deprecated, can you try to use the normal approach of specifying a function callback for errors? https://docs.angularjs.org/api/ng/service/$http

Anders Bjerner 20 Feb 2017, 17:51:42

That doesn't make any difference. If I change my code to the snippet below, Umbraco will still show it's 404-notification:

    url: '/umbraco/api/404',
}).then(function successCallback(response) {
}, function errorCallback(response) {
    console.log('OH NOES!');

Shannon Deminick 22 Feb 2017, 02:37:33

Ok, thanks for having a look, i see you've made the name umbIgnoreErrors which is much better than: stayAwayFromMyRequest, i'll pull this in.

Shannon Deminick 22 Feb 2017, 02:39:34

Just added a note to your PR, needs a null check

Anders Bjerner 22 Feb 2017, 16:34:36

The property was named umbIgnoreErrors in the initial pull request as well (only the issue had the name stayAwayFromMyRequest - merely for illustrative purposes :D).

Anyways, I have now updated the pull request with some improved validation. However I don't think config can ever be null (if you see line 30 in the old file, the code doesn't check if config is null either). And at line 24 it doesn't actually check whether the headers property is null either. Agree? The updated pull request now checks for whether both properties are null.

Shannon Deminick 23 Feb 2017, 04:49:53

ah yes i see, I was just looking at your code changes and noticed that it null checked so assumed that would need to be the case. All good,i'll pull in.

Priority: Normal

Type: Bug

State: Fixed


Difficulty: Very Easy


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.0.0, 7.1.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.1, 7.2.0, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7

Due in version: 7.5.11

Sprint: Sprint 53

Story Points: