I was recently made aware of meteor private subdirectories. According to the docs: "The private subdirectory is the place for any files that should be accessible to server code but not served to the client, like private data files." I am a newbie at web development in general, so my question is what is the advantage of having these files within the private subdirectory vs. just in the server subdirectory itself? Is the server subdirectory not private - e.g. I have some email templates defined and my email login information is set up in a startup function in the server subdirectory, are these somehow exposed to the client? Any clarification would be very helpful, thanks!
No, your code in the server directory is safe. The difference is on how you use/access those files. Files in your server directory will be loaded/executed on the server, and they would also be difficult to access using the filesystem in the running app. Content of files in your private directory is available as an asset. See http://docs.meteor.com/#assets for full details.
The thing to note is that your server code does not execute in your server directory, but will have a current working directory that is a temporary build directory within .meteor. So if you wanted to use, say, the fs node package to read files in your server directory, you'd first need to find it. Moreover, any new file or a file change in your server directory will trigger meteor to restart your app. There are scenarios where you don't want that. So private gives you a place to handle files that do not affect the execution of the app.
Another way to think about it is that private is for the server what public is for the client.
Related
I am working on a Symfony 2.8 project, and I would like to ask users to upload files via a form. These files are not public (like a profile avatar or something), so I don't want to place them under web/, after uploading them only the admins are allowed to know the location of them and to open them via the admin interface of the site. Moving uploaded files near the source code in the actual bundle sounds wrong to me...so is there any official or recommended path to move the uploaded files which is still under the root of the project?
If your requirement is that uploaded files should be downloadable by authorized people only then you must keep them outside the web root obviously. Any directory outside would be fine however they should be kept outside your codebase as well.
You could create data directory in the project root for instance. You can event mount a NFS/S3 share, that choice is yours to make.
To allow files to be downloaded you can create a controller which would serve files to authorized requests only. Example controller (PHP7 based):
final class DownloadController extends Controller
{
/**
* #Route("/download/{path}", requirements={"path"=".+"}, name="download")
* #Method("GET")
* #Security("is_granted('FILE_DOWNLOAD', path)")
*/
public function __invoke(string $path): Response
{
return $this->file($yourUploadBasePath . $path);
}
}
You can either create a data or uploads directory in your project root or if your server is nginx and you have control over web server configuration, you could use http_auth_request module:
https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
Then if you try to access the file, nginx performs a subrequest to your application and if your app returns anything else than 2xx status code, access to the file is denied.
The downside of this approach is that if you replace the webserver or have some error in the configuration, those files would be publicly exposed.
I am relatively new to Drupal. I have a drupal site on my staging but I would like to transfer the site to production server. My question is: Is doing drush archive-dump enough to do this? I tried doing this and it seems like the site is not loading the configurations correctly? I already executed the sql commands from the file generated by the dump.
There are three components to moving a Drupal site to another server:
Database
Code
Files (e.g. files uploaded by content creators; usually sites/all/public)
drush archive-dump is specifically there to grab all three and tar them. So yes, that is all the data you need. There can be other issues (e.g. server permissions; software versions; DB credentials; etc...)
To go live you need to:
Test your site in the same environment as production site have.
Move code to production server.
Move database to production server.
That's all.
Please read:
http://www.slideshare.net/erikwebb/the-basics-of-smart-drupal-deployment
https://www.drupal.org/best-practices
Almost. It seems that archive-dump will not include the Private Files Directory if it resides outside the DocumentRoot.
Some administrators will place the Private Files in a directory such as DOCROOT/sites/default/files/private/ and although Apache 2.x should deny access to this directory directly via .htaccess rules, placing this outside the DocumentRoot entirely ensures that protection regardless of HTTPD service...
So no, archive-dump is coming up short if you have Private Files outside your DocumentRoot directory.
According to the Meteor Doc, the public fodler is accessible for both server and client. But, if I just need to use the HTML head elements to access it, how can I do it from server ?
I made a lib with very specific functions, and I'm tired of copy pasting them at the top of each of my server .js file.
Could anyone give me the tip ? I couldn't find out on google :/
Thanks you,
David
You are making your life harder than necessary. Any folder that is not called client, server, private, or public is shared by the client and the server. Just put your shared .js files into any folder, say, /common, and they will be available (loaded) on both the client and the server.
The public folder is specifically for assets that are not loaded automatically by the server, but are instead served statically over HTTP, similar to the static functionality of express. It's the place for images and other assets you want on the client.
My ASP.NET Web API service dynamically generates files for users to download.
The remote application sends a request to the API which:
Generates the file and saves it ----> where?? <-----
Returns the URL of the file location so it can be downloaded.
Nothing fancy there, but my question is what are the best practices for where to save these files?
Some digging around suggests that App_Data might be the appropriate place but I haven't seen anything definitive.
Some considerations:
This all happens on a company intranet so security isn't really a big deal.
The files are essentially temporary. Is there a simple way to delete the file once it's downloaded? Not a big deal - I can set up a scheduled task to clean out whatever the destination folder is.
Thanks!
You can write to any location your application stores data in.
I recommend using the system Temp directory, that's what it's there for (System.IO.Path.GetTempPath()) or if your have write access, a subdirectory of your application:
String path = Server.MapPath("~/Temp");
if( !Directory.Exists( path ) ) Directory.CreateDirectory( path );
using(FileStream fs = File.OpenWrite( Path.Combine( path, "TempFileName.dat" ) )) {
fs.Write( new Byte[1024] );
}
If you have access to your web server, you could also create a virtual directory under your web application and configure it to point to whatever file location you want. Then you can have your application save the files into that virtual directory using System.IO. That's what I've done in the past.
I have video files (mp4's as I want people to be able to view them on ipads etc.) that I serve to users. However some of these videos are only available to users who have a certain number of user points. I have that working in that if a user doesn't have enough user points they can't view the node. All users have the same role (video viewer) and the problem is that it is possible for someone who has enough user points to view the node, grab the url of the video and then give it to someone who has the video viewer role but doesn't have enough user points and then that person can directly download that mp4.
Just looking for a way to limit access to the mp4 file if a user does not have access to the node or hide the path to the file somehow. I have the mp4's stored in a private file system but this hasn't solved the problem as the users have the same role.
I've got this (http://www.ioncube.com/html_encoder.php) working on static pages in my webspace (non drupal pages) but can't get it working in my drupal setup. When I include the php code in my node to include the php file it just gives me a blank page.
Many thanks
There's not much I could say about this that the Drupal documentation doesn't already.
http://drupal.org/documentation/modules/file#access
Managing file locations and access
When you create a file field, you can specify the sub-directory of the site's file system where uploaded files for this content type will be stored. The site's file system paths are defined on the File system page (Administer > Configuration > Media: File system).
You can also specify whether files are stored in a public directory or in a private file storage area. Files in the public directory can be accessed directly through the web server; when public files are listed, direct links to the files are used and anyone who knows a file's URL can download the file. Files in the private directory are not accessible directly through the web server; when private files are listed, the links are Drupal path requests. This adds to server load and download time, since Drupal must resolve the path for each file download request, but allows for access restrictions.
The best practice for public files is to store them in the multi-site directory like: sites/default/files
The default way to securely add a private directory for your files is to use a directory that can not be accessed directly by your web server, but can be accessed by Drupal. Ideally this directory should be located outside of your Drupal root folder.
The simple way to add a private directory for your files is to create a sub-directory under the public directory like: sites/default/files/private
When you specify the private directory in admin/config/media/file-system it will automatically create the sub-directory & create a simple .htaccess file with Deny from all. This stops Apache from serving files from this directory. Make sure that you test this by adding file to that directory and verifying that you can't browse there directly. If this isn't working, all files in this directory will be accessible to anyone who can guess the URL! Note that non-Apache web servers may need additional configuration to secure private file directories.
Accessing Private Files
Once configured, files stored in the private directory are inaccessible via a direct link; however, if Drupal constructs a link to the file, the file will be accessible to anyone who can see the link.
For example: you have created a new content type with a file field which stores files in your site's private file directory. Next you create a node from this new content type and attach two new files. When the node is published links to both attached files are visible and anyone who can view the node may download the files. Now, if you unpublish the node, all attached files become inaccessible for download even if you use the direct link to the files that worked when the node was published.
Re-publish the node, and disable the "display" checkbox for one of the files. Save the node. Now one file is accessible for public download and the other is not accessible--even if you have the direct URL for the file that is not listed you will not be able to download this file.
For finer grained control of who can see/download attached files you will need an additional access control module. You may write a module yourself, or use a contributed module such as Content Access.