Hide password

[SteveOgh]

Looking for method(s) to hide the password portion of the <ConnectionURL> for demos and scripts.

[pesse]

Hi @SteveOgh , thanks opening an issue.

What you can do is to write your password to an environment variable and use it in your call:

Linux/Unix:

export PW=myPassword
utplsql run user/$PW@myConnectstring

Windows:

$env:PW="myPassword"
utplsql run user/$env:PW@myConnectstring

That way it is not shown and - as far as I know - not written to the command history.

It might still be useful to have another option. What comes to my mind:

1. Get user, password and connectstring from (predefined, fixed) environment variables when they are not provided
2. Prompt for password if it's not set

I prefer 1 over 2, because prompting might break automated setups and it's also harder to implement.

[simonuwe]

In linux using an environment-variable in/as a commandline parameter does not really hide the value (only in shell history). It is possible for every user on the system to see the password while the utplsql is running with ps -ef

Example ` export PW=xx; sh -c "sleep 1; echo $PW"& ps -ef | grep echo [2] 1881476 uwe 1881476 1312384 0 11:07 pts/2 00:00:00 sh -c sleep 1; echo xx uwe 1881478 1312384 0 11:07 pts/2 00:00:00 grep --color=auto echo

`

[gassenmj]

Hi there,

i am commenting this issue - hope it is okay to track it here: Let's say i run something like:

sh ./utPLSQL-cli/bin/utplsql run -c -q schema-tst/super-secure-pwd@tns-string

Can i hide the password at least from the DEBUG output? In version 3.1.9 i always get the password printed like:

14:37:26.505 [main] DEBUG org.utplsql.cli.Cli - Args: run, -c, -q, schema-tst/super-secure-pwd@tns-string

EDIT 7-AUG-2023: It is possible by placing a logback.xml file in the lib folder with the following content:

<configuration>

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>
  <root level="info">
    <appender-ref ref="STDOUT" />
  </root>

</configuration>

Reading a bit about Logback it says that Logback scans the classpath for such an .xml. In my case i had to create a ./etc directory:

>tree -D
[Aug  7 20:43]  .
├── [Aug  7 20:43]  bin
│   ├── [Aug  7 20:42]  utplsql
│   └── [Jun 13  2022]  utplsql.bat
├── [Aug  7 20:43]  etc
│   └── [Aug  7 20:39]  logback.xml
└── [Aug  7 20:42]  lib
    ├── [Jun 13  2022]  cli-3.1.9.jar
    ├── [Jun 13  2022]  java-api-3.1.9.jar
    ├── [Jun 13  2022]  javax.activation-api-1.2.0.jar
    ├── [Jun 13  2022]  jaxb-api-2.3.1.jar
    ├── [Jun 13  2022]  jsr305-3.0.2.jar
    ├── [Jun 13  2022]  logback-classic-1.2.11.jar
    ├── [Jun 13  2022]  logback-core-1.2.11.jar
    ├── [Jun 13  2022]  ojdbc8-19.3.0.0.jar
    ├── [Jun 13  2022]  ons-19.3.0.0.jar
    ├── [Jun 13  2022]  oraclepki-19.3.0.0.jar
    ├── [Jun 13  2022]  orai18n-19.3.0.0.jar
    ├── [Jun 13  2022]  osdt_cert-19.3.0.0.jar
    ├── [Jun 13  2022]  osdt_core-19.3.0.0.jar
    ├── [Jun 13  2022]  picocli-4.6.3.jar
    ├── [Jun 13  2022]  simplefan-19.3.0.0.jar
    └── [Jun 13  2022]  slf4j-api-1.7.36.jar

I did find my classpath by adding an echo $CLASSPATH in ./bin/utplsql

imho it still makes sense to change the logging level in the code to TRACE