This is similar to some questions on here, but none have seemed to produce an answer that has helped me. I'm calling the graph api from a c#/.Net application to get photos for a particular album, and I'm receiving a 403 error...sometimes.
I've never received the error in my development environment, only in production. I'm also caching the responses for an hour, so the most the application would hit the API in a given hour would be around 20 times, and not all at once. I'm currently swallowing the exception when it errors out and simply not showing the images, but that isn't a long-term solution.
var request = WebRequest.Create("https://graph.facebook.com/ALBUM_ID/photos");
var stream = request.GetResponse().GetResponseStream();
This just started happening about a month ago but I didn't see anything in the breaking changes list that would suggest this behavior. Any insight would be appreciated.
Update
This was hidden away in the response stream.
{"error":{"message":"(#4) Application request limit
reached","type":"OAuthException","code":4}}
I don't see for the life of me how I could be hitting a limit considering I'm only hitting the api a few times.
if you make a GET request to one of FB graph API endpoints that does not require access_token that does not mean you should not include it in request parameter. If you do as FB documentation says as do not include access_token then in FB server side it registers into your server machine. So limit (whatever amount is it exactly) can be reached very easily. If you however, put the user access token into the request (&access_token=XXXXXX) then requests register into the specific user, so the limit hardly ever be reached. You can test it with a simple script that makes 1000 requests with and without user access_token.
NOTE, FB app access token will not be sufficient as you will face the same problem: requests will be registered into app access_token that situation is alike making requests without access_token.
Related
Morning all,
I've not posted on SO for quite some time, but I need to ask the question, I’ve spent a day and a half trying to get this to work - it’s super frustrating considering I managed to implement v2 with posting a tweet in 2 - 3 hours but because I need the media endpoint (does not exist in v2), I rebuilt my flow into v1 to upload media.
Ok, so my app allows the user to authenticate with twitter and tweet/upload media. I’m using (I think) the 3-legged oauth flow.
Currently, the flow is :
https://api.twitter.com/oauth/request_token - 200 status code and I
confirm the callback URL
I use the access token from step 1, and then call/redirect
https://api.twitter.com/oauth/authorize?oauth_token={accessToken}
this obviously redirects to my endpoint.
I extract the oauthToken and oauthVerifier and call:
https://api.twitter.com/oauth/access_token, this returns an
oauthToken and oauthTokenSecret, I store the values.
All of the above conforms to what is in the docs, but when I use the stored values from step 3 to post a tweet I get unauthorized.
The signing logic works because it’s what’s used in “Request access token” - with a couple of changes.
I'm learning more towards a flow issue due to trying various nuget packages(tweetinvi in particular) and I get exceptions in those too.
Any help is greatly appreciated.
Not really an answer per-se, but rather notable actions.
At this point in time, you cannot upload media with V2 of the API, whilst you can integrate quite quickly and send a tweet, it's almost pointless without media.
So, you'll need to build/integrate with V1.
The unknowns and curve balls:
The most important! V1 requires elevated access! Which you'll need to
apply for, not all get accepted! but V2 just integrate and tweet with
no elevated access - very strange.
Always ensure to read the resp correctly, and try few times in code, postman,
fiddler etc. Whilst the resp contains a collection of errors object,
you'll never get a collection of errors.
If you're not using any sort of package/library, pay close attention
to crafting the request signature - it's a pain.
I have an Angular Web Application, that is backed by a C# Web Api, which facilitates speaking to an Azure Function App.
An rough example flow is like the following:
Angular Web App (press download with selected parameters) -> send GET request to API Management Service
API Management Service makes call to a C# Web Api
C# Web Api then responds back to the APIM, which in turn calls an Azure Function App to further process
data from an external source
Once a csv is ready, the data payload is downloaded in the browser where the Web App is open
For larger payloads, the download request fails with the following error in Application Insights:
"ClientConnectionFailure at forward-request"
This error occurs at exactly 2 minutes, every time, unless the payload is sufficiently small.
This lead me to believe that the Function App, which I understand as the client in this situation, is timing out, and cancelling the request.
But testing a GET with the exact same parameters through a local instance of the Azure Function App using Postman, the payload is successfully retrieved.
So the issue isn't the Azure Function App, because it did not time out in Postman as when using the WebApp.
This leads me to three different possibilities:
The C# WebApi is timing out and cancelling the request before the APIM can respond in full
The WebApp itself is timing out.
The internet browser (Chrome), is timing out. (Chrome has a hard unchangeable timeout of 5 minutes, so unlikely)
#1. To tackle the the first option, I upgraded the timeout of the HttpClient created in the relevant download action:
public aync Task<HttpResponseMessage> DownloadIt(blah)
{
HttpClient client = getHttpClient();
client.Timeout = TimeSpan.FromMilliseconds(Convert.ToDouble(600000)); // 10 minutes
var request = new HttpRequestMessage(HttpMethod.Get, buildQueryString(blah, client.BaseAddress));
return await client.SendAsync(request);
}
private HttpClient getHttpClient()
{
return _httpClientFactory.CreateClient("blah");
}
This had no effect as the same error was observed.
#2. There are a couple of Timeout properties in the protractor.conf.js, like allScriptsTimeout and defaultTimeoutInterval.
Increasing these had no effect.
** There is a last possibility that the APIM itself is timing out, but looking into the APIM policy for the relevant API, there is no forward-request property, with a timeout, meaning by default according to Microsoft, there is no timeout for the APIM.
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies
I've tried a few different strategies but to no avail.
Indeed there's a timeout, as ClientConnectionFailure indicates that the client closes the connection with API Management (APIM) while APIM is yet to return a response to it (the client), in this case while it was forwarding the request to the backend(forward-request)
To debug this kind of issues, the best approach is to collect APIM inspector trace to inspect request processing inside APIM pipeline, paying attention to the time spent on each section of the request - Inbound, Backend, Outbound. The section where the most time is spent is probably the culprit (or it's dependencies). Hopefully, this helps you track down the problem.
You can explicitly set a forward-request on the entire function app or a single endpoint such as:
<backend>
<forward-request timeout="1800" />
</backend>
where the time is in seconds (1800*60 = 60 minutes here)
To do this in APIM,
go to your APIM
APIs
Select your function app
Click on the Code icon </> under Inbound Processing
Alternatively, if you want to do this for just a single operation/endpoint, before performing step 4., click on an individual operation/endpoint.
After testing each component of the solution locally (outside Azure), web app (front end), web api, function app (backend), it is clear that the issue was caused by Azure itself, namely the default 4 minutes for Idle Timeout at the Azure Load Balancer.
I double checked by timing the requests that failed and always got 4 minutes.
The way the code in the backend is sending requests is all together, for larger data sets this caused it to hit the load balancer's timeout.
It looks like the load balancer timeout is configurable, but this doesn't look like something I will be able to change.
So solution: Write more efficiet/better code in the backend.
I am building an application using accept js and C# SDK of authorize.net. here, i am using accept js token to make a credit card payment over authorize.net and able to create transaction and customer profile successfully. but when i tried to create a subscription with customer profile id and payment profile id, i got "E00040 Record Not Found" error response.
I also tried to create subscription with another token after creating transaction but getting "E00114 Invalid OTS Token" error response.
What would cause authorize.net to return an these errors?
Looking forward for your quick response.
I was having this problem today, although I was doing PHP on the backend instead of C#. I called into their tech support and here's what I found:
Their production endpoints are actually pretty overloaded on server resources compared to their sandbox unfortunately, at least as of Aug, 2018. This can lead to this misleading Invalid OTS Token error, which can also have several other causes. The tech explained to me that if you have a submit button on the payment form that generates the token and then immediately submits the transaction, that you should add some kind of sleep call (on PHP, that's sleep(5);, for instance). We tried and got it to work on 4 seconds, minimum, but only intermittently. He told me if it fails after a 4 or 5 second sleep call, to reattempt that call one more time after waiting another 2 seconds, before you give up and recommend the customer call your call center or use your other support channels.
In the sandbox, they won't care if you're not using the cert.pem file in your transactions. Not so in production -- you need to ensure you've got that loaded. You can get that file off of Github if you search on the official Authorize.Net files.
I'm building an bot that auto replies to tweets that contain specific words. I am using HttpWebRequest to make a request to the streaming API and posting the tweet. Only problem is that the twitter API limits the ammount of requests you can make in a specific ammount of time. This makes the stream request successful but the request to post a tweet fails with the 403 error. How can i avoid this? (Not really sure if this is actually the problem, but it seems so.)
I used this as an layout on how the stream request thingy works http://www.emoticode.net/c-sharp/twitter-stream-api-client-example.html
If you know anything about this, let me know.
According to the Twitter docs(error codes, limits) you should get an error message explaining what limit you hit (if you hit it). That should clarify if that is truly your problem.
If it is I suggest using a message queue or a response schedule, to allow you to track how many tweets you are sending. Maybe you could also assign priorities to those tweets you want to respond to, even filter out some low priority ones eventually. That depends really on the load of tweets you will be processing.
I'm using Google Apis, instead of Google Sign In, to connect to Google on my app because I'm developping with Xamarin.
This is the library I'm using : https://github.com/xamarin/google-apis
When I'm logging in, i get this error :
Authentication Error
Unexpected character '<'. At line 1, column 0.
Maybe it's because my AccessTokenUrl is not good, but I've tried many things. I know for a fact that my ClientId, my RedirectUrl and my Secret are okay.
When logging in, Google asks correctly for the good permissions that I want, but after I accept, this is when I receive the error.
I've tried finding the request to see if there was the '<' in it but had no luck accessing it.
Is there a good way to connect to Google with Xamarin using this library or I'm just doing something bad?
Should I just do it nativaly on iOS and Android?
Thanks
I just encountered a similar problem using Xamarin.Auth to hit a custom OAuth service (i.e. not Google). In my case, the accessTokenUrl pointed to an action on a controller that was entirely protected by the [Authorize] attribute. Naturally, the user was required to login before hitting the /oauth/authorize endpoint using a web browser, but the request to /oauth/token to exchange the resulting authorization code for an access token was not inside the same web browser/session. It was trying to get back token data in JSON format but was being redirected to an HTML login screen. Once I changed the token endpoint for anonymous access, things started working (Note: A valid authorization code cannot be obtained without authenticating).
General Recommendations
The error message strongly suggests that the response coming back is HTML (or at least some form of XML). This could be an authentication redirect as it was in my scenario, or possibly some sort of error page. I would first start by setting up a proxy. I used Charles Proxy to uncover some interesting information. You will need to configure SSL on the proxy to see anything except high level information. This will show the exact requests coming out of your app to the OAuth application.
Another technique I used was simulating the requests that the OAuth2Authenticator would be making in a web browser and/or Postman. The first request would be to authorize:
https://your.domain.here/oauth/authorize?client_id=<some_client_id>&redirect_uri=https%3A%2F%2Fyour.domain.here%2F&response_type=code&scope=<some_scope>&state=<some_state>
That endpoint should be protected, so you will likely be redirected to something like this:
https://your.domain.here/Account/Login?returnurl=%2Foauth%2Fauthorize%3Fclient_id%3D<some_client_id>%26redirect_uri%3Dhttp%253A%252F%252Fyour.domain.here%252F%26response_type%3Dcode%26scope%3D<some_scope>%26state%3D<some_state>
After authenticating, the authorize endpoint should redirect to your redirect URI with the authorization code and state included as query string parameters. You will use the code in the next step.
Lastly, using a fresh web browser (i.e. new session), you should hit the token endpoint with your new authorization code and other client information.
https://your.domain.here/oauth/token?client_id=<some_client_id>&client_secret=<some_secret>&grant_type=<your_grant_type>&code=<your_authorization_code>&redirect_uri=https%3A%2F%2Fyour.domain.here%2F
If the response is not JSON data, it should give you an indication about what is failing with Xamarin.
Got the same error.
Solved by using https://accounts.google.com/o/oauth2/token as AccessTokenUrl