Start a new topic

Auto-fill use very limited

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 Ricardo,


thank you for your question and feedback.


The short answer to your question: yes, we are constantly improving our products - including the auto fill feature!


As you may know, we are currently working on our next major release and we have some improvements on our roadmap here as well (although not yet in the beta!).


Let me comment to some of your statements:

  • There's already support for delay in both, auto fill and key sequence tasks.
  • If possible, always try to configure the URL which ends up after the redirect to avoid timing and delay related issues.
  • When using key sequence tasks, there's always the risk that a password can be exposed when the input focus changes. We may be able to prevent that in the future.
  • You mentioned other products with EO web view. I can't really tell what version of the component they are using but I know that in recent versions there are issues with keyboard input. You can check their support forums and in particular the tickets I opened over there. We always try to keep using the latest release to get the latest Chromium engine with all the security patches.
  • We also do support "selectors" in auto fill to specify HTML elements explicitly. For more information check out this KB: https://www.royalapps.com/go/kb-all-web-autofill
  • To specify password HTML elements, you can additionally include the [type="password"] selector to ensure it doesn't end up in a different type of field: https://api.jquery.com/password-selector/ 

In general, I recommend to simply open a support ticket should you have an issue with one of the above, so that we can investigate. We are always happy to help.


Regards,
Stefan


1 person likes this

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 Ricardo,


to be honest, some of your examples aren't very clear and it's also hard to discuss multiple different things in one conversation/thread. I suggest the following:

* if you have a specific issue with a feature, please open a support ticket and provide as much details, samples, screenshots, etc. as possible.

* if you miss a feature, please use the Idea forum and post a feature request there. This makes it easier to discuss, track and notify participants. It also allows us to get a sense how "popular" a feature is when others chime in and vote features up.


I think this is the best and most efficient way to get fixes and features into Royal TS.


cheers,

Stefan

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






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.


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.

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.

Hi Ricardo,


this is Felix. I'm responsible for the auto fill feature here at Royal Apps.


First, we have great auto fill improvements planned for the next major versions of Royal TS/X! Our plan is to have a new "magic" auto fill mode which doesn't require any configuration or mapping for the most common cases. This hasn't been implemented yet and we can't yet promise that it will ship in the first stable release or be part of a later point release.


We also plan to add support for multi-step login forms. Those are slowly becoming the norm so please rest assured, it's an important feature for us.


Another improvement, which is already part of the current beta releases of Royal TS (for Windows) and Royal TSX (for macOS) is that we simulate the "input" and "change" DOM events when filling fields. This should help for those cases you mentioned where a login button is only enabled after "seeing" input in the username/password fields. I invite you to try out the beta(s) and see if this change helps you automate login for the VMware Horizon View you mentioned.


I'm reluctant to add another mode (custom JavaScript) because of various reasons. First, I don't think it's necessary because the auto fill feature has a very specific goal: To be able to fill HTML DOM elements with content and press a button. The existing mapping mechanism and the new planned "magic" auto fill mode should be enough to achieve that goal in combination with some improvements like the ones I already mentioned.

Another reason is that this mode wouldn't play well with our Royal Passwords browser extensions. Right now, the script that's injected into websites to automate login is shared between Royal TS/X and Royal Passwords. If this new custom JavaScript mode is introduced, we would have to somehow separate the two scripts and this obviously complicates things. Allowing arbitrary JavaScript in auto fill configurations also has security implications which have to carefully be evaluated before shipping this to customers.

So to sum up, while I see the potential upsides of custom auto fill JS in advanced scenarios, I don't think the benefits outweigh the disadvantages and work required to support this. Also, it's really a niche feature which 99% of our customers probably would never use.


Hope that clarifies our thinking and our plans.


cheers,

felix 

Hi Felix,


Thanks for your in depth explanation.

Looking forward to the next version.


Thanks.

Hi Ricardo,


you're welcome!


If it wasn't clear from my previous reply, the betas are already available and at least the the input simulation enhancements are already included and can be tested.

Here are the links to the respective download pages again:

Royal TS (for Windows) V6 Beta: https://www.royalapps.com/ts/win/features-beta

Royal TSX (for macOS) V5 Beta: https://www.royalapps.com/ts/mac/features-beta


Hope that helps!


cheers,

felix

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





Hi Ricardo,


do you happen to have a website that shows this behavior that is publicly available?

This is important so that we can try to reproduce this ourselves to see why it's failing.


thx,

felix

Login or Signup to post a comment