I've been using oath 2 for all my fusion table queries as described here: https://developers.google.com/fusiontables/docs/articles/oauthfusiontables). From today I'm getting this response for all queries: Error 400 Bad request:Required: X-Goog-Encode-Response-If-Executable.
Can't find similar issues with google search. No change to my code recently-was there any changes made to fusion tables API or oath 2 recently that I'm not aware of that can cause this error? Please help
The latest Fusion Tables product roll out included a change that enforced request safety. The side effect of this is that GET requests with alt=csv that use the access_token=[your token] argument result in an error.
The immediate fix is to use an authorization header and remove the access_token=[your token] argument from the GET request.
The request header should include
Authorization: Bearer [your token]
We are working on a more permanent fix which would re-enable GET requests with access_token=[your token] arguments. This may take a few hours
Related
I am attempting to use the REST api of Jenkins. Jenkins requires a POST request to a URL to delete a job. This results in the following:
I tell my chosen Client to send a POST to the appropriate URL.
The client sends a POST and authorizes itself with username and password.
Jenkins deletes the job.
Jenkins returns a "302 - Found" with the location of folder containing the deleted job.
Client automatically sends a POST to the location.
Jenkins answers with "200 - OK" and the full HTML of the folder page.
This works just fine with Postman (unless I disable "Automatically follow redirects" of course).
Jersey however keeps running into a "404" at step 5 because I blocked anonymous users from viewing the folder in question. (Or a "403" if I blocked anonymous users altogether.)
Note that the authentication works in step 1 because the job has been deleted successfully!
I was under the impression that Jersey should use the given authentication for all requests concerning the client.
Is there a way to actually make this true? I really don't want to forbid redirects just to do every single redirect myself.
To clarify: The problem is that while Jersey follows the redirect, but fails to authenticate itself again, leading to the server rejecting the second request.
Code in question:
HttpAuthenticationFeature auth = HttpAuthenticationFeature.basicBuilder()
.credentials(username, token)
.build();
Client client = ClientBuilder.newBuilder()
.register(auth)
.build();
WebTarget deleteTarget = client.target("http://[Jenkins-IP]/job/RestTestingArea/job/testJob/doDelete")
Response response = deleteTarget.request()
.post(null);
EDIT: The "302-Found" only has 5 headers according to Postman: Date, X-Content-Type-Options ("nosniff"), Location, Content-Length (0) and Server. So neither any cookies nor any tokens that Postman might use and Jersey disregard.
Question loosely related to this one - if I were able to log the second request I might be able to understand what's happening behind the scenes.
EDIT2: I have also determined that the problem is clearly with the authentication. If I allow anonymous users to view the folder in question, the error disappears and the server answers with a 200.
I found the answer with the help of Paul Samsotha and Gautham.
TL;DR: This is intended behavior and you have to set the System property http.strictPostRedirect=true to make it work or perform the second request yourself.
As also described here, HttpURLConnection decided to not implement a redirect as it is defined in the HTTP standard but instead as many browsers implemented it (so in laymans terms, "Do it like everyone else instead of how it is supposed to work"). This leads to the following behavior:
Send POST to URL_1.
Server answers with a "302 - Found" and includes URL_2.
Send GET to URL_2, dropping all the headers.
Server answers with a "404 - Not Found" as the second request does not included correct authentication headers.
The "404" response is the one received by the code, as steps 2 and 3 are "hidden" by the underlying code.
By dropping all headers, the authentication fails. As Jersey uses this class by default, this lead to the behavior I was experiencing.
What Http Status code should be returned from a HttpDelete action if a record cannot be deleted from the database because of database integrity?
403 - Forbidden
405 - Method not allowed
409 - Conflict
??
From my point of view HTTP code 409.
RFC does not say anything about this concrete situation but also it is not rejecting it.
https://www.rfc-editor.org/rfc/rfc7231#section-6.5.8
The 409 (Conflict) status code indicates that the request could not be
completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be able
to resolve the conflict and resubmit the request. The server SHOULD
generate a payload that includes enough information for a user to
recognize the source of the conflict.
Source:
REST HTTP status code if DELETE impossible
And why do I think that 403 and 405 are not appropiate?
403 - Forbidden. It's related with permissions. But the scenario that you are describing occurs after authentication/authorization.
405 - Method not allowed. This is usually related with the "object" exposed by the endpoint, it accepts X number of verbs and the one you requested is not available. Throwing this error in a determined situation like integrity-check would be confusing for the RESTful logic.
I encountered an odd problem working with the Microsoft GraphAPI beta Delta Query endpoint for users.
The first 2 requests worked as expected, supplying a "nextLink" in the response.
Then, the last request (which was supposed to be the last, and according to documentation should have returned a "deltaLink" in the response) fails returning a 404 (non-JSON response).
Is this a known issue with the beta Delta Query?
The request:
https://graph.microsoft.com/beta/users/delta?$skiptoken={TOKEN_HERE}
The response:
404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
There is a known issue in the API where the skip token size, hence the query string size, is sometimes large (> 256 characters) and service does not handle it. We are actively working on a fix. Please check your skip token size and let us know in case it does not satisfy above criteria.
This issue has been fixed. Let us know if you have any more issues or feedback on the capability.
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
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.