Features in Orchestrator: More types of assets, Access control, Log control

Help
1

Hello all

I’ve been looking at the features of the Orchestrator, but do not have access to it yet. The basic toturial video is my main source of information.
I’ve have a few questions that I can’t find the answer to.
If thise questions have been answered somewhere else, I would be very happy to be linked to the location :slight_smile:

In assets it looks like you can “only” make Text, INT, Bool and Credentials as types.

  1. It is true that you cannot store other types that UIPath normaly supports? (say… Generics, Objects, Chars or something completely diffrent?)
  2. If not, is this being considdered for the future?

Log Message in Studio is seperated into 5 categories, along with a message.

  1. Is all thise logs available to view on command from the Orchestrator?
    Like if a robot succeded with errors that has been specified with <log message: Error “Message”>, can i see the Message from the orchestrator?

Roles and credentials:

  1. Is it possible for a non-uipath programmer to get a custom made role and access the orchstator, to type in a password that only that user knows, and noone else can see (even not admins), but still can be used in workflows made by other users?

Example:
Login to site requires password. User provides credentials through the Orchestra, I make the workflow that login to site and run it using the users credentials, but I do not have access to see the user password.

Any help on thise topics will be highly appritiated!
Thank you for your time!

2

First off, you can now follow the more official training, along with practice assignments and demo Orchestrator access, at the Academy:

If you are using the (non-Community) trial version, you should also be able to connect your robot to the demo and try out the remote command options.

Yes.

I don’t know. I am not one of the developers, so if you have specific ideas you could try asking them in the #ideas category. Also, note that the Text, Int and Bool assets are only stored as such by Orchestrator; they all translate into a GenericValue when retrieved in a workflow, while a Credential results in String (username) and SecureString (password) variables.

You can only currently store UiPath’s .NET types by including them in the ItemInformation property of a QueueItem when submitting it to a queue. The robot that later processes this item can read them back for use in the workflow it’s executing.

Yes, provided the robot’s logging level is set appropriately. By default I think a robot will log messages of the lnformation level and above.

Yes, you can create custom roles for users with asset creation permissions. User passwords cannot be read from the Orchestrator, but not theoretically by no one at all, because the Type Secure Text activity can technically be used to write into any text area.

1 Like
3

Thank you much @sfranzen !
Really appreciate the help!

I guess it mostly was as expected, however I’m really surprised that you can write a secure stings out.
Doesn’t password fields normally have an identifier that UI path can use so that it’s only possible to write into password fields?
From a security standpoint, the credential manager is completely useless :cry:

4

I’m not sure whether this is an issue that can be easily overcome. After all, human users have to type their actual, unencrypted password string into a field that just masks the characters for them. Unfortunately this masking adds only weak security, and there is no universal way of identifying such fields across applications.

5

True, it might be hard to do something about from UIPath’s side. I guess it’s up to windows and the applications to find a standard, that then UIPath can use.

Thank you for the help :slight_smile:

6

I think in the end the situation is similar to other (web) applications that handle private information. To some extent you have to trust their developers to avoid things like storing passwords in clear text, accessing people’s account details, posting them to Twitter or other serious security breaches, even though they could just obtain user passwords from the input box.

So, you will have to trust your developers with this, though if at all possible I would prefer having a separate account at this website for use by the robot(s), as I think you are rightly cautious about having a robot impersonate a human user. There are other issues with this, like failing the password prompt and locking everyone out of the account, the particular application not allowing simultaneous logins, etc., that are also avoided this way.

7

Indeed you are correct. We consider using new accounts for the robot whenever possible as best practice.
The problem is that sometime you WANT to the robot to imposonate the user (Like going into pupblic systems), and then you have the problem.

We are probally gonna use a workaround and let the user type the password at the start of the run, but this option wont work for unattended runs.

I guess I have to battle our security team and get them to accept that a few of us can get access to user passwords. :frowning:

8

can we update the assest value through studio ?

9

@TharmaKS I think what you are asking for is in topic: Activities to interact with Orchestrator

10