File load error while uploading a file from the path specified in json data file

[Sjain01]

trafficstars

1. Newman Version (can be found via newman -v): 4.4.1
2. OS details (type, version, and architecture): Windows Server 2012 R2
3. Are you using Newman as a library, or via the CLI? CLI
4. Did you encounter this recently, or has this bug always been there: Recently
5. Expected behaviour: Should be possible to upload files from the path mentioned in data file
6. Command / script used to run Newman: node newman run $collectionfilepath -d $jsondataFilePath -e $environmentfilepath
7. Sample collection, and auxiliary files (minus the sensitive details):
8. Screenshots (if applicable):

Steps to reproduce the problem:

1. Hereby my data file :-

2. I am using the variable to substitute paths in my collection

3. the variable is then replaced by the path mentioned when collection is executed using newman command :-

My issue is even though the file exists at path , I am getting file load error.

I have multiple collections to test this upload functionality and at this moment all are failing. Please advise how can this be resolved.

[Sjain01]

Hello Team ,

Would it be possible to provide any workarounds or any sort of updates to resolve this issue ?

[shamasis]

We are working to add built-in support within Postman app to store file references. This is something I think we will be tying up with our initiative to modify request body from pre-request script and not via variables.

On a second thought - @saswatds, with our new file resolver security algorithm in place, is it still unsafe if we later work to allow providing an editable text box for file path as well and resolve variable settings in them?

[Sjain01]

Thanks @shamasis - for now , I have placed all files to be uploaded in same folder as collection files. And with this workaround it is working fine. I hope with this new feature request , this workaround would still work.

[saswatds]

@shamasis The idea to provide an editable text box for file-path can surely be explored. But before doing that a few things around the resolver have to be ironed out with regards to how app, variables, runtime interact. Otherwise, we are good.