Allow setting ReadyAPI working directory for user
Feature request: Please consider adding a global log file location and removing the dependency on the bin/ directory being writeable by the user running ReadyAPI (or testrunner.sh, etc). Even better would be if you would support using a variable in the path, or simply relative paths, so that the ReadyAPI logs of one project could be placed under the project's working directory.
I'm not overly familiar with ReadyAPI but I imagine the ideal location in which to specify a log path would be in soapui-settings.xml.
Background (as per our forum post and support ticket):
We have installed in a system-wide location at /opt/SmartBear/ReadyAP-1.2.2, but unless we make the bin/ subdirectory of that path writeable by the user (not a good idea!) the software refuses to start.
Even giving write permissions to all of the individual log files that ReadyAPI expects to write to is insufficient. It requires write access to the bin/ subdirectory.
If I temporarily make bin/ writeable, I can launch the GUI, run tests, etc.
Even if installed into a user's home directory, we'd prefer for logs not to be created in the same dir as the binaries.
I have so far tried setting global properties as follows using the GUI:
Neither of these worked when running our test suite, even after restarting the ReadyAPI GUI.
I have tried various combinations but ended up having to make our user the owner of the directory for ReadyAPI to even launch at all. I had considered editing soapui-log4j.xml but thought it was bad form to do so (and it's likely changes will be over-written next time we upgrade ReadyAPI).
I think many *nix systems administrators would be concerned about the fact that ReadyAPI requires write access to the binaries directory (not just the log files in it, but the whole directory).
A bit more detail:
1. The simplest "User-wide" implementation would look like this: in soapui-settings.xml a new variable would specify the ReadyAPI working directory (or the existing variable 'user.dir' variable could possibly be used). I imagine that from the coding side, the application would change directory (Unix 'chdir') to this directory immediately after loading configuration. This would then be the location in which any log files and temporary files would be created/updated, except where absolute paths had been given, i.e. in soapui-log4j.xml.
2. If #1 could be implemented so as to permit use of a relative path, that would allow logs for a project to be created within the project's tree and make for easier log review and troubleshooting for a failing project.
3. For more flexibility, consider supporting the use of an optional working directory 'override' variable within project definitions, which would cause SoapUI to change directory or otherwise use the specified path for all output.
We would be very happy even if only #1 is implemented in the short term. At least that would deal with the immediate security issue. Thank you, Ashley Hooper
I think this is very interesting and makes a lot of sense. It's been on the radar for a looong time. 1.4 is not possible however.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.