How to deal with errors and a used refresh token in production
We've been implementing some of the Sky API endpoints and during our tests, sometimes we make a mistake and so our code fails to capture the refresh token because of a server error (on our server). So the endpoint is called, but our server doesn't receive the result. The refresh token is then useless because it was used.
This is fine during testing, we can go and easily go through the authorization process again and get another refresh token manually.
But my question is for production code, is there no failsafe? Let's say our code errors for some unforeseen reason - from what I understand, that would leave us without a working refresh token on our live production server.
Because if our code fails, and we don't capture the new refresh code correctly that means all our interaction with the Sky API will be down until someone manually re-authorizes and gets a new refresh token.
I don't really like having that as a possibility. Or am I missing something?
Is there anyway to request that the previous 5 refresh codes continue to work as a bit of a failsafe buffer? Or what is normal practice in this regard?
This is fine during testing, we can go and easily go through the authorization process again and get another refresh token manually.
But my question is for production code, is there no failsafe? Let's say our code errors for some unforeseen reason - from what I understand, that would leave us without a working refresh token on our live production server.
Because if our code fails, and we don't capture the new refresh code correctly that means all our interaction with the Sky API will be down until someone manually re-authorizes and gets a new refresh token.
I don't really like having that as a possibility. Or am I missing something?
Is there anyway to request that the previous 5 refresh codes continue to work as a bit of a failsafe buffer? Or what is normal practice in this regard?
2
Comments
-
Nathan, we may have different use cases which may not be applicable to what you are doing. We have a separate process which obtains refresh token(s) - this separate process makes that current token available to all of our skyapi processes hence our processes are never without a refresh token. Should this separate process fail it auto-recovers (we basically have a 1/2 hr window to recovery) - if there are still issues at ~10mins prior to token refresh I get a text however I can't ever recall the refresh token refresh failing for more than 30mins. We do get network hiccups every now and then but the next try takes care of it.1
-
Thanks for your reply Dennis.
We also have a separate process for getting the refresh tokens which then allows everything in our system to have access to the token.
But it sounds like you have run into the same issue I am concerned about - being that you setup texting for when something goes wrong.
It seems like it would be a whole lot better if there was a way for the refresh token to be used again instead of expiring on first use so that we don't have any of these "manual" type of needs.
If we are going to be processing credit card payments and the like through the API, I really don't like the idea of everything breaking because we weren't able to get to a computer fast enough to re-authorize.
There must be a better way?1 -
Hi Nathan and Dennis,
A while ago, they introduced the preserve_refresh_token option. I think this might be what you're after as if an Access Token refresh fails - for whatever reason, network outage, code bug, etc - you can reuse the existing Refresh Token to get going again without a manual re-auth.
Do a search of the Community on "preserve_refresh_token" and you find some posts by Chris Rodgers explaining its use. The documentation also takes you though it.
I hope I haven't misinterpreted your question, but, in your situation, that's where I'd start looking.
Of course, you will eventually have to accept a new Refresh Token before it expires in 365 days and that is still obviously prone to error, but it's way less frequent and you can build in an explicit flow to manage this "less-off" event.
Cheers,
Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions
1 -
Thanks Steven Cinquegrana The preserve_refresh_token = true does seem like the best option we have.
I'm also thinking of using two apps for our production code so that if one refresh token fails, we have another through the backup app.
It would be nice if there were a simpler solution though.1 -
Looks like there is a feature request regarding this: https://blackbaud-developer.ideas.aha.io/ideas/API-I-283
It would be great if we could get rid of the manual authentication step!1
Categories
- All Categories
- 6 Blackbaud Community Help
- 213 bbcon®
- 1.4K Blackbaud Altru®
- 402 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 360 Blackbaud eTapestry®
- 2.6K Blackbaud Financial Edge NXT®
- 655 Blackbaud Grantmaking™
- 576 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 939 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.6K Blackbaud Raiser's Edge NXT®
- 3.7K SKY Developer
- 248 ResearchPoint™
- 119 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 241 Member Lounge (Just for Fun)
- 34 Blackbaud Community Challenges
- 34 PowerUp Challenges
- 3 (Open) PowerUp Challenge: Chat for Blackbaud AI
- 3 (Closed) PowerUp Challenge: Data Health
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Product Update Briefing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports+
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Email Marketing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Gift Management
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Event Management
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Home Page
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Query
- 792 Community News
- 2.9K Jobs Board
- 53 Blackbaud SKY® Reporting Announcements
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)

