Encrypting a Connection String in my Add-In

[BrianBulla]

Hi,

So I have an add-in that uses the "ID" of the selected feature to query a database.  Currently I have the Connection String with username/password right in the code, but from what I am reading it is "bad coding" to include that in your code.

Can anyone provide some advice on best practices for this, and maybe an example.  Are there any considerations specfic to an ArcPro add-in I will need to consider??

Thanks,

[RichardDaniels]

Most people would put the connection string in the Resources/Settings area in Visual Studio, this allows easy update as one moves from DEV, QA, to PROD environment. Key here is that that user/id will be part of the compiled coded (i.e., will not be human readable) after the Add-In is built. The end user would rarely if ever have access to the Visual Studio project that contains this information. There are also options in Visual Studio to encrypt strings if you need to go that far.

[BrianBulla]

Thanks....yeah, this only came up after we moved the SQL database I connect to, to a new server.  I told them I will need to update/recompile my code and now our IT Security Team is suggesting that I take the connection string out of the code.  I'll need to do some research I guess.

[RichardDaniels]

Which lead to the web.config route were the string would be saved in a XML file vs. the settings area in Visual Studio. This would allow you to edit the connection string without recompiling...but remember that ArcGIS Pro only (re)downloads an Add-In if the DAML is updated with a new creation date. Thus even if you changed the XML you could not guarantee that the Add-In would actually read the new file on startup (unless you have the configuration file on a separate well known location that you do a traditional file read from).  However, this solution actually would be less secure since all end users would need read access to the 'well known location').

[sjones_esriau]

There's a few options.

Use an sde connection file rather than connection properties.
The user/pass is encrypted in the connection file for you. You can then place the .sde file in a folder and set access permissions for authorized users.

Use SQL OS authentication rather than a DB login
Permissions are pulled from the running process. There are pros/cons to this approach.