In what way is the Windows registry meant to be used? I know it's alright to store a small amount of user preferences, but is it considered bad practice to store all your users data there? I would think it would depend on the data set, so how about for small amounts of data, say, less than 2KB, in 100 or so different key/value pairs. Is this bad practice? Would a flat file or SQLite db be a better practice?
I'm going to take a contrarian view.
The registry is a fine place to put configuration data of all types. In general it is faster than most configuration files and more reliable (individual operations on the registry are transacted so if your app crashes during a write the registry isn't corrupted - in general that isn't the case with ini files).
Marcelo MD is totally right: Storing things like operation percentage complete in the registry (or any other non volitile storage) is a horrible idea. On the other hand storing data like the most recently used files is just fine - the registry was built for just that kind of problem.
A number of the other commenters on this post talking about the MRU list have discussed the problem of what happens when the MRU list gets out of sync due to application crashes. I'm wondering why storing the MRU list in a flat file in per-user storage is any better?
I'm also not sure what the "security implications" of storing your data in the registry are. The registry is just as secure as the filesystem - the registry and the filesystem use the same ACL mechanism to protect their data.
If you ARE going to store your user data in a file, you should absolutely put your data in %APPDATA%\CompanyName\ApplicationName at least - that way if two different developers create an application with the same name (how many "Media Manager" applications are there out there?) you won't have collisions.
For me, simple user configuration items and user data is better to be stored in either a simple XML configuration file, a SQLLite db, or a MS SQL Server Compact db. The exact storage medium depends on the specifics of the implementation.
I only use the registry for things that I need to set infrequently and that users don't need to be able to change/see. For example, I have stored encrypted license information in the registry before to avoid accidental user removal of the data.
Using the registry to store data has mainly one problem: It's not very user-friendly. Users have virtually no chance of backing up their settings, copying them to another computer, troubleshooting them (or resetting them) if they get corrupted, or generally just see what their software is doing.
My rule of thumb is to use the registry only to communicate with the OS. Filetype associations, uninstaller entries, processes to run at startup, those things obviously have to be in the registry.
But data that is for use in your application only belongs in a file in your App Data folder. (whiever one of the 3+ App Data folders Microsoft currently wants you to use, anyway)
As each user has directory space in Windows already dedicated to storing application user data, I use it to store the user-level data (preferences, for instance) there.
In C#, I would get it by doing something like this:
Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);
Typically, I'll store SQLite files there or whatever is appropriate for the application.
If your app is going to be deployed "in the enterprise", keep in mind that administrators can tweak the registry using group policy tools. For example, if firefox used the registry for things like the proxy server, it would make deployment a snap because an admin can use the standard tools in active directory to set it up. If you use anything else, I dont think such things can be done very easily.
So don't dismiss the registry all together. If there is a chance an admin might want to standardize parts of your configuration across a network, put the setting in the registry.
I think Microsoft is encouraging use of isolated storage instead of the Windows registry.
Here's an article that explains how to use it in .Net.
You can find those files in Windows XP under Documents & Settings\\Local Settings\ App Data\Isolated Storage. The data is in .dat files
I would differentiate:
On the one hand there is application specific configuration data that is needed for the app to run, e.g. IP addresses to connect to, which folders to use for what sort of files etc, and non trivial per user settings.
Those I put in a config file, ini format for simple stuff, xml if it gets more complex.
On the other hand there is trivial per user settings (best example: window positions and layout). To avoid cluttering the config files (which some users will want to edit themselves, so few and clearly arranged entries are a must), I like to put those in the registry (with conservative defaults being set in the app if no settings in the registry can be found).
I mainly do it like istmatt sais: I store config files inside the %APPDATA% folder. Usually in %APPDATA%\ApplicationName, I don't like the .NET default of APPDATA%\CompanyName\ApplicationName\Version, that level of detail and complexity is counterproductive for most small to medium sized applications.
I disagree with the example of Marcelo MD of not storing recently used files in the registry. IMO this is exactly the volatile sort of user specific information that can be stored there.
(His example of what not to do is very good, though!)
To me it seems easier to think of what you should NOT put there.
e.g: dynamic data, such as an editor's "last file opened" and per project options. It is really annoying when your app loses sync with the registry (file deletion, system crash, etc) and retrieves information that is not valid anymore, possibly deadlocking the user.
At an earlier job I saw a guy that stored a data transfer completness percentage there, Writing the new values at every 10k or so and having the GUI retrieve this value every second so it could show on the titlebar.
Related
I'm working on a Win32 based document management system that employs an automatic check in/check out model. The model it currently uses for tracking documents in use (monitoring the processes of the applications that open the documents) is not particularly robust so I'm researching alternatives.
Check outs are easy as the DocMgt application is responsible for launching the other application (Word, Adobe, Notepad etc) and passing it the document.
It's the automatic check-in requirement that is more difficult. When the user closes the document in Word/Adobe/Notepad ideally the DocMgt system would be automatically notified so it can perform an automatic check in of the updated document.
To complicate things further the document is likely to be stored on a network drive not a local drive.
Anyone got any tips on API calls, techniques or architectures to support this sort of functionality?
I'm not expecting a magic 3 line solution, the research I've done so far leads me to believe that this is far from a trivial problem and will require some significant work to implement. I'm interested in all suggestions whether they're for a full or part solution.
What you describe is a common task. It is perfectly doable, though not without its share of hassle. Here I assume that the files are closed on the computer where your code can run (even if the files are stored on the mounted network share).
There exist two approaches to controlling the files when they are used: the filter and the virtual filesystem.
The filter sits in the middle, between the process and the filesystem (any filesystem, either local, network or fully virtual) and intercepts file requests that go to this filesystem. Here it is required that the filter code is run on the computer, via which the requests are passed (this requirement seems to be met in your scenario).
The virtual filesystem is an endpoint for the requests that come from the applications. When you implement the virtual filesystem, you handle all requests, so you always fully control the lifetime of the files. As the filesystem is virtual, you are free to keep the files anywhere including the real disk (local or network) or even in the cloud.
The benefit of the filter approach is that you can control individual files that reside on the real disks, while the virtual filesystem can be mounted only to the new drive letter or into the empty directory on the NTFS drive, which is not always fisible. At the same time, sitting in the middle, the filter is to some extent more restricted at what it can do, and the files can be altered while the filter is not running. Finally, filters are more complicated and potentially error prone, as they sit in the middle and must play nice with other filters and with endpoints.
I don't have specific recommendations, but if the separate drive letter is an option, I would recommend the virtual filesystem.
Our company developed (and continues to maintain for the new owner) two products, CBFS Filter and CBFS Connect, which let you create a filter and a virtual filesystem respectively, all in the user mode. Those products are used in many software titles, including some Document Management Systems (which is close to what you do). You will find both products on their website.
I'm writing a Windows app that has a time limited demo. There's not going to be a server that the app can phone home to, so I need to store data on the system in order to figure out if the demo has been started and how much time is remaining. The location of this data needs to be obfuscated so that a typical user (and possibly even some power users) are unlikely to be able to find it.
I already know the logistics of how to implement a time limited demo as long as I can store data secretly somewhere on the system, but I'm not sure how to do that last part. The requirements here are:
The data needs to be globally readable and writable so that any user account can access it and modify it without requiring elevated privileges (as the demo applies system-wide and not on a per-user basis)
Preferably it doesn't require elevated permissions to create the data, but if it's necessary to do that once (for example to create the data and adjust its permissions so that everyone has write access) that's acceptable though not ideal.
Whatever method or combination of methods I use to do this needs to work in Windows 7 and later
Does anyone have any idea on how I can accomplish this?
I have a Matlab GUI used on my institution with multiple users. We store the application on a local server that everybody has access to. Now I want to add user information, last server, last database and etc.
My first idea is to create a .mat file, store the data under a structure and use the computer name/id as the handle. Requesting users to login is not a very good option since I have no clue how to store the passwords in Matlab (if you know how, please do tell).
I've been putting this on hold for a while now since I'm never quite satisfied with my approach. I would love to get some input (ideas) on this.
We have a similar situation, for a very small user base, we don't need any privacy (we only store window size and locations and few configuration parameters) so we store these are local mat files under users home directory (in windows I guess we store them in My Documents\Matlab).
So if privacy is not an issue you can just use user names without passwords.
I do NOT recommend storing passwords using matlab because it is not just a matter of storing hashed passwords but also you need to enforce permissions on a server (that you said is accessible to all of your users) which is in the best case senario a reinvention of the wheel.
You didn't say if these settings are computer specific, or user specific, or both.
I can tell you where non-admin's aren't allowed to write to:
Environment::GetFolderPath(Environment::SpecialFolder::ApplicationData) + "\\Config.ini";
Environment::GetFolderPath(Environment::SpecialFolder::CommonApplicationData) + "\\monitorService\\Config.ini";
Environment::GetFolderPath(Environment::SpecialFolder::ProgramFiles) + "\\monitorService\\Config.ini";
I had high hopes for Environment::SpecialFolder::CommonApplicationData but sadly that one's off limits for ordinary limited users also. I need a common, easy to, err, know & find, directory where I can load configuration data from and save it to. I suppose I could countenance per-user config files, but I'd rather keep things as simple as possible.
Could I perhaps have my installer set aside some area of the registry or filesystem for universal access? I use Innosetup and .NET code to install. I've noticed (IRC) firefox fills up "Application Data" folders for named and default users so I guess that's another possibility. As the config data is needed by the service it might be too much trouble to store a couple of short strings and ints in anything other than the registry.
Since no one has answered I may as well posit my solution while I go about the implementation.
Limited users only have write access to HKCU. This is the same as using the file system- some user specific branches will be writable. It is hassle to have to check for write access to the global config file at the right time the user logs on and then delegate to user-local config if it throws, but that is what must be done. Being easier to defrag and less of a performance hit I will attempt using the FS before HKCU.
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
is there a way, to encrypt information on windows, and have windows securely manage the passwords?
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call EncryptFile() on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use the FILE_ATTRIBUTE_ENCRYPTED flag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.
If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.