Hi Tim,
It feels like you try to apply file system security a little to early. Indicium or the Web GUI backend will access the file system by one single account which is configured as the Application Pool Identity of the Application Pool of IIS.
Now the Windows GUI still accesses the file system directly based on the logged in (domain) user. So for now you indeed provide everyone access to certain file locations.
The GUI indeed creates an empty file to reserve the file location and its file name during editing. The file will be saved to disk just after the record is saved, so we have to overcome the time between the upload and saving the record. In the meanwhile we have to provide a filename to execute application logic when editing fields in the edit mode session.
The Windows GUI connecting to the database through Indicium should let the file upload to Indicium. We have to implement that.
Maybe database file storage is an option to use?
Regards, Erik
Hi Erik,
I should’ve mentioned we’re using the Windows gui exclusively in this part of the application. The software runs on a terminal server which provides users full access to the upload folder via a windows share.
I’ve consider database file storage but I’m worried the database will grow in size beyond control. I don’t have any experience with it and I’ve seen reports to always use it cautiously. What’s your opinion?
I’ve considered an alternative which is to change the ownership of uploaded files overnight using a script. At least this way files do become uneditable for regular users just not immediately.
After some more thinking couldn’t the gui reserve the file name more passively, skipping the step of creating an empty file first? You could have it check if a file exists first. Then if it does append some characters to that file name and only then save the file with its unique filename in 1 step. That would solve the issue with file and folder rights. I’m no expert on file systems and file management though and there could very well be a good reason to first create an empty file that I’m unaware of. :)
Hi Roland,
I’ve consider database file storage but I’m worried the database will grow in size beyond control. I don’t have any experience with it and I’ve seen reports to always use it cautiously. What’s your opinion?
For database file storage, could you predict the amount of records with a attached file to expect? You could use the MaxFileSize option from the SF to keep the memory footprint of the database in control.
After some more thinking couldn’t the gui reserve the file name more passively, skipping the step of creating an empty file first? You could have it check if a file exists first. Then if it does append some characters to that file name and only then save the file with its unique filename in 1 step. That would solve the issue with file and folder rights. I’m no expert on file systems and file management though and there could very well be a good reason to first create an empty file that I’m unaware of. :)
We choose this solution because first we save the records, where we need the filename/path already, and a little later we upload the file content to its definitive location. We have to allocate the filename before saving to be sure the saved record doesn't reference a total different file with the same name.
The chance it will happen this way is small, but we can't allow it to happen in production environments.
I hope you understand our architectural choices here a little better now.
Regards, Erik
Thanks! And course, there are always choices to be made. We’ll opt for the workaround I mentioned.
