Special Character Limitation in Global Send Keys

[naveed_raza]

Hi All,

These days , password characters and length, specially password characters has lot of special characters.

We have an automation in place it was running fine from last 4 years, however all of sudden its started giving an issue , we are using Global Send Keys to enter credential as those textboxes is not accepting via normal Write stage.

Global Send Keys its not entering all the characters properly and we thought of adding Interval however we are getting an error as "When we specify Interval then few special characters will not work", this is weird.

as an alternative , we are planning to go with Copy and Paste functionality, however want to know about this limitation and in some cases we have to go with Global Send Keys only.

How we can make this step more reliable and what is the best practice here ? or we have to post this in Product Idea or not to make that Global Send Keys allow all special characters ?
@Michael_S  

[naveed_raza]

And also, is there any way to read password what bot has entered in textbox ?

just verify whether bot is entered correctly or not as we are not using write stage to enter the password , we are using either Global Send Keys or copy clipboard functionality.

@david.I.Moris - need your suggestion here

[naveed_raza]

Here in my organization i checked with other RPA teams and everyone is facing the same issue , everyone is updating the code now to use copy clipboard as send keys is not entering all characters (including special characters).

we are in blackout days , for this we are opening emergency CIRT call for PROD deployment

[naveed_raza]

just for information to All,

for immediate resolution , we requested RPA COE team here to update the password with plain text without special characters in CyberArk.

These number of special characters is giving an issue in blue prism send keys

{

}

+

^

%

~

[

]

(

)

[steven.boggs]

Hi Naveed,

The Global Send Keys action in Blue Prism internally uses the Microsoft System.Windows.Forms.SendKeys class so characters like braces or parentheses must be escaped. The scenario you describe can also occur if there are some local decoding issues between the host (your Blue Prism resource machine) and the target machine and application. Use of some international keyboards can also yield unpredictable results.

We have a few Knowledge Base articles on this topic with specific suggestions for how to work around this limitation of the Microsoft code class in the article, "Why do some characters not get sent to my target application when using Send Keys?".

Another known workaround is to copy the special (or multi-byte) characters to the clipboard using the "Set Clipboard" action in the "Utility - Environment" VBO, then send "^v" to the target application using Global Send Keys. (Source KB)

You could also try using Global Send Key Events to see if it helps as it uses a different method: "What is the technical difference between Global Send Keys and Global Send Key Events?"

The Global Send Keys and Global Send Key Events actions in Blue Prism use the available Windows O/S methods, so this is not something specially coded by Blue Prism and wouldn't necessarily benefit from a feature enhancement change in BPE.

[VanamalaSrinivas]

Am not sure if there is a way to read and verify the password entered by Blue Prism is correct or not as they are masked. But via debug mode in prod run time resource, you can inspect the password field and modify the input type from 'password' to 'text' to view what bot is entering the password.
Before: 
After: 

[naveed_raza]

we can't read value what entered in password textbox , i tried many times.

what i am doing is currently , using clipboard , and verify clipboard has correct value copied or not.

I am not sure, if we can add this to enhancement list with blue prism or not.

[naveed_raza]

thank you so much steven , what i observe is , whatever special character list i have shared that is reserved keyword in blue prism (Example: ^ , this symbol uses for control key) and when we have this symbol in password its not accepting, and if want send keys to enter correctly then we have pass text like this {^}, then send keys will enter ^ this symbol.

post our CRP , will update our code to utilize Clipboard functionality , for now we asked our RPA COE team to update the password without above mentioned special characters, they have updated and we tested our automation and its working fine.

this special characters impacted in all teams here (we have different units (around 10 units) and each units have their own RPA Team)

[naveed_raza]

Solution what i suggest here is , if we have above mentioned special characters in text then go with clipboard functionality else we can go with global send keys

we implemented clipboard functionality in our DEV environment and tested successfully

- Set Clipboard value

- activate browser

- focus on the textbox element

- control A

- control V

all these steps in one navigate stage

[david.l.morris]

As Steve said, the best way to handle this is with pasting the password into the field, as you've found and determined already. Note that these days, I recommend just never using send keys to enter text into a text field any time ever. There are some apps that may require you to do it because of how it triggers events, but I now ALWAYS do set clipboard > activate > focus/click the element > ctrl+a > ctrl+v > clear clipboard.

After you paste the password, be sure that you always include clearing the clipboard so that the password is not inadvertently used somewhere else.

As for reading the password after entering into a textbox such as in a desktop app or web app, I would imagine that is not possible. I assume you're talking about reading a password from a textbox in an app anyway. There's no way to do that, and any app where it is possible is a poorly-designed app.

One other validation that I sometimes add though is to verify whether the password was put in successfully at all. This is very situation dependent so I can't say this will work in all scenarios. For example, let's say that the app lets you try to copy the password but it returns asterisks (******) instead of the underlying password. In that case, you could verify that there are no asterisks before you entered the password and that there are asterisks after you pasted the password. You could even consider counting the number of asterisks. Depending on the app, you may be able to use a Read stage or do a click > ctrl+a > ctrl+c > get clipboard and put into a data item.

The last thing I'd say is we always need to design logic that checks to see if a login failed or not. That means when developing, we need to reproduce a failed login, spy the error message that shows up (whether in page or in a popup) and then use logic to check for that error message and include the error in an exception detail if it shows up.