Hi all,
I don't know how to avoid saving password in plain text when testing code from the PB IDE "Run" button. Goal is to protect sensitive data (password) on developer machines.
PB encrypts and stores DB-profile passwords in the registry and uses these to connect to the DB, see image.
Would be nice to use same functionality when pressing the Run button, so DB passwords do not need to be in clear text in the source code (or in INI / external files).
The sqlca object could then use the logPassword string from the registry when connecting to the DB, with PB that converts it so it can log into the DB.
Even better would be, if we can pass in DBparm a string like "DBProfilename=myprofile" and then PB takes all necessary info from the database profile called myprofile as stored in the registry.
This would be same as when running in PowerServer mode, where we pass something like sqlca.DBParm= "cachename='myprofile'".
Best,
.m
my goal is to remove password readability from the source code.
By using crypterobject or STD frmk, a developer can always access - in PB debug mode - the actual password.
In short, have sqlca to accept either 1) the Logpass string in the Win Registry as encrypted by PB or 2) the DB profile name, when pressing the PB Run button (i.e. in developer-mode only!).
This is probably an enhancement request to Appeon because not possibile at the moment.
Cheers,
.m
IMHO, no sensitive datum should ever be stored in any programming language's source code in plain text mode. Proper design & QA processes should confirm that before any app is released into production.
Yes, developers though in unit test / debugging mode only need access to this protected data but not in production. Also in production, this datum should always be different & not controlled by any developer.
You bring up great points for App designers & developers to consider in any system design / maintenance cycle!
I think that you are really "over thinking" the challenge. If the user ID's & passwords are *different* in all environments (Dev, QA, IT, UA, Prod) then who cares if the developer cam see the UID & Pwd (ie: DBA & SQL) in the PB IDE's debugger!. Each environment should be able to change the UID & Pwd(s) in the their environment. Also, each UID & Pwd in each environment should / must be *different*. Only people responsible for each environment should change the App's UID & PWDs appropriately. These changes should not be shared with DEV. Only App EXE's should be used in each environment after DEV. Thus, there should be *NO Way* any password in any non-Dev environment should be able to be exposed on Disc, O/S Registry, App Memory, etc if this standard SDLC process is used. Just my $0.02. HTH
Regards ... Chris