I'm trying to prevent users from downloading or accessing SWF files on my server. Using FlexPaper, the embed code looks something like this:
$('#documentViewer').FlexPaperViewer({ config : {
SwfFile : 'swf/File.swf',
// etc.
}});
The problem is, obviously, that people can view the source and go directly to the swf file, which I'm trying to prevent. Is there any way around this?
Rule #1 of the internet - of you don't want people "stealing" it, don't put it online.
That being said, you can set up a file proxy, where the file is outside of the web root. A request is make to a server-side file with the filename which then spits out a MIME header and streams your file. How you do this depends on your server-side language preferences.
It would look something like this:
SwfFile : 'serveFile.php?File.swf',
There are many plug-ins that will allow people to save the file to their local systems from the page, regardless of what you do so you need to balance your efforts against the forces of futility.
Related
I've built a simple html page with javascript in a separate file, called on a button press.
I've opened the html file in chrome, and the path resembles: file:///home/tom/projects/index.html
The javascript needs to read a JSON file (file:///home/tom/projects/mydata.json) which is in the same directory, using a hardcoded path.
I'm really struggling to do this. As I understand, this is because I'm using client side js (meaning I can't use the fs library for example), which is limiting my options.
According to the question here, I can't load the file if I use the URL in the format: file:///home/to.... as it gives me the error:
Cross origin requests are only supported for protocol schemes: HTTP, data, chrome, chrome-extension, https.
If I start an HTTP-server, as the answer suggests, I can use server-side modules, but if possible I would like to avoid this.
I've noticed many answers that suggest using a dialog box like this:
var selectedFile = document.getElementById('input').files[0];
function readFile (file_path) {
var reader = new FileReader();
reader.readAsText(file_path);
console.log(reader.substring(0, 100));
};
but I can't make this work with a path in the form: file:///home/tom/projects/mydata.json
Is there a way to load a .json file from a file:///home/to.... format URL using client-side javascript, with a hardcoded path (ie not asking the user to select the file from a selection box)?
This is a deliberate security restriction, to stop a user from being given, and then opening, a HTML page which then tries to read their disk.
Run your page in a webserver (as that question suggested) then you can either load the JSON from a URL (e.g. something like http://localhost/projects/mydata.json) using JavaScript, or use a server-side language to fetch it and display it inside the rendered HTML. Either way will work, the first way is probably simpler and closest to what you've got now.
It's always far better to serve HTML pages from a HTTP server, the way it's intended to be.
I am creating browser based video editing tool. I want a user to first download a ~70mb javascript file and store it somewhere on his computer. I want to link that file when my website is opened. How can I achieve that.
EDIT
What i meant is that there are various files like js1.js,js2.js... all sums upto 70mb . So i will offer a zip folder to download and only link js1 or js2 file etc depending on the effects user wish to apply
i am sorry to inform you but i think there is something really wrong with what you are trying to do.
A "solution" would be to just cache the javascript on the user's browser so any subsequent requests parse the cache instead of requesting the resource again from the server.
You should know however that if you are in need to download ~70mb of a javascript file you are doing something wrong. I have a whole web app project that when published the total size is around 60mb, all files required to properly run included, and its a damn big codebase in there.
I find it very hard to believe there is ever a need for a single javascript file to be that big, in any case maybe a simple caching should do the trick
That is actually done automatically. Once you add a <script> tag with a link to a local js file (also stored on the server) the file is loaded automatically.
See HTML <script> src Attribute for more information on that.
You can only reference to js files on the server. Files on the server could look like this:
index.html
somefancyjsfile.js
You can then reference from inside your html file to the js file via the <script> tag.
I'm not sure though if the size is not a bit too much...
I am trying to make a compiler in which users make code at abc.com/newProject and their output is in an iframe, that iframe need to be served files that are made at the abc.com/newProject. So I will be doing a POST of JSON obj at abc.com/compile-project that will create files and those will be used by the iframe, after being used those should get deleted. Files are basically JS files that iframe will fetch using script in header.
So a pseudo-code will look something like this:-
app.post('/compile-project', function(req, res){
//Directory created using node tmp
//files created in the directory
//These files are accessible using <script src="/js/file1.js"></script>
//when the current connection requests the files they get deleted
});
Any help will be appreciated thanks.....
I am trying to make a compiler [...] Any help will be appreciated thanks.....
I would strongly discourage you from doing that if you don't know what you're doing (and considering the fact that you're asking how to save a file then apparently you don't).
The requirements that you described are extremely simple but you need to have much deeper understanding of everything that's going on to avoid serious security problems that you will encounter with no doubt along the way.
What you describes can be done without even using a file system, since all your files are served only once so it doesn't make much sense to store them in actual files. But even if you insist on the file system then all you need is to use fs.mkdtemp to create a temporary directory, use something like the uuid module for unique IDs to use in the filenames, then use fs.writeFile to write a file. This is all you need for the file upload endpoint. Now in the download endpoint all you need is to use fs.readFile to read the file and fs.unlink to remove it. That's it.
Now, it will surely get you into trouble of failures on browser reloads, back button not working, and finally security issues of people being able to serve any random code from your servers leading to vulnerabilities too numerous to even list here.
Take a look at the source code of repl.it and JS Bin on GitHub:
https://github.com/replit/repl.it
https://github.com/jsbin/jsbin
to appreciate the scope of the project that you are willing to undertake.
Ok, this is my domain: example.com/index.html and I want to create a .txt file into the domain. result: example.com/file.txt with this info:
.js:
$('.saveButton').on('click', function (e) {
e.preventDefault();
$('.HTMLcontentTosave').html(); //save this html content into a file.txt
});
$.ajax maybe?
Thanks a lot!
Using only jQuery/javascript in the browser, and a typically configured web server, this isn't possible. The filesystem of the server is not exposed in such a way that it is directly writeable from a client, that would be a rather large security risk.
To make it possible, you will need to employ some server side code, such as PHP to assist in writing the file on the server. At that point you can send the desired content, and name of the file as a request to the server side code and that code can then write it to your desired location on the server's file system.
Make sure to employ adequate protections so only certain (safe) files can be written to, by the certain users you specify, otherwise you could open the previously mentioned security hole.
Does this help you?
Saving a text file on server using JavaScript
Also, you can go through this one.
Technically, the "right" way would be to make a PUT request (the "type" argument: see http://api.jquery.com/jQuery.ajax/), but this is apparently not supported on all browsers, and some servers may also block these by default so you'd need to get around this. I say the "right" way because a PUT request is intended to mean that the consequence will be to save a file at the pointed location.
The more common approach would be to allow a POST request but you'd need a server-side script to do things like validate that a user had permission to make the request.
Is there a way to force the clients of a webpage to reload the cache (i.e. images, javascript, etc) after a server has been pushed an update to the code base? We get a lot of help desk calls asking why certain functionality no longer works. A simple hard refresh fixes the problems as it downloads the newly updated javascript file.
For specifics we are using Glassfish 3.x. and JSF 2.1.x. This would apply to more than just JSF of course.
To describe what behavior I hope is possible:
Website A has two images and two javascript files. A user visits the site and the 4 files get cached. As far as I'm concerned, no need to "re-download" said files unless user specifically forces a "hard" refresh or clears their cache. Once a site is pushed an update to one of the files, the server could have some sort of metadata in the header informing the client of said update. If the client chooses, the new files would be downloaded.
What I don't want to do is put meta-tag in the header of a page to force nothing from ever being cached...I just want something that tells the client an update has occurred and it should get the latest once something has been updated. I suppose this would just be some sort of versioning on the client side.
Thanks for your time!
The correct way to handle this is with changing the URL convention for your resources. For example, we have it as:
/resources/js/fileName.js
To get the browser to still cache the file, but do it the proper way with versioning, is by adding something to the URL. Adding a value to the querystring doesn't allow caching, so the place to put it is after /resources/.
A reference for querystring caching: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9
So for example, your URLs would look like:
/resources/1234/js/fileName.js
So what you could do is use the project's version number (or some value in a properties/config file that you manually change when you want cached files to be reloaded) since this number should change only when the project is modified. So your URL could look like:
/resources/cacheholder${project.version}/js/fileName.js
That should be easy enough.
The problem now is with mapping the URL, since that value in the middle is dynamic. The way we overcame that is with a URL rewriting module that allowed us to filter URLs before they got to our application. The rewrite watched for URLs that looked like:
/resources/cacheholder______/whatever
And removed the cacheholder_______/ part. After the rewrite, it looked like a normal request, and the server would respond with the correct file, without any other specific mapping/logic...the point is that the browser thought it was a new file (even though it really wasn't), so it requested it, and the server figures it out and serves the correct file (even though it's a "weird" URL).
Of course, another option is to add this dynamic string to the filename itself, and then use the rewrite tool to remove it. Either way, the same thing is done - targeting a string of text during rewrite, and removing it. This allows you to fool the browser, but not the server :)
UPDATE:
An alternative that I really like is to set the filename based on the contents, and cache that. For example, that could be done with a hash. Of course, this type of thing isn't something you'd manually do and save to your project (hopefully); it's something your application/framework should handle. For example, in Grails, there's a plugin that "hashes and caches" resources, so that the following occurs:
Every resource is checked
A new file (or mapping to this file) is created, with a name that is the hash of its contents
When adding <script>/<link> tags to your page, the hashed name is used
When the hash-named file is requested, it serves the original resource
The hash-named file is cached "forever"
What's cool about this setup is that you don't have to worry about caching correctly - just set the files to cache forever, and the hashing should take care of files/mappings being available based on content. It also provides the ability for rollbacks/undos to already be cached and loaded quickly.
i use a no-cache parameter for this situations...
a have a string constant value like (from config file)
$no_cache = "v11";
and in pages, i use assets like
<img src="a.jpg?nc=$no_cache">
and when i update my code, just change the $no_cache value, and it works like a charm.