I'm wondering where's the best place to save some simple insensitive data? Like a few URLs and some settings.
Please advise.
If this is a per-user file, you should save it in the current user's profile. For example, on my Windows 7 system, you should use
C:\Users\Andreas Rejbrand\AppData\Local\Your Company Name\Your Product Name\Version
such as
C:\Users\Andreas Rejbrand\AppData\Local\Rejbrand\AlgoSim\2.0
To get the C:\Users\Andreas Rejbrand\AppData\Local path, you use the SHGetSpecialFolderPath function.
Settings, and specifically user-specific settings, can be stored in the registry. Have a look at the Registry unit and the TRegistry object.
Here's some demo code to get you going:
var
r:TRegistry
begin
r:=TRegistry.Create;
try
r.OpenKey('\Software\MyApplication',true);
r.WriteInteger('Setting1',Setting1);
r.WriteString('Setting2',Setting2);
finally
r.Free;
end;
end;
INI file or JSON file or XML file depending on your needs for local usage.
DB is for net usage.
It all depends on the purpose of those settings! If you want XCopy deployment, I would suggest an XML file next to the exe. But if you also need to write to this, you should find a suitable location in the current user's profile or the "all users" profile. The registry (local machine or current user) would also be a good option for simple settings.
Another question is the type of settings that you need to store. If it's simple settings, I generally start with Altova's XMLSpy to generate an XML schema, defining the structure of the settings. Then I use Delphi's XML import wizard to generate code from this schema and just use that generated code. It allows me to modify the structure in an easy way and also makes sure there's at least some documentation (the schema) telling others about the structure. It might sound complex at first, but once you're used to this, it's perfect! No more manual editing of registry settings or forgetting about the structure of your INI files. And no more thinking about writing code to read and write those settings, since Delphi will do that for you!The Registry would also be a good location for settings but not every user will have proper access rights to read from, or write to, the registry which could crash your application. Besides, the registry has some other limitations which makes it unsuitable if you need to store a lot of settings! It would be okay to store a connection string and maybe username and encrypted password for some user account, but if you need to store 40 settings or more, then the Registry becomes unsuitable.The same is true about INI files, which tend to be limited to a maximum size of 64 kilobytes. Of course, you could also store those settings in a regular text file or just some binary file. In the past, I even stored settings inside a ZIP file, because I needed to store dozens of grid-related settings. So each grid would read and write it's settings to some binary stream which would then be stored in an encrypted ZIP file.
There are many options like XML (structured data storage), ini files (simple data), databases or flat files.
I will go for XML's saved with ClientDatasets. They allow lot of options like searching, sorting, usage of the database controls and many more.
Related
I'm trying to create PropertyHandler shell extension.
What's the best way for embedding properties like (Title,Author,.....) to use the same file in multi computers or devices?
StgCreateStorageEx ? way or there is other ways to do it?
because StgCreateStorageEx dealing with NTFS files only and i'm not sure if the file hold these properties with it if i open it in other device with same PropertyHandler
Is there any way to save properties inside the my file ?
The StgCreateStorageEx function creates a new storage object using the IStorage interface. This allows storing multiple data objects within a single binary file, see for example https://en.wikipedia.org/wiki/COM_Structured_Storage. So, technically, you can save almost anything in this file including embedded properties.
I don't think that this is limited to NTFS: The old Microsoft Office .doc format (and many other Microsoft products) use this storage format and work also with FAT32.
If you want to use this binary file format is a completely different question. As you did not provide any information about the content and format of your file, I cannot recommend anything. One alternative would be to store the content of your file in an xml file. Properties like Title and Author then could be added easily.
I am using Express Quantum Grid from developer express. From code i came to know that they are storing the user settings using TMemIniFile. I know the sections where they are storing but is there any way to open the Ini file and see the contents? If so where is the file located?
From code I came to know that they are storing the user settings using TMemIniFile.
The constructor of TMemIniFile receives the name of the file that stores the INI file. So, you simply need to find the call to TMemIniFile.Create and your answer will be revealed.
If we want to store critical information, like passwords and server addresses, inside the executable file generated by the Delphi compiler, how can we do that, without knowing the final executable size and binary structure, like at the end of the file for example?
Side note:
The text to be stored is already encrypted; and in some computers the windows don't give access to write in the registry, specially when the user is not administrator, and there are hacks to monitor registry changes and the smart user can find the new windows registry entry.
Comment
Why this question was down voted? This is achievable! Doesn't meter if not interesting for most people.
I think about the bios and other firmware upgradeable, like satelite tv signal decoders that update themselves. How is that possible?
You can use an .rc file to put your data into a custom resource inside the final .exe file. You can then access that resource at run-time, such as with a TResourceStream, and decrypt and use its content as needed. However, you cannot write new data into the resource while the .exe is running, as the file is locked by the OS. If you need to write new settings, and do not have write access to the Registry, you will have to use a separate file instead. Windows has special folders set aside that users have write access to within their user profiles.
Create a string table resource is one way.
Create a text file. say secretstuff.rc (has to have .rc extension)
with something like this in it.
STRINGTABLE
{
1,"This is my encrypted password in say Base64"
}
Compile it to a .res file with BRCC32.
Include it in the relevant code with a compiler directive
{$R secretstuff.res}
After that you access with TResourceStream.
If you want to manage it a bit better might be wise to stuff them in a dll instead of an exe, then you can update things by delivering a new version of the dll.
There's an example with a it more detail, another purpose but same principle here
I would like to create a simple file repository in Ruby on Rails. Users have their accounts, and after one logs in they can upload a file or download files previously uploaded.
The issue here is the security. Files should be safe and not available to anyone but the owners.
Where, in which folder, should I store the files, to make them as safe as possible?
Does it make sense, to rename the uploaded files, store the names in a database and restore them when needed? This might help avoid name conflicts, though I'm not sure if it's a good idea.
Should the files be stored all in one folder, or should they be somewhat divided?
rename the files, for one reason, because you have no way to know if today's file "test" is supposed to replace last week's "test" or not (perhaps the user had them in different directories)
give each user their own directory, this prevents performance problems and makes it easy to migrate, archive, or delete a single user
put metadata in the database and files in the file system
look out for code injection via file name
This is an interesting question. Depending on the level of security you want to apply I would recommend the following:
Choose a folder that is only accessible by your app server (if you chose to store in the FS)
I would always recommend to rename the files to a random generated hash (or incremntally generated name like used in URL shorteners, see the open source implementation of rubyurl). However, I wouldn't store them in a database because filesystems are built for handling files, so let it do the job. You should store the meta data in the database to be able to set the right file name when the user downloads the file.
You should partition the files among multiple folders. This gives you multiple advantages. First, filesystems are not built to handle millions of files in a single folder. If you have operations that try to get all files from a folder this takes significantly more time. If you obfuscate the original file name you could create one directory for each letter in the filename and would get a fairly good distributed number of files per directory.
One last thing to consider is the possible collision of file names. A user should not be able to guess a filename from another user. So you might need some additional checks here.
Depending on the level of security you want to achieve you can apply more and more patterns.
Just don't save the files in the public folder and create a controller that will send the files.
How you want to organise from that point on is your choice. You could make a sub folder per user. There is no need to rename from a security point of view, but do try to cleanup the filename, spaces and non ascii characters make things harder.
For simple cases (where you don't want to distribute the file store):
Store the files in the tmp directory. DON'T store them in public. Then only expose these files via a route and controller where you do the authentication/authorisation checks.
I don't see any reason to rename the files; you can separate them out into sub directories based on the user ID. But if you want to allow the uploading of files with the same name then you may need to generate a unique hash or something for each file's name.
See above. You can partition them any way you see fit. But I would definitely recommend partitioning them and not lumping them in one directory.
I have .Net desktop app which users can download from my website. I want to customize this app to per user basis.
Is there way to modify exe before downloading, just to change few strings with appropriate for the users downloading ?
Or it is possible to pass command line parameters to this exe via URL ?
The .exe file needs to be customized for it to behave differently for certain downloads.
Skip below to find the solution I found tolerable.
Add section to the .EXE file – Not ideal.
The .exe file has sections one after the other. You could add a section with your data in it, which the executable would then read. This requires you to modify (have access to) the source code of the executable for it to do anything meaningful with the data. Also getting familiar with the .exe file format and modifying it on the web server side as well al playing with it in the program's source code is somewhat tedious.
Change resources section of the .EXE file – Not ideal.
A dedicated "resources" section exists in the executable. You could add custom strings or blob of data to it. Same cons as the first one.
Overwrite data in the .EXE at a fixed position – Passable.
Have the executable read data from itself from a fixed position in the file, which is overwritten with the customization data when serving the .exe file. Requires modifying the executable's source code.
Append data to the .EXE – Passable.
Append data to the executable. Again, reading it and doing anything special with it requires the executable itself doing so.
☑ Wrap the .EXE in another .EXE and append your data to it – Tolerable.
Create a program to which the original executable and the custom data will be appended to. When this custom program is then executed, it will extract the embedded executable and launch it with the custom data as it arguments.
This kind of a bundle-executable is also easy to produce on most server-side (scripting) languages. When the download is requested, the server sends the wrapper-exe, the original exe, the customized data and of course some statically-sized data fields denoting the sizes of both of those data blocks so it can extract them.
Cons: Requires such a wrapper program to be created, unless someone already has.
Related links:
1. Best practices to let my web users download custom .exe from my site using PHP
2. Modifying executable upon download (Like Ninite)
If the application is ClickOnce deployed, passing URL parameters is an option in the ClickOnce options dialog. However, I have not yet used this feature.
EDIT
You might want to change some user settings in your configuration depending on the user that actually runs the application. You could also make sure this is done only once per user by adding an appropriate SettingsNeedUpdate setting you set to true after the initial initialization.
Example:
Add new setting "Option1", "Option2" and "SettingsNeedUpdate" which are user settings. In Main you could add something like:
...
try
{
if (Properties.Settings.Default.SettingsNeedUpdate)
{
Properties.Settings.Default.Option1 = ...;
Properties.Settings.Default.Option2 = ...;
Properties.Settings.Default.SettingsNeedUpdate = false;
Properties.Settings.Default.Save();
}
}
catch (Exception exp)
{
...
}
...
You could write a library which can modify an assembly resources (here string table).
This library could benefit from reflection.
When a user asks for your file, asp.net page could customize the exe (using your library) and send it to client.
Not like that, No.
You could however automatically zip (on your server) your exe with a custom app.config file for each user.
Update
Point your download location to a custom HttpHandler that zips together your exe (using http://www.sharpdevelop.net/OpenSource/SharpZipLib/) with a generated (for the current user) application configuration file ( http://generally.wordpress.com/2007/09/27/using-appconfig-for-user-defined-runtime-parameters/).
The user then unzips the two files (MyApp.exe & MyApp.exe.config) to any location and run MyApp.exe.
This method does not work if you have an installer.