How to add restrictions to aras.vault.selectFile() file picker

Hi community,

I currently design a custom form with a button that calls a regular file picker. In my scenario, end users shall only be able to upload certain datatypes, like txt and xml. As the affected users group does not have any edit rights for items, I have to upload the Files to the Vault and link them later to the correct items by a Server Method. As this approach directly throws files into the Vault, I want to ensure that only the right files can go through.

What´s the best way to add restrictions to the file picker?

var vlt = aras.vault;
vlt.selectFile().then(
function (fileObject)
{

  if (fileObject.size > 1000 || fileObject.type != "text/xml" )
  {
     return alert("This file can´t be right")
  }
  var fileItem = inn.newItem("File","add");
  fileItem.setFileName(fileObject);
  fileItem = fileItem.apply();
  var fileId = fileItem.getID();
// do something with the file
}
);

I have noticed, that the fileObject contains the mime type, file size and other file properties that I can use for a later filtering. It´s even possible to read the hex file signature, which maybe helps to prevent faked files. But I wonder if I can directly pass a filter to the file picker, so users can only select certain file types from the start. This way my lnnovator would not get in touch with invalid fileObjects at all. 

Thanks for sharing your ideas!
Angela

Parents
  • Hi Chris,

    I would have a short question regarding this thread. In my sample code I use the following code for file upload:

     var fileItem = inn.newItem("File","add");
     fileItem.setFileName(fileObject);
     fileItem = fileItem.apply();

    The code works, but I wonder if this is the recommended way to upload a file from client side. I am little bit confused about setFileName(fileObject).

    The fileObject contains much more than the name of the file. Do you have a better sample for the file upload? I have no idea where I got this code, I assume I have programmed it by accident. So it maybe just works in my current Innovator version. 

  • Hi Angela,

    It looks like this is setFileName was an older function intended to work when adding File items as you're doing. It's listed as obsolete in the IOM API though, so I'd recommend updating the code in the event that support for it is removed in the future.

    The Programmer's Guide recommends using the setFileProperty function when adding files using vlt.selectFile(). However, this seems to be intended for when you are adding files in the context of another item (the native_file property of CAD in the example in the programmer's guide) and not when you're adding File items directly. I tried testing fileItem.setFileProperty("id", fileObject); in my local environment but that didn't work for me. If you don't need to add the file directly, I'd recommend this approach.

    If you do need to add File items outside of the context of another item like you're currently doing, you could try this approach using aras.newFileItem:

    vlt.selectFile().then(function(fileObj)
    {
        var newFile = aras.newFileItem(fileObj);
        var fileId = newFile.getAttribute("id");
        var fileItem = aras.IomInnovator.newItem();
        fileItem.loadAML(newFile.xml);
        fileItem.apply();
    });

    This code worked for me in a 12.0 SP4 instance. Note that the functions defined on the aras object are typically more subject to change the functions in the IOM like setFileProperty. If you don't need to add Files directly, the recommended approach would be the one in the Programmer's Guide.

    Chris


    Christopher Gillis

    Aras Labs Software Engineer

  • Hi Chris,

    thanks for this solution! The obsolete version still works fine, but I prefer to use the more future-proof version. I replaced my current code with your new version. Worked!

    I agree that a regular upload within a context item is probably the better approach. But I am not sure if this is possible in my current use case.

    In my current use case an external (!) user shall be able to upload a file into an existing item. The user must not be able to edit any of the other fields. So the external user only has "Get" permission for the item.

    I was thinking about different concepts of how to achieve this one:

    1. Property based permissions (as seen in the corresponding community project). 

    2. Give user full edit permissions, but use a custom Form so user cannot edit field in Form. This one would be a simple solution, but user could still edit all fields via AML or Rest API.

    3. Edit via Server Method that grants permission for editing only the specific item property. This is the variant I currently use. But as this one runs on the server, I have to separate File upload and the actual edit of the context item. 

    I am not sure if there are other variants available. The "Grant permission" variant right now seems to be the best mix of security and usability.

Reply
  • Hi Chris,

    thanks for this solution! The obsolete version still works fine, but I prefer to use the more future-proof version. I replaced my current code with your new version. Worked!

    I agree that a regular upload within a context item is probably the better approach. But I am not sure if this is possible in my current use case.

    In my current use case an external (!) user shall be able to upload a file into an existing item. The user must not be able to edit any of the other fields. So the external user only has "Get" permission for the item.

    I was thinking about different concepts of how to achieve this one:

    1. Property based permissions (as seen in the corresponding community project). 

    2. Give user full edit permissions, but use a custom Form so user cannot edit field in Form. This one would be a simple solution, but user could still edit all fields via AML or Rest API.

    3. Edit via Server Method that grants permission for editing only the specific item property. This is the variant I currently use. But as this one runs on the server, I have to separate File upload and the actual edit of the context item. 

    I am not sure if there are other variants available. The "Grant permission" variant right now seems to be the best mix of security and usability.

Children
No Data