CIv2 Access Refresh Flexibility
Logan Cook
Custom Integrations v2 are coming along very nicely!
Sadly, there are still quite a few authentication scenarios that stop it from working perfectly with some APIs.
Salesforce, for example, expires Access Tokens/sessions based on activity (or lack thereof). Additionally, they (for some reason) choose to not include
expires_in
as a property of the Access Token response, leaving us in the dark as to when it will die.Temporarily, I've worked around this specific issue by blasting Salesforce with queries on a cron timer.
For the end-game of CIv2, I think a dedicated mechanism to account for this will be required. I see two features that could fix this:
- Forced periodic refreshes: Allow us to set a period on which Rewst will forcefully refresh the tokens. For example, if we know Salesforce is set to 24h, then we can expect the expiration to happen at around the 12 hour mark of no activity. Forcefully refreshing every 8 or 12 hours could keep authentication live here.
- On-Failure refreshes: Allow us to enable attempted token refreshes on task failure. If a task from the integration fails with a 40# error, we should refresh the token ONCE and retry. Subsequent failures can be considered failures. This allows for the integration to mitigate authentication some failures as they appear, also dodging any potential unmonitored expiration issues.
Let me know your thoughts, folks :)
Log In
Chris Williamson
For #2, I agree this would be a nice feature to have. It should be configurable (both on/off for integration, and which HTTP status codes indicate an authentication failure that can potentially be recovered by refreshing the token).
Logan Cook
Chris Williamson specifying the error codes to refresh on is a great point, especially since the main cause of the request is vendors not sticking to a 'typical' OAuth setup :P