You state that
Note that passwords and passphrases not stored in the log.
Therefore a log would not be useful at all.
That log would just say that the wrong password was used, which is perfectly correct.
the wrong password is used is what counts: the "Generate Session URL" feature changes
the password from the entered/stored one, when that password includes a comma.
1) Set up an account with a password that begins with a comma
2) Make a new entry for that account in WinSCP, and store the password.
3) Connect to that account using the WinSCP GUI: works OK.
4) Now use the "Generate Session URL" feature to obtain an URL for that connection that can be used in a script.
You'll notice that the URL does not include a comma at all.
Where the passord is supposed to be (so immediatly after the colon) the first characters are %2C.
After that %2C are all remaining characters of the password (those after the comma) and then the @-character followed by the host etc
5) Using that URL in a script leads to a refused connection caused by bad credentials (which is correct)
6) If the log of the server would show the used password (I guess it won't) then that password would start with "%2C" instead of with ",".
I see two options for what you need to correct:
A) "Generate Session URL" should not URL-encode the password string
B) The script engine should convert the URL-encoded password back before sending it to a sever.
If you go for option B, I suggest adding a security improvement: if the scripting engine has to decode the password anyway, why not make it a bit more secure by really encrypting
the passwords in the generated URLs?
I won't be following this up any more since my workaround is working fine.