I deployed to AWS for first time, and experienced a very strange behavior. I use AngularJS and there is a function that performs $http service call with DELETE method specified.
var fn = function () {
$http({ method: "DELETE", url: "/active/route/"})
...
and when I perform it, request hangs for a while and get refused.
I've changed fn to
function () {
$http({ method: "POST", url: "/active/route/delete"})
...
And it worked just fine.
I want to know if beanstalk has specific policy about some HTTP methods or what was causing this behavior?
I know this has been fairly inactive for a while but I figured out what was happening in my case and thought I would post it here for anyone else who needs it. Basically http DELETE methods do not play nice if you are sending a request that contains a request body. Pure RESTful services should be employing the URI to pass object ids back and form, rather than form data or in the request body. When the data is passed via request body some web servers will read that as a POST method, which can wreak havoc on your API.
In my case I was passing the object id both in the URI and, as a side effect of my architecture, in the request body. This works perfectly ok in all cases except DELETE. To fix the issue I simply removed the unnecessary request body and viola!
Hope this helps someone.
See this post for more detail:
http://www.spenceruresk.com/2011/11/http-delete-requests-that-include-a-body/
Related
I've worked with some previous APIs in AngularJS, however there has always been a preflight using the OPTIONS method. Now I am building a new API from scratch and for some reason, AngularJS does NOT send a preflight request.
From what I have experienced AngularJS always sends a preflight when working with CORS, but not in my case. So question is really, what triggers a preflight in AngularJS if its not request to a domain which is not the same as the one AngularJS is being hosted on?
The example I have is quite easy and looks like this:
$scope.submit = function () {
$http.post('https://slimapi.devz/')
.then(function successCallback(response){
alert(response.data);
}, function errorCallback(response) {
console.log(response);
});
}
The requesting URL is https://slimfrontend.devz/.
Chrome gets triggered by the response headers in the XHR with the POST method, and will not display the result, however, the result is being fetched (as seen in timeline). But again, there is no sign of OPTIONS preflight.
Here is a picture of what my request looks like, and as you can see by the arrow. Chrome does detect the bad match of the origin.
MDN has a good description:
In particular, a request is preflighted if any of the following conditions is true:
(I paraphrase the rest below)
If the request uses any of the following methods (such as PUT)
If particular HTTP headers are set by the JS
If the Content-Type is not a valid value for the enctype attribute of an HTML <form>
IIRC, Angular defaults to sending application/json payloads (which trigger the final condition above).
Your example is of a POST request where you aren't POSTing any data (which is odd) so there is no Content-Type.
I have Json data being pulled from a REST API. On success I have created a simple alert that will display the Json results inside of an $http.get. I found a sample URL that points to Json data online for testing and I get the alert with the results just fine. But when I try to do this with my URL pointing back to the api, I get no results (not even an alert). However, when I take that same URL and put it into the browser, all of my Json data is there. Any ideas or thoughts on what might be causing this issue? Thanks.
JavaScript (with test Json data)
var myApp = angular.module('paladinMonitor', ["highcharts-ng"]);
myApp.controller('SizeCtrl', function ($scope, $http, $timeout) {
$http.get('http://ip.jsontest.com/?callback=showMyIP').success(function (data, status) {
alert(data)
});
I had something similar happen to me. Restful web services must use the Access-Control-Allow-Origin header to specify what origins are allowed to access the service. Without it, you can hit the web service successfully by putting the address directly in your browser but it won't work from your app. If your REST service is written in Java, you can see this question for details on how to add the appropriate headers. Other languages will use a similar mechanism.
My other guess is that the web service requires authorization to access. It works fine from your browser because at one time you provided the proper credentials and
your browser cached them. If your service does require authorization, see the "Setting HTTP Headers" section on this page for information on how to add the appropriate headers.
As Alvin Thompson mentioned, you have to set your access-control-allow origin and should also set your access-control-allow-headers, access-control-allow-credentials on the server side. In my case I had to do this in my WebAPIcontroller. This is because in order for CORS to work (cross-domain) you have to have the service 1 (RESTApi in my case) allow permissions for service 2(client) to receive call it. In order, to allow this I had to add the following NuGet packages
NuGet
- Microsoft.AspNet.Cors NuGet package
- Microsoft.Owin.Cors NuGet package
Once these were installed I went to my config file on the API project and added
API App_Start/WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
config.EnableCors();
}
Then in my controller that inherits the API controller I referenced the NuGet package I installed and enabled CORS on the client side and this is where you set you origin, headers and methods
YourController : ApiController
namespace YourNamespace.Controllers
{
[EnableCors(origins: "https://localhost:.....", headers: "*", methods: "*")]
public class YourController : ApiController
{
//The rest of your controller functionality
}
}
The rest of the issue I was having was how the Json Web Token variable is being passed into my javascript file. I am still working on this, I will post the answer to this as well when I figure it out.
To read more about the CORS issue, this was the best reference for me: http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api
As can be seen in AngularJS's source, any $http.post request that returns an HTTP code in the 200-299 range will trigger the success() callback even if the response contains invalid data (like for example invalid JSON).
I'm specifically setting my call's responseType: 'json' and even then the success callback is fired when something else comes back. This is especially annoying in the development server where PHP's display_errors setting is turned on. When something goes wrong server-side and PHP outputs an error message the AngularJS app doesn't detect this and continues happily.
Is there a way to prevent this? I mean, to make the AngularJS app fire the error() callback when the response data is invalid JSON?
Thanks
so your PHP server responds with a 200 error code even on an error? Not knowing PHP, this feels like a server configuration problem to me. I'd expect a 500 error with a payload. That being said, there are two things that I can think of offhand.
$http includes transformResponse handlers you can set up to inspect the response for problems.
$http also includes the concept of "interceptors" which allow you to pick up the response payload and do something with it. You could use an interceptor to "reject" the response.
More information on transformResponse and "interceptors" in the $http documentation:
http://docs.angularjs.org/api/ng.$http
I'm running a $http.get for a JSON and am getting a status of 0. I've downloaded the same JSON and the get works locally, and in Python using the requests library I can get the JSON no problem, but in AngularJS it's not working. What I don't understand is why angular isn't getting it but everything else is. Code snippet below.
function AgentListCtrl($scope, $http) {
$http.get('http://foo.bar/api/objects').success(function(data) {
$scope.objects = data;
}).error(function(data, status) {
$scope.status1 = status;
});
This provides the JSON and parses it when using a local file, but otherwise it fails and sets status1 to 0.
Just to make this clear since is not directly stated in the above answer (but in its comments) and, like me, some Angular newbies may be spending some time on this:
Angular's $resource will be able to execute a REST verb on another server, which in turn will respond correctly (with a status 200). Angular will nevertheless fail with a cryptical message, identifyiable by the status 0. It is further misleading since, in a browser's debugger, you may actually see the server's answer.
Angular will do an OPTIONS request on a cross-domain request (at least for the default query() method) unless specified on the contrary. Usually the server will not answer with the desired content (i.e. your representation). One simple way of doing this per request is specifying the method to be 'GET'.
$resource('http://yourserver/yourentity/:id', {}, {query: {method: 'GET'});
The server answering your REST requests MUST include the headers specified by CORS [1] in order to allow Angular to consume properly the response. Essentially this means including the Access-Control-Allow-Origin header in your response, specifying the servers from where the request comes from, that are allowed. This value may be *.
Complementing this answer for anyone integrating AngularJS with spring-data-rest-webmvc:
the HATEOAS json formatted response will not be properly consumed by Angular, producing instead the error Expected response to contain an array but got an object. This is solved by adding the isArray: false parameter to the $resouce's configuration;
a very to-the-point example of configuring CORS for the spring-data-rest-webmvc scenario is presented at [2] (see the SimpleCORSFilter)
[1] https://developer.mozilla.org/en/docs/HTTP/Access_control_CORS
[2] https://spring.io/guides/gs/rest-service-cors/
In your code, the status assignment only occurs when the error happens. You should be able to get the status when the call was made successfully like this:
success(function(data, status, headers, config) {
$scope.objects = data;
$scope.status1 = status;
}).error(function(data, status) {
$scope.status1 = status;
});
I was having a similar problem myself. A third party API that returns JSON just fine through every other means was failing with status 0 when called through Angular's $http.get() method.
In my case there wasn't any CORS problem. Instead, the URL I was using for the API was not quite right and the server was issuing a 301 response. Angular wasn't respecting the redirect.
Word to the wise.
I have a web application for iPhone, which will ultimately run within a PhoneGap application - but for now I'm running it in Safari.
The application needs to access tweets from Twitter friends, including private tweets. So I've implemented OAuth using the Scribe library. I successfully bounce users to Twitter, have them authenticate, then bounce back.
At this point the web app has oAuth credentials (key and token) which it persists locally. From here on I'd like it to user the Twitter statuses/user_timeline.json method to grab tweets for a particular user. I have the application using JSONP requests to do this with unprotected tweets successfully; when it accesses the timeline of a private Twitter feed, an HTTP basic authentication dialog appears in the app.
I believe that I need to provide the OAuth credentials to Twitter, so that my web application can identify and authenticate itself. Twitter recommends doing so through the addition of an HTTP Authorization header, but as I'm using JSONP for the request I don't think this is an option for me. Am I right in assuming this?
My options therefore appear to either be putting the oAuth credentials as query-string parameters (which Twitter recommends against, but documentation suggests still supports); or proxying all the Tweets through an intermediate server. I'd rather avoid the latter.
I access the Twitter API using URLs of the form
http://api.twitter.com/1/statuses/user_timeline.json?user_id=29191439&oauth_nonce=XXXXXXXXXXX&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1272323042&oauth_consumer_key=XXXXXXXXXX&oauth_signature=XXXXXXXXXX&oauth_version=1.0
When user_id is a public user, this works fine. When user_id is a private user, I get that HTTP Basic Auth dialog. Any idea what I'm doing wrong? I'm hoping it's something embarrassingly simple like "forgetting an important parameter"...
The oAuth stanza needs to be exact, as per http://dev.twitter.com/pages/auth#auth-request - I ended up building an Authorization: header that I could first check with curl.
I built it using the really helpful interactive request checker at http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/
Here's a friends API request for a protected user:
curl -v -H 'Authorization: OAuth realm="https://api.twitter.com/1/friends/ids.json", oauth_consumer_key="XXXXXXXXXXXXXXXX", oauth_token="XXXXXXXXXXXXXXXX", oauth_nonce="XXXXXXXXXXXXXXXX", oauth_timestamp="1300728665", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_signature="XXXXXXXXXXXXXXXX%3D"' https://api.twitter.com/1/friends/ids.json?user_id=254723679
It's worth re-iterating that as you've tried to do, instead of setting the Authorization header via e.g. jquery's beforeSend function, that for cross-domain JSONP requests (which can't add HTTP headers) you can make oAuth requests by putting all the relevant key/value pairs in the GET request. This should hopefully help out various other questioners, e.g
Set Headers with jQuery.ajax and JSONP?
Modify HTTP Headers for a JSONP request
Using only JQuery to update Twitter (OAuth)
Your request looks like it has a couple of problems; it's missing the user's oauth_token plus the oauth_signature doesn't look like it has been base64 encoded (because it's missing a hex encoded = or ==, %3 or %3D%3D respectively).
Here's my GET equivalent using oAuth encoded querystring params, which you can use in a cross-domain JSONP call:
https://api.twitter.com/1/friends/ids.json?user_id=254723679&realm=https://api.twitter.com/1/friends/ids.json&oauth_consumer_key=XXXXXXXXXXXXXXXX&oauth_token=XXXXXXXXXXXXXXXX&oauth_nonce=XXXXXXXXXXXXXXXX&oauth_timestamp=1300728665&oauth_signature_method=HMAC-SHA1&oauth_version=1.0&oauth_signature=XXXXXXXXXXXXXXXX%3D
I was struggling with similar problem of making JSONP requests from Jquery, the above answer helped just to add what I did to achieve my solution.
I am doing server to server oauth and then I send oauth token, secret, consumer key and secret (this is temporary solution by the time we put a proxy to protect consumer secret). You can replace this to token acquiring code at client.
Oauth.js and Sha1.js download link!
Once signature is generated.
Now there are 2 problems:
JSONP header cannot be edited
Signed arguments which needs to be sent as part of oauth have problem with callback=? (a regular way of using JSONP).
As above answer says 1 cannot be done.
Also, callback=? won't work as the parameter list has to be signed and while sending the request to remote server Jquery replace callback=? to some name like callback=Jquery1232453234. So a named handler has to be used.
function my_twitter_resp_handler(data){
console.log(JSON.stringify(data));
}
and getJSON did not work with named function handler, so I used
var accessor = {
consumerSecret: XXXXXXXXXXXXXXXXXXXXXX,
tokenSecret : XXXXXXXXXXXXXXXXXXXXXX
};
var message = { action: "https://api.twitter.com/1/statuses/home_timeline.json",
method: "GET",
parameters: []
};
message.parameters.push(['realm', "https://api.twitter.com/1/statuses/home_timeline.json"]);
message.parameters.push(['oauth_version', '1.0']);
message.parameters.push(['oauth_signature_method', 'HMAC-SHA1']);
message.parameters.push(['oauth_consumer_key', XXXXXXXXXXXXXXXX]);
message.parameters.push(['oauth_token', XXXXXXXXXXXXXXX]);
message.parameters.push(['callback', 'my_twitter_resp_handler']);
OAuth.completeRequest(message, accessor);
var parameterMap = OAuth.getParameterMap(message.parameters);
Create url with base url and key value pairs from parameterMap
jQuery.ajax({
url: url,
dataType: "jsonp",
type: "GET",
});