This may come off as opinion, but I really do not know. What is the difference between setting up the views in the public directory as opposed to the being placed on the server? I know express sets up with JADE in the server, but I see equal amounts of tutorials with html files that are public. I do not understand what my benefits or concerns are. Could someone please explain?
In a default express app the public folder is configured to serve static resources that require no server-side processing. Any assets (images, scripts, html) in this folder will be url addressable directly from the client.
There is no benefit in placing your jade files in this folder as making them accessible to the client is meaningless and could present a potential security concern. You could configure express to read the jade files from the public folder server-side but I can't think of any valid reason to do this.
Related
I'm wrapping up my Ember application and I want to figure out the best practice for handling the public site (/, /about, /faq, etc). Ideally the Ember JS and the majority of the app itself wouldn't be loaded.
There are a couple options, but I'd like to know the best practice.
Option 1 - Part of the app
Just make the public pages templates within ember-cli.
Pros:
Same asset pipeline
Single delivery of your entire site
Cons:
How do you have two base templates? One for the public site and one for the app itself. Ideally I'd be able to have different nav bars for each part. Everything inherits from the application.hbs template but I don't want to put conditionals in there to handle the two nav bars. I also don't want to overwrite every other page in my app to put it under a different template (/app/*).
The entire app would be loaded the first time the user goes to the page (only gets slower as the app gets bigger).
Option 2 - Part of the public folder
Create static HTML in the /public folder.
Pros:
Same asset pipeline
Single delivery of your entire site
Not loading the entire app for public pages
Cons:
You have the write the entire HTML for every page. This doesn't allow for quick development.
No template system. As the public site grows it's best to have a template so you can easily change the nav bar on all pages.
Not sure how to handle / since ember-cli wants to handle that url, but I'd want it to be apart of the public site.
Adds a lot of junk to your public folder since you'd need to add about/index.html for good urls.
Option 3 - Separate from the ember-cli project/app
Create a nanoc site or some other statically generated site and deliver it for your public pages.
Pros:
Have properly layouts for public site
Separation of assets
Not loading the entire app for public pages
Cons:
Need to figure out how to properly deploy separate apps on the same domain (putting ember-cli under /a/ is easy, but if I deploy to heroku how do I serve up multiple heroku apps on the same domain?).
How should /sign-up and /sign-in be handled? Public site with public site chrome, or web app with a signed out state (not ideal).
I would go with first opinion. About your questions about two base templates > you can hack it in router to show exactly what you want.
Here's the link about similar issue: https://stackoverflow.com/a/14231712/4560056
Separate.
Use your .htacess file or whatever the equivalent configuration mechanism is for your server setup to control when your app should have responsibility for serving content and when it should not.
I have three different domains all on the same server and I want to run the code on all three domains from one source on the same server, but not sure the best way.
Here's what I have:
domain01.com
domain02.com
domain03.com
domain04.com/sourcecode
I want domain01-03 to run the code inside domain04.com/sourcecode so the user can go to their domain and not have to go to domain04.com to see their site. I want to keep all the code inside domain04.com because I don't want to have to put the code inside each domain every time I make a code change.
For whatever reason I can't get my head around the best way to do this -- and want to do it right.
Any advice?
Thanks!
All you need to do is create a mapping on the first three sites to the appropriate directory in the fourth site, eg map /domain04 to /full/path/to/domain04/sourcecode, then refererence its CFML resources via /domain04 in CFC and include paths. The inference here is the code does need to be accessible via the file system for all sites concerned.
Note that if you also want to server non-CFML files via HTTP (eg: images, css, js), then you will also need a web server virtual directory along the same lines.
None of this requires a framework, it's standard CF / web server functionality.
Are you using a framework? One like ColdBox could make this trivial if your code is written modularly. (Disclaimer, I am affiliated with ColdBox)
If not, it really depends on what the code is. CFCs can be mapped anywhere via ColdFusion mappings. Even .cfm files can be included as long as the file systems are visible. If you're wanting to basically have complete copy of a site in another web root without duplication, I would first consider using a shared source control repo and a build process that checks it out in the appropriate places, and secondly a good old, symlink will also work .
I m new to joomla world. pls can any1 tell how to use bootstrap size option in joomla 3.0?
and i have 1 more question, what is the use of index.html in every modules folder which has no content in it ?
Second question answer
Web servers list all its directory-content in the browser if there's not present an index.html, making it easy for attackers to click on any of the links and view the contents; worse, if it's a PHP file, which will invariably execute upon clicking. That brings three risks:
Direct access to a PHP file exposes sensitive information (e.g. the
server's path structure) to directly alter codes.
It makes easier uploading hacking scripts to a site through any of
its vulnerable component. This allows for direct web access which
compromises the site.
It reveals the names and size of the site's files and helps
identifying any vulnerable extension, making it an easy target
The index.html files prevent the file listings from such exposures.
The "bootstrap size" option in the module parameters has to be supported by the used module chrome. From the default system chromes, only the html5 one does support it. Depending on your template, there may be other chromes as well which do support it. But since it's a rather new parameter, most templates probably don't support it yet.
For example, I have an Asp.net MVC application in the path D:/myprojects/sample and I have placed static files in E:/files.
I don't want to place static files in content folder since static files are very large in size. Is it possible to use files in E:/files in my application? How?
I want to display static html files inside frame as below
< iframe id="content-frame" src="E:/files/index.html" width="100%" frameborder="0">
But i am getting alert in Firefox as "Firefox doesn't know how to open this address, becuase the protocol (e) is not associated with any program".
Will this issue be resolved if virtual directory is created in IIS?
Thanks for the replies.
You can store files wherever you want on the file system, as long as you have permission. However, it often makes sense to save them in the application directory.
A good place is the App_Data folder in the root. The reason for this is because files in the App_Data folder cannot be accessed directly over HTTP - the server returns a 404 error. This could be useful if you need to restrict access to these files in the future to authorized users only for example.
Since you're using MVC, you'd need to set up a route to server files in this folder, which would look like:
public FilePathResult GetFile(string path)
{
return File(Path.Combine(Server.MapPath("~/App_Data/"), path), "image/jpeg");
}
So then a file could be used in your markup like:
#Url.Action("GetFile", new { controller = "Files", path = "myimage.jpg" })
You probably don't want to pass the file path directly as this is just an example (maybe pass an id in instead) but you get the idea of how it would work.
It really depends on the nature of these 'static' files and what a client, or indeed you, want to do with them.
If they're only to be accessed on the server, then it doesn't matter, so long as the identity the process runs as has the necessary permissions.
If they're to be accessed by the client, then you need to serve those files up.
If they're HTML files, then you can dump them in any folder you want. The Content folder seems a reasonable place to me so I'm interested to know why you "don't want to".
Images and other stuff, well there are already folders for that too of course.
But then you have to consider whether these static files are updated outside of a website deployment process. If so, then consider a simple virtual directory in IIS pointing to the location where those files are updated in situ - that way you don't have to worry about them.
Use routing and passing the request through a controller as a last resort, in my opinion, as it unnecessarily complicates the request pipeline for a file that could easily be served by IIS directly.
You can place it anywhere.
In IIS you can have a virtualDirectory pointing to that address.
for example,
lets your static files are in "E:/files"
In IIS -- > YourWebSite --> Add an VirtualDirectory ( lets say "content" and points to "E:/files".
Now you can access it from out side like,
http://YourWebSite/content/myimg.png
It will act as if files are placed with in same directory.
Edit - more details about App_Data What is the App_Data folder used for in Visual Studio?
You can use App_Data I think this is the absolute place to store static content.
I'm having issues serving out static (image) files from an Azure + MVC 3 project when running in the dev web server. I have forms authentication running on the site, and any requests for images are met with a login redirect.
I have been able to make access possible by making my images folder an application (via iis) and explicitly setting my windows user to have access to the images folder, though this only works for a debugging session, and clearly isn't a real solution.
There are a couple of problems it isn't:
Static file requests being picked up by mapped routes
Folder permissions not allowing access to the NETWORK SERVICE account
Rules in web.config requiring authorization for the folder
Currently the images reside in ~/Images/... though I have also had them in ~/Content/... which is where the main css resides. Said css always serves out without any issues.
Notably the images are not served even if you do log in.
I realise that it may be better to store these images in a blob, particularly in the development phase, and for source control, it seems easier to carry these few static resources in a project folder.
EDIT - Question was incorrect. Actually just an issue with some files being encrypted on my hd and others not, causing odd results.
It turns out windows was encrypting all of the files in these directories (not standard behaviour for my configuration, but was happening here for one reason or another). I had a couple of images that weren't encrypted (including the styles.css) but most of the images were. That meant that images wouldn't serve without my credentials against them...
So nothing to do with mvc / azure / cassini!
My guess is that this is some config issue and is not related to Azure itself.
It is probably worth trying similar questions/answers like:
My ASP.NET MVC2 application with Forms Authentication is blocking access even to Images, Styles and Scripts
Also, if you create a new project then do you see the same effect?
If no, then compare the web.config type settings one by one - the difference will be there.
If yes, then it seems like the problem is somehow at the web server/machine level (maybe something to do with anon or windows authentication in web.config and/or app.config)