Could you please advise on the following?
Let's assume I have a local html page stored on my local drive "c:\test.html".
If I open it in a browser, it's treated as a GET request to this page, right?
Is it possible to send, for example, POST request to the same local page, with "fetch"?
And inside "c:\test.html" to check if it was requested with POST method, return something?
It would be something like a local-PC API.
Static HTML pages do not have any request capabilities. What's actually happening here is that there is some sort of server that takes your request and responds with the HTML document. You would need to host your own server of some sort that could take and respond to requests. For this, libraries like express.js work well.
Edit: If you are accessing it through a file:// url, your browser is just reading the file off your drive directly, so you would need some sort of localhosted server.
This is not how it works. When you open a file with your browser, it uses a file protocol, not a HTTP protocol. Look at the URL. You'll see what kind of protocol was used to retrieve the resource.
So no, you cannot sent a fetch request to a local file. You have to establish a proper sever in your localhost and let it handle requests. Local files do NOT handle requests. Servers do.
Related
I recently found (here: Does every web request send the browser cookies?) that every HTTP request contains the cookies related to a domain every time a request is made to that same domain.
Given this, what happens when the request is not sent through a browser but from Node.js, for example? Is it possible that no information is sent in the request?
Is it also possible to prevent it to be sent in the browser requests?
Browsers
Is not possible to prevent browser to send cookies.
This is why is generally it is recommended (Yahoo developer Best practice, see section Use Cookie-free Domains for Components) to serve static content like css, images, from a different domain that is cookie free.
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
Programmatically
From any programming language, instead, you can choose if you like to send cookies or not.
Cookie management is done by the programmer, because libraries are written to make single requests.
So if you make a first request that return cookies, you need to explicit read them, hold them locally somewhere, and eventually put them in a second request to the same server if you need.
So from NodeJS if you don't explicitly add cookies in your requests the http call doesn't hold them.
You Can Use Fetch with the credentials option set to omit
see
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
You can strip cookies with a proxy server. For example our product WinGate will allow you to modify requests (and responses), and you could use this to clear the Cookie header in requests.
However, this will prevent a large number of websites from functioning properly, as cookies are used to transport session IDs so that the server can identify each connection / request your browser makes as being from the same "session". HTTP itself does not have any concept of session.
Disclaimer: I work for Qbik who make WinGate.
I'm trying to process onedrive files in client-side javascript, but first I need a way to use XMLHttpRequest to download the file. Onedrive supports cors for a lot of operations, but for downloading the file into javascript there is the following problem:
As mentioned here: onedrive rest api manual
I can send a request to:
GET https://apis.live.net/v5.0/FILE_ID/content?access_token=ACCESS_TOKEN
and it will reply with a location header redirecting the browser to the file. The problem is when I send these requests through XHR, the browser always sends the Origin header with the request. For the first request I described above, onedrive also replies with an Access-Control-Allow-Origin:* header, so the request is allowed in the browser. However, when the browser is redirected to the actual location of the file, that resource does not have the Access-Control-Allow-Origin header, so the XHR request is denied by the browser(chrome sends an Origin header set to null for the redirect request).
I've also tried getting the location but not redirecting automatically, and then sending another XHR request, this will set the origin header to the domain of my site, but the result is the same.
As I mentioned in the beginning, I need to process the data in javascript, so I'm not asking about how to download onedrive files to hard drive. I need the data to be accessible by javascript in the webpage.
I know that I can use server side programming to get the file data for me and then send it to the client, but for my application this is not an option(at least this is not what I'm asking for at the moment).
If there is no way to do this, does anyone have an idea why they would implement their api this way? To allow javascript to get the location through cors and redirect but not include a cors header for the redirected resource. Why not just deny cors in the first place? Is this a bug?
The answer, as best as I can tell, is that downloading content cannot be done purely by JavaScript in a browser. Why did they do it this way? You'd have to ask them, but I would guess either a bug, or some unspecified "security concerns". For what it's worth, they seem to think that downloading content is CORS compliant in the documentation here: https://dev.onedrive.com/misc/working-with-cors.htm:
To download files from OneDrive in a JavaScript app you cannot use the
/content API, since this responds with a 302 redirect. A 302 redirect
is explicitly prohibited when a CORS preflight is required, such as
when providing the Authorization header.
Instead, your app needs to select the #content.downloadUrl property,
which returns the same URL that /content would have redirected to.
This URL can then be requested directly using XMLHttpRequest. Because
these URLs are pre-authenticated they can be retrieved without a CORS
preflight request.
However, to the best of my knowledge, they are wrong. Just because you don't need a preflight request doesn't mean that the response is CORS-compliant. You still need an Access-Control-Allow-Origin header on the response.
For anyone wondering, this is still an issue in the new Graph API (which is essentially a proxy API to the OneDrive API, as I understand it). The same basic issue is still present - you can get a download URL from your items, but that URL points to a non-CORS-compliant resource, so it doesn't do you a whole lot of good.
I have an active issue open with Microsoft here about this issue. There has been some response to my issue (I got them to expose the download URL through the graph API), but I'm still waiting to see if they'll come up with a real solution to downloading content from JavaScript.
If I get a solution or real answer on that issue, I'll try to report back here so others in the future can have a real answer to reference.
This is not an answer, I cannot comment yet.
Last week the new API for onedrive was released. http://onedrive.github.io/index.htm
Unfortunately it will not solve the problem.
https://api.onedrive.com/v1.0/drive/root:{path and name}:/content?access_token={token}
Will still redirect to a ressource somewhere at https://X.files.1drv.com/.X.
Which will not contain any Access-Control-Allow-Origin headers. Same goes for the Url "#content.downloadUrl" in the JSON response.
I hope that microsoft will address this problem in the very near future, because the API is at the moment of very limited use, since you cannot process file contents from onedrive with html5 apps. Apart from the usual file browser.
The only solution, which I see at the moment would be a chrome app, which can process the Url without CORS. see https://developer.chrome.com/apps/angular_framework
Box does exactly the same thing for download requests. I have not found any way around this problem without involving a server because the browser will not let your program get access to the contents of the 302 redirect response. For security reasons I am not convinced of, browsers mandatorily follow redirect requests without allowing user intervention.
The way we finally worked around this was
the browser app sends the GET request to the server which forwards it to the cloud provider (box/ondrive).
server then DOES NOT follow the 302 redirect response from Box or OneDrive
The server instead returns to the browser app, the content of the location field in the 302 response header, which contains the download url
The javascript in the browser app then downloads the file using the url.
You can now just use the "#content.downloadUrl" property of the item in your GET request. Then there is no redirection.
From https://dev.onedrive.com/items/download.htm:
Returns a 302 Found response redirecting to a pre-authenticated download URL for the file. This is the same URL available through the #content.downloadUrl property on an item.
I can prevent other web sites (e.g. example.com) access and use my server resources via WebSocket. I mean they cannot access the server by pointing to something like "ws://47.80.151.189:1234" and use its resources (bandwidth, memory) or receive data sent from it. It’s a node.js server.
However, my local computer can still receive data sent from that WebSocket url. It can still receive data even in this file location: file:///D:/test.html
I don't want the data exposes to anyone. So how can I prevent this and thank you.
You can restrict browsers connecting by checking the origin HTTP header.
When a JavaScript script running in a browser opens a WebSocket connection to some server, it will set the origin header to the URL (well, host) of the original HTML that contained the JavaScript that opens the WebSocket.
Note that non-browser clients are not required to provide an origin header and/or can fake to anything.
You can also restrict of course based on source IP of the connecting client. Or you can require some kind of authentication.
I'm using Simperium JS in Safari, and have been able to authenicate, and fetch data from buckets with no problems at all. I am even able to create new users.
However, when I try to use the <rest-of-url>/update/ calls when running locally on a server, I get cross-origin request issues. It appears that the Simperium server is rejecting requests from http://localhost:8000, as I can load up an HTML file (using a file:// url), and the request succeeds.
Is this an intentional thing, or am I missing something?
The auth.simperium.com/1/.../update/ call has been updated to support cross origin requests so you should be able to use that now. The reset_password and delete endpoints though probably won't be since they require use of an API key with admin privileges.
I need to send some of my data into another server. Actually to post into facebook. So here i already have an API which works by an URL.
So if i set the parameters from the URL and if i try it in web browser it works. But when i try it as a AJAX call it do not work. (Because its not hosted in the same server as my web pagers are).
Is there any way to send this URL in the background??
You cannot. For security reasons, Javascript can't initiate requests to sites in different domains.
The only way to do that would be query your own server and have it query the external API, and then respond to your page.
You will have to write a proxy routine on your own domain that communicates with your JS on the one hand and with third party domain (Facebook) on the other.
I created a iframe dynamically. It seems working.