A general question about SQ tokens: once a token is revoked, does its state persist in the SQ database, or is it cleaned up entirely?
Basically, we’re looking at using short-term tokens for certain scripts that use web_api. The script would create a token with api/user_tokens/generate, use it for the duration of the script, then revoke it (which is simpler and safer than trying to save the token for the next run of the script). Does revoking a token remove its state from the database? We could potentially be running this script hundreds of times, so I’m concerned about having the leftovers of hundreds of old revoked tokens cluttering the database.
Great! So short-term tokens should be fine as long as we clean them up.
We were getting auth errors in the MIDDLE of the script. I’m guessing LDAP glitches. Since we have to send creds with every web_api call, does that mean SQ checks with LDAP on EVERY web_api call? Or does it cache the creds internally and only check with LDAP SOMETIMES? Our thought is that using creds to create a token, and then using the token, should fix the problem.
The system we use involves calling Invoke-WebRequest (in PowerShell) where the URL is one of the SQ web_api endpoints and the header includes a string “Basic xxxxxx” where xxxxxx has been encoded and contains the username and password. Obviously, the first time this happens, the SQ server calls LDAP to check the credentials.
My point about calling LDAP is whether every call to SQ with that “Basic xxxxxx” string leads to another LDAP call, or if SQ tries to optimize by caching successful login creds.
Yes - hence the original question. (We already use tokens for the normal CI/CD process; this is for special cases where users do some unscheduled tasks with scripts. So I’m trying to set up what are effectively “session tokens” like various SSO systems do.)