PySpeckle icon indicating copy to clipboard operation
PySpeckle copied to clipboard

SpeckleApiClient stores the authorization token in 2 places

Open tsvilans opened this issue 4 years ago • 5 comments

Further to the discussion in #41 and #42, I want to flag this as an issue.

#42 wraps getting / setting the token in a property, so this is more API friendly. Internally, however, there is still the chance of setting 2 different tokens: one in the Session header and one in the me dictionary.

One solution would be have the token setter set both simultaneously.

The next issue is that me stores both apiToken and token - the former being the long-term token and the latter being the short-term token. How do we decide which to store and use? @izzylys is this - the 2 token variants - still the same for Speckle 2.0?

tsvilans avatar Dec 02 '20 16:12 tsvilans

It seems a bit weird to me to store it in two places in the first place... I haven't used the websockets stuff, but is it possible to refactor this so we only ever have the token stored in one place? If that's impractical, I think using the token setter to set both could be a decent solution as well since a mismatch would be pretty problematic as you can accidentally send to different accounts using the same client.

Tbh I was not clear on the difference two tokens stored in me 😅 In 2.0, getting an account from the local db will just give you a single token (plus a refresh token but, that's not relevant for this).

izzylys avatar Dec 02 '20 16:12 izzylys

Thanks, @izzylys :)

I think in this version of the Cache (local database) there is also only one token, but when you login via the API, you get both token and apiToken. Would this be the same in 2.0? I guess we should establish whether or not clients should always use one or the other, if so?

tsvilans avatar Dec 02 '20 16:12 tsvilans

To clarify, you won't get two tokens back from 2.0!

izzylys avatar Dec 02 '20 16:12 izzylys

Yes! all this mess is sorted in 2.0. The apiToken was a longer lived token designed for longer term use by the desktop clients, and the token was a shorter lived token designed for the frontend.

Since this is mostly used for the blender client, i would suggest storing the longer lived one (afaik, apitoken - it might be the other one). You can check them out here: https://jwt.io/#debugger-io

didimitrie avatar Dec 02 '20 17:12 didimitrie

Great, that clears things up. The Blender client always tried to use the longer-term one (apitoken) except when older accounts (mine) got denied 😛

@izzylys good news for going forward with 2.0 then!

tsvilans avatar Dec 02 '20 19:12 tsvilans