I'm using Express and I need to download a file from server. I can easily download it with just , but there is some query parameters, that I want to hide from user.
So now I'm trying to use jQuery.ajax that sending a request to Express (srv1) and then Express sending request with my parameters to the another server (srv2). Server responds me with 'Content-disposition' header and a file data. It's ok. And there is a question - can I use that file and respond with it to my initial ajax request?
The problem is, that even res.download() with files (that already on my srv1) doesn't work. Express sets headers well, but no file is prompting to download. Maybe there is a probem in ajax?
You cannot cause the browser to perform a file download with a javascript ajax request (this is a security limitation). See https://stackoverflow.com/a/9970672/266795 for details. You'll need a normal browser GET or POST request to get a proper file save dialog.
Related
I am attempting to create a custom connector for the Clio API (https://app.clio.com/api/v4/documentation). I was able to successfully authenticate and access the API in Postman, testing out quite a few different types of requests with good results.
Then I exported the collection to a Postman file and imported it into a new custom connector in my MS Flow account as instructed at https://learn.microsoft.com/en-us/connectors/custom-connectors/define-postman-collection. As part of that process, I entered the following settings:
Scheme: HTTPS
host: app.clio.com
Base URL: /
Within the custom connector requests, all the definitions looked acceptable, except that instead of having the fully qualified request URL, they did not include https://app.clio.com.
For example, one request should use the following address:
https://app.clio.com/api/v4/contacts.json
The field in MS Flow, where URL should be entered, is grayed out and only includes /api/v4/contacts.json and looks like this:
The grayed out field cannot be typed in. Instead, I have clicked "Import from sample," which leads to a window where I can type in the fully qualified URL. After I do that and click the "import" button, the window still lists the partial URL as shown above.
At first I thought that was intentional, since I had entered the host elsewhere for the connector, and I thought that Flow would put them together to send the request to the right URL. But it did not: when I tested the operation, I got a 404 error:
{
"error": "{\r\n \"code\": 404,\r\n \"message\": \"Unable to match incoming request to an operation.\",\r\n \"source\": \"msmanaged-na.azure-apim.net\",\r\n \"path\": \"\",\r\n \"clientRequestId\": \"500779d5-356d-4c79-bf96-caf2-f5bc2919\"\r\n}"
}
When I looked at the request, this is the URL:
https://msmanaged-na.azure-apim.net/apim/clio2.5fb03ce8462066f352.5fdeb6bc35b813689d/92053762-68ce-4c1d-9085-0785-0fd98c3b/api/v4/contacts.json?type=Person
So obviously Flow is not using the correct request URL, and I cannot figure out how to enter the fully qualified request URL. Can anybody tell me what I am doing wrong?
I found another comment where someone else is having the same problem: https://stackoverflow.com/a/48813209/7191369 so I'm not the only one. Thanks in advance for your help.
Edit:
After some additional searching, the address in the request (with https://msmanaged-na.azure-apim.net) is the required redirect URL for the proxy per this post: https://powerapps.microsoft.com/en-us/blog/custom-api-with-authentication/, and is used when processing OAuth. But the crappy part of this is that I can't see the request URL so I can't troubleshoot. Is there any way to see what request the proxy server is sending out to the Clio API?
It's been a while since this question was posted, but let me give you a suggestion to include the /api/v4 part of the URL inside the Base URL property of the Flow. This way all your endpoints will use the specified version and you will not have to define them one by one in each request.
Except if you intentionally want to use different versions across the requests :) Anyways, I'm glad that you've been able to resolve the issue.
Facing the issue while developing the performance script for salesforce application. The issue is, one of the apexremote post call is too large in size. Jmeter is getting hanged if i am trying to click that particular request. Even if I manage to enhance the post request somehow the cursor is not going to end of the line. Hence at the end of the line there is one CSRF which I am not able to correlate. This is only happening for only one apex post request. Because of this my orders are getting rejected while provisioning. I tried by increasing my heapsize in jmeter.bat file but no help.Searched in google but didn't find related queries. I tried the same thing with neoload and I was successfully access and enhanced that particular request.
Has anyone experienced ever! How to resolve this.
Please HELP!
1.Basically for that you need to be Patience after clicking on the request and when the request populate properly copy that post data into notepad++for correlation purpose.
2.Or other solution is Open the .JMX directly into notepad and from there copy the post data into other notepad++ instance and form there with some manipulation you can do correlation.
3.Hope you already changed the property "view.results.tree.max_size=0" in "jmeter.properties" file because may be for next correlation you will get the message like "Response data is to Large".
I had also faced the same issue several times in past, so in that case just copy the complete post body and paste it into notepad++ and modify the content there instead of modifying in jmeter itself, then paste the content back to jmeter and execute it.
This will resolve your issue but have patience while clicking on http request to copy the post body because it'll take some time to open the request properly
I have found out the solution for the very big request for which meter is getting hanged. The best solution is to take the request from the html body of the view result tree listener for the recorded original one and paste in the payload of a new sampler. Then add it in appropriate place accordingly. We can also keep a raw request and make the correlation changes there itself instead of messing around in the big request payload.
I am working on upload file module that works on internet explorer only and it requires following browser setting mandatory:
"Include local directory path when uploading files to server" should be enabled.
A failure message "Unable to upload file" displays when we do not make required setting in browser while manual attempt else it works fine.
Now when I am trying to record the scenario in JMeter, getting same error message even I made required browser settings.
Note: Additionally, I tried to include these calls by copying from browser tools and paste it in JMeter transaction but get the same result in response.
Have any one experience the same or can help me out?
Thanks,
Nitin
Few things to consider:
Make sure that you use Java implementation of HTTP Request
Make sure that "Use multipart/form-data for POST" is checked
Make sure that you provide a file within "Send Files With the Request" field providing correct path, parameter name and mime-type
If all above has already been applied and you still experience problems I would recommend to capture the data being sent by Internet Explorer with a sniffer (Fiddler, Wireshark, etc.) and compare it to data, being sent by JMeter. They must be the same. If they aren't - you'll need to customize it using HTTP Header Manager, HTTP Cookie Manager, etc. If JMeter is not flexible enough to set all the required parameters via GUI, i.e. still tries to send full path of file instead of just filename or vice versa, you can always go deeper and manually build multi-part post request via Java Request Sampler (see SleepTest and JavaTest source code for details) or via Beanshell which is 100% compatible with Java syntax but may be harder to debug due to it's script nature.
Path to SleepTest and JavaTest files is follows:
/src/protocol/java/org/apache/jmeter/protocol/java/test/JavaTest.java
/src/protocol/java/org/apache/jmeter/protocol/java/test/SleepTest.java
JMeter sources are available from JMeter download page
Steps to upload the image using jmeter:
locate the image in bin folder Select Post method and check the "Use
multipart/form-data for POST" in HTTP Request
Provide details of Send files With the Request in HTTP Request
Record the Upload scenario and stop button in Jmeter (Image wouldn't upload while recording in Jmeter)
Now before running the script, Go to upload response and give the full path of image in "Send files with request field"
Now Run the script. You can able to see the image
Sometimes I come across an image that I can't scrape so that it can be saved. An example of this is:
https://s3.amazonaws.com/plumdistrict.com-production/perks/12321/image/original.?1325898487
When I hit the url from Internet Explorer I see the image but when I try to get it from the code below I get the following error message "System.Net.WebException The remote server returned an error: (403) Forbidden" error with GetResponse:
string url = "https://s3.amazonaws.com/plumdistrict.com-production/perks/12321/image/original.?1325898487";
WebRequest request = WebRequest.Create(url);
WebResponse response = request.GetResponse();
Any ideas on how to get this image?
Edit:
I am able to get to save images that do have extensions. For example I can scrape the following image just fine:
https://s3.amazonaws.com/plumdistrict.com-production/perks/12659/image/original.jpg?1326828951
Although HTTP is originally supposed to be stateless, there are a lot of implementations that rely on it being stateless. I could configure my webserver to only accept requests for "http://mydomain.com/sexy_avatar.jpg" if you provide a cookie proving you were logged in. If not, I send you a redirect 303 to "http://mydomain.com/avatar_for_public_use.jpg".
Amazon could be doing the same. Try to load the web page using Chrome, and look at the Network view in developer mode (CTRL+SHIFT+J) to see all headers supplied to the website. Maybe you even need to do a full navigation in the same session before you are allowed to see the image. This is certainly the case in many web applications I have developed :-)
Well, it looks like it's being generated from a script (possibly being retrieved from a database). The server should be sending a file/content type to go along with that... but it doesn't seem to be, which I believe is a violation of standards.
My Linux box knows full well that that's a JPEG image once it's on my hard drive, because it examines file headers rather than relying on extensions. Perhaps there is a tool to do the same in Windows?
Edit: Actually, on further contemplation, it seems odd that you'd get a 403 for that. Perhaps the server is actually blocking you from retrieving the file in that manner.
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load
http://External-IP:port/page.php. Origin
http://myTestdomain.tld is not allowed
by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple $.post() to the other domain (External-IP)?
Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
The important thing to note about the JavaScript same-origin policy restriction is that it is something built into modern browsers for security - it is not a limitation of the technology or something enforced by servers.
To answer your question, neither of these are bugs.
Requests are not stopped from reaching the server - this gives the server the option to allow these cross-domain requests by setting the appropriate headers1.
The response is also received back by the browser. Before the use of the access control headers 1, responses to cross-domain requests would be stopped dead in their tracks by a security conscious browser - the browser would receive the response but it would not hand it off to the script. With the access control headers, the server has the option of setting the appropriate headers indicating to a compliant browser that it would like to allow certain origin URLs to make cross domain requests.
The exact behaviour on response might differ between browsers - I can't recall for sure now but I think Chrome calls the success callback function when using jQuery's ajax() but the response is empty. IIRC, Firefox will not invoke the success function.
I get the same thing happening for me. You are able to post across domains but are not able to receive a response. This is what I expected to be able to do and happens for me in Firefox, Chrome, and IE.
One way to kind of get around this caveat is having a local php file with will call the data via curl and respond the response to your javascript. (Kind of restated what you said you knew already.)
Yes, it's correct and you won't be able to do that unless you use any proxy.
No, request won't go to the external IP as soon as there is such limitation.