Git Product home page Git Product logo

Comments (8)

witoldsz avatar witoldsz commented on June 23, 2024

Hi,
we need to find some better way of handling such custom codes.
I was thinking about something like adding an option like forceAuthModule; it would work contrary to ignoreAuthModule.

Now, with option like this, you could just insert an interceptor:

.config(['$httpProvider', function($httpProvider) {
  $httpProvider.interceptors.push(['$q', function($q) {
    return {
      responseError: function(rejection) {
        rejection.config.forceAuthModule = (rejection.status === 419);
        return $q.reject(rejection);
      }
    };
  }]);
}]);

If such an interceptor would be registered before the one from this module, it should make it work with 419 codes, I guess.

Another solution would be to provide an option to add some kind of extra "rejection resolver" function, so everyone could amend the way this module triggers, but it would require more changes in code than the first option with simple flag.

What do you think?

from angular-http-auth.

wcyrek-comrise avatar wcyrek-comrise commented on June 23, 2024

Hi, I too am using 419 for expired JWT token much in the same way as OP. It could be useful to have configuration for nonstandard codes, but coding that in myself was not too difficult. If anything, supporting JWTs out of the box would be a much better addition.

from angular-http-auth.

wcyrek-comrise avatar wcyrek-comrise commented on June 23, 2024

Continuing on this issue. I am adding yet another code in addition to 419 (I need something to handle accounts that were logged in but are not yet confirmed accounts, which forces the user to enter confirmation code from email). This seems like also a common use-case for deferment and should have it's own set of events. I now feel that adding both of these use-cases to this module would be useful, since i end up adding the necessary code to app.js and my controller instead of http-auth-interceptor.js, and not having all the code that does similar things in one place is a headache and triggers my OCD :)

Dzienki,

Witek

from angular-http-auth.

wcyrek-comrise avatar wcyrek-comrise commented on June 23, 2024

Ok one more thing that I found useful is using call to authService.loginConfirmed() in the event listener for my custom event auth-confirmConfirmed. But this is not ideal because that call also triggers auth-loginConfirmed event.

Anyway we can split off the part of loginConfirmed that will configure the updater and call httpBuffer.retryAll(updater) from the part that broadcasts the event? That way we can reuse the former without the latter causing possibly unintended behavior. Or maybe we can have the event to be broadcast passed as an optional parameter?

from angular-http-auth.

vlapo avatar vlapo commented on June 23, 2024

@witoldsz What about config property with HTTP status codes for loginRequired and forbidden (401/403 default configuration)? Call it support non-standard HTTP status codes.

Now module support only standardized 401 and 403 HTTP statuses. But I could imagine some project use non-standard HTTP codes.

Of course it is necessary create some kind of module configuration and so on.

from angular-http-auth.

witoldsz avatar witoldsz commented on June 23, 2024

Yes, I like that idea. The only thing to figure out is how exactly the configuration should look like, i.e. what should be hard-coded and what should be open for change.

from angular-http-auth.

vlapo avatar vlapo commented on June 23, 2024

Configuration is very powerful tool and it give us space to create new functionalities. But angular-http-auth is simple module, so I think configuration dont have to be complicated.

loginConfirmed: function(data, configUpdater) {
    var updater = configUpdater || function(config) {return config;};
    $rootScope.$broadcast(config.eventPrefix + 'loginConfirmed', data);
    httpBuffer.retryAll(updater);
},
loginConfirmed: function(data, configUpdater) {
    var updater = configUpdater || function(config) {return config;};
    $rootScope.$broadcast('event:auth-loginConfirmed', data);
    if(config.retryOnLoginConfirmed) {
        httpBuffer.retryAll(updater);
    }
},

IMHO non-standard HTTP codes and event prefix are enough.

from angular-http-auth.

kofronpi avatar kofronpi commented on June 23, 2024

What if you want to include additional interceptors on errors such as 500, etc. ?

from angular-http-auth.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.