I'm getting a 400 bad request error from Facebook when requesting an access token. My return_uri includes a query string parameter which is causing the problem. I've encoded the return_uri but I stil get the error. Can anyone help me with this?
Here is the request I'm sending to Facebook:
"https://graph.facebook.com/oauth/access_token?client_id=IDb&client_secret=SECRET&redirect_uri=http%3a%2f%2fexample.com%2fOAuthHttpHandler.ashx%3fReturnUrl%3d%2fpage.aspx&code=CODE"
I'm getting an "Error validating verification code." error message.
I've done a little more digging and found that the redirect_uri below works fine:
"http://example.com/OAuthHttpHandler.ashx?ReturnUrl=page.aspx"
But if I pass across a return url of "/secure/page.aspx" validation fails. I've tried encoding the forward slashes but no luck.
Unfortunately, the Facebook Oauth implementation doesn't handle url parameters in the return_uri querystring well, even when they are correctly encoded. There are several threads in the fb developer forums discussing this issue:
http://forum.developers.facebook.net/viewtopic.php?pid=237845
http://forum.developers.facebook.net/viewtopic.php?pid=239866
http://forum.developers.facebook.net/viewtopic.php?pid=255231
Until its fixed on their end, you'll have to use an alternative method of passing state: session, cookie, or building a simple page-specific identifier into the url.
After hours of searching around I finally found a good solution to the facebook access_token request returning "Bad Request 400".
The return_uri param sent to "https://graph.facebook.com/oauth/access_token" must be exactly the same uri as the one sent "to https://graph.facebook.com/oauth/authorize"
What I did was just replace the slashes with dashes when I send 'em to facebook. Then on the callback, replace the dashes with slashes again!
Related
I've tried the below request (with two different proper API keys), on the HERE Places API, but I get an auth error.
Request:
https://places.sit.ls.hereapi.com/places/v1/autosuggest
?at=40.74917,-73.98529
&q=chrysler
&apiKey=g51V9*****N4-_GTA
Response:
401
{
"error": "Unauthorized",
"error_description": "ApiKey is missing."
}
I've also tried OAuth, I can get the request token, but when I use this for the places request I get an HTML webpage (for HERE place API) as the response, rather than an expected JSON or XML reponse.
Is anyone able to get any of the example requests to work for Places API?
I had this issue before aswell. Trying the exact same request as you, in Postman with my own apiKey, made the request successfull.
Try making the URL a single line, there might be newline characters hidden somewhere.
This has solved this issue for me many times using this API.
Example:
https://places.sit.ls.hereapi.com/places/v1/autosuggest?at=40.74917,-73.98529&q=chrysler&apiKey=g51V9*****N4-_GTA
You need to check the key name it may wrong
you should check it out into the documentation of api. and see key name
try key name apikey or api_key or api-key instead of apiKey
https://places.sit.ls.hereapi.com/places/v1/autosuggest
?at=40.74917,-73.98529
&q=chrysler
&apikey=g51V9*****N4-_GTA
Please refer to this guide for the updated list of domains to use with apiKey.
For places, the domain is: places.ls.hereapi.com
Disclosure: I'm a product manager at HERE Technologies
In my case I was using : https://github.com/julianshen/gin-limiter with the provided example
I have a problem with the x-csrf-token validation with regard to a HTTPS-Post-Request. The request comes from a Lambda function triggered by an Amazon Alexa skill and is sent to a XSO Data file running on the SAP Cloud Platform in an SAP HANA Database. I use Javascript/Node.js.
A valid token is set in the request header (see code in the first picture below) but the response header shows for the x-csrf-token "required" (see code in the second picture below). So there is an error with the validation. The same post request with POSTMAN works correctly, but when I try it via a JS File as a Lambda function (in the first picture) there it comes this error with HTTP status code 403 (see code in the second picture below). The POST request itself does work, but the token validation not. GET requests work fine.
Does anybody know a possible solution?
Thank you very much!
1.picture: request
2.picture: response
Please try to get the csrf token first before setting it to the request body. CSRF token changes from device to device as well as the timeframe. I also had a similar issue, and upon implementing the above solution, it started working perfectly.
I am writing this as a separate answer as I had an issue in Spring Boot RestTemplate call. I could arrive at a solution after going through this article.
SAP CSRF Issue
Basically the "set-cookie" header is instructing the browser to set the "Cookie" header. All one has to do (apart from x-csrf-token) is to replace the comma in the string of the cookie with a semicolon. Then set the header "Cookie" to this replaced value;
I'm using Twitter OAuth provider to login to my site. This works great; I can login, and get the access token. I want to make an additional request to the server to grab some user information. Using the 1.1 API, I do:
var request = HttpWebRequest.Create("https://api.twitter.com/1.1/users/show.json?screen_name=name");
var response = request.GetResponse(); //400 bad request error
Again, I've successfully logged in, and at this point, I have not made any successful requests, so I'm not being rate limited. Any idea what my problem is?
I can make the previous API work fine, using the URL: http://api.twitter.com/1/users/show.json?screen_name=name. But not the new URL.
Thanks.
According to the Twitter Developers Documentation for response codes, you get a 400 in this case :
The request was invalid. An accompanying error message will explain
why. This is the status code will be returned during version 1.0 rate
limiting. In API v1.1, a request without authentication is considered
invalid and you will get this response.
Seeing your code (your URL is right and you use the 1.1 version of the API) I think that you forgot to authorize the request.
I'm doing an AJAX call to set the username. If the username is already taken what HTTP code should I return?
You can use 409 Conflict.
Indicates that the request could not be processed because of conflict in the current state.
I would choose 422 Unprocessable Entity . Lot's of rails developers use this for all validation errors.
And yes, it is totally appropriate to evaluate the error status and render the error message with javascript. This is especially useful, if you are using the same actions for an API. Then your ajax requests are accessing the same API that you would expose to other developers.
There is no rule here, it is up to you. However, as #rationalboss said, it makes sense to return 200 with a message since the HTTP request has succeeded, the error is unrelated to the request.
400 errors mean the request itself was not correct in some way, like wrong verb or missing parameters.
The question here is about interpretation, both from software clients and from humans and it might be better to stay away from error codes when there is no HTTP error.
There is no HTTP Code for name already taken. Please see List of HTTP Status Codes.
If you are using AJAX calls to set the username, why not just show the error in HTML? This is more user-friendly as your visitors would know what the actual error means, instead of seeing some 4XX code.
I have a web application that uses RESTful url patterns. Currently if a users tries to access a page where they need to be authenticated it just returns nothing. Is it good practice to return the HTTP status code in this case? Would I use 403 or a different one?
You should send a response with the HTTP status code.
I wouldn't send a 403 Forbidden back though as the spec specifies for this status code :
The server understood the request, but
is refusing to fulfill it.
Authorization will not help and the
request SHOULD NOT be repeated
Return a 401 Unauthorized status code instead. See this for more info on the status codes:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The way I do this with Jersey is to send a response with the status and then include a String entity which contains a human readable message, e.g.
Response response = Response.status(Status.PRECONDITION_FAILED).entity(
new String("Incorrect " + id + " [" + id + "]")).build();
This will be displayed to the client. I throw a Jersey WebApplicationException which wraps this response.
If they don't have permissions return 401 to give them the chance to respond to the authentication challenge or 403 if you don't want them to.
Restlet 1.1 onwards return 403, while earlier versions return 401. 403 seems to be regarded as more correct, if not necessarily more helpful.
It depends. You really ought to return something, of course, just to have a decent client experience. If you'd like to give them opportunity to authenticate at that moment, you can return a 401 and the client will know to pass credentials using standard authentication. If, however, you'd prefer that they authenticate through some other mechanism (some login URL and then set a cookie or somesuch), then returning a 403 is probably the way to go.
lol... in the REST API implementation I just built I returned a 401 status code with a response body that read "goodbye". Was the first thing complained about by guy interacting with API. I still think "goodbye" said it all ; )