witoldsz / angular-http-auth

MIT License
2.38k stars 417 forks source link

A clearer, more flexible means of ignoring URLs #13

Closed mbrio closed 11 years ago

mbrio commented 11 years ago

The previous pull that was accepted into angular-http-auth was flawed in three ways:

  1. The naming scheme was terrible, migrated to .when() for configuration which matches Angular's own $httpBackend class in ngMockE2E
  2. When ignoring URLs it still fires the auth-loginRequired event
  3. The previous configuration was pretty flexible but with the lack of a deferred object passed to the handler it was unable to modify the behavior. This is best explained in an example. You most likely would want a 401 to be ignored from a login form. In the previous configuration you would add that URL to the ignore list. Because the deferred object was not rejected you could not handle the error from the login form through the $http.get().error() method because the deferred object was not rejected. With this new configuration you could reject the deferred object and thereby allowing the controller to display an error message like "Incorrect Credentials"

You can see an example of this in practice: https://github.com/qloo/angular-authentication, be sure to bower install to get the dependencies in and view the example/index.html file.

witoldsz commented 11 years ago

Hi, I am sorry, but I must close this without merging. I like your approach which adds infinite flexibility to the handler, but the problem is it now becomes too complicated. OK, this is subjective, let me explain.

The thing is, the original solution was much simpler, and I was not once asked about how it works and how should it be used, etc... It was already hard for many to follow. Now it becomes an order of magnitude more complex (the price of flexibility).

The question is: do we need such a flexibility if all the original solution was missing was a kind of a "flag" to be attached to some specific requests, so they would go through the interceptor without being noticed?

Another question is: wouldn't it be easier, for some specific case, to write a dedicated (case-specific) HTTP interceptor instead?