Feature request: redirect / logout on expiration

[CD-UNCC]

Love the plugin. I think it would be great to be able to set a redirect or function for when the JWT expires. The Nav bar will update automatically and auth: true routes will vanish. But if you are on an authenticated route when the token expires you can simply remain there.

[apawsey]

Second this. I was about to ask if you have any tips on how to handle expiration? My understanding is it'll only be triggered when you try to navigate somewhere, but the token will still exist in storage, so surely all we need to do is redirect if token exists but has expired? If that logic makes sense, I'll try and do a PR for this.

[paulvanbladel]

Cool, thanks for making a PR.

[CD-UNCC]

@apawsey What I did was in authentication.js line 129
Make a check for Math.round(new Date().getTime() / 1000) <= exp;

If the token has expired in this check a getLogoutRedirect should be added at the top of this file that looks in the config file just like the login redirect does. Otherwise you can just call logout.

if (exp) {

    if(Math.round(new Date().getTime() / 1000) <= exp){
        return true;
    }
    else{
        this.logout();
        return false;
    }
  }`

In the future I may ask to remain logged in when expiry is approaching and call to renew the token. Similar to banking sites. Hope this helps!

[stuartbale]

Has anyone implemented a solution to this?
I'm interested in knowing how others have intercepted when a token is about to expire and enable a user to 'refresh' the token.

[CD-UNCC]

@stuartbale aurelia-auth is constantly checking the expire time of the token and you can incorporate your custom logic there. See my above post.

authentication.js line 129

Here you can change the conditional to fit your needs.

[don-bluelinegrid]

@CD-UNCC
I don't think that "aurelia-auth is constantly checking the expire time of the token" - according to the code for tokenInterceptor(), this check is only being made during AJAX requests, by a request interceptor. It is similar to @apawsey 's statement that the check is done on navigation - but not exactly, because this check is done on request -> and the only purpose of it is to add the "Authorization: Bearer: XXX" header.

@paulvanbladel
Paul -
I've had a similar query, but more generally about the full Oauth2 use case implementation, specifically regarding expiration and "refresh tokens".
My understanding of the OAuth2 intention is that this sequence should occur -

1. Client makes request with accessToken.
2. Server/provider receives request; responds with 401 Unauthorized for expired token, otherwise returns response.
3. If client received 401 Unauthorized response, client re-tries authentication request for token with grant-type:refresh, using refreshToken instead of accessToken.
4. Server returns a new accessToken to client.
5. Client retries original request using new token.

Since this aurelia-auth module is strongly based on OAuth, is there anything in the module to help with this pattern? Or is the expectation that all consumers/developers using the module will implement this sort of logic?

Thanks,
Don

[seagullmouse]

Has anyone fixed and/or forked this as yet?