I am doing a site which submits a form to a different server. For upload progress tracking I use: for server side the NginxHttpUploadProgressModule und for client side - jquery-upload-progress. I have tested the setup by submitting the form to the same server and everything worked fine. Submitting to another server doesn't show the progress tracking(cross domain scripting). After hours of investigating this matter I came to the conclusion that the GET request generated by JQuery is at fault.
The query looks like this:
http://domain.com/upload/progress/?X-Progress-ID=39b2825934dbb2f33fe936df734ff840&callback=jsonp1249230337707&_=1249230345572
From the NginxHttpUploadProgressModule site:
The HTTP request to this location must have either an X-Progress-ID parameter or X-Progress-ID HTTP header containing the unique identifier as specified in your upload/POST request to the relevant tracked zone. If you are using the X-Progress-ID as a query-string parameter, ensure it is the LAST argument in the URL.
So, my question is how do I append the X-Progress-ID parameter to the end of the jquery GET request or set the X-Progress-ID header?
This doesn't work with jsonp(code from jquery.uploadProgress.js):
beforeSend: function(xhr) {
xhr.setRequestHeader("X-Progress-ID", options.uuid);
}
Currently the request is generated this way(code from jquery.uploadProgress.js):
jQuery.uploadProgress = function(e, options) {
jQuery.ajax({
type: "GET",
url: options.progressUrl + "?X-Progress-ID=" + options.uuid,
dataType: options.dataType,
success: function(upload) {
...
I solved the GET parameter problem(code from jquery.uploadProgress.js):
jQuery.uploadProgress = function(e, options) {
jQuery.ajax({
type: "GET",
url: options.progressUrl,
dataType: options.dataType,
data: "X-Progress-ID=" + options.uuid,
success: function(upload) {
...
Modified GET request looks like this:
http://domain.com/upload/progress/?callback=jsonp1249230337707&_=1249230345572&X-Progress-ID=39b2825934dbb2f33fe936df734ff840
The nginx webserver is now correctly responding.
However as Ron Evans pointed out the client side progress tracking part won't work unless NginxHttpUploadProgressModule is modified.
You simply cannot fire an XmlHttpRequest from a webpage, to a domain different from the page's domain. It violates security definitions that are default on all browsers.
the only thing that I can think of that you can do is to use Flash or Silverlight to initiate the progress calls (Flash and Silverlight can, given the correct crossdomain.xml setup, send async requests from the browser to preset list of domains)
or, setup a browser addin (say Firefox plugin, or IE ActiveX, or Embedded WinForm control) that can initiate calls without the same-domain restriction (as the request will not originate from the webpage, but from the browser itself)
You need to install the Apache module for upload status as well, just using the jQuery plugin will not work.
To respond to Ken, I suggest you familiarize yourself with JSONP spec, since JSONP was created specifically to handle cross-domain Javascript calls.
Anyhow, this code works great in Passenger/Apache WITH my modified Apache module. Without modifying the extension for Nginx it will not work with a JSONP call.
I made a minor modification that solved the problem for me, you can check it out here:
http://github.com/tizoc/nginx-upload-progress-module/commit/a40b89f63b5a767faec3c78d826443a94dc5b126
Related
I have code (Classic ASP) which was recently working POSTing orders to Shopify but has now stopped POSTing and either creates an error "A Redirection problem has occurred" or redirects to the admin area of the Shopify site, depending on which XMLHTTP component I employ. The code below still works on older OS but not on Server 2016 where I am working.
I can't find much on Google but there was an indication in the Shopify Forum that the problem was a result of cookies (I have set none) and that this is overcome by sending a header containing X-Shopify-Access-Token:. I tried this using the "Authorize" setRequestHeader but it made no difference, or I got the syntax wrong or something. I used
xmlhttp.setRequestHeader "Authorization","X-Shopify-Access-Token=<token>"
Below is the code that worked a few weeks back. Variable jsondata contains valid JSON to send to create an order.
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP.3.0")
xmlhttp.Open "POST", "https://<api key>:<passowrd>#<sitename>.myshopify.com/admin/orders.json", false, "<api key>", "<password>"
xmlhttp.setRequestHeader "Content-Type", "application/json; charset=utf-8"
xmlhttp.setRequestHeader "Content-Length", Len(jsondata)
xmlhttp.Send jsondata
Set xmlhttp = nothing
I expect a POST and a JSON order response but this is not happening - just a redirection to https://<sitename>.myshopify.com/admin. Any ideas anyone?
When I hit site for first time, then results of request.headers[HTTP_ACCEPT] is "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
but between internal links requests it shows text/html, application/xhtml+xml
until I hard refresh the page.
Is it due to turbolinks or any other issue?
It's a turbolinks issue. By default, the turbolinks' XMLHttpRequest, only send the headers "text/html, application/xhtml+xml", but you can send the "image/webp" header by capturing the request-start event like this:
document.addEventListener("turbolinks:request-start", function(event) {
var xhr = event.data.xhr
xhr.setRequestHeader("Accept", "image/webp")
})
The question is how to know from javascript whether or not the browser accepts webp images to send the "image/webp" header to the server.
You can use the Modernize library or a custom function that guess if webp is available when trying to decode a small webp image like described here: https://developers.google.com/speed/webp/faq. However, these solutions add a certain overhead that precludes the benefit of the fastest load time of webp images.
Maybe, the most efficient solution is to create a boolean cookie in the server side to store whether or not webp images are accepted. The cookie is stored with the first browser GET call to the server. In subsequent turbolinks calls you can check this cookie in your javascript code:
document.addEventListener("turbolinks:request-start", function(event) {
browserAcceptsWebp = document.cookie.includes('webp_available=true');
if (browserAcceptsWebp) {
var xhr = event.data.xhr;
xhr.setRequestHeader("Accept", "image/webp");
}
});
I'm using Angular2 Beta 14 and calling a URL with a "dot" in it leads to a 404 not found error from the lite server which is 2.2.0.
This is the URL I'm calling:
http://localhost:3000/confirmuser/token/eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjYsInVzZXJOYW1lIjoiYXNkZmFzQGNlZC5saSJ9.PMzNWp8mbUKbSAiOqhOqjhZUYNejXY3pIQueBkc8_2E
The router path in app.component.ts looks like this:
{path: '/confirmuser/token/:token', name: 'ConfirmUser', component: ConfirmUserComponent}
The Chrome console shows this:
Failed to load resource: the server responded with a status of 404 (Not Found)
Ant the Lite Server:
[1] 16.04.13 15:57:13 404 GET /confirmuser/token/eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjYsInVzZXJOYW1lIjoiYXNkZmFzQGNlZC5saSJ9.PMzNWp8mbUKbSAiOqhOqjhZUYNejXY3pIQueBkc8_2E
When ever I call the url without a "dot", the page gets loaded correctly.
My aim here is, to confirm a user sign up. He receives an email with an URL he has to confirm. Using a JWT in this (and other cases) is habit I've been using.
Now I doubt this is an Angular issue, I believe this is a lite server issue.
Anyone experience with this?
Thanks
I found a suitable workaround for this issue.
Basically I'm getting rid of the path parameter ":token" and replacing it by a query parameter
In the app.component.ts the new path now looks like this:
{path: '/confirmuser', name: 'ConfirmUser', component: ConfirmUserComponent}
An the URL like this:
http://localhost:3000/confirmuser?token=eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjYsInVzZXJOYW1lIjoiYXNkZmFzQGNlZC5saSJ9.PMzNWp8mbUKbSAiOqhOqjhZUYNejXY3pIQueBkc8_2E
In the component that handles this request I can continue to call route params as I was used to. So nothing to change there:
constructor(params: RouteParams){
this.token = params.get('token')
...
This question has been answered in https://stackoverflow.com/a/36283859/1465640#
But it can be summarized with dots doesn't work in urls unless you do some work on the lite-server config.
If you are using webpack then you need to change the config to make it working.
Please make the change in webpack dev server config file
historyApiFallback: {
disableDotRule: true
},
I am a newbie with Ruby on Rails and I am trying to figure out ways to connect Angular to RoR in a very simple way
Here is my service
mWebApp.service('mWebSrvc', function($http, $log) {
this.getCustomers = function() {
$http({
method : 'GET',
url : 'http://127.0.0.1:3000/api/customers/'
}).success(function(data, status, headers, config) {
$log.log('Done');
angular.forEach(data, function(c) {
$log.log(c.Title);
});
customers = data;
return customers;
});
};
});
When I look under the Net tab in Firebug, I see OPTIONS /api/customers/ 404 Not Found, but if I click on the Response tab within, then I see the JSON file - WTF? And not the JSON tab - again, WTF?
Under Firebug's console -
"NetworkError: 404 Not Found - http://numberForLocalHost:3000/api/customers/"
My Rails server is running in daemon mode - numberForLocalHost:3000 - is this what the issue might be? That it should be calling a true api
If I paste the URL above into any web browser, then I can see the JSON
As usual, thanks in advance
You're getting an OPTIONS request because your browser believes this is a cross origin request.
See this question for example. Is your RoR app also serving your client side angular? If not, you should decide whether it can be (there shouldn't be a reason not to), or you need to reply to the pre-flight OPTIONS request from your server that you are seeing.
I had the very same issue with my Rails + Angular app. I had my cors well set up in my rails app but still nothing, I still got a 404 not found in the angular app. This could be the reason:
Perhaps you have "angular-in-memory-web-api": '0.x.x' in your package.json and also imported in your app.module.ts, as InMemoryWebApiModule and InMemoryDataService. These apparently intercept all calls to an API preventing them from ever reaching your back-end server. When I Removed those dependencies and their declarations, all of a sudden my app started working normally!
Look at this answer for more information.
I've installed Luracast's Restler API framework and am having marvelous success with it all except when sending PUT or DELETE across domains. The below works fine when all on the same server, but when I cross domains, Firebug shows the the PUT or GET as OPTIONS, and it is not found on the server. Am baffled how to stop "OPTIONS" being sent instead of PUT or DELETE.
$.ajax({
url: url,
type: 'PUT',
data: "thename="+ $('#TheName').val(),
success: function(xhr, status) {
console.info(xhr);
},
error: function(xhr, status) {
console.info(xhr.responseText);
},
complete: function(xhr, status) {
$('#showResponse').val(xhr.responseText);
}
});
Per another thread somewhere, I've added the below to the Restler output:
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: GET, POST, DELETE, PUT, OPTIONS');
You've got the right response headers, but you have to have your server respond to an OPTIONS request with those headers, too.
This is a cross-origin request, and is subject to something called preflighting. Before making the PUT or DELETE request the browser asks the target web server if it's safe to do so from a web page at another domain. It asks that using the OPTIONS method. Unless the target server says it's okay, the web browser will never make the PUT or DELETE request. It has to preflight the request, because once it's made the PUT or DELETE, it's too late to honor the response; sensitive information may have been leaked.
GET and POST are a bit more complicated, as sometimes the browser decides they are safe without asking first, while other times the browser will also do a preflight check. It depends on whether certain headers are used in the request.
The CORS spec has the gory details. The bottom line is that the code on your web page will not be allowed to make these requests unless the target web server supports the OPTIONS method, and the response to the OPTIONS method includes the headers saying that such requests are allowed.