Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

error callback won't execute #4

Closed
L42y opened this Issue · 9 comments

3 participants

@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
Owner

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
Owner

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.

@acido69

@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
Owner

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.

@acido69 acido69 referenced this issue from a commit in acido69/angular-http-auth
@acido69 acido69 fixes #4 - add improvement for enabled()/disabled() in particular case 0c9d4c3
@acido69

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
Owner

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
Owner

Resolved: #10

@witoldsz witoldsz closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.