" />

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Manage DB pwd for a PB app on a dev machine

  1. Misc
1
Votes
Undo
  1. Marco Meoni
    Marco Meoni
  2. PowerBuilder
  3. Saturday, 26 August 2023 17:10 PM UTC

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

Migrate to 2022 R2
Powerclient: Release planning with test and produc...
Responses (2)
Peter Pang @Appeon
Peter Pang @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 5 September 2023 02:47 AM UTC
  2. PowerBuilder
  3. # 1

Hi Marco，

 

If you have a new requirement, please open a ticket through our support portal at https://www.appeon.com/standardsupport/newbug.


Best Regards,
Peter

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Saturday, 26 August 2023 19:59 PM UTC
  2. PowerBuilder
  3. # 2

Hi Marco;

  My STD Framework does this encryption automatically for both external DB connection information and for SQLCA while in memory. This works for native, PowerClient & PowerServer based Apps as well.

  You can achieve the same protection in your App using the PB built-in Crypter Object...

https://docs.appeon.com/pb2021/objects_and_controls/CrypterObject_object.html

HTH

Regards ... Chris 

Comment
Marco Meoni
  1. Marco Meoni
  2. Sunday, 27 August 2023 05:59 AM UTC
Hi Chris:

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
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Sunday, 27 August 2023 14:55 PM UTC
Yes, this type of sensitive data protection is not available in native PB apps PBVM runtime wise.

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!

  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 5 September 2023 13:35 PM UTC
Hi Marco;

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
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.