I want to add a set of static files to my meteor app; it's currently deployed to an nginx + ubuntu server as described here. When I simply add the static file to the app and execute restart appname, it doesn't work (the 404 page is displayed instead of the file), while files which were already deployed work fine.
However, when I re-build my entire app and restart the app on the server, the static files are served appropriately. Why? Does it have to be this hard?
Depending on whether or not you want your static files to be publicly available, you should do one of two things when setting up your application. Put assets only accessible by your application on the server and not accessible to the rest of the world within the private top-level directory in your application. Once these are bundled into your application, they will appear in the directory /program/server/assets. If you want files to be accessible to the world on the client, put them in the public top-level directory in your application. These files will be available from the top level of your website (www.example.com/examplefile.jpg).
As for whether or not you should rebuild your application when attempting to deploy new static files in your application, it is best to allow Meteor to properly bundle everything as necessary into the application rather than trying to add files to your application directly.
For additional information, please see the Meteor documentation here or check out this SO question/answer here.
Related
I'm testing out Blazor WebAssembly and I'm hung up on one detail of deployment. I'm using the VS 2019 sample app, and deploying it to Firebase Hosting. It works, for the most part, but I can't figure out how the auto-generated web.config file should fit in.
When I publish the app to a local folder (call it dist), the contents are one file (web.config) and one wwwroot subfolder (where everything else goes, including index.html). If I deploy the entire dist folder, as expected the website cannot load on the internet because there is no index.html in the root. Conversely, if I deploy just the wwwroot folder, it can be loaded via the internet, but since the web.config file is missing, I get some issues with pages loading. I'm assuming that's because the rewrites contained within web.config are missing.
So my ultimate question is, when hosting in a non-IIS environment like Firebase, where or how does the web.config file, or its contents integrate?
Can someone help me... When I run firebase deploy it's deploying my static folder to hosting, but when I open website url in browser and check source files, there all my files with configs and components, tokens for DB as well. It is not safe at all... everybody can view all source files. How I can deploy so that nobody can view config files etc?
The Firebase CLI will deploy everything you put in the "public" folder by default. Once that folder is published, everything is, as you observed, public information.
If you don't want a file to be deployed, you should either remove it from the public folder, or tell the CLI to ignore that file for deployment using the ignore configuration in firebase.json.
I got a 503 when trying to upload using the CollectionFS Filesystem adaptor (only on production, local works fine.)
the response headers show:
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Methods:PUT
Access-Control-Allow-Origin:http://meteor.local
I would like to know what this address is, but I could not find documentation about it.
Few thing that come to mind:
Your static files URL under the web server.
Do you set it to a virtual directory (location) on your web server?
If yes, check your nginx/apache virtual directory directives. Make sure there are correct
Do you handle it in your meteor application?
If you set it to your meteor application, did you set the route for it in your application correctly?
Permission issues between the user that run the web-server, the user that run the meteor application and the user that own the actual folder on the file system
Currently working on an internationalization project. One of the requirements is to take static files published from a content management system and serve the correct language version based on the locale. Unfortunately the published files are .aspx and include references to master pages and potentially other controls.
If the pages are inside the web root, this is pretty easy. I just have something in global Application_BeginRequest that takes a request for /abc.aspx and rewrites it to /content/[locale]/abc.aspx.
For ease of deployment and a couple of other reasons, I would really like these files to be outside the web root. e.g. site is in "D:\www_root\site\" and content is in "D:\content".
Is there a way to achieve this?
You can create a virtual directory in IIS that points to d:\content.
A virtual directory is a directory name (also referred to as path) that you specify in IIS and map to a physical directory on a local or remote server. The directory name then becomes part of the application's URL, and users can request the URL from a browser to access content in the physical directory, such as a Web page or a list of additional directories and files.
We're having the same setup and receiving the same problem as:
IIS 6 with wildcard mapping and UNC virtual directory problem
Setup
Server 2003 32bit, IIS 6
ASP.NET wild card mapping
A virtual directory mapped to an UNC share serving static images for a CMS in a load balancing environment
My question if it's possible to turn off asp.net from virtual and only serve static files e.g. images in the virtual directory, to avoid the problem with too many open connections?
If it's not possible I'll guess I have to implement a solution like Version control of uploaded images to file system to server the files from a local disc.
I found a possible solution at http://blog.stevensanderson.com/2008/07/07/overriding-iis6-wildcard-maps-on-individual-directories/ that removes the wild card mapping and makes it possible to turn of execution of asp.net files.
There is not a way to remove .NET from a subdirectory as it is part of an application at this point (your root directory). However, this method works just fine for keeping .NET from processing your static content.
From your site that you linked:
Alternative
If you don’t like to use adsutil.vbs, you can achieve the same by exploiting what appears to be a bug in IIS Manager. Turn your subdirectory into an application (from its Directory tab, click “Create”). Then edit its script mappings to remove aspnet_isapi.dll. Then go back and “Remove” the application you just created. The metabase’s new ScriptMaps value will be retained, even though the option has now disappeared from the GUI.