Access Tokens expire in 60 days, Starting May 18th

Just in from Groundspeak

Am I understanding this correctly that on May 18 the vast majority of GSAK users will find that their access to the API is disrupted?

And not just GSAK but also all apps on smartphones?

This is by design?

Hmm.. Does this mean EVERY 60 days? (That's what I would assume from the text.)

-Stephen

And not just once, but every 60 days.

While this will be an inconvenience, I can see where they are coming from. Many systems have password ageing or cookie expiry dates, so you need to re-login (or even change passwords) every once in a while.

So far, the token system needed explicit revoking of a token which meant that in theory, you might authorize a third party app/web site to have access to your gc.com account, then after a short tested decide it wasn't for you and if you didn't explicitely revoke the authorization, that token would stay valid indefinitely.

This change will make sure any unused tokens will expire after 60 days.

From a user experience point of view, this is annoying, from a security point of view it is long overdue.

I haven't yet made up my mind which pov has more weight for me ;-)

Edit: x-post with TheWinterTrio

This post has been edited by sbeelis on April 30, 2015 01:20 pm

So does this mean the all members must log out of geocaching.com and then log in again !!!!

OK a slight inconvenience for GSAK as you need to click a couple of buttons to get a new access token 6 times a year, which I do far more regularly anyway while uploading caches from my GPSr.

Might be more of an issue for mobile app users but at least it's still free (oops, let's not give them ideas).

The greater inconvenience are for those who got Access tokens for more than one account in GSAK, but I agree with sbeelis the security aspect of the decision is probably sound.

I could see this being done for tokens not used for 60 days, but active tokens. My bank doesn't even force me to change passwords that often.

You shouldn't have to log out of Geocaching.com (but make sure you have installed the latest patch), but you need to fetch another token. Doing so will bring up the Groundspeak dialog asking you to Authorize the use of the api, which in tern will ask you for your log in details.

Could this (fill in my account details) be done by GSAK itself?

Hans

This post has been edited by HHL on April 30, 2015 07:34 pm

Could this (fill in my account details) be done by GSAK itself?

It might be feasible from a technical point of view, but it would defeat the whole purpose of OAuth authorisation, where a third party application (in this case GSAK) can identify itself against groundspeak as "you" without the need to know your password.

Actually, that would be a good compromise to discard stale tokens without inconveniencing regular users of an app.

Actually, that would be a good compromise to discard stale tokens without inconveniencing regular users of an app.

Drop them an eamil at <apihelp@geocaching.com>, and tell them that. I did. It may not do any good, but if they hear from enough regular users, it may cause to frog to jump.

Here's what I got back from GC.com (David Patterson <davidp@geocaching.com>)

What a pain. They're worse then my bank, or PayPal, or anyone else. I can't think of anyone else that forces you to do something like this. Kind of over kill.

I predict the number of posts regarding API errors will take a large up turn after the 18th. I bet you the GS apps will not be affected.

Hopefully the feature that Clyde added to GSAK 8.5.1.17 will help:



However, we know that not all users update to the latest patch and that not all users read the messages that pop up, so I fear you are correct that the support load will increase.

I also noticed that if you revoke your access token (to simulate an expired token) and attempt a multistep API action (e.g. Get Recent Logs on multiple caches), you get this error for every API call even after you've reauthorized GSAK, which is likely to make users think things are still broken. If you terminate the current API action and start again, everything works fine.

Clyde - is it possible that GSAK is not using the correct (new) token in this scenario (i.e. when you start a series of API calls with a bad token and grab a new token mid stream)?

Have emailed api help address as suggested. The thing that is going to hack me off is that I've 3 instances of GSAK and 2 android apps on a tabled and phone so looks like I'm going to be requesting a new token every 12 days . . . . .

I suspect that there is more to this than the email from Nate alludes to......

This post has been edited by Big Wolf on May 01, 2015 07:05 am

If I read this correctly *all* tokens older than 60 days will become invalid on the same day, so it will be all your copies all on the same day, assuming they are all older than 2 months, starting on May 18th, then every 60 days there after.

Or you could manually redo all tokens on the same day so it is only a once every 2 month thing for you.

This post has been edited by Knightyme on May 01, 2015 06:40 am

Think that is going to be the solution

Because this change will cause some Macros to crash unexpectedly, it would be good if Clyde could code a way of tracking Token age and alerting the user at startup and ideally also, a macro function that returns the number of days left for the current Token.