I am working on one desktop application which is built by using .net WPF. I have some data inside the application like images,videos..
I want to make this folder secure, so nobody can access the data inside the folder after application installation. Only the application can read the data from that directory.
Even though administrator of that machine can not open that folder to check the content.
Is it possible to have this kind of security inside the WPF application.
Only motive it to keep the sensitive data protected from external copy from the application users.
Thanks,
Vijay
It depends on how you use the resources.
Actually you could encrypt all "protected" files, so that after the installation every one can copy but no one can use them unless your application decrypts the files.
When you encrypt files you should definitively test the performance (decryption takes some time).
Two links showing how you could do it:
What's the easiest way to encrypt a file in c#?
http://lukhezo.com/2011/11/06/encrypting-files-in-net-using-the-advanced-encryption-standard-aes/
Add the file you would like to strongly protect to you solution. Then right click each file, go to properties and set its "build action" to "embedded resource".
And for how to access the resource stream from within the exe for use with in your application, see link below
How to compile all files to one exe?
That way, your private files will not be copied to the installation folder but will instead reside inside your .exe file.
WPF is beside the point. Applications run with the permissions of the users that start them. If an application needs access to files, then the user will also need rights to those files.
In short, the answer is no, you cannot do exactly what you are asking.
The best you will be able to do is make it hard for a user to discover where the assets are coming from, but you will never be able to give access to your application without giving access to the application's user.
Related
I understand this folder App_Data is normally for database files etc but I want this now for images, the idea being users upload images into this folder and they can be accessed from the website, I basically want App_Data to be used/thought of as a normal folder now, anyone know how to do this? Is it just permission settings or can this folder not be used like a normal folder. Thanks in advance :)
ApplicationData is a folder for Application Data. What kind of data you store there is up to you. Note that there are 3 on a Windows:
ApplicationData
CommonApplicationData
LocalApplicationData
Generally data in there it should be data specific to this user - except for CommonApplicationData, of course. Being shared across users, is what the "Common" Prefixed Folders are there for.
However the rest of the question makes no sense. You want the user to manually put stuff there, so a WebSite can upload it? You also seem to think it is somehow not a "normal" folder?
WebSites do not have random access to the file System. So it would really just be annoying for the user to navigate there. And if there is another programm in the loop, you have not told us of it.
And the folder is quite normal. The OS stores a path to it wich can be changed (and the file moved Automagically), but beyond that it is as normal as can be. The unknown position is why you should always retreive the real values from the OS with https://learn.microsoft.com/en-us/dotnet/api/system.environment.specialfolder
Edit:
Based on your comment, I understand now. You are writing a Website. And you wonder why the server has no access to the AppData Folder. Of course only now I noticed MVC properly.
WebServers are uniquely vulnerable to hacking. Online 24/7, a few well known frameworks and widespread reachability as a core goal. As a result they generally run under the most restrictive userrights possible.
Read access to the servers programm and the Instances content directory - any more can not be expected and should never be granted. Maybe write access in a subfolder of content for Temp files - but there are better solutions, that involve Databases and HTTP Handlers.
Solution:
If you want your images to be avalible, put them into a subfolder of the Content directory for this instance. However you really should be considered Database Storage with HTTP Handlers: https://www.red-gate.com/simple-talk/sql/learn-sql-server/an-introduction-to-sql-server-filestream/ Some even go as far as having a seperate, dedicated Webserver just for Images. But I doubt you are on that scale yet.
How to use image without making .exe file heavier in c# windows application.
One way is keeping the file in debug folder and reading it at runtime but i dont want the user to see any images in the debug folder.
How can i achieve this?
You could store images in a separate Class Library and then reference it in your application.
Users wouldn't be able to see the image files this way, instead they would be stored as a dll file in your debug folder.
Edit:
I have recorded the actions required to achieve this setup, check out this link:
https://www.youtube.com/watch?v=8i794GmZ_aI
I have a C# app which reads from and writes to an Access database. There is one database file per user. My intention is to check for the existence of the MDB in the user's My Documents folder at launch, and if the MDB isn't found, then copy the template MDB to that folder.
I have already added the template MDB to my project and placed it in its own folder which I have called Packaged. However, I am unable to refer to this Packaged folder from code as it doesn't appear in IntelliSense.
My intention had been to use File.Copy to copy the MDB over, but I cannot determine the file path as I can't access the MDB in code. And presumably it wouldn't have a file path anyway if it's just packaged in the .exe?
What would be the best way to achieve this, given that I would rather not distribute a separate MDB if possible?
I've done this in the past by making the MDB an embedded resource, and writing it to disk as needed (if it doesn't exist).
Here is more info on writing an embedded resource to file.
You'd almost have to use one of the Environmental paths for the template MDB. Like ApplicationData or Documents and Settings\Username\Local Settings\ or one of the other ones. Local User Data is the best way for user specific data. IN the code in the beginning, determine to see if the file exists in the first run. If it exists copy the template, if not don't.
That way the user has full read and write access and the ability to copy the file or duplicate the file without security problems. These environmental variables are accessible through
Environment.GetEnvironmentVariable
You could also have a registry setting and read and write to the registry for that specific application, that has a simple DatabaseAvailable key, and toggle it yes or no.
You could also embed the MDB as a resource too, and then write it as necessary.
i have an windows application that i have made by visual studio 2008.this application uses some graphical files such as jpeg.i make a setup for this appreciation but i worry about such files being modified by client.would you please help me how to protect those files ?
To detect such a tampering you should add your graphical files as resource within your application (or load from another assembly) and use Strong-Name signing. Even if it is not completely secure, it should prevent the most ones from altering your resource files.
You could embed the images into resource files that get included in the exe.
The easiest way is to use the images as a resource.
If you don't want to do that for any reason, then you could also calculate a cypher of the jpegs (maybe MD5) and check them against the one you previously stored in the code while loading the load program (form.load or whatever).
You could sign your files this way no one would be able to change the files without having your certificate.
this might be overkill and it depends on how mutch security you want else just place the images as resources.
I can't see anything on here but I do remember being told that If you want an application to update a config file then it needs to be under ...
**C:\Users\Ibrar Mumtaz\AppData**
Well somewhere there, the reason being is that the user should have permisions to update a config file here and not under the applications install folder. This is the impression that I am under and I'm fairly certain that this is definately the case. As I think I read that on here = p
My question is, is there anybody on here that can shine some light on this as this is the last feature I want to implement before I give my application out to test.
1) First thing is, an installer is needed to set up the folder and then drop my apps config file into it. I already am using the visial studio installer so I have my app packaged up but this point is throwing me off? How do I do this then? I just need someone to show how to do this and I should be O.K reconfiguring my app to look for the new home of the config file.
2) I should be able to work out how to find the folder and locate the config file found within it. As once I know the installer is chucking the config file out into the right folder where the user has permissions then it should be straight forward from there.
Thanks for reading.
UPDATE:
It was pretty straight foward, as the VS Installer has an option to add a special folder so all that was left was to access the folder programmatically and read and write to the config file. ONE PROBLEM? The ConfigurationManager class which I have used to create my config file for my application expects my config file to be local to the application and not miles away in a completey different part of the local FileSystem? Errr help here Plz?
Ibrar
If you are using the VS Settings file to create application setting keys, and have values that the user might want to change in runtime, and save his preferences, just set the scope of those settings to "User" instead of "Application".
That way you will have a setter method for them, and you can edit the Settings.Default instance, and when you are done call the Save() method to persist them to disk.
The file will be saved in the user's "AppData" folder, wherever it is, under some cryptic folder. But you needn't worry about it's location most of the time, since it will be read automatically on the next execute, and persisted to the same location on subsequent runs.
Afaik the installer can be extended with classes that do things.
On INSTALL-action to do could be to
var path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
"My app name");
if (!Directory.Exists(path)) Directory.CreateDirectory(path);
And vice-versa on uninstall.
App.config files are related to where the physical assembly is located I think.
Actually, if your app is running on the user's machine- it will have whatever permissions that user has. So most likely, you can expect to be able to write anywhere on the file system.
However it is possible the user would be running under a restricted acct, and thus not have the permissions. So you could just use the registry to store where your config file is (install folder), then when you try to update it, if it fails for permissions, ask the user to grant it.
Or you could use the Windows standard folders, as you were getting at, because doing so also separates out user data from application data.
Use the Environment.GetFolderPath () method to get the 'special folder' paths in your app.
http://www.programmersheaven.com/2/Les_CSharp_15_p2
http://msdn.microsoft.com/en-us/library/14tx8hby.aspx
If you are talking about application settings found on project Properties -> Settings tab, then there're two different types of settings: user-level and application-level.
If you need to change any settings in run-time, these would be user-level settings (http://msdn.microsoft.com/en-us/library/cftf714c.aspx) and all changes would be buried somewhere in the private folder in your user profile.
If you want to update application-level settings, your best shot would be to do that during software installation. In this case you don't need to look for the configuration file (YourApp.exe.config) anywhere but in the application folder. More likely you would need to create some sort of post-install event handler in your setup package and run some script or another application which would update data in YourApp.exe.config. Everything in the setup package will be executed with elevated priviledges and thus that configuration file would be writeable. BTW, this scenario applies to 2000 and XP, if the user is using limited user account type priviledges.
Because I did not technically find the answer I was looking for, after 6 months I have come back to my application and have managed to produce a solution that does not break my current architecture.
If you are implementing an application to make use of some of the features on offer by the ConfigurationManager then it offers a static method called:
ConfigurationManager.OpenMappedExeConfiguration(); // takes two arguements.
It can be used like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = returnUsersAppDataFolderPath();
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
e.g
fileMap.ExeConfigFileName = #"some file path external to your applications install folder."
remember to use '#' symbol in front to allow the compiler to literally treat the string on as is basis.
If the config file can be conveniently locally located then just use the:
ConfigurationManager.OpenExeConfiguration(string exePath)
Above is what you would typically use but for me i needed my config file to located under the users AppData folder so the first option is what I needed. And it does indeed work.
I hope this helps others as it does for me as I want to deploy my application to Win7 and vista environments therefore this question needed asking if I was to stick to using the ConfigurationManager it's a shame the method of choice in the end never really stood out in the first place = ).
If you want to read from your config file then leave a comment and I will show you how I managed to do that also.