Our corporate scheduler executes a script on the Cognos application server that receives the 5 parameters necessary for the trigger.bat.
This script then executes the trigger.bat file in the default Cognos directory.

We need to obfuscate the Cognos user password in all places possible.
The user password hidden as a variable in the scheduler, however, the log file produced from the trigger.bat file shows the password.

Is there a way not to produce this log file or to have the parameters passed to trigger.bat obfuscated in the log file?

In the trigger.bat file, I believe @echo on is defined, can I modify this to @echo  off?
In which case, am I better to create another version of trigger.bat so that it is not overwritten during an upgrade? 
Does the trigger.bat file need to remain in the defined directory and what are the risks of changing it?

Thanks in advance,
Adam.

Hello Adam,

the trigger is (more or less) a sample of SDK. In the folder sdk/java/EventTrigger on your Cognos Analytics server you find the java source code which you can modify with your requirements and place your script outside of the installation directory.

In general the trigger script can be put outside of Cognos Analytics (any other server with network connection to Cognos Analytics dispatcher).  See: https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=scheduling-set-up-trigger-occurrence-server for details.

Thanks Michael...

So if I understand you correctly, and to confirm I am not looking to move the trigger scripting off the application server, I am looking to edit the Java code in sdk/java/EventTrigger assuming that to be the easiest solution.

However, to be clear, I am not an SDK or Java code developer (but, I hopefully have access to some in our IT department). 
It looks like there are two main files - trigger.class and trigger.java - which one, and or both, need editing such that the password will not be logged?
To me, trigger.java is the most likely candidate for modification as it opens most easily for editing in a text editor, but I could well be mistaken.

It looks like there is a section of output in the log following the statement that displays the parameters in somewhat, but not completely, obfuscated manner: 

• javax.net.ssl|FINE|01|main|2025-02-28 15:05:22.134 EST|Thread.java:1178|Plaintext before ENCRYPTION (
  

This is the section of code that I would like to exclude or modify such that output is excluded from the log.

Thanks again, and any help would be greatly appreciated.

------------------------------
Adam McIlravey
------------------------------

Hello Adam,

the file Trigger.java is the source code that needs to be adjusted. The .class is the one that is "executed" by JRE (see run.bat or run.sh file).

I assume you are referring to an error message due to an error during login (because of .ssl). So I assume that you need to modify the "catch" area. A developer should be able to change the java in the way you want.

Hi, if I'm understanding things properly, I believe the issue you are hitting stems from the Trigger program. When a login error is encountered, it calls "error.printStackTrace()" which by default writes the error stackTrace to the console of the java Trigger caller (ie your corporate scheduler console). 
So, the easiest way to fix this is likely just to modify your corporate script to redirect the console output to on of your choosing using the native OS console redirect capabilities.
See: https://coderanch.com/t/485476/java/Saving-Java-Console-output-file

Eg
trigger.bat http://localhost:9300/p2pd/servlet/dispatch username password namespaceid "databaserefreshtriggername,emailtriggername"  > output.txt 2> error.txt
Of  course, you now lose that logging within the corporate script logging but if you need it... you know where it. Alternatively, you can redirect to a "null" console or built a more elaborate redirect solution here that suits your corporate needs.
Eg: for windows, see: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb490982(v=technet.10)

If that solution doesn't jive... your other option (assuming you have the Trigger.java source code) is to modify Trigger.java and remove/refactor the problematic "error.printsStack" statement and recompile.
ensuring all required jar files are in the classPath along with a compatible JDK. (Java 8 is likely your best bet).

Finally/in addition you can consider reporting the security concern to your IBM rep who can initiate a ticket to have the issue investigated/fixed.

Hope this sheds some more light on the issue and solution.

Good luck!