Database applications need to be able to resolve environment variables.

[HolQue]

Background: Database credentials have to be hidden. This can be realized by using environment variables instead of hard coded values in command line.

The database applications are currently not able to resolve environment variables. With the following modified code it's possible:

# 3. Connect to database
db=CDataBase()
ARGS_SERVER   = os.path.expandvars(str(args.server))
ARGS_USER     = os.path.expandvars(str(args.user))
ARGS_PASSWORD = os.path.expandvars(str(args.password))
ARGS_DATABASE = os.path.expandvars(str(args.database))
try:
   db.connect(ARGS_SERVER,
              ARGS_USER,
              ARGS_PASSWORD,
              ARGS_DATABASE)

[ngoan1608]

Hi Thomas,

From my point of view, I do not see this is the reasonable change.

The terminal/console (which tool is executed on) has handled the environment variable expansion. In case, user uses in the unnormal way (call in script or subprocess, ...), he should know the values he parse in the tool arguments (value or env vars) so that the env var expansion should be handled within that script or provided in subprocess call.

With the current implementation, there is nothing need to be explained with user when getting arguments from input commandline.

Furthermore, I see the potential problem due to unwanted env var expansion with the proposal of using os.path.expandvars. For example when password contains the special chars % and $ such as mypass$existingenvvar, ...

Please give your idea about this request.

Thank you, Ngoan

[HolQue]

1. No one should do this: mypass$existingenvvar. This is strange!
2. Resolving does not depend on os.path.expandvars only. The console does the same! Example: A batch file containing: "%RobotPythonPath%/python.exe" "./TestScript.py" my%RobotLogPath%password causes: myC:\RobotTest\logfilespassword

[ngoan1608]

1. No one should do this: mypass$existingenvvar. This is strange!

It is just example, I think we can not make sure the no one do it. But every thing after $ char will be expanded as env var and if the env var definition is existing => unwanted expandsion. You can try

2. Resolving does not depend on os.path.expandvars only. The console does the same! Example: A batch file containing: "%RobotPythonPath%/python.exe" "./TestScript.py" my%RobotLogPath%password causes: myC:\RobotTest\logfilespassword

You got that console has handled it, so I think there is no reason for tool to do it again.

Thank you, Ngoan

[HolQue]

You assume that in every case an instance (like a console) is involved who does the job - and out of this assumption you conclude that it is not necessary for the database application to do it again. But we cannot be sure, that such an instance is involved. I already demonstrated that it is possible to start the entire tool chain out of a Python script. No environment variables are resolved in this case and the database applications get the variable names unresolved an throw an error. This can only be avoided if the database applications also resolve environment variables.

[ngoan1608]

In case, user uses in the unnormal way (call in script or subprocess, ...), he should know the values he parse in the tool arguments (value or env vars) so that the env var expansion should be handled within that script or provided in subprocess call.

As I mentioned above and the risk of the implementation.

In case, user uses in the unnormal way (call in script or subprocess, ...), he should know the values he parse in the tool arguments (value or env vars) so that the env var expansion should be handled within that script or provided in subprocess call.

[HolQue]

???? I didn't get your point.

And we should stop to distinguish between a normal and an unnormal way to execute software. There is no normal and no unnormal in this context. Every user of the database application is free to introduce any environment to execute the application. If we want to sell it as a feature that it is possible to use environment variables for database credentials, then it is under our own responsibility to make sure that these variables are resolved. In my opinion it is not OK to push away this responsibility to the world outside the database application.

[ngoan1608]

Hi Holger,

Sorry if making you think in the negative way that I push the responsible to other. I just do not want to implement the feature that has the problem as my above example and it is (can be) already handled by other one (console) before.

I just give my idea that the request is unreasonable. If this is reasonable request, for sure I will do it immediately without any concern as other requests from you.

For the requirement to hide the db credential (I think password is enough), the request to support encrypted password is more reasonable.

Thank you, Ngoan

[HolQue]

Hi Ngoan,

now I am very sorry!!!! Never ever I wanted to tell that YOU are the one who pushes responsibility!!!!! No - I had the database application in my mind when using this wording!!!! The database app pushes the responsibility ;-)

[test-fullautomation]

Hi both, let us discuss this topic in our team meeting. Seems to be a series of misunderstandings. Thank you, Thomas