I'm seeing a new error via the Soundcloud API. It is intermittent, so it may be backend+bug related or it could be a sign of further reduced access to the Soundcloud API.
A User request now returns the following:
https://api.soundcloud.com/users/cadenzamusic?client_id=CLIENT_ID
(replace CLIENT ID with your own)
An HTTP/1.0 200 OK response is returned, but I'm getting the following string, rather than the User JSON object as expected:
Request was not processed by the server due to an error and is safe to retry
Is anyone else experiencing this?
As I stated earlier this was an error on SoundClouds part. Their servers were experiencing issues and it seems that they have resolved since 17:26 CET/ 08:26 PST
If you want more information on the status check out their post here.
When experiencing similar issues in the future it might prove useful to check the SoundCloud status page to see if they are aware of any issues.
Related
We keep playing this cat and mouse game with Robinhood.com. I have a trading app which used to trade stocks with Robinhood, but they keep changing the unsupported unofficial API to make it difficult for traders to use. I know that many people are doing the same thing and I want to reach out to them to see if there is a new answer. The latest problem is when I try to get a Bearer token using the URL https://api.robinhood.com/oauth2/token/ the API returns the following JSON: {"detail":"This version of Robinhood is no longer supported. Please update your app or use Robinhood for Web to log in to your account."}. This started happening on 4/26/2019.
Has anyone found a work around for this, yet, or have they finally beaten us into submission?
A more complete solution (not need browser):
Use requests.session.
Obtain the login page by making a GET request to "https://robinhood.com/login".
At this point the session's cookies will contain 'device_id'.
Obtain this device_id and use it in making the oauth2 token request to "https://api.robinhood.com/oauth2/token/" also add in the data request "challenge_type" (either "sms" or "email").
This request will fail with a 400 error code. Robinhood will send an SMS message or Email with a temporary (5 minute) code.
Also at this point use the 400 response's body to get "id" from "challenge" inside of the JSON object.
Confirm the challenge by making a POST request to "https://api.robinhood.com/challenge/CHALLENGEID/respond/" where CHALLENGEID is the same id mentioned in the first failed /oauth2/token/ POST request.
Make the same POST request to "https://api.robinhood.com/oauth2/token/" and include in the header "X-ROBINHOOD-CHALLENGE-RESPONSE-ID" with the value CHALLENGEID.
You can reuse a device_id with user/pass after this even after logging out.
Be cautious with storing device_id as it is the result of user/pass login and successful SMS/email 2FA.
Just got it working. At the risk of them seeing this post and changing it more, here we go:
First, you're going to want to log into your RH account in a web browser
View Source on the page, and look for clientId - it should be a big hex number separated by dashes
Add that number to your POST requests to /oauth2/token under the field device_token
There's probably another way to retrieve the device token, and I'm not even sure it's unique, but that way should work.
Good to be back here after a very long time.
Not sure if anyone is still looking for answers to this, but I have a very simple solution.
At Robinhood's login screen, enter your username/email and your password, press F12 on your keyboard to bring up the console panel and switch to the "Network" tab then wait for the page to load completely. (During this time you will see a list of items being loaded rapidly depending on the connection speed.)
At this time you can keep clearing the list by clicking on the button highlighted in the below image.
Click on button highlighted repeatedly until the list is empty
Now, log into your Robinhood account. At this point your console should display a list similar to the one shown below.
Look for the name "token/", most likely it will be the second one you get all the information you need. And this information will be under the Headers then Request Payload
I was able to find this with past knowledge and experience of web scraping for fun. And also, I needed to know this as well, since I recently started doing trades via Robinhood.
Hope this help you curious ones out there.
For my Robinhood account I am using Google Authenticator for my 2FA. What I have so far is that I send the original call that I was sending before to https://api.robinhood.com/oauth2/token/. This is giving me a response of:
{"mfa_required":true,"mfa_type":"app"}
I then repeat my oauth token request, but this time providing the value from Google Authenticator (so my GUI has to prompt me to fill it in) with this payload in the request to https://api.robinhood.com/oauth2/token/:
{"grant_type":"password","scope":"internal","client_id":"c82SH0WZOsabOXGP2sxqcj34FxkvfnWRZBKlBjFS","expires_in":86400,"device_token":"***","username":"***","password":"****","mfa_code":"***"}
and then I am getting an access token in reply
I am using the Google Cloud Messaging services described at https://developers.google.com/instance-id/reference/server but I am getting a HTTP response status of 400 and this response text:
{"error":"InvalidTokenVersion"}
At the time I write this, that exact error code has zero results on Google! Has anyone else encountered it? I could understand "InvalidToken" but it is the "Version" bit which is confusing me.
I'd like to see a nice list of all the possible error codes for the https://iid.googleapis.com/iid/info/ and https://iid.googleapis.com/iid/v1/*/rel/topics/* services, if you know where that is?!
All the GCM pages say at present is...
HTTP status 400 (Bad request) - request parameters are missing or invalid. Check error messages for detailed information.
Background information:
I am using a registration token from an Android device which still shows a log of successful notifications in the GCM Diagnostics (part of Google Play Developer Console). So surely the token cannot be wrong?
If I try a token value of "bum" I get error "InvalidToken" instead.
However, trying to send a new notification with https://gcm-http.googleapis.com/gcm/send results in the "InvalidRegistration" error, so I guess something has gone screwy.
I'd like to claim that I've changed nothing recently, but something to do with SSL on the server might have expired I suppose.
The token you are providing is regId not instanceId.token. Follow the documentation:
https://developers.google.com/cloud-messaging/android/client.
see examples here.
https://github.com/googlesamples/google-services/tree/master/android/gcm/app/src/main/java/gcm/play/android/samples/com/gcmquickstart
I'm designing an endpoint for my API where only one submission is allowed per user. After reading the specification and trying to find the best response, I am hesitantly planning on using a 403 - Forbidden when the user attempts to submit a second one:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If
the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity. If the server does not wish to make
this information available to the client, the status code 404 (Not
Found) can be used instead.
I was always under the impression though that 403s where meant to be an access response - not necessarily something that responds to state issues. Is this correct? Or is there a better status code I should be using here?
I've always 403 with authorization/authentication issues so I'm puzzled a bit ;) Below is the list of codes I'd take into consideration:
403 Forbidden - (as mentioned above)
409 Conflict - since a resource is in a given state that can't be changed it also a good status to notify the user about the problems.
And just a curiosity:
410 Gone - request can be sent exactly once so the endpoint may be not available for subsequent requests. I do not consider it as good idea, since the endpoint is still available but will not be processing request from particular user. Hmm.. Might be considered weird.
I'd vouch for 403 or 409 and eventually will use rather 409. 429 seems not to be a good idea because it's rather associated with network (broadband, throughput) problems rather than with resource itself.
Okay, so we are building an iPhone app to hit a Sharepoint 2013 site that is hosted on Office 365. If I were building this in C#, which I've already done, I would have the luxury of just using TokenHelper.cs to get me most of the way there. Unfortunately, as far as I know, there is no TokenHelper for Objective-C yet.
So here's the deal, we can already successfully get the OAuth authentication/authorization page to come up and we successfully get an Authorization Code back.
After this point we were stumped for a bit because we knew that we were missing the realm id in the POST for obtaining our Access and Refresh tokens. I finally figured out how TokenHelper does this and we've duplicated that. (This was an additional call to /_vti_bin/client.svc where you expect to get a 401 so that you can pull the realm id out of the header)
We now have a realm id that, from what I've read in documentation and TokenHelper and seen in Fiddler, needs to then get used in the following 2 ways: within the URL construction for the POST as well as for the resource value in the header for that POST.
So the POST url looks like this:
accounts.accesscontrol.windows.net/{realm id}/tokens/oauth/2
Our resource value looks like this:
resource=00000003-0000-0ff1-ce00-000000000000%2f{realm url}%40{realm id}
This at least connects fine and accepts our POST. Unfortunately, we are getting the following message back:
ACS50012: Authentication failed. ACS90011: The realm '' is not a configured realm of the current service namespace.
This message makes me think that there may be a configuration issue, but I really can't be sure.
Has anyone else tried performing OAuth against a 365 site yet within Objective-C and had success?
I can post code as well, but I was trying to shy away from that initially.
I recently came across the same problem and have a feeling it may be the same issue you are seeing.
The correct POST request for OAuth is as follows:
POST https://accounts.accesscontrol.windows.net/<REALM_GUID>/tokens/OAuth/2
x-www-form-urlencoded params:
grant_type:authorization_code
client_id:<CLIENT_ID>#<REALM_GUID>
client_secret:<CLIENT_SECRET>
code:<AUTH_CODE>
redirect_uri:<REDIRECT_URI>
resource:00000003-0000-0ff1-ce00-000000000000/<SHAREPOINT_AUTHORITY>#<REALM_GUID>
The major gotcha for me was that the value of the "client_id" required the realm id appended to the client id. Not including the realm id will throw an "ACS90011: The realm '' is not a configured realm of the current service namespace."
HTH
I have been successfully using the D2L Valence API for about a month, but this past
weekend, all API calls return a 403 error. I contacted the support team in
charge of our D2L server, but they said nothing changed over the weekend.
They're still looking into the issue. I've tried 3 different users that
have different permission settings, but all of them fail. Do you know what
could cause this? Is there some kind of spam filtering, or a limit of
requests per hour? Thank you.
The 403 may have additional body to indicate more information. If you are saving the userid and userkey the body may be "Token Expired". This is a possible cause because some servers have a 30 day expiry.
If you are using an interactive app a 403 with "Token Expired" can be used to reprompt the user for auth (if you are using the library it will tell you that you need to reauth in the interpretResult() call. ) Apps also need to be able to do this in the event of a password reset as tokens are expired when a password is reset.
If you are not using an interactive app (or if you prefer avoiding the reauth) Desire2Learn support can update the token expiry to be indefinite (your institution support team can open a ticket with Desire2Learn support to have this changed: d2l.Security.API.TokenTimeout should go to -1).