The workaround here is to click on the link provide your own token instead of using your credentials to sign in.
To generate a simple access_token using the client_credentials flow one alternative is using the Rested extension for Google Chrome or Mozilla Firefox:
Well, it seems I can’t GET anything anymore as well.
I’m a complete noob in APIs for my part.
So when accessing one of the legacy API of this page : https://develop.battle.net/documentation/starcraft-2/community-apis
Am I supposed to click on provide my own access token, and then paste this ?
While filling the first XY with my client ID, the second one with my client secret, and the third one with : https://develop.battle.net/documentation/starcraft-2/community-apis
I was able to fix my code thanks to the information in this thread. For the record: I only saw “400 Bad Request”, I never saw anything about GET being bad all of a sudden. The fix was as simple as changing GET to POST in my C# code, but digging to the right location took a while …
I agree, the communication of this kind of things sure could use some improvement.
Yeah, that turned out to be a mistake on my end. After good night sleep I found out my data fetching implementation was faulty (sending GET requests even when I thought it would POST) and managed to fix it. Thanks!
I’ve seen a lot of 404 errors recently, they happen often (but not exclusively) for very recent profiles (possibly depending on some privacy settings as well). Interestingly enough when I’ve got a 0404 on an EU profile with an EU region parameter, going for the exact same request with an US region gets an errorless but empty response .
Anyway, if that’s a 0404 just going for another profile ID should get rid of it. It’s different from the 0401 or “GET method not allowed” we get for every request since half a day I think.
So if I understand you well, until the devs change the GET button to a POST one in their pages, the GUIs are unusable ?
First, we would like to apologize for the disruption and confusion that some API consumers have experienced over the last 24 hours.
We are able to confirm that there was indeed a change deployed which altered the behavior of the OAuth APIs for the /oauth/token endpoint, which removed support for HTTP GET requests. This change was applied with the best intentions to ensure the best security practices are followed for the Blizzard OAuth APIs, however, we realize that this also negitively impacted a number of consumers. We failed to communicate this change ahead of time, and for that we deeply apologize.
This change hase since been reverted, and requests to /oauth/token using HTTP GET should continue to work as they previously did. Our intention is to once again disable HTTP GET requests to the /oauth/token endpoint at a later date, and we ask consumers to please account for this in your integrations by migrating to using HTTP POST. Please keep an eye out for further communication at a later date regarding migrating.
We would like to extend our thanks to everyone who reported issues, and to everyone who assisted others with debugging & troubleshooting efforts here on the forums and through other channels.
Thank you for all of your feedback, reports, and collaboration.
If it was possible, please then consider changing the GET requests mode from the GUIs (such as this ones) simultaneously, as otherwise it requires third party programs to send the oauth token and knowledge of command lines which will leave some of us wondering for a while.
And most particularly Schiller, who seems always ready to provide some advice.
For what it’s worth, speaking for myself here, I totally get why the change was made. IIRC the spec always said “use POST” and your change did not deviate from that spec, you simply stopped supporting an unofficial alternative method. If we had all been following the spec, we wouldn’t notice you made any change at all. On my own projects, I had some code to fix, but at work I followed the spec 100% and didn’t have any interruption in service. So, technically, the change should’ve been harmless, and indeed been an improvement since the method change could make things more secure in regards to request logs, etc.
However, lots of folks were using GET requests, as evidenced by this thread, as well as your own documentation examples. It would have been nice if you noticed this in your logs, ideally before, but especially after, this change. I think we could’ve supported this change with a minimum of moaning about it if we were given advance notice.
As an API consumer, here’s my feedback for this incident.
Kudos:
The backend change simply followed your existing spec.
The purpose of the change was in service of security.
When your change caused issues, you reverted it within 24-ish hours.
You posted a reply in the forums addressing our issues and stating your intentions.
Opportunities for improvement:
Before removing functionality (even for good reason), review current usage, especially for components which are used by everyone (authentication/tokens).
Announce breaking API changes ahead of time with a future date for when it goes live. Obviously, if there’s a serious security breach, it may be prudent to patch first and notify next, but I don’t think this change qualifies.
Sounds good. I think a lot of us are already ready for it, after this incident.
To get my access-token for the Authentication Code Flow in Postman, this configuration did not work to me, I had to change the “Client Authentication” option to “Send client credentials in body”, instead of “Send as Basic Auth header”.
Thank you anyway because this screenshot helped me a lot.