Royal Apps

Hi,

Royal TS auto-fill is way too limited to be useful. Most of the sites I try do not work either because they need some delay for credentials to be entered, or they need some javascript command to be issued, or they have dynamic fields, or they redirect to another page, etc.

Some examples: Commware web interface, all Aruba web interfaces, Airwatch, VMware Horizon, Commvault, VMware Vsphere Client. 

Also, nothing prevents passwords for only being entered on "password" fields. I already say multiple instances where the password were shown in clear in some other UI part because I just clicked outside of the browser.

Same problems happen with Key Sequences, because they do not validate where they are being entered.

Alternative software (ex.: Devolutions RDM), also relying on EO Webview, work perfectly. Not only do they ensure text is only entered into the correct fields, they also support a auto-fill delay, allow to enter custom javascripts to fill the forms, enforce password into password fields, and even fill login info even if the login page was redirecting to another page.

Is there any plan to improve this?

Thanks

Hi Stefan,

Thanks for your answers.

I'm aware of some of those suggestions, but somehow I get a very low success with auto-fill comparing to similar products. What seems to be missing most is a way to use a custom javascript to autofill, and also make Royal TS wait for the fields to be present and only afterwards fill them. 

I also tried the "type=password" but there are cases when, if the focus changes in any way to a regular field, Royal TS seems to auto-fill the text there in clear.

Another problem with auto-fill is with "su/sudo" scenarios. With RDM I am able to run "su" as soon as I connect, but _ONLY_ when it's required. I can set what string it should see for the command to be sent. Royal TS sends it blindly.

This causes issues when I use "screen" or "byobu". A short example:

- I connect to a server running screen/sudo and Royal TS blindly sends "su" and "password"

- I disconnect

- I reconnect later. Because of Byobu, the shell will pick up where it was before. So, I will be already "sudoed".

- Royal TS will blindly issue "su", but because I'm already root no password prompt will be required. But as Royal TS is not aware of that, it will enter the password in clear at the prompt.

- Now, not only was the password printed in clear, it is now also stored into history

A fix would be to make Royal TS wait for password prompt to send the password. And wait for the "non root" prompt to do su. This is what I do with RDM and it never fails.

Are you also looking for this kind of functionality with Royal TS 6?

(I'm sorry for referring other products but while I do prefer Royal TS for it's speed and UI sleekness, the lack of this functionality really hampers my productivity)

Thanks

Hi,

I can try to explain some scenarios:

# VMware Airwatch page

To login a user must do the following:

- Enter username at the username field

- Then click next

- Then the password field will show; User enters password and clicks login.

Will not work with Royal TS "auto-fill".

Other tools allow me to enter a custom javascript that is injected at the page. The script will enter the username in the HTML DOM, then call the "next" function, than enters the password and submits.

# VMware Horizon View

- The login button is disabled to begin with

- User enters username, then password. Only after that does thje "login" gets enabled to be clicked.

Will not work with Royal TS "auto-fill". Royal TS will fill the username and password, but the login button will stay disabled because it expects a keypress on the fields.

Other tools allow me to enter a custom javascript. Inside the javascript I just remove the button "disabled" attribute and "click" it

# Ubuntu with Byobu + SSH

- Byobu (ot TMUX, or Screen) makes the session persistent. So, if I disconnect from SSH and reconnect back, I will pick the session where it was before

- So say I set Royal TS to issue a key sequence with su  + password everytime I login.

- I login the first time, and Royal TS will play the sequence. Su => ubuntu asks for password => Royal TS enters the password. Now I'm root.

- If I reissue "su" I will not get any password prompt because I'm already root.

- Now I disconnect and reconnect.

- Because of Byobu I will already root (because it picks up the last session), but because Royal TS does not parse the prompts it will do "Su => ubuntu will not ask for password because I'm already root => Royal TS enters the password at the prompt". So now I have a terminal with a visible password. And because Royal TS clicks "enter" it is also saved into the linux history.

Other tools allow me to say something like WAITFORTEXT("password: ") , and only enter the input when they find the prompt.

Thanks

Hi again,

I had a quick look into EO and it look like the "custom autofill javascript" could be easily implemented with the EvalScript function.

https://www.essentialobjects.com/Products/WebBrowser/JavaScript.aspx

You would "find and replace" the $EffectiveUsername$ and $EffectivePassword$ inside the user provided script, and then issue the EvalScript. Maybe with some configurable delay.

You would then achieve an universal autofill.

Maybe even share some Javascripts already pre-built for some known applications from your Github repo.

I had a quick look into EO API, and the Javascript bit, for Autofill, seems to be easilly achievable by using the EvalScript() function:

https://www.essentialobjects.com/Products/WebBrowser/JavaScript.aspx

You just find-and-replace some username and password tokens inside the user provided script, and issue it with the EvalScript() function. Maybe with some configurable delay.

That would provide a universal way to handle mostly all the login forms and autofill scenarios. I'm pretty sure that's what the other guys are using, and maybe you are also using it as well for your internal autofill implementation. It's just a matter of allowing the user to enter a custom script.

(As an added feature, you could share some pre-built scripts for some popular applications from your github repo.)

As for the "byobu" problem, maybe you could look into REBEX scripting framework (ex.: scripting.WaitFor(ScriptEvent.Prompt, ScriptEvent.FromString("Xyz")) and add a WAITFOR("prompt") into the key sequences.

Maybe add an option for a custom autofill script, and then run it with EO EvalScript after a find-and-replace to change username and password tokens into real values.

Hi Felix,

Thanks for your in depth explanation.

Looking forward to the next version.

Thanks.

Hi Felix,

I already gave it a try but was not able to see any improvement on autofill.

The "simulate the "input" and "change" DOM events when filling fields" seems to not be working. I already tried multiple sites and the "login" buttons are still grayed after autofill. I have to do some keypress for them to become available.

Maybe one thing you could consider is to remove the "disabled" attribute from all the login buttons. As far as I can see, most of the buttons are clickable and work just by removing that attribute.

Thanks