search

speckleworks / PySpeckle

Check a brand new Speckle at: https://github.com/specklesystems
MIT License
21 stars 9 forks source link

SpeckleApiClient stores the authorization token in 2 places #43

Open tsvilans opened 3 years ago

tsvilans commented 3 years ago

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?

izzylys commented 3 years ago

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).

tsvilans commented 3 years ago

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?

izzylys commented 3 years ago

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

didimitrie commented 3 years ago

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

tsvilans commented 3 years ago

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!