SSO Access Tokens, CharID updates

(Terror InDeep) #1

Hi, I’m currently working on a website, that is heavily using ESI, which means I need both Access token and Char ID to be actual.

Because of how fast both access Token and Char ID are changing, I though of 2 ways to update them. I’m currently using Laravel PHP.

  1. Create a Kron Job that will update all access tokens and character IDs 2 minute before they expire, using the refresh tokens.

  2. Whenever I get sso_status 0 as a response, update the token and ID of the current user and retry the request.

I’m thinking the first one would be better, because I wouldn’t need to retry the requests each time the token expires, but I have no idea how will CCP SSO servers handle a mass update (even 200+ requests) each 20 minute for access tokens and setting a kron job for all the tokens would mean I’ll update even the tokens or inactive users.

What’s the best way to update both Access Tokens and Character IDs, without causing any issues for the SSO/ESI servers?

PS: As caching mechanic, I’m creating a table and just keep the information I get from the requests there, using Refresh Tokens as identifiers (the only permanent id) and if the request time is bigger then the expire time (aka the information expired, and I can make another request), then that row will be deleted, a new request will be made and a new row will be added.

(Blacksmoke16) #2

Character IDs do not change? They are unique to a character.

(Brock Khans) #3

I’ve used laravel to build both my sites. One is public . CharacterID doesn’t change, Once you get the tokens if you hit /verify you get the character id and name back.

I store the characterid,charactername, refreshtoken, accesstoken, expires time and a couple other columns all in one table.

I then have a function called tokenRefresh that checks if the expires time < now(), if so go refresh it, if not just return and continue forward.

Generally I ere on the side of refresh when I need it, not on a set schedule. Granted if you are making constant requests it wouldn’t hurt to have a cron that refreshes every 20 minutes.

(Brock Khans) #4

And I would not key off the refresh_token as those will change if the character reauths (re logs in using your SSO link). You should be keying off the CharacterId that does not change and the tokens are tied to that specific character

(Blacksmoke16) #5

CharacterOwnerHash + CharacterID would be most optimal. CharacterID will never change with that character, and CharacterOwnerHash will only change if that character is transferred to another account, i.e. while it is still the same character it really isn’t due to new owner.

(Mr Twinkie) #6

use the expires in to find out when it expires, store that, than if necessary update on demand.

(Bloemkoolsaus) #7

You can use the refreshtoken to get a new accesstoken even the token has expired. So, just refresh it when you need it. There is no need to “keep it alive”.

(Golden Gnu) #8

It really depends on how often you use the access token.
If you use it more than once every 20min, it may be easier to keep it alive all the time.
If not, it’s may be better to update it on demand.
There is no single right solution that fits all needs…
And it’s okay to make it easy for yourself, if one of the solutions is just easier to do.

(Terror InDeep) #9

Thanks for the replies. I though it’s changing because there was a key called Expires At and I though it’s gonna expire.
I’ll probably use the CharID + Salt as combination and if the salt changes, I’ll notice the user and delete all the prior configurations for that charID.

Probably checking and updating the token on demand is the best idea, especially that I can use Carbon to do the time comparison.


(Blacksmoke16) #10

ExpiresAt key is when the access_token expires.

Yea i agree, refreshing token when needed is best option, is what i do as well. No reason to make those extra calls if that key never get used or seldom gets used.

(system) #11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.