Open erzhan46 opened 2 weeks ago
Hi there @erzhan46 , thank you for reaching out!
Incorrect expiration date - looks like it shows grant/refresh expiration instead of token expiration.
What do you mean here? The token validity, effectively is the grant validity; once the grant is expired, the token is not valid anymore as well, thus you need to get a new access token. Not sure if I'm missing something. Could you elaborate more if you think my answer doesn't apply?
Timestamps returned in ISO8601 format, whereas 'getcred' option displays it in unix timestamp / epoch format. (This makes it harder to implement scripting / automations logic)
This timestamp was by designed for most currently scripting scenarios that our customers use, thus this behavior is expected (not a bug). It'd, definetely, be good to have a way to specify different formats for the timestamp returned value, but this would be an enhancement.
I'll be removing the "bug" tag as these issues seems more to be "question" and "enhacenment" types.
Hi @luispresuelVenafi
My understanding is there are two expiration timestamps:
# vcert checkcred --token ${OAUTH_TOKEN} -u ${SDK_URL}
vCert: 2024/07/02 14:41:51 Warning: --platform not set. Attempting to best-guess platform from connection flags
vCert: 2024/07/02 14:41:51 Checking credentials...
access_token_expires: 2024-09-30T13:48:35Z <- Access token expiring in 90 days
grant_expires: 2025-07-02T13:48:35Z <- Refresh/grant token expiring in one year.
client_id: <REMOVED>
scope: certificate:manage
So in checkcred json output - in expires_ISO8601 field it shows refresh/grant token expiration (one year). What I'm asking here is consistency - in free text output - checkcred shows both access and refresh/grant token expirations, whereas in json output - it shows only some generic 'expires' field with refresh/grant token expiration and doesn't show at all when access token will expire.
The problem with timestamps I have is that getcred in json format outputs them in Unix timestamp whereas checkcred in json format outputs them in ISO8601 format. What I'm asking here again is some consistency. From scripting/automation point of view I think unix timestamp will be more convenient, but any format will work as long as it's the same.
My understanding is there are two expiration timestamps...
Indeed there are, but unfortunately, the access_token timestamps itself is not returned in the API response, only the validity: https://docs.venafi.com/Docs/currentSDK/TopNav/Content/SDK/AuthSDK/r-SDKa-GET-Authorize-Verify.php?Highlight=vedauth%2FAuthorize%2FVerify
Which is what we return in JSON format (valid_for
for access_token
and expires_ISO8601
for refresh_token
). Unlike the text version, where we do calculate the timestamp itself for the access_token:
...
iso8601fmt := "2006-01-02T15:04:05Z"
tm, _ := time.Parse(iso8601fmt, resp.AccessIssuedOn)
accessExpires := tm.Add(time.Duration(resp.ValidFor) * time.Second).Format(iso8601fmt)
fmt.Println("access_token_expires: ", accessExpires)
...
The problem with timestamps I have is that getcred in json format outputs them in Unix timestamp whereas checkcred in json format outputs them in ISO8601 format. What I'm asking here again is some consistency. From scripting/automation point of view I think unix timestamp will be more convenient, but any format will work as long as it's the same.
Yeah, adding this consistency would be an enhancement. As well as adding (calculating) the value for JSON version of the command.
Thank you for explanation.
Between timestamps in checkcrd output returned in ISO8601 format and the fact that access token expiration is not calculated in json output - it makes it somewhat hard to calculate token expiration e.g. if I use it in shell scripts.
Thanks again!
PROBLEM SUMMARY There are couple issues with checkcred json format output:
E.g.:
STEPS TO REPRODUCE Run vcert getcred and vcert checkcred with --format json option.
EXPECTED RESULTS
ACTUAL RESULTS
ENVIRONMENT DETAILS Venafi vcert v.5.6.4
COMMENTS/WORKAROUNDS