_handleNewBearerToken() florps on .slice()

[shaunanoordin]

Weird Glitch Detected?

I ran across this weird glitch while working on some ASM updates. Essentially, after returning to an idle webpage after 2 hours, the Panoptes Client goes, "Hmm, time to renew the bearer token" then suddenly goes "BLARP I'm dead"

While I fully expected the token to die after a lengthy timeout (this is why I went on a 2 hour tea-drinking binge, after all - for science! ) I didn't quite expect to see how it died: the code crashes at oauth._handleNewBearerToken()'s console.log() line, which attempts to .slice() an undefined

Debug Details

Setup: OSX+Chrome, panoptes-client 2.9.2

Steps taken:

1. At 5pm I am logged in to Anti-Slavery Manuscripts, development, on localhost:3000. Computer is put to sleep. (ASM window is not closed)
2. Two hours are spent attempting to create the perfect blend of chamomile and chrysanthemum.
3. At 7pm computer is reactivated. ASM window is viewed again.
4. I notice the following new logs in the console, timestamped at 7pm:

- Deleting bearer token
- Found existing Panoptes session
- Panoptes session has expired
- TypeError: Cannot read property 'slice' of undefined
    at Model._handleNewBearerToken (oauth.js?13a0:260)
    at Model.eval (oauth.js?13a0:276)
    at <anonymous>

Expected: After 2 hours of non-activity, login token (user session) should expire - any attempt to conduct user-only Panoptes requests should fail with a 401 or similar.
Actual: Exactly as expected, but with weird bonus console errors.

The ASM page when accessed after 7pm. Note the console messages.

The ".slice() of undefined" error traced to the oath.handleNewBearerToken() code

Analysis:

• The error seems to happen at the line: console.log('Got new bearer token', tokenDetails.access_token.slice(-6));
• Presumably, oauth._handleNewBearerToken() received the tokenDetails object, but for some reason it was missing the .access_token property. (I was unable to trace what the value of tokenDetails was, unfortunately.)
• This is worrying since the console.log() is the first line in the _handleNewBearerToken() function, meaning everything else in the method would have died, and the method returned nothing.
• That said, I'm pretty sure the bigger concern is that the tokenDetails in the method didn't conform to expected data structures. And I'm not sure what's up with that.
• Also, I'm not sure if this is an issue that's already been solved by PR OAuth improvements #82 (which is the basis for panoptes-client 2.9.3), what with the this._deleteBearerToken() no longer triggering before return this._handleNewBearerToken(tokenDetails) in oauth._refreshBearerToken() 🤷‍♂️
• Either way, the code may need to be made robust enough not to crash at the first console.log() statement.

Status

Unknown priority? Help, I have no idea if this is a minor issue, an edge case, or something that needs to be taken care of.

This may be tangentially related to #81, as any attempt to create a better token-refresh system may need to be aware of possible crashing in _handleNewBearerToken's unexpected tokenDetails.

[shaunanoordin]

Hey, I just realised that I might be able to figure out WTF is up with tokenDetails if I peek into my Network tab at around the 7pm mark. brb.

[shaunanoordin]

Request
URL: https://panoptes-staging.zooniverse.org/oauth/authorize?response_type=token&client_id=BLAHBLAH&redirect_uri=http://localhost:3000
Status Code: 302 Found

Response
Date:Fri, 23 Feb 2018 19:09:28 GMT
Location:http://localhost:3000#access_token=eyJ0eXA_super_long_string&token_type=bearer&expires_in=7200

Looks legit? I saved the non-truncated data dump elsewhere in case somebody can make more sense of it than I can.

[eatyourgreens]

D’oh! I updated the URL parsing code to use window.location.hash when the page loads but the iframe code is still using location.href.

[eatyourgreens]

I guess that will be fixed in 2.9.4.