Hello RevaTarale - can I ask what the use case for this is? What is there is an issue during the credential injection phase, how would the user interact with anyt error messages?

Just curious what the reason or concern is here we are trying to solve?

Hello PhillC,

I have integrated a web application with PS-Automate. I use remote app mode to launch my application through the MS Edge browser. The issue and concert we have is when we are launching a session, it injects the credentials of the user automatically. There is a little bit of delay between username and password. So let's say a username is injected, and when it comes to putting a password, the user can click during the automated password injection. If I interrupt the session and click on the tab of username, it puts the password over there aromatically. That password is visible in plain text. So, my concern is that when we are trying user credential injection through a script, the end user should not be able to interrupt that flow in the middle till it takes a successful sign-in.

Please let me know if there is anything we can do to avoid this interruption.

@RevaTarale Are you using XPathElements in your INI files? I ask because I am unable to replicate what you mention when using XPathElements to target Username & Password input boxes. Regardless of where I’m clicking, the XPathElement is consistently targeted for the injection. 

Here is our KB on using XPaths: https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0019664

@Neil Yes, I am using XPathElements in ini files. Even if I give XPathElements, it allows me to interrupt the session with clicks. Here again, I have the issue that my login key doesn’t work with this script. I have another format that works with credentials injection and login as well, but again, allow me to interrupt with a click.

Find the format below.

Here, INIformat1: Works properly but allows to interrupt with the click.

EnableLogging=0
LogMethod=1
KioskMode=1
RunApp=C:\Program Files (x86)\Microsoft\Edge\msedge.exe -inprivate "target URL"

GlobalSequenceDelay=5000

>TaskSequence1]

AppWindowTitle=” Privacy Error”
SendKeys={TAB}{TAB}{TAB}{ENTER}{TAB}{ENTER}

�TaskSequence2]
FormByID="XpathValue"
ObjectByName="username"
ObjectData=%username%
SendKeys=%username%

>TaskSequence3]
SendKeys={TAB}

pTaskSequence4]
FormByID="XpathValue"
ObjectByName="password"
ObjectData=%password%
SendKeys=%password%

SendKeys={ENTER}

INIformat2: Login doesn’t work and allows to interrupt with the click.

/General]
EnableLogging=0
LogMethod=1
KioskMode=1
RunApp=C:\Program Files (x86)\Microsoft\Edge\msedge.exe -inprivate "target URL"

GlobalSequenceDelay=5000

AppWindowTitle=” Privacy Error”
SendKeys={TAB}{TAB}{TAB}{ENTER}{TAB}{ENTER}

NTaskSequence2]
XPathElement="copied full path"
XPathValue=%username%
SendKeys=%username%

rTaskSequence3]
SendKeys={TAB}

sTaskSequence4]
XPathElement="copied full path"
XPathValue=%password%
SendKeys=%password%

aTaskSequence5]
XPathElement="copied full path"
SendKeys={ENTER}

Please let me know if there is anything I missed in this script.

@RevaTarale Thank you for sharing the above information.

Without having the actual script & target URL it will be difficult to replicate on my end, but I can speak to a couple points at a high level.

0.) General settings (using BrowserName & TargetURL instead of RunApp):

BrowserName=%browsername%
TargetURL=%targeturl%
GlobalSequenceDelay=2000

1.) Getting past your Privacy error (Task Sequence 1):

>TaskSequence1]
XPathElement="//*"@id="details-button"]"
XPathAction="click"
WaitLoginWindowDelay=2000
 

pTaskSequence2]
XPathElement="//*=@id="proceed-link"]"
XPathAction="click"
WaitLoginWindowDelay=10000

2.) Username input:

tTaskSequence3]
XPathElement="//input/@name='username']"
XPathValue=%username%
WaitLoginWindowDelay=2000

3.) Password input:

oTaskSequence4]
XPathElement="//input/@name='password']"
XPathValue=%password%
WaitLoginWindowDelay=2000

4.) Login click:

uTaskSequence5]
XPathElement="//ui-button-with-progress-barr@class='login']"
XPathAction="click"
WaitLoginWindowDelay=2000

Key notes:

1. Instead of using RunApp, I’m leveraging the built-in BrowserName & TargetURL parameters and passing these through Password Safe. If run locally, the parameters might look like this: “ps_automate.exe ini=BIWebApp.ini BrowserName=chrome TargetUrl="https://<URL>" Username=test Password=hunter2”
2. The goal with this approach is to use WebApp task sequences only: Define Command Line Arguments for PS_Automate Utility
3. I’m taking a different approach to get past the Privacy Error page. I find this approach to be a bit more resilient as user input should not interrupt the process.
4. In my example, I’m using only “XPathElement” and “XPathValue” as a means to directly target elements on the webpage and inject appropriate values, even for my click actions. This is the piece that should ensure you cannot click elsewhere to expose a password. To find the specific XPathElement, right click in the target input box and Inspect it. From the developer tools, you should be able to copy the XPathElement directly. KB0019664 has more information on this.

@Neil Thank you so much for your response. I have taken note of your points.

When you said, “This is the piece that should ensure you cannot click elsewhere to expose a password,”

This is exactly the concern of our client. Even if we suggested they educate end users not to interrupt during this automated sign-in process. We cannot control the curiosity of end users to interrupt in between. And we absolutely agree with the concern they have about password exposure. This is causing the risk in the application session.

There might be a way to avoid this risk. If anyone has an idea about this, please let me know how we can deal with it.