Page does hard refresh when session invalidated

Question

Page does hard refresh when session invalidated

Redsandro opened this issue 6 years ago · 27 comments

When token-refresh fails, or is too late, or the session invalidates (automatically or manually), the page does a hard refresh. How do I stop this?

I still want to "change" my app, so an event would be nice, but I do not want a hard refresh. This is a SPA.

I'm using authenticator:jwt and mistakenly posted an issue here: myartsev/ember-simple-auth-jwt#52

Answer 1 · 2019-03-07T17:29:57.000Z

@Redsandro This library never does anything to cause a page refresh. Can you post the code needed to reproduce this behavior so I can take a look?

Answer 2 · 2019-03-08T16:01:53.000Z

Triggering sessionDataInvalidated causes a hard refresh for me. Here are my environment.js settings:

	ENV['ember-simple-auth-token'] = {
		serverTokenEndpoint: `${ENV.APP.API}/token`,
		serverTokenRefreshEndpoint: `${ENV.APP.API}/refresh`,
		tokenExpirationInvalidateSession: true,
		refreshAccessTokens: true,
		refreshLeeway: 10, // 300,
	}

When token-refresh fails (handleTokenRefreshFail):

https://github.com/jpadilla/ember-simple-auth-token/blob/65435bd7ddc579382276fb276132a722b8813499/addon/authenticators/jwt.js#L316-L319

And when the session expires (handleAccessTokenExpiration in the case of tokenExpirationInvalidateSession: true):

https://github.com/jpadilla/ember-simple-auth-token/blob/65435bd7ddc579382276fb276132a722b8813499/addon/authenticators/jwt.js#L347-L349

This causes invalidationSucceeded to be triggered upstream.

https://github.com/simplabs/ember-simple-auth/blob/0ab8847ed94812c391f66f79c645127abd771f95/addon/internal-session.js#L141

But I am not extending it. I don't know why the refresh happens.

Answer 3 · 2019-03-08T16:08:56.000Z

@Redsandro Are you able to provide a complete example of this behavior? I can't reproduce the behavior with the information provided and I don't see anything that would cause this behavior. In all of my applications using this library, there is not a hard refresh when invalidationSucceeded is triggered.

Answer 4 · 2019-03-08T16:17:22.000Z

@fenichelar it's not easy because some code is not mine/libre, and I would need to spoof the backend and everything.

I will explore opinions from upstream first. If I can't get a hint as to what might cause this, I will go the extra miles. Although there has to be a way to listen for an event and track what triggered it.

Answer 5 · 2019-03-08T16:21:09.000Z

@fenichelar said:

In all of my applications using this library, there is not a hard refresh when invalidationSucceeded is triggered.

That's interesting, because I got word from upstream that:

Reloading is ESA's default behavior

How do your apps prevent it from happening?

Answer 6 · 2019-03-08T16:28:57.000Z

Wait, just to be clear... are you using both TokenAuthorizerMixin and ApplicationRouteMixin?

Application adapter:

import TokenAuthorizerMixin from 'ember-simple-auth-token/mixins/token-authorizer'

Application router:

import ApplicationRouteMixin from 'ember-simple-auth/mixins/application-route-mixin'

Answer 7 · 2019-03-08T16:36:05.000Z

On closer examination, I don't believe invalidationSucceeded is actually being called in any of my applications.

I am using TokenAuthorizerMixin but I am not using ApplicationRouteMixin.

Answer 8 · 2019-03-08T16:44:48.000Z

I take it back, I think invalidationSucceeded is called it just doesn't do anything.

Answer 9 · 2019-03-08T16:48:07.000Z

invalidationSucceeded is called it just doesn't do anything.

Ah, okay, I get it. That's because you don't use the ApplicationRouteMixin.

I think I might be using this wrong. I assumed I needed ApplicationRouteMixin for handling the session and the automated refresh_token business.

~~I only need TokenAuthorizerMixin? It will handle the session refreshing? I can remove ember-simple-auth? It's not a dependency/requirement?~~

Indeed, ApplicationRouteMixin is optional. Do I even need to install ember-simple-auth next to ember-simple-auth-token, or can I remove it entirely?

Answer 10 · 2019-03-08T17:03:54.000Z

(Btw, setting refreshAccessTokens to false does nothing, it will still refresh tokens.)

Answer 11 · 2019-03-08T17:20:47.000Z

ember-simple-auth is a required dependency of ember-simple-auth-token. You don't need to manually install it or add it to your package.json.

Answer 12 · 2019-03-08T17:24:06.000Z

I just did a quick test with refreshAccessTokens set to false and it did not attempt to refresh the token. Can you show me your config?

Answer 13 · 2019-03-09T02:33:47.000Z

	ENV['ember-simple-auth-token'] = {
		serverTokenEndpoint: `${ENV.APP.API}/token`,
		serverTokenRefreshEndpoint: `${ENV.APP.API}/refresh`,
		tokenExpirationInvalidateSession: true,
		refreshAccessTokens: false,
		refreshLeeway: 10, // 300,
	}

JWT session expiration time is 15 seconds, and refreshLeeway 10, so that I only need to wait 5 seconds to test this out.

Answer 14 · 2019-03-12T20:35:01.000Z

I can't seem to reproduce this, can you provide a working sample?

Answer 15 · 2019-04-19T14:22:43.000Z

Closing. Let me know if you still have this issue.

Answer 16 · 2021-04-29T18:25:30.000Z

It's doing this to me too. Somewhere in the code it's triggering a hard refresh and losing the token state.

This only happens locally for me.

Answer 17 · 2021-04-29T18:26:46.000Z

I've tried just copying the local storage from my production app (as it's pointing to the same database) but that gets replaced immediately. No errors anywhere in the logs.

Answer 18 · 2021-04-29T19:31:34.000Z

@allthesignals

What version of ember-simple-auth-token are you using?
What version of ember-simple-auth are you using?
What version of ember are you using?
Are you using either of the mixins?
What is in your ember-simple-auth-token config?
Can you provide a sample app that can reproduce the hard refresh?

Answer 19 · 2021-04-29T19:42:31.000Z

@fenichelar thank you so much for replying I really appreciate it.

"ember-simple-auth": "^1.8.0",
"ember-simple-auth-token": "^4.0.6",
```
ember: 3.15
```
Using many many mixins but still using the classic object model including TokenAuthorizerMixin

    'ember-simple-auth-token': {
      serverTokenEndpoint: `${getHost(environment)}/auth/v1/login`,
      refreshAccessTokens: false,
      tokenExpireName: 'exp',
      tokenExpirationInvalidateSession: true,
    },

This thing is a behemoth so not really but the repo is available here https://github.com/NYCPlanning/ceqr-app

What is mysterious to me is this behavior doesn't occur in production: https://www.ceqr.app.

Further context, I've inherited this app and am unsure how to proceed. I just cannot get it to authenticate. Attempts to cUrl the login endpoint in the backend work fine — they return the token. I can even observe a 200 OK response in the frontend. But I get a "transition aborted" — unless it's a red herring, it seems to be interrupting and I don't know why.

Answer 20 · 2021-04-29T21:28:06.000Z

@allthesignals Thank you. I'm not completely following what the issue is. Can you walk through what is happening in a little more detail?

Answer 21 · 2021-04-30T17:07:00.000Z

@allthesignals Thank you. I'm not completely following what the issue is. Can you walk through what is happening in a little more detail?

Yes, here's what I'm observing:
https://user-images.githubusercontent.com/5004319/116729040-ae651680-a9b4-11eb-9e8c-fc07927cf69e.mov

This is local development. When I successfully login (I am confirm through backend logs), it seems to try to transition to a new route, but does a hard refresh instead. This hard refresh causes the token to never be persisted in memory in the application instance.

This doesn't seem to occur in the production deployment of the site.

Even a vague guess at what is causing this would help...

Thank you!

Answer 22 · 2021-04-30T17:25:54.000Z

Can you expend the transition aborted console log and provide the full output?

Answer 23 · 2021-04-30T17:35:33.000Z

Can you expend the transition aborted console log and provide the full output?

Yes — I don't think it's very helpful though. I think something more serious is being buried... let me see if I have an error hook in a route somewhere:

Answer 24 · 2021-04-30T17:43:11.000Z

Ah, here's some more information (There indeed was an error hook swallowing up valuable information):

Okay, so the transitionAbort error might be happening because of an immediate 401:

So that invalidates something probably and causes a refresh or navigation to login? Looking at the XHR history is interesting:

What's odd about the "successful" login request is that it fails to load the response data?

I'm not sure if this is even how browsers behave, but perhaps there's some race condition.

EDIT:

Plot thickens... this.session.authenticate throws the following:

TypeError: Cannot read property 'email' of undefined
at Class.sessionAuthenticated (labs-ceqr.js:20510)
at Class.superWrapper [as sessionAuthenticated] (vendor.js:49590)
at Class. (vendor.js:166708)
at sendEvent (vendor.js:31263)
at Class.trigger [as _super] (vendor.js:46377)
at Class.trigger (vendor.js:167293)
at Class.superWrapper [as trigger] (vendor.js:49590)
at Proxy. (vendor.js:167264)
at sendEvent (vendor.js:31263)
at Proxy.trigger (vendor.js:46377)

Answer 25 · 2021-04-30T18:39:53.000Z

Can you expend the transition aborted console log and provide the full output?

You can disregard this now... I think this had to do with some weird dep resolutions issues for fetch (competing with jQuery maybe?) The particulars of the faulty fetch shim I was using were probably interfering with how ESA-token makes requests.

Answer 26 · 2021-04-30T19:50:42.000Z

@allthesignals Is everything working now or just the transition?

Answer 27 · 2021-05-03T14:14:33.000Z

@allthesignals Is everything working now or just the transition?

Everything is working now but my advice (or shot in the dark) for others would be to make sure there are no weird issues with ember-fetch. The fix described in that issue thread seemed to cause the issue. I got around it by switching to an earlier version of node.