Node.JS Express Security with document root - express

I am building a Node.JS Express App which can load plugins.
These plugins are in the root folder of my project.
database
helper
plugins
webserver
....
Each plugin can register routes and handle own views. I do this so this is capsled.
In this case I set the view to the document root which I showed you above.
app.engine("eta", eta.renderFile);
app.set("view engine", "eta");
app.set("views", "./");
app.use(express.static("./"));
I need this, so that I can include templates from main site and the plugin as well
for e.g in a plugin:
// This is inside the plugin
<%~ includeFile('./partials/meta/default_header', it); %>
<%~ includeFile('./partials/addon-styles.eta', it); %>
// This is from the main project
<%~ includeFile('/webserver/views/partials/navbar.eta', it); %>
<div style="height: 20px;"></div>
I want to know if this is a security risk for my application. And are there other options I can receive same results but not to set the views root to the root folder of my project. Are there any other attempts or can you give me the same behavior, only without going to the document root directory as the view directory?

Related

Vue.js - How to loop through a folder

I have a Vue SPA app. Now I want to extend this app with app modules so I thought to make a folder src/modules that contain the modules folders. I want to put at the root of each folder some configuration js files (store.js, route.js, and so on).
The question is: in the main files (src/store/index.js, src/router/index.js, etc.), how can I loop for every folder in src/modules and check if some configuration file exists to add its content at the main config? Of course this operation should be executed at build time, modules install is not intended to be dynamically.
Thanks a lot
You can use require.context
const configurations = require.context('./modules', true, /config\.js$/i);
configurations.keys().forEach(filename =>
{
console.log(filename);
// file contents will be inside configurations[filename]
});

NuxtJS SPA mode (ssr false) still generates HTML for each vue file in the pages folder

The Nuxt documentation (latest) states that for SPA you need to set ssr: false in nuxt.config.js. Also, every vue file in the pages folder is added to the router configuration, so you don't have to do this yourself. This is both correct and works perfectly, but there is something I really don't understand.
When I run npm run build (nuxt-ts build), it builds the production output of the project and puts in the dist folder (default). I was surprised to see that even though I configured it to be a SPA, it still generates HTML files for each vue file in the pages folder.
It happens with newly generated projects using npx nuxt-create-app as well.
What I'd expect is that it only generates one HTML file (which is index) when ssr is set to false and when I want a static app, I would use npm run generate or set target to 'static' to create HTML files per route.
Nuxt documentation also states this for the target property:
https://nuxtjs.org/docs/2.x/get-started/commands#target-server-default-value (builds output to dist)
https://nuxtjs.org/docs/2.x/get-started/commands#target-static (generates HTML per route)
All I have in my config is ssr set to false, so it should not generate static files (HTML) per page.
What am I missing here, or am I misunderstanding how this works?
Thanks in advance!
Remember that in a static setup, your visitors may arrive at your site via any of your page routes— not just index.html.
For example, they may access https://www.your-app.com/contact-us. If you do not have a contact-us.html file available, and you don’t have a server configured to handle this request (as is the case with universal mode), you’re gonna end up with a 404.
What happens in static mode is contact-us.html is served, which contains the minimum javascript necessary to hydrate your nuxt app, then SPA mode kicks in— giving you client-side navigation.

How do I introduce a build step into a "mixed mode" vue/asp.net app

We're currently using vue as a script file without a build step. We want to start using webpack and vue-cli. We need to preserve the asp login pages and session handling (cookies) so we need the vue stuff and the asp stuff to share an origin.
The current plan is to ignore the vue dev server, to put src and dist inside the existing .net project folder, and to have iis serve the contents of dist. Is this the way to go? We will lose hot reloading.
If we do this, how and where do I configure the url fragment from the web root to the dist folder? Currently, vue expects dist to be the root of the domain.

EXTJS 4 Custom Plugins and/or Features where to place

So I've set my project up using sencha cmd. I have the following dir
app
-model
-view
-store
-controller
If I create custom plugins or feature where should I place them under views, or some other location?
I have the following directory structure:
app
controller
model
plugins
store
view
You then include each plugin in your header:
<script type="text/javascript" src="app/plugins/SomePlugin.js"></script>
There is some sense though to have the following folder structure as plugins are component plugins thus are part of the view layer:
app
view
plugins

ScriptBundle not rendering scripts that are in a VirtualDirectory

I have a modular asp.net app where the modules are deployed inside virtual directories underneath the primary .net web application. We have a common module with a lot of stuff. I tried to move all of the common script files out of each client specific project into a common module.
If I create a script bundle that references files at the root level, it renders the script tag into the html. But it won't render script tags for bundles that point to files in a sub virtual directory.
For example:
bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
"~/App_Modules/Common/Scripts/jquery-1.*"));
no longer renders any script tag and now I get jquery errors client side. I looked at the resultant html, and now there's no more script tag to download the jquery library.
I had the same problem. The root cause was that I included only minified scripts in the bundle. Once I placed in the scripts directory the uncompressed scripts, it rendered them correctly.
Unfortunately bundling doesn't yet support VirtualPathProviders so if your virtual paths are relying on a VPP to serve the resource, bundling won't be able to find them. This is a scenario we are investigating currently and hopefully will support soon.