I'm experitmenting with the Twitter API (OAuth). I have a test bed that can tweet from my dev box, but fails in production. I get a status code of 424 returned when trying to tweet.
I can't spot the difference between my live environment and my dev environment so really need to understand what a '424' is, but can find no documentation relating to it.
Turned out to be a quirk of classic ASP.
FAILS: Set objXMLHTTP = Server.CreateObject("Msxml2.ServerXMLHTTP.6.0")
WORKS: Set objXMLHTTP = Server.CreateObject("Msxml2.ServerXMLHTTP")
Wikipedia describes HTTP Response Code 424 as being a Failed Dependency. It's introduced by the WebDAV extensions to HTTP (see the WebDAV RFC). It means that the request you made failed as a result of a previous request failing.
As a high level example (although the actual response codes might be different), you might issue a request to get an OAuth ticket or token for your identity. If this fails and you then make a request using that token, then a 424 might be thrown.
Related
We have an API published on WSO2. It works perfectly.
When I send my request like the picture below, it responses 200 as I wanted:
I just wanted to test my request by adding more deleted=false query. So, I can send request until the request's size is 5.75 KB. I see stil 200 OK nicely. You can see on picture below:
But, if I reach request size 5.76KB by adding 1 more deleted=false query, I see this error:
As I searched on internet, I see that the REST API supports Uniform Resource Locators (URLs) with a length of up to 6000 characters.
My question is, how can I extend this limit? Is there any way to do that ?
As per the shared screenshot, it seems the Backend itself is responding back with a 400 Bad Request status code. The API Manager doesn't have any restrictions on large query parameters in the URI. So, this error is coming up from your actual Backend service, which is not able to handle a large request.
To confirm this behavior, you can enable the WIRE logs in the API Manager server and troubleshoot the behavior. If the request is dispatched to the Backend and the Backend is responded with 400 Bad Request means, the Backend is only capable of handling requests up to 5.75 KB in your case.
Also, as an alternate check, you can also try invoking the actual Backend service URL from the Postman (direct invocation and not via WSO2) and verify the behavior with large requests.
Given below are few documentations related to enabling WIRE logs and understanding the WIRE logs
WSO2 API Manager v3.1.0: Enable WIRE Logs
WSO2 API Manager v2.6.0: Enable WIRE Logs
How to read and understand WIRE Logs
I'm starting to use Microsoft Graph threat assessment API to report Phishing Website URL.
(Ref: https://learn.microsoft.com/en-us/graph/api/informationprotection-post-threatassessmentrequests?view=graph-rest-1.0&tabs=http)
My use-case is automatic reporting and manual reporting via Slack Command.
But throttling is very strict, so I get "429" response immediately.
"code": "ActivityLimitReached",
"message": "The client application has been throttled for reaching an activity limit. The request may be repeated after a delay, the length of which may be specified in a 'Retry-After' header.",
Does anyone know a workaround for the throttling?
As far as I confirmed, throttling is 1 request per 15 minutes (Limit per resource) by default.
(150 requests per 15 minutes (Limit per tenant) though)
Ref: https://learn.microsoft.com/en-us/graph/throttling#information-protection
I would try the following best practice to avoid/handle the throttling.
When you implement error handling, use the HTTP error code 429 to detect throttling. The failed response includes the Retry-After response header. Backing off requests using the Retry-After delay is the fastest way to recover from throttling because Microsoft Graph continues to log resource usage while a client is being throttled.
Wait the number of seconds specified in the Retry-After header.
Retry the request.
If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended Retry-After delay and retry the request until it succeeds.
The guidelines for throttling is already provided by Microsoft Graph team and it's straightforward. Please go through this doc, look out for best practices to avoid throttling, to handle throttling etc and think about throttling/batching to see if it suits your scenario (so you can optimize the calls).
If retry-after header doesnt exists then it would be tough - thats the way to handle throttling, unless if any alternate way exists provided. If you still believe Microsoft to implement this feature, consider creating a new user voice.
Update: #rung created a new uservoice on this.
I am working on the similar use case. I am planning to submit the Msg Id/URL/file to Microsoft for phishing assessment using API . I am stuck with an error that shows " "code": "Unauthorized",
"message": "Required authentication information is either missing or not valid for the resource.",
"
I would highly appreciate your help!
I am trying to create a Google Assistant for my Raspberry Pi in Kotlin. I implemented a OAuth flow using the so called "device flow" proposed in this IETF draft, since my Raspberry shall later just expose a web interface and does not have any input devices or graphical interfaces.
Google does support this flow (of course) and I obtain a valid access token with user consent in the end. For testing purpose I also tried a default authorization flow that will just forward the user to localhost, as it is normally done but it did not solve the problem.
I tested the access token using this tool and it confirmed validity of scope and token. So the token itself should work.
Scope is: https://www.googleapis.com/auth/assistant-sdk-prototype as documented here
This actually does not point to any valid web resource but is referenced in every documentation.
Then I tried to stream audio data to the assistant SDK endpoint using the gRPC provided java stubs. As took a third party reference implementation as a guide how to authenticate the rpc stub. But neither the reference implementation nor my own one works. They both report
io.grpc.StatusRuntimeException: UNAUTHENTICATED: Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
The stub is authenticated this way:
embeddedAssistantStub.withCallCredentials(
MoreCallCredentials.from(OAuth2Credentials
.newBuilder()
.setAccessToken(
myAccessToken,
myAccessTokenExpirationDate))
.build()))
and the authenticated request is performed like this:
val observer = authenticatedEmbeddedAssistantStub.converse(myStreamObserverImplementation)
observer.onNext(myConfigConverseRequest)
while(more audio data frames available) {
observer.onNext(myAudioFrameConverseRequest)
}
observer.onCompleted()
(I prefixed pseudo variables with "my" for clarity, they can consist of more code in the actual implementation.)
I even contacted the author of this demo implementation. He told me, last time he checked (several months ago) it was working perfectly fine. So I finally ran out of options.
Since the client implementation I took as reference used to work and I do actually authenticate the stub (although the error message suggests the opposite) Probably, either my valid access token with correct scope is not suitable chosen for the assistant API (though I followed the suggestions of google) or the API servers had a change not properly documented in the getting started articles by google.
So: Did anyone ran in the same problem and know how to fix it? I have the project on github. So if anyone needs the broken source code, I can do a temporary commit that produces the error.
Note, to save some works for mods: This issue referres to this and this question, both unresolved and using different languages but describing a similar problem.
Well, seems I was right about my second assumption: The error is server side. Here is the github issue, let's just wait for the fix.
https://github.com/googlesamples/assistant-sdk-python/issues/138
I am making Google API request through application using RestClient library to get address.
Sample request code-
require 'rest-client'
require 'json'
gmaps_api_href = "https://maps.googleapis.com/maps/api/geocode/json?latlng=18.56227673,73.76804232&language=ar"
response = RestClient.get gmaps_api_href
result = JSON.parse(response)['results']
This request works fine on my local machine and it completes within 1-2secs. But on production instance it takes 20secs to finish one request.
Due to some security measures, we can not access production instance directly. So I am unable to find pin point for this delay.
After doing trial and error, we found that
If we make request using CURL, it takes 1 sec on server
If we make request using Net::HTTP, it takes 20sec to complete same as we were observed for RestClient.
If we make request using WebRequest in small .net app, that request complete within 1 secs.
Its difficult for me to get difference between above observations.
Please let me know why it is so? and what changes I have to do to make it work in my Rails App?
Are you using a Google API key? Your example does not show use of an API key. if not, I'd guess you are getting rate-limited by Google. On your server, you've probably already deployed a version of this app, which made lots of requests to Google without an API key in the fairly recent past, and Google noticed and it's rate-limiting software may be slowing down your requests made from that server. While your local machine hasn't in the past made an enormous amount of requests to the google api, so is not being rate-limited by google's servers.
It's possible Google's rate-limiting is paying some attention (for now!) to User-Agent, and the different user-agent sent by Curl somehow evades Google's rate-limiting that was triggered by the requests sent by RestClient with it's User-Agent (and RestClient may use net-http under the hood, and have the same User-Agent as it).
While one would hope that if you were rate-limited you'd get a "429 Too Many Requests" error response instead of just a slow response, it's possible RestClient hides this from you (I haven't used RestClient), and I've also seen some unpredictable behavior from Google rate-limiting defenses, especially when not using an API key on a service that requires one for all but a few sample requests. I have seen things similar to what you report in that case.
My guess is you're being rate limited because you are not using an API key. Get and use an API key from Google. Google still has rate limits when you are using an API key, but they are clearly advertised (for free? 2500 per-day, and no more than 10 per second. more if you pay) and should give more clear and predictable error messages when exceeded. That's part of why Google requires the api key, so they can reliably rate-limit you in clear ways.
https://developers.google.com/maps/documentation/geocoding/usage-limits
https://developers.google.com/maps/documentation/geocoding/intro#BYB
UPDATE: All calls to the API receive the following response:
failed [500] An error has occurred
Weirdly, my auth process (documented here) works perfectly, while all calls to the API (documented here), fail.
The Bigcommerce API is in transition from basic auth to oAuth. The documentation is consequently a little confusing.
I am trying to create a webhook using the new oAuth methodology. The documentation states that I need an oAuth access_token for the relevant store, which I have obtained.
The documentation also includes sample http request data:
{
"scope": "store/order/*",
"headers": {
"X-Custom-Auth-Header": "{secret_auth_password}"
},
"destination": "https://app.example.com/orders",
"is_active": true
}
In this context, I am assuming that {secret_auth_password} refers to the store's access_token. However, when I include the access_token here I get the following error:
failed [401] You are not authorized.
Thinking that this might be a scoping/permission issue, I have given my app the highest possible level of access through the app settings, but this did not work either.
Thanks in advance for any pointers.
Well after a couple of days of serious head-scratching (not to mention hair out-tearing) I worked out that this was all down to an error in my SSL intermediate certificate, which I have now fixed.
It was the old API returning an error of “UNABLE_TO_VERIFY_LEAF_SIGNATURE” that put me on the right track – the new API just returned:
500 – there is an error
or
404 – you are not authorized.
If you are using PHP I would recommend using the the Webhooks pull request combined with the OAuth pull request. They are both working fine together (I personally use them).
Webhooks pull - https://github.com/bigcommerce/bigcommerce-api-php/pull/101
OAuth pull - https://github.com/bigcommerce/bigcommerce-api-php/pull/88
Then to create a webhook you can just call createWebhook($object)
Object needs to include scope and destination.
Also - a side note.. Are you using SSL for the destination address. It won't work otherwise. You can use a self-signed cert to get around this though.
This will only work for setting up the webhooks though.
To actually receive them you need a valid certificate (else you get nothing).
Hope this helps.
I came across this same part of the documentation and was also confused by it. The proper headers to send for webhooks are the following:
"X-Auth-Client":"[YOUR_APPS_CLIENT_ID]",
"X-Auth-Token":"[OAUTH_ACCESS_TOKEN]"
In addition to using the headers that #FlyingL123 suggested, also take note of of the requirements as noted by BigCommerce:
Requirements
The following properties of the webhooks are required. The request
won’t be fulfilled unless these properties are valid.
scope
destination