i wanted to use SQLite with .net application. It only works if the DLL and the Database file are in the BIn folder and the permissions of BIN are set to read / Write.
Is that a security risk ?
Yes, it's a security risk, and what's more, every time a file in the Bin folder is updated, it will cause your application to restart. So you put the database file in the App_Data folder.
Yes, allowing read/write permission for the IIS worker process to the bin folder would allow anyone that can gain adequate permissions to your system (running as the generally low-privilege account running IIS) can now change your application binaries.
If indeed SqLite poses that requirement (but I would tend to agree with Michael P's comment), I would not use it under IIS. Whether you should use it depends on the security risk you expect your application to be at and the cost of a security breech (managing your stamp collection vs managing credit card data).
I do suspect that SqLite will allow you to place your data file in App_Data, where such data belongs. In fact, the answer to the question below outlines how to do just that:
How do I reference the Sqlite db file in the App_Data folder for my ASP.NET Web Application?
It only works if the DLL and the Database file are in the BIn folder
Well that sounds like a blocker. There is a free commercially licensed Microsoft SQL Server CE. It fits perfectly and securely into ASP.NET. Runs as DLL with database in single file up to 4GB. The limitation is file size and no stored procedures capabilities.
Related
I was exploring options for deploying my ASP.NET web app by creating a publish profile when I noticed that .pubxml files are included in this .gitignore file (which I had been using):
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
Searching around, the reasoning seems to be that either references to the publish profile or references in the publish profile contain absolute paths or other information that may only be valid on the local dev machine at the time.
Can anyone confirm the reasoning behind this exclusion?
I cannot confirm the reasoning but I can tell you what we do. I include the .pubxml files in source control due to the fact that any of us can publish to our DEV or TEST environments. I even checked the files themselves and did not see any local paths. But consider that we use web deploy, so long as we all have access to the same server to deploy to, then there is no problem.
So it really, IMO, depends on what deployment settings you use and if all of your team have access to the same servers.
No credentials and no local paths are stored in our .pubxml files.
From Microsoft documentation (for ASP.NET Core 2.2 and up)-
When publishing to an Azure target, the .pubxml file contains your
Azure subscription identifier. With that target type, adding this file
to source control is discouraged. When publishing to a non-Azure
target, it's safe to check in the .pubxml file.
Sensitive information (like the publish password) is encrypted on a
per user/machine level. It's stored in the
.pubxml.user file. Because
this file can store sensitive information, it shouldn't be checked
into source control.
This is correct. These publish profile files have local settings like target path to deploy which may be different for different systems. So it is always kept these files only locally.
I have an existing ASP.NET website that I would like to port to Azure within my free trial.
I would like the migration to be as painless as possible. The application uses log4net and NHibernate, plus it needs to share data with an application supposed to run on a virtual server.
Two questions can be asked as 1
How do I configure paths in Web.config to access a shared drive?
I need to configure the paths into which logs will be stored and, most important, I have to specify where the application will read the files written by the daemon that will run on my Azure Linux VM.
When both the app and the daemon ran on the same server (yes, I had Mono running fine) I just had to choose a shared local directory.
I'm not sure I'm totally understanding the scenario, but I'll try to give you a few options.
One - Windows Azure Web Sites (currently in Preview) could be a great option for your ASP.NET site. Of course, it depends what needs your site has. But, you can write your log4net files with web site and using NHibernate too.
Two - Web roles work great for situations like this. You would likely have to change some code to use blob storage for persistant file storage. You could use Windows Azure drives as a way to get a persistent location for log files. Windows Azure drives don't have a pre-determined drive letter, so you'd want to use the API to get to that. That may, or may not, be a good option for your situation. With web roles you could also write the log4net files to local storage and use Windows Azure diagnostics to transfer them periodically to blob storage. Just another way to persist the files.
Three - Using Windows Azure Virtual Machines (currently in Preview) you could write the log files to a data disk, which is backed by blob storage.
In the end, if you have files you need to share across instances and/or roles, then leveraging blob storage is likely your best option.
When creating a new database with SQL Server Express 2005, the database files (.mdf and .ldf) get stored in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data by default.
However, with the tutorials I've seen for ASP.NET MVC (e.g., Nerd Dinner), it seems to be common practice to keep the database files in the ASP.NET project's App_Data folder.
Questions
Is there any significance to the App_Data folder, or is it just a convenient place to store database files if you happen to use Visual Studio's designer to create a new database?
Will there be any negative repercussions if I don't use or even delete the App_Data folder?
Update
One thing I'm still not getting. If you have a production database on the server, why would you even want to replace this database with what is in App_Data. Wouldn't you normally just want to have update scripts that you run on the production database when you release a new version of the app? Even for initial deployment, I'd rather script database creation than physically copy over the files. Also, with SQL Server (Express) databases, copying is not enough. You have to detach the database to manipulate the files then reattach when you are done.
So, I have to say, the point of App_Data still escapes me. Can someone enlighten me?
You can delete App_Data without any negative repercussions, but when it exists (by folder name) inside an ASP.NET website then it has the special website power of disallowing direct linking to download its contents - this is a security feature to protect your database from being downloaded directly over the web (e.g. by a web browser) even though it exists in the website. However your application can still access the files in the App_Data folder just as it accesses other website content.
Microsoft states it as:
Note: The content of application
folders, except for the App_Themes
folder, is not served in response to
Web requests, but it can be accessed
from application code.
Microsoft describes their special ASP.NET folder structures including App_Data here.
There are a number of advantages of placing database files in the App_Data folder:
As some have mentioned, that folder is secure from people browsing it directly on the web. This is also true of placing the database in folders outside of your web site, though.
You can "xcopy deploy" your application by copying the entire folder from your local development machine to your hosting web site.
Various components in Visual Studio can offer extra assistance in building your application by having your database files there. For example, you can double-click on a SQL Server Express MDF file and have it automatically open up in Server Explorer so that you can change the database's schema or view its data.
There is absolutely no need to use the App_Data folder. It's just a convenient place to keep your database files together with your site. The decision to use it or not is more a matter of preference / policy than anything else.
yes, when you are simply using an express database which will exist within your webroot it is best to use the app_data folder. The primary reason is that the asp .net isapi implicitly knows not to fulfill any requests for files from this directory. The same goes for the app_code folder. There is no stipulation that you have to but its good practice to be prudent.
You can also store sensitive xml,access dbs and any other data files in here for added security.
I've only ever used it for local development before pointing the web.config at a SQL server instance rather than the db files.
I have a web application running on IIS. Instead of using a database it reads and writes to a couple of XML files. I currently store these files in the Application Data folder in windows. This folder (\Documents and Settings\All Users\Application Data in win 2003) however requires at least "Power Users" privileges to write!
Reads are OK and are granted to everyone but writes are not allowed as long as your not in the one of the more privileges groups on the system. Why is this so? Is there a better place for a application to write to and one that does require me to add the user of the application pool to a more privileged group?
My second question is that if I have file that just needs reading. Can I then read this directly for the folder where I have my web application deployed (say a folder in "Program Files") or should I at all times use the Application Data folder?
The idea here is that this files sometimes need manual change and using the folder where the web application runs from would basically make more since to normal users I think (especially on win 2008 where the Application Data is hard to find).
Reads are OK and are granted to everyone but writes are not allowed as long as your not in the one of the more privileges groups on the system. Why is this so?
You don't want to allow just anyone to write to the file system via a web application.
Using ASP .NET, people usually use the APP_Data folder to store data files that need read/write access to an account such as Network Service.
When creating a new ASP.NET application in Visual Studio, a couple of files and folders are created automatically. One of those folders is called App_Data.
Also when publishing a website by selecting the menu option Build->Publish a checkbox is available Include files from the App_Data folder.
Am I right assuming that the files put in this file and its sub-folders are not going to be accessible through the web? For example, would it be safe to put in that folder resources that I only intend to be used by the application code?
What is the real intended use of the App_Data folder?
EDIT:
Thank you for all the answers. From the answers received so far I am interested mostly in two points mentioned:
App_Data is essentially a storage point for file-based data store
It should not be viewable by the web and is a place for the web app to store and read data from
Would someone be able specify how the "not viewable by the web" is ensured?
Can I rely on that fact when performing standard deployment, or do I need to check some IIS settings on the server as well.
In the situation when I have a set of pdf files that I want to be accessible only from the application. Would App_Data folder be the right place to use, or should I create a separate folder and manually set IIS to ensure that it is not accessible by Web?
App_Data is essentially a storage point for file-based data stores (as opposed to a SQL server database store for example). Some simple sites make use of it for content stored as XML for example, typically where hosting charges for a DB are expensive.
in IIS, highlight the machine, double-click "Request Filtering", open the "Hidden Segments" tab. "App_Data" is listed there as a restricted folder. Yes i know this thread is really old, but this is still applicable.
The intended use of App_data is to store application data for the web process to acess. It should not be viewable by the web and is a place for the web app to store and read data from.
It's a place to put an embedded database, such as Sql Server Express, Access, or SQLite.
The App_Data folder is a folder, which your asp.net worker process has files sytem rights too, but isn't published through the web server.
For example we use it to update a local CSV of a contact us form. If the preferred method of emails fails or any querying of the data source is required, the App_Data files are there.
It's not ideal, but it it's a good fall-back.
From the documentation about ASP.NET Web Project Folder Structure in MSDN:
You can keep your Web project's files in any folder structure that is
convenient for your application. To make it easier to work with your
application, ASP.NET reserves certain file and folder names that you
can use for specific types of content.
App_Data contains application data files including .mdf database files, XML files, and other data store files. The App_Data folder is
used by ASP.NET to store an application's local database, such as the
database for maintaining membership and role information. For more information, see Introduction to Membership and Understanding Role Management.
The main intention is for keeping your application's database file(s) in.
And no this will not be accessable from the web by default.
We use it as a temporary storage area for uploaded csv files. Once uploaded, an ajax method processes and deletes the file.
The intended use for App_Data is to store database related file. Usually SQL Server Express .mdf files.