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:
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.
Thanks for your answers.
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)
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.
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".
# 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.
# 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.
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.
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.
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.
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.
Thanks for your in depth explanation.
Looking forward to the next version.
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!
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.
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.
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.
Is there any plan to improve this?