Serving static files with nginx, available through browser? - javascript

I have a server set up using nginx to serve static files (used by two apps, one Django and the other AngularJS). My concern is the following:
If someone navigates to Example Domain (or any other static file) they can see its contents. For some reason it feels like bad practice to me that users can find all my stuff (if they know the URL or care enough to figure it out). Is this a legitimate concern or am I just being paranoid?
If this is a legitimate concern, is there a way to make it so that my server can serve my Django and AngularJS apps without the static files being visible through a browser?
Thanks

Related

Access to files on HDD from AngularJS application

I have AngularJS (1.2.16) application which works on Tomcat 8.0.x I need to add following feature: create a new tab in the application (no problem) and allows to user to select concrete from select box on previously implemented new tab, file from HDD (directory is given but outside from Tomcat) and preview (PDF file). How to connect those two worlds? I have backend also.
I have found very similar question- Simplest way to serve static data from outside the application server in a Java web application but I do not understand how to get in UI a list of files from given dir. There are any best practices on that?
EDIT: I have found also possible duplicate, so you suggest to serve all files under URL? Is it safe? Is it the only one solution?
Security considerations
Providing read/write access to a filesystem folder from an application server is always a bad practice.
It should be considered if the web application will be accessed from internet.
In case we need to handle this kind of situation the better think to do is to understand which information we need to have and to modify, and wen wrap those information inside a specific API that allow to work on strictly what we need.
Or we could have an operation approach which consists in the hardening of the server and the folders that should be accessed in a way that any threat will be contained.
The solution part
This answer was proposed for duplicate of: Simplest way to serve static data from outside the application server in a Java web application.
But this part just explain alf of the requested solution.
The answer here explain how to configure an extension of the default servlet from a custom folder in Tomcat:
You have to act on the conf/server.xml:
<Context docBase="/path/to/files" path="/files" />
Here you configure a folder in a way that Tomcat will access, and connect it to a path that could be requested on the HTTP requests (http://mytomcatserver/files/).
Now you need to configure the web.xml to connect a specific servlet to this path, to be able to handle the folder content.
Once you have your servlet and your Tomcat properly configured it's time to access the folder and files.
This could be done as explained int the answer Display list of files in webpage using servlet.
In short, you cold access the folder with plain java:
File filesFolder = new File(req.getSession().getServletContext().getRealPath("/files"));
And then with the method File.listFiles() you could get the list of files in the folder.
With File.listFiles() you could also add filters that allow you to hide files you don't want the user could access.

What's difference between static and non-static resources?

I am primarily a front-end developer/designer, however recently, I've been exploring end to end solutions. Yesterday I finished a TODO application using the mean stack and would like to start exploring deployment options to my VPS.
That being said, I've been advised to use nginx as a reverse proxy is for serving up static resources? Unfortunately, I'm getting stuck on simple questions.
What are the example static resource?
What factors define static resources?
What are examples of non-static resources?
Lastly, are there any weird edge-cases I should be aware of?
Sorry about the noobness of this question.
In this case, a static resource refers to one that is not generated with code on the fly, meaning that its contents won't change from request to request.
Images, JavaScript, CSS, etc., are all candidates for this. Basically, you set a large cache time for these resources, and your Nginx servers can keep a copy on disk (or in Redis or something similar) so that they are ready to return to the client without hitting your application servers.
It's important to remember to use versioned file names when setting large cache times. header-image-20140608.png for example, means you can have a later version without worrying about the old one still being in the cache.
A static resource is something that isn't generated dynamically.
An example of a static resource is an image. It's the same for each and every request. It's a file on the filesystem that doesn't require any processing - you simply tell nginx send this file as-is to the user.
An example of a dynamic resource is json data specific to the user requesting it (it has to be generated specifically for that user).
With a dynamic resource these is also often your own domain specific code executed, a request to the database etc.
The reason nginx should serve static content is because it excels at serving this content in a parallel way - it was designed exactly for this.
If you are using Ruby/Python/node.js/Java etc, you can also serve static resources through these processes (Just call File.open() and start streaming the data) - however it would be much slower, and also lower the number of simultaneous dynamic requests you could serve.
A static resource is resource which will not be changed frequently and this can be stored on client's browser end unless required , to prevent load on web server and loading the site faster at client end.
Some examples of these are : images, javascript, css
A dynamic resource is the content that changes on a web resource which is mainly data that keeps changing on a page which is specific to a user or items.
In order to make sure that your static data reduces the load on your server and ensures fast performance on client end you need to take care of various server specific configurations like enabling the compressing of js files , rendering the header content for images properly.
When you want to change the file content make sure you prevent the browser from picking this static old content from cache, attach a time stamp with the urls of these static resources which will ensure upldated resource is loaded when needed
Static resources mean resources that don't change and do not involve server-side code.
This typically means images, CSS, and somethimes client-side Javascript.

How can I ambidextrously handle different hosts when Django is running Gunicorn behind Apache?

I have a Django installation that I would like to run multiple variations of the same site: same data, different static content, with an ultimate goal of demonstrating XYZ as implemented with various JavaScript frameworks. I would like to have different home pages load, and those pull their own distinct static content. (All intended projects are SPAs.)
I tried the solution at How can I get the domain name of my site within a Django template?, but on my system the incumbent site doesn't give a hostname of 'pragmatometer.com'; it gives a hostname of 'localhost:8000', because Django / Gunicorn is serving up pages as localhost. I tried specifying in /etc/hosts that pragmatometer.com is 127.0.0.1 and having Apache proxy to pragmatometer.com, but that resulted in an error. That leaves open the prospect of running separate hosts on different ports, which should be proxied as distinct, or making the homepage redirect to a URL-specific landing page, a solution which would sacrifice the clean URL of xyz.pragmatometer.com to demonstrate the XYZ framework implementation. I'm seeing multiple ways of duct taping it with JavaScript, only one or two of which I would want a future boss to see...
I would ideally like to have multiple (sub)domains' root URL's pulling a subdomain-specific homepage and the /load/*, /save/* etc. consistent across them. I would also like to have the root URL's pulling their own CSS and JavaScript, but that's easy enough if I can get the root URL working appropriately.
The best solution I am seeing so far is having separate server processes listening on the same IP, but having isomorphic servers running on different ports and proxied by different Apache VirtualHosts. Either that or having JavaScript detect the URL and overwrite the page with the "real" index for the domain, which has a bit of a smell.
Comments about a better solution or how to execute the above intent well?
--EDIT--
Or another approach which might be a little cleaner:
Have a home image that loads the contents of /framework/ for each framework, and then document.write()s it after the page is loaded enough for a document.write() to clobber existing page contents.
If I used jQuery to clobber and load a page in this fashion, would it leave behind any pollution that would interfere with frameworks working appropriately?
Your stack looks kinda crazy.
You want one webserver with Django which can be accessed by multiple domains. Each domain causes the Django application to serve different content. Did i understand you correctly?
If yes, maybe you are successful by replacing Apache by Nginx. It can resolve the requesting hostname and decide how to redirect the request:
What's the difference of $host and $http_host in Nginx
Multiple Domain Hosting With One Django Project
Update
Relevant nginx documentation for distinguishing between different hostnames:
http://nginx.org/en/docs/http/request_processing.html
http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name
Relevant nginx documentation for adding request headers:
http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
Also see this answer:
Adding and using header (HTTP) in nginx

Nginx (serving html) and Node.js setup

I was thinking of building a web app which would be single page, using only javascript to update the page (no reloads). So I'm confused about what kind of setup to use.
I'm kinda new to both technologies, so I was wondering if you can set up nginx to serve html (+ js, css and other static resources) like a normal web server and then from those pages connect to a node.js websocket server (same host/ip) using something like socket.io?
Is this setup good or bad? What would be a better approach? What advantage would I get if I serve html pages in node.js and get static resources (css, js, images, ...) from nginx?
I dont think serving few images and static htmls from nodejs itself will ever be a bottleneck , ideally a front end proxy like nginx is required if you need to load balance between multiple servers and also for exposing you internal http services as https traffic. If you dont have that requirement it would be a overkill imho.
From various comments in the currently accepted answer, I wanted to note the following.
NodeJS itself does a pretty decent job of delivering static content, as good as nginx in many cases.
Trying to proxy a WebSocket connection is problematic at best currently, as most proxy code simply doesn't support it. Currently, it is best to use Node directly.
If/When you have a need to deliver static content separately, best to use another domain and a CDN at that point.

Serve a html/jss/css application from CDN or application server (RoR, node.js etc)?

I'm doing a rich internet application (html/js/css) which has to communicate with a backend application server (RoR or node.js) through XHR/Websocket.
I wonder what the best way is to serve the RIA files to the web browsers: CDN or RoR/node.js as static file servers?
Does't the latter make it impossible for the browser to communicate with the backend server due to the same origin policy?
Thanks
Same origin policy applies to requests, not static files.
You are on www.test.com
$.get('api.someotherorigin.com/things.json', function(res){
// I'll get a same origin policy error
});
This is why people use getJSON/jsonp in these cases. It even applies to subdomains, depending on how things are set up.
A cdn has the benefits of serving your static files from a cookieless, often geolocation optimized source. You almost certainly don't need this during development.
The benefits later on are that you are likely going to have only a few servers (or just one) located in a spot that may favor people in one location and give a crappy RTT for folks not close. Additionally, your domain is going to likely have cookies for authentication, sessionid, etc etc -- if you use a cdn, you avoid sending these cookies along with every single subsequent request for static files, reducing the over all request/response sizes.
Just host the files yourself. You can serve static files quite easily using connect
connect.static
You may request popular JavaScript files from a cdn if you want to take advantage of caching. jscdn and google cdn are popular.
But your own personal HTML/CSS files should be on a static file server. (You can use something else like nginx to serve those through a sub domain if you want )

Categories

Resources