You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.
Hi @aharbis
I see that on the SOMA request there is no domain info, and so, files are pushed to 'default' domain.
In some scenarios (specially in test envs.) users are allowed to upload files only to their own domains, and so, in the way the tool is designed it will certainly fail into an auth. error.
I would suggest adding a command line parameter to get the domain name, and, if omitted, uses the 'default' domain.
The text was updated successfully, but these errors were encountered:
Hey @rzancoper thanks for trying this tool out, and thanks for opening the issue.
I definitely can see some value in providing a --domain "name" option, so I'm more than happy to take this enhancement request.
In the meantime, you should be able to specify the full path from the default domain's perspective. This is because all application domain sub-directories exist within the default domain's filesystem. So for example if you had a domain sandbox and then a sub-directory foo in that domain, you could use the tool like this:
Hi @aharbis
I see that on the SOMA request there is no domain info, and so, files are pushed to 'default' domain.
In some scenarios (specially in test envs.) users are allowed to upload files only to their own domains, and so, in the way the tool is designed it will certainly fail into an auth. error.
I would suggest adding a command line parameter to get the domain name, and, if omitted, uses the 'default' domain.
The text was updated successfully, but these errors were encountered: