Read/Write Application Settings in C#.NET project - c#

I need to save informations (db password) permanently in my project via an .aspx file. I found the Application Settings to store the password but other users can not access my values.
For example:
Setting db_password has the value oldPassword
Administrator (User A) changes the database password to newPassword. It is stored into the Applicatoin settings via: Properties.Settings.Default["db_password"] = tb_testSettingPassword.Text;
Saving: Properties.Settings.Default.Save();
Administrator (User A) see the changed value: lt_testSettingPassword.Text = System.Convert.ToString(Properties.Settings.Default["db_password"]);
User B (no administrator) accesses the page and want to get informations from the database. He needs to connect via the password that user A has saved but I still gets the value oldPassword.
How can I store the value for all users?

Settings stored with Properties.Settings.Default are stored in the current users own application data folder (%USERPROFILE%\AppData under Vista and above).
If you want to have a config file easily accessible to all users you should store it at System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData).
That line will give you the path to the common AppData folder (C:\ProgramDAta under Win7), where all users will have read and write access.
In there you should create a folder for your application and then create your config file in that folder.
If you need help creating folders and files there are multiple questions and answers on SO that should help you out.

Related

Allow write permissions for .NET application

I've been running in circles with allowing my application to write to a folder on a shared network drive.
So far I have this:
FileUploadControl.SaveAs(Server.MapPath("myFolder/" + filename));
this successfully saves the file to
\\machineName\inetpub\wwwroot\myApp\myFolder
However, I am also trying to save the same file to a folder outside of the root folder on the path
\\machineName\myFolder
using:
FileUploadControl.SaveAs("C:\\myFolder\\" + filename);
This returns an error of "Access Denied." So how do I go about allowing my application to write a file to \\machineName\myFolder? I have tried giving write permissions to IIS_IUSRS and NETWORK SERVICE to no avail. Should I create a user with privileges to write to the network drive and then use impersonation to use that user when writing to the drive?
Using IIS 7 with .NET 4 application.
Go to your application's app pool, right click on it and choose Advanced properties. Check the Identity value under Process model settings group. Give this Identity permissions to write files in your folder.
If the value is ApplcationPoolIdentity than user name is IIS APPPOOL\app_pool_name.

WPF app writes files/data into "C:\ProgramData" but fails to write into other folders

We have developed WPF application which allows user to select folder path. WPF application writes files/data into this selected path. When we select "C:\ProgramData" as the path, it creates the file and write the data. But when the path is other than "C:\ProgramData", file is generated but data is not written into the file and it seems a permission issue. Can anybody help us in finding out , how we can assign the same kind of permission to selected folder same as "C:\ProgramData" so that it allows to write data into the file. In conclustion what is the extra permission does "ProgramData" has which is not their for other folders?
Note: it only works properly with ProgramData folder.
Whenever your application is launched with standard user rights, it can write to only those folders to which a standard user can write to. E.g. are:
C:\Users\USERNAME\
C:\ProgramData\
D:\
It will not be able to write to folders like:
C:\
C:\Users\SOME_OTHER_USERNAME\
c:\Windows
C:\Windows\System32 etc
For that you either need to disable UAC or launch the application with administrative permissions.
I would suggest that whenever user selects a folder from your application check if you can create a file/ folder in that location before accepting the path.
solution what i can give is let's user select the path after you get the folder path just check whether you can write data to it , see this code
bool HasAccessToWrite(string path)
{
try
{
using (FileStream fs = File.Create(Path.Combine(path, "Access.txt"), 1, FileOptions.DeleteOnClose))
{
}
return true;
}
catch
{
return false;
}
}
#Ganesh is right but you may go with one of the following options:
Run the installer with admin rights, ask user to select target folder during installation and set the permissions to everyone or required groups of users/roles.
If above is not applicable then configure your application to always run under admin account, in that way it will have access to all folder to write data. To configure run as admin user application manifest as explained here:
Turn off UAC, not a recommended approach though.
I had same issue so, I forced installer to be run under admin rights and asked user to create target folders during installation. Used a custom action to set full rights for everyone user group on the target folder. Since security was not issue for us so, it was ok to allow everyone but consider your environment before using this option.

Properties.Settings.Default save to AppData but read from Program Files

When I'm saving settings in context of process runas with specific login and password it's using his home folder (AppData) to store settings. But if I run program in context of the same user from T-SQL Trigger settings file form app_data is not used. There is config file which is used. It's placed in program files with executable. In this config are sections for WCF client settings.
I'm wonder why program doesn't try to read first config file. After manually putting some values to the user section in config when program is running from trigger - he will use them. But for save form single instance it store them in AppData. So after all, when running from trigger in default scenario he reads empty values.
BTW For running program in context of user from trigger I use EXECUTE AS USER = ... exec master..xp_cmdshell ... .
Best Regards

file upload C# asp.net

