Skip to main content
Solved

Access denied when uploading file to folder without edit rights

  • October 28, 2019
  • 5 replies
  • 130 views
R
Hero
Forum|alt.badge.img+13

For a new table we need users to be able to upload files to a folder. To protect the integrity of these files the folder rights are set in such a way that files can be added but not edited or deleted. If users want to change a file in a record we want them to simply upload a new file. This also allows us to keep a history of all the files ever used in a record while keeping all the original files.

When I try to upload a file using the gui I get an “access denied” error. The folder then contains a new empty file with the same filename as the original. It seems that the gui always creates an empty file first and then tries to edit it which is not allowed in this case.

Is there a way for the gui to simply copy the file to the upload folder with the correct filename in 1 step? Manually copying a file to the same destination in Windows works fine.

Best answer by Erik Brink

Hi Roland,

Roland wrote:

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.

 

Roland wrote:

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

View original
    This topic has been closed for comments

    Erik Brink
    Moderator
    Forum|alt.badge.img+5

    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

    R
    Hero
    Forum|alt.badge.img+13
    • RolandHero
    • Hero
    • October 29, 2019

    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.

    R
    Hero
    Forum|alt.badge.img+13
    • RolandHero
    • Hero
    • October 29, 2019

    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. :)

    Erik Brink
    Moderator
    Forum|alt.badge.img+5

    Hi Roland,

    Roland wrote:

    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.

     

    Roland wrote:

    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

    R
    Hero
    Forum|alt.badge.img+13
    • RolandHero
    • Hero
    • October 29, 2019

    Thanks! And course, there are always choices to be made. We’ll opt for the workaround I mentioned.

    Terms & ConditionsCookie settings

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings