error callback won't execute

[L42y]

For example, if we replace this function https://github.com/witoldsz/angular-http-auth/blob/gh-pages/app/content.js#L13 with following code:

    $scope.restrictedAction = function() {
      $http.post('data/protected', $scope.restrictedData).success(function(response) {
        // this piece of code will not be executed until user is authenticated
        $scope.restrictedContent.push(response);
      }).error(function() { console.log('forever alone.') });
    }

the error callback will never execute no matter what happen.

In the authentication process, if user enter wrong authentication information, we should get response to know what happens if something is wrong, but here the error callback never been execute.

[witoldsz]

When do you think the error function with 'forever alone' log should execute?

[L42y]

@witoldsz So the code was designed like the way how it works right now? If so, could you please explain me how should I get around the issue I wrote at above? Thank you.

[witoldsz]

I am sorry, but I really do not understand your issue. It seems you want to handle the HTTP 401 error in your controller, but this project is all about handling the HTTP 401 responses in such a way that this is all invisible to $http customers. Your controller does not log "forever alone", because the error never happened from it's point of view. Yesterday I wrote a small manual, this is a link to a snapshot: https://github.com/witoldsz/angular-http-auth/blob/5638403468f751c66097b668a95c94131ed3c40c/README.md (in future you may check history for newer versions of that file, if any)

I hope it explains your case. Let me know.

[L42y]

Yes, you're right. In my case, the situation is that when authentication has failed (not when someone enter an unauthorized area), API will return a error message describing why it's failed such as password is wrong, the problem is that I don't know how to get that error message.

[jimmy-collazos]

@L42y I have a same problem; the problem is when intercept htpp status (401); because create and return new "deferred":

....
      function error(response) {
        if (response.status === 401) {
          var deferred = $q.defer(); //create new instance of Deferred
          authServiceProvider.pushToBuffer(response.config, deferred);
          $rootScope.$broadcast('event:auth-loginRequired');
          return deferred.promise; //this is the "problem" !!!
        }
....

I think use this method for call not associate task at the promise; the problem is when try login and need capture response from server for show message to user.

[witoldsz]

There is the if(response.status===401) condition which is basically the main entry point and essence of entire process. If your server uses HTTP 401 to communicate the login attempt has failed, then either change the status or extend the if(...) condition, so it will not process the particular situation of yours.

[jimmy-collazos]

I do send "pull request" for enabled/disabled in this particular case.

Example:

angular.module('app')
  .controller('Login', ['authService', function(authService){
    authServiceProvider.disabled();
    //.... in login response OK
    //authServiceProvider.enabled();
  }]);

[witoldsz]

I am sorry, but I cannot accept this. I can't see the reason for such a weird solution: why do you expose enabled/disabled methods? Who, when and why should call these methods? (BTW: method names: enabled, disabled does sound like a question or statement, not a command). Is it suppose to be a workaround? What if there are other requests going on, and suddenly those request will start throwing 401 exceptions, because someone has temporary disabled the authService?

If all you want is to make interceptor to ignore specific requests (login requests in your case) then maybe it would be better to "mark" those requests and let interceptor ignore only the marked ones? Or to setup the provider with resource patterns to be ignored? Wouldn't it be much more obvious?

[witoldsz]

Resolved: https://github.com/witoldsz/angular-http-auth/pull/10