i am trying to upload files in asp.net and putting a specific path to be saved. windows user.
it is outputting me an error :
System.UnauthorizedAccessException was unhandled by user code
Message=Access to the path 'C:\Users\USER\Desktop\fyp2\CMS TEST4\CMS\CMS\Upload' is denied.
my code is:
var guid = Guid.NewGuid();
if (File.HasFile)
{
var length = File.PostedFile.FileName.ToString().Length;
var ind = File.PostedFile.FileName.ToString().IndexOf('.');
var sdfs=guid.ToString()+File.PostedFile.FileName.ToString().Substring(ind, length - ind);
File.PostedFile.SaveAs("C:\\Users\\USER\\Desktop\\fyp2\\CMS TEST4\\CMS\\CMS\\Upload");
}
The ASP.NET worker process does not have access rights to that path. By default I believe IIS worker processes run under the Network service account. You can either add write rights for the folder to this account, or set up a new Application Pool with a different identity (i.e. a user that does have write rights).
As simple as the error puts it, your application requires the folder to have proper write permissions.
I'm asuming this is a Web Application. In that case, you'll need that the user which IIS uses to run applications has Write permissions over the specified folder.
The users directory is fairly locked down. If the account the web server is running under is not the specified user, it will not, by default, have access to the path. You can either grant explicit access to that path to the account running your web server, or create a folder with appropriate permissions external to that path and create a link on the user's desktop.
Looks like current user has not permission to save. Before writing try use FileSystemRights with AccessControlType.Allow to know permission info of the destination.

Storing User Settings

Environment.SpecialFolder.CommonApplicationData
*returns "C:\Documents and Settings\All Users\Application Data" under XP that is
writeable for all users
*returns "C:\ProgramData[MyApp]\" under Vista and this is not writeable for regular users
Now why i want CommonFolder ?
Because, an admin will install my software database on XP (or vista) under Admin account, but when user logs back and run my software, the current account will tel my software to look at a different place the database was installed : the user directory in Documents and settings....
so AllUsers (common folder) is common to admin and regular non admin user..
This drives me crazy : where to put my database so it works under Vista and XP ?????
thanks
Jonathan
User-specific settings should be stored in the User's application data folder (Environment.SpecialFolder.ApplicationData) , so that if multiple users log in to the machine they each get their own settings. Create a default user-settings db for the program in the program's main folder at install time and copy it to a user's folder the first time that user runs the program (you'll know it's the first time because the db file won't exist yet).
If you have settings that should apply to all users on the machine, you want those settings to be set by an administrator, and you want them protected from casual change. Storing these in a place where normal users don't have write access is a good thing.
Are you using an installer to have the admin run? If so, you should be able to use the installer settings, plus a proper assembly/executable manifest to allow the application (regardless of who is running it) the proper permissions to update/modify files in the ProgramData specific to their application.
I run a similar scenario (application installs to Program Files, common data repository installs to ProgramData, user config,save files store to C:\Users) and the manifest and the settings in the WiX installer allowed this to work.
Vista is set up such that files saved from one user's account cannot
be modified from another user's
account. This enforces isolation
between one user account and another,
as well as protects settings/files
that affect the state of the entire
system.
Your program should indeed install
whatever machine-wide state it needs
in ProgramData at install time - this
folder is shared between all user
accounts; however, it is a read-only
type of shared . Administrator
privileges are needed to modify these
files if the current user did not
create them because they affect the
entire computer, not just the current
user account.
In accordance with this policy, the
security on the ProgramData folder is
as follows:
System: Full Control over files &
folders Administrators: Full Control
over files & folders Creator/Owner:
Full Control over files & folders
Users: Read Only for files, but can
create new folders and files
What this accomplishes is that it
allows any user to read and create a
folder/file anywhere inside the
ProgramData folder, but the user can
only modify the files that were
created from their user account; they
cannot modify files created from
another user account.
The only exception that I know of to
this policy is the c:\users\public
folder, which is designed to allow
users to store documents and such that
they want to be world read/writable.
From here. Looks like someone else had the same problem.
Can you make use of the IsolatedStorageFile.GetMachineStoreForApplication and IsolatedStorageFile.GetUserStoreForApplication methods?
My apologies if I have misunderstood your question.
where to put my database so it works under Vista and XP
If this database is a SQL Express data file or other shared resources it needs to be in a loocation that the server process's account can read/write.
returns "C:\ProgramData[MyApp]\" [corrected typo] under Vista and this is not writeable for regular users
Not according to a quick check at the ACL here (actually Win2k8):
PS C:\ProgramData> get-acl . | select -expand access
[...]
FileSystemRights : ReadAndExecute, Synchronize
AccessControlType : Allow
IdentityReference : BUILTIN\Users
IsInherited : False
InheritanceFlags : ContainerInherit, ObjectInherit
PropagationFlags : None
FileSystemRights : Write
AccessControlType : Allow
IdentityReference : BUILTIN\Users
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : None
Note the last to ACEs, normal users do have write access, but only to folders and the files they contain, not to files directly in C:\ProgramData.
However if a user creates a folder in C:\ProgramData then other users will not have write permissions.
Answer: Create folder under ProgramData for your database, and set the ACL on that folder to give all users read & write access to files in that folder.

Categories