Skip to content

Simplify token handling, and support more grant types.

Paal Kvamme requested to merge kvamme62/token-handling into master

Add support for the 4 SLB-Internal Sauth providers, when using an SDAPI that have these built in.

Simplify token handling by not passing an explicit token type. This is based on a better understanding of how tokens work.

When a callback is user to let the application refresh the token the return should always be a simple token. Returning an impersonation token, or client credentials, or any other high level type makes no sense because those will be refreshed by SDAPI and the callback would not have been needed. So, remove references to "callback return type".

When programmatically setting credentials (and not using a callback) the old code allowed passing the credentials and the type either as two separate arguments or by a single string with colon-delimited fields. The former was never implemented completely and also wouldn't work with the 4 Sauth credentials as they need multiple arguments. So get rid of that particular api.

The ability to pass "type:value" is kept and has been extended to allow more than one colon-delimited value.

For backwards compatibility, SeismicStoreIOContext::sdtoken() and sdtokencb() with type arguments are kept as deprecated. I am 99% sure that all callers send a bogus type. So the fact that the type is now completely ignored should not make any difference.

To consume an Sauth client credentials grant, assuming the library was built with Sauth, set:

OPENZGY_TOKEN="ServiceSauthV2:${CLIENT_ID}:${CLIENT_SECRET}

Types SauthImpersonationToken, SauthV2, and FileV2 should also work but have not been tested. Ditto for type ImpToken which is a plain OAuth2 impersonation token and is usable also in the opensource version of the library.

Merge request reports

Loading