What is the best practice for making a ‘login’ within a library?
Use Case Description
Hi, I learned to use libraries according to an official course at this link: https://academy.uipath.com/courses/working-with-orchestrator-resources-v2022.10
There I learned how to create a login that requires 2 arguments:
A String for username.
A SecureString for password.
But when I do this I get an error that it is not the best practice to do it.
The question is what is the right practice?
All I found on the subject is how to bypass this, I want to know what is the right way.
I would appreciate your help (:
AS-IS WORKFLOW, TO-BE WORKFLOW
-
Other information about the use case
Industry categories for this use case: Finance
Skill level required: Beginners
UiPath Products that were used: UiPath Studio
Other applications that were used: -
Other resources: -
What is the top ROI driver for this use case?: Accelerate growth and operational efficiency
So I assume the feedback comes from the workflow analyzer rule related to Secure Strings.
I’ll be frank, its a crap rule, and it just encourages people to do worse things in my opinion.
Let me break down the concern raised by the rule.
A secure string is not fully secure, and the longer it is in memory the longer the secured data might be at risk. As such its encouraged to keep the scope of them as small as possible and I believe this rule is intended to encourage that.
The bad thing is, it results in things like modifications to the REFramework where people are taught (badly) to pass around a dictionary<string, securestring> to manage credentials. This wont trigger the rule, but it does have the exact same risk the rule warns against and infact is even worse because it makes their scope huge.
Passing a secure string to a library login workflow is very low risk, and functionally its no or less risk that passing a secure string to a Secure Type Into activity (which is also a library activity).
If its acceptable to use secure strings on arguments for library activities made by UiPath, it should be acceptable to use them in library actions made by us.
TLDR, ignore that dumb rule, the workflow analyzer is often more trouble than its worth and I wish it could be ignored as it frequently throws false positives about fake compile issues preventing me from actually compiling (which the code can compile, command line works).