Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add checkBearerToken() to OAuth #80

Merged
merged 6 commits into from
Feb 13, 2018
Merged

Add checkBearerToken() to OAuth #80

merged 6 commits into from
Feb 13, 2018

Conversation

eatyourgreens
Copy link
Contributor

@eatyourgreens eatyourgreens commented Feb 12, 2018

Towards #76

Stores an expires_at timestamp with new tokens. Adds a checkBearerToken method that can be used by client apps to check the token, and refresh it if possible.

Tries, as far as possible, to copy the equivalent methods in the Auth module.

oauth.checkBearerToken()
.then(function (token) {
  // I'm probably still logged in
})
.catch(function (error) {
  // refreshing the token failed
}

Keep method names consistent with the Auth module.
Calculate an expires_at timestamp and store it with the new token.
Add a public method to check if the client has a current, valid token. Also add an internal method to check if the stored token has expired.
@eatyourgreens
Copy link
Contributor Author

@shaunanoordin this might help towards your problem with long transcription sessions on Anti-Slavery Manuscripts.

@@ -155,6 +165,15 @@ module.exports = new Model({
].join('');
},

_bearerTokenIsExpired: function() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a new method to check if token is expired? One already existed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a method that works. I'd prefer if the OAuth class has the same API as Auth, so that common code can be consolidated as per the recommendations in #76.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, sorry I forgot you already commented on that.

It never worked, and nothing seems to use it.
@simoneduca
Copy link
Contributor

I'm going to test with SW as part of the review.

@simoneduca
Copy link
Contributor

I haven't waited to see the refresh failure, but this seems to work well. The way I was thinking of handling the failure in SW is to logout the user.
I was thinking of checking the token validity every time the user submits a classification. I think this would work fine for most projects, but I know some SW users can be on a single subject for more than two hours before they submit a classification. In that situation I think a warning to save their work and login before submitting should be enough. Thoughts?

Copy link
Contributor

@simoneduca simoneduca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@simoneduca
Copy link
Contributor

I realised the above discussion belongs on the SW PR.

Copy link
Contributor

@camallen camallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check hook and renew flow LGTM

_bearerTokenIsExpired: function() {
var tokenDetails = JSON.parse(SESSION_STORAGE.getItem(LOCAL_STORAGE_PREFIX + 'tokenDetails'));
if (tokenDetails) {
return Date.now() >= tokenDetails.expires_at - TOKEN_EXPIRATION_ALLOWANCE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is 60s long enough to get a new token via an iFrame on slow network / a slow busy server?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know. What's a reasonable time to allow for Panoptes to respond?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The load balancer kills connections that have not started responding after 60s so in theory it could be up to that long for a refresh promise to fulfill on a slow server.

I prefer to be overly cautious on this as i'm pretty sure slow / late token refreshes have caused some auth issues with ASM. E.g. say if the refresh via iFrame setTimeout is 10s late to fire and the token refresh takes 55s then there is a 5s period where the token will be expired and invalid.

Perhaps add 30s to it to be 180secs or maybe 2 mins?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've bumped it to 5 minutes. I've also been thinking that the solution to the unreliable timeout in #81 is to set the timer interval to the same allowance.

@eatyourgreens eatyourgreens merged commit 8dbd507 into master Feb 13, 2018
@eatyourgreens
Copy link
Contributor Author

Published as 2.9.2

@eatyourgreens eatyourgreens deleted the oauth-check-token branch February 13, 2018 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants