This week, most of our Yahoo imports started failing. Here’s what we learned about this issue and how we worked around a new quirk in Yahoo’s authorization to keep our service stable.
In the morning on Wednesday, February 13, we found that almost all our Yahoo imports were failing, starting at about 6:30 AM PST. We had made no changes to our service during this time. Nor had we made any changes to our Yahoo OAuth project.
Initially, all we knew was that nearly all accesses to the Yahoo Contacts API were returning
401 Unauthorized errors.
This investigation was spurred on by a near total failure when accessing Yahoo’s Contacts API.
We started to confirm the flow of information through the OAuth flow and subsequent API access to determine the source of the issue.
- We confirmed that the OAuth2 flow was being successfully granted.
- Our callback URL was receiving a valid
codein the query as expected and we were able to exchange the code it for an access token that contains the user’s Yahoo GUID.
- Authorized calls could be made successfully to Yahoo’s /profile endpoint to obtain the user’s profile information.
- Any calls to the /contacts endpoint were returning a
401 Unauthorizederror with the description “You are unauthorized for this operation.”
- We could successfully make a request to the /contacts API using an OAuth1.0a integration with the same credentials.
When authorizing requests to the Contacts API we were using the Authorization header as
perscribed by Yahoo:
GET https://social.yahooapis.com/v1/user/abcdef123/profile?format=json Authorization: Bearer aXJUKynsTUXLVY
Upon further investigation, we found that everything was working correctly when accessing the /profile endpoint. Interestingly this has only affected the one endpiont.
Some debugging ruled out an issue with our account. We created a separate OAuth project under a different Yahoo account and found the same issue.
Solution 1: Revert to OAuth1.0a
Because we were able to make a call to the /contacts API using the deprecated OAuth1.0a specification, we were able to mitigate some of the issues by reverting to this integration for a time.
Clearly, this was not a long-term solution but it was an easy change to make our our side to help mitigate the damage.
This helped to restore a few imports but we were still failing to import most of the time.
Solution 2: Remove all request headers and put them into the query string
Through a perseverence and trial-and-error, we finally discovered an alternative authentication method that did work.
When we include the
access_token and the
format parameter in the query of the request, then the calls were succssfully authorized and we win.
Now we’re sending authorized requests to Yahoo that look like this:
Rather than change this for all sources, we have now updated it for Yahoo only.
We continuing to monitor the situation with Yahoo and all our providers to ensure that we detect and resolve issues
like this one with as little interruption to our service as possible.