Security issue, passwords inside Method not recommended

[AngelaIp]

The direct specification of login name and password inside the Method is not recommended.

[EliJDonahue]

One option is to get the XML contents of the InnovatorServerConfig.xml file and use XPath to retrieve the reporting server credentials. However this introduces a new challenge - finding the file. You'd probably have to hard-code the path.

The drawback there is that connecting the database to a new Innovator instance or importing the method to a new database would require manually updating the file path.

[AlAlderaan]

You can read the config from CallContext Cache, like that:

XmlDocument xml = CCO.Cache.GetCacheInfo("ApplicationXML");

This will give you the InnovatorServerConfig as XmlDocument. You can use XPath to retrieve Reporting Services User, URL, etc. I.e:

string reportServerURL = xml.SelectSingleNode("//ReportingServices/ReportServer").InnerText;

[EliJDonahue]

Great suggestion, AlAlderaan!

[AngelaIp]

Yep! I always liked the XML idea a but didn´t know how to do it. Many thanks for the example, I will test it soon!

I did not even expect this project to be found by much people, so I am right now highly-surprised. From all questions that could be answered, you joined GitHub to answer this one. Classy!

[EliJDonahue]

If either of you get the code working in your method, feel free to submit a pull request to improve the project.

[AngelaIp]

I have created a new pull request but have not merged it yet. I have reworked large parts of the code and improved the AML queries and error handling.

The basic idea of using the credentials directly from the InnovatorServerConfig.xml works well. But I am unsure what´s the best way to handle passwords. I use encrypted passwords in the ServerConfig created with pwcrypt tool. The current code only works with unencrypted passwords. Also the pwcrypt encryption is not very strong, therefore we don´t loose anything when we don´t use it. The main benefit with the XML approach is clearly, that you can use one place for storing all passwords. This is much easier to maintain then spreading passwords through Variables and Methods. Also I am not sure what the best way to retrieve the password. I made some test with SecureStrings, but I don´t think that my current approach is really secure (see notes in code). Any ideas welcomed!

[AngelaIp]

Some remarks: SeucreString requires some additonal dll definition in the method_config. This is not mentioned in my current descripton. Perhaps I'll take the SecureString part out of the code again. SecureString seems to be intended to handle client login data. So I am not sure if in my case this few lines of code will bring any benefit at all. I think for normal purpose the current sample is already quite ok. The password question is more a question of personal interest. I want to use achive the best possible option for handling credentials to avoid any unexpected and unnecessary trouble in the future. One of my other jobs is writing risk analyzes, so it´s part of my job to be paranoid. :-)

[EliJDonahue]

I just realized that this is your project, @AngelaIp, and not an Aras Labs project. Pardon my suggestion that you submit a pull request to your own repo. 😆

[AngelaIp]

:sweat_smile: No Problem! I noticed the small contradiction, but as I used your readme template, it´s probably not so easy to differentiate the projects at first glance. I don´t wait half a year for a solution to this question for not updating the project. So your main intention wasn´t wrong at all.

I submitted a pull request to my own project, as I still need a few days to think through the SecureString part. It´s more some kind of marker for myself.