Office365 - Mail Boolean Variables Missing and not supporting Secure String

Hi UiPath,

Been a while, so i hope i post in the correct sub category :slight_smile:
As you can see below we are missing the option to add variables to booleans in Get Mail activity, this is also true for some of the other activities. Can we please have an update where this is added?

I’m currently in a situation where it is needed.

Also the O365 scope, if using username and password, does not support Secure String in password. So if you use the Get Credentials from orchestrator, you can’t use the password from that activity. I’ve had to create my own library that use the Get Credential and then converts and outputs it to two variables as plain text.

This is also true for a whole bunch of your activies, they do not support Secure String in their password fields, can’t mention them all because i don’t remember them, but i come across them from time to time, might be a great idea to check all your activities and update them so they work without a problem with a basic activity like Get Credentials?

image

-Rasmus

Thank you for your feedback.

As far as SecureString, there was recently this post by @AndrewHall where he explains the situation a little bit:

3 Likes

@loginerror good read indeed.

I’ve never personally seen Secure String as a security measure as it’s easy to get around, I’ve seen it as a nuisance that i have to build a library for and use to retrieve credentials to be able to use the login in activities where Secure String is not supported.

Please update the Get Credentials to have a boolean ‘Get Password As Secure String’ that we can tick true/false, because some activities need the secure string while others don’t support it. It would make the integration of Get Credentials way better, all it has to do is what i’ve uploaded if it’s set to false.
Get Credential.xaml (6.4 KB)

In my opinion there should be a balance between ease of use and the potential security risk, be the server memory dump, and the way the end users, us, use this activity. We should have the option to use secure string where possible, but not use it where it is not possible, without going through hoops to make it work.

To be honest, with that solution, i think it will stop the, “how do i get XYZ to work with secure string” as people just can tick it off. And every time it gets ticked on/off it should make a check if there is a variable defined and if it’s the right data type, like it does in all other activities :slight_smile:

3 Likes

The suggestion for the option for how to store is an interesting one. However, anything that is stored as a SecureString can be converted to string with a single line of code, and if you prefer you can even do this directly when passing the argument. For e.g. to convert SecureString a variable named “secureStringPassword” stored as SecureString to a string use this line of code either in an Assign activity or just as the the value supplied to the property requesting the password as a string:
new System.Net.NetworkCredential(string.Empty, secureStringPassword).Password

I agree that it is easy to get around, but it is still time spend, as I wrote I created a small library so i have easy access to this functionality every time I need it without having to remember som obscure text or go back to my notes. But since it’s possible to add it to the activity, why not make it easy on the end user, since you already know end users have this issue (look at your forum). People do the assign anyway because it is needed, it’s that simple, there is no way around it, so why not just add it in and throw a description on it stating that users should read the wiki for the full understanding of this function and copy that post over you made, explaining the it?

It would make the every day use of the ‘Get Credentials’ work without any issues and you keep support for activities that need secure text. Instead of going through hoops we would have easy use.

Also looking at the time aspect for the end user compared to how much time a developer at UiPath would have to spend upgrading it, I can only say that having one or more developer add it in, versus 1000 or 10000 end users, if not more, forced to do the assign/library every time they need credentials for an activity that doesn’t support Secure String, which is quite often in my experience, makes a lot more sense.

1 Like