This is a plugin to allow the AutoType functionality to work with browser URLs as well as window titles. It can match against the standard URL field on entries, or can have custom AutoType sequences set up to match against alternative URLs or URL patterns. Optionally, the User Name part of the sequence can be skipped when you invoke AutoType starting from a password entry box.
It can also set a hot key for creation of new entries from the current browser page.
Great work Alex, and fast too! You took something that CEPOPTb did a good job on, and made it even better. The Create Entry hotkey is very helpful, and I really like the idea of skipping usernames in password boxes, although it doesn't seem to be working correctly for me. (Chrome 27.0.1453.110) Is it inspecting the HTML for the input type?
For example, on Amazon.com my username is already in the field, so I skip to the password box and use the global autotype hotkey.
That's the HTML for the password box, but it still types the entire sequence of {USERNAME}{TAB}{PASSWORD}{ENTER}. I'm using The WebAutoType Plugin 3.1.0.0, and I do have the option checked for "Automatically skip user name for passwords."
Otherwise, it's serving me quite well so far, and I'm glad to be able to update to KeePass 2.22 :)
You should see about getting this added to the KeePass plugin page for more visibility.
Thanks you and CEPOPTb both for your hard work!
Last edit: Haxus 2013-06-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Chrome, by default, does not expose the accessibility information for the web page itself, so while we can still get the URL, we can't get anything else.
To enable accessibility from Chrome, start it with thes flag: --force-renderer-accessibility
Or, visit this url to turn it on from within Chrome: chrome://accessibility
Once it's turned on, the advanced features of WebAutoType should just start working.
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, looks promising . But when I hit the hot-key it starts up creating a new entry instead of taking the one for the url available in the keepass DB. What am I doing wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are talking about the hotkey defined in the WebAutoType settings, that hotkey is for creating a new entry. To auto-type, just use the standard KeePass AutoType hotkey.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's great, thank you. I'm pleased to be able to use KeePass without needing a browser extension, and will maintain this plugin to continue to do so.
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great job -- love it! I have a handful of sites which set the window title to something generic like "Login", so whenever I try to Auto-Type it makes me choose which of those I want. Now I can match them against a URL and Auto-Type will know which one to use without needing to prompt me. Very cool. Thanks for sharing!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
3.2 also improves the reliability of UIA field detection after a focus shift (such as after entering the master password), at the cost of introducing a maximum 1 second delay if the field with the focus when you trigger AutoType isn't an edit or password field of some sort (not just in a web browser, anywhere). This should rarely be the case, but if you experience it to be a detrimental change then let me know and I can take steps to improve it, or at worst, make it optional.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was having some issues with a few websites, but everything is working great again. The 1 second delay is worth it if it helps with compatibility. Thanks Alex. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is (again) for improving Chrome compatibility - this version should work with non-English versions of Chrome v29 and newer too.
I've also added a new optional function. In the options window, there is now a checkbox for "Show search for repeated autotype". If checked, this works such that if you hit your global auto type hotkey, but no match is found, then you can just repeat the hotkey and KeePass will show the search window, pre-populated with the URL of the page you are on, in case what you want to search for is part of that.
This can be helpful for when you are sure you have an entry for the page, but for some reason it just isn't matching the autotype (usual culprits for me are http vs. https, having forgotten to put the URL in at all, autotype disabled for the entry or group in question, or different TLD (.com, .co.uk, etc.)).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex
If you set up AutoType to type {HOME}+{END}{Username}{TAB}{HOME}+{END}{Password} then KeePass always clears the field before sending keystrokes. So, even if a Username field is pre-completed, you can still click in Username as KP will clear it before sending the Username.
As a consequence, you ALWAYS place the mouse in Username before pressing ctrl/alt/a.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the user could be assured that he was at the real Lloyds bank site, and not a spoof site like lloydsbank.co.uk/nasty_person.com/, it would give added security.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you need finer control over the matching URLs then you can use the Auto-Type tab of the edit entry window. Click the Add button and then in the Edit Auto-Type Item window click the URL button. You can then put the URL that you want to match into the box. Bear in mind that this must be an exact match, so if you want wildcard behaviour, you have to actually end it with a *.
First of all thank you very much for this useful plugin. I prefer it to using the default window title match in KeePass.
I do have a performance problem though: I have about 700 entries in KeePass and some of them have 2-5 URLs added, sometimes with wildcards. At times the auto-type feels slow compared to the built-in KeePass window title way, there's a ~2 sec. delay before it starts auto-typing. Is this related to the accessibility way of getting the URL from the browser or rather to the matching of URLs, as it probably has to go through all entries each time. Is there anything I can do to speed it up?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello TimK, I think the first thing to do is to pin down where the problem is.
Firstly, can you try creating a new test database, and just put one card in it? If the delay is due the number of cards, then auto-typing from the test database would be fast.
If it is still too slow even with the small test database, then the delay can't be the number of cards, so try adding two entries with the same URL, and then auto-typing again. This will let you see if the delay is in obtaining the URL from the browser (in which case it will occur before showing the selector window to pick the entry to auto-type) or in the auto-typing itself (in which case there will be a delay after you pick an entry to auto-type).
Finally, if the delay is determined to be in obtaining the URL, then please can you let me know which browser and version you are using? Getting the URL is necessarily slower than just getting the window title, as it has to go through accessibility interfaces, but it shouldn't be as much as 2 seconds.
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex - thank you very much for your prompt reply.
I tried exactly what you suggested above and here's my conclusion: it is slow to get the URL from the browser (Firefox). When there are 2 identical entries, it takes a bit of time to pop up the selection dialog, then once I select an entry the actual typing goes quickly.
Here's my setup and some observations:
- Firefox 25.0 running on Win7 Pro x64. I tried it on Chrome and IE and while there is some delay with those browsers too, it's not as bad as Firefox. I noticed Chrome is the fastest one to get to the selection dialog, then IE, then Chrome. These are with all the latest stable versions of these browsers as of today, all other OS updates applied. I'm just running MSE, no other security software that monitor various calls or interactions between apps and windows.
- The slower the computer is (I tried it on some underpowered laptop) the slower it is to get to the selection dialog. On a slow laptop it takes 4 sec. to get to the selection dialog.
- Unchecking "Use the URL field value for matching" is not enough to speed it up. I have to remove the WebAutoType plugin completely and then KeePass auto-type is almost instantaneous.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for getting back to me. Did you try the test with a smaller test database? I wasn't sure from your reply if you did.
In any case, there's another test that will give some more clues: if you go to WebAutoType Options and set a hot key for Create Entry from Web Page, then we can test the reading of the window information without performing the entry search.
Once you've got the hotkey set, go to Firefox and type some text into a textbox on a web page (like a Username field for log-on). With the cursor in that textbox, hit the new hotkey. KeePass should create a new entry, and populate it with the title of the page, the URL of the page, and the text of the textbox as the username. Could you let me know if it gets all three pieces of information, and if the delay is the same in bringing up the new entry?
Sorry about all this, but if I can't figure out exactly where the delay is, I won't know which bit needs fixing! On my machine, it's all instant...
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex - yes, my original test was with a fresh database with just 2 similar entries in it, nothing else.
I tried your "save entry" test. It does capture all the info correctly, but it is slow to pop up the KeePass window that asks to save the card. So it seems capturing the info from Firefox is slow.
I even tried a clean Firefox profile just in case any of my addons are at fault. It still slow, maybe it feels just ever so slightly faster than my regular profile or it might be just my imagination because the profile is "clean".
I will continue helping you investigate, if you need any other tests, please let me know. Meanwhile, do you think it is a good idea to remove WebAutoType and instead use a browser addon that always adds the full hostname to the window title so that I can do more reliable matching based on the KP built-in window title approach?
Last edit: TimK 2013-11-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex - one more issue with Chrome this time: I like to set the match URLs to always end with / for added security, e.g. https://example.com/ rather than simply https://example.com IE and Firefox seem to return the trailing / but Chrome does not. Is it possible for WebAutoType to always make it a rule for the simple URLs that have no path to enforce that the match is done using a trailing slash?
I don't want to have a match rule https://example.com* as that could possibly match something malicious such as https://example.com.hacker.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tim, thank you for the additional information. The fact that the Create Entry test captures all the information correctly does indicate that although UIA access is working (not timing out, for example), it is just working very slowly. That pins down the area of the problem quite precisely, unfortunately it's also something that I don't think I can fix. Unlike the Search case, the Create Entry case doesn't do any waiting, retrying or anything else under my control, it simply asks for UIA information in the most direct way possible.
I will do some research and see if I can discover any specific circumstances under which UIA might run slowly, but I'm not optimistic. If you are happy with using the browser add-on, that's up to you - I can certainly understand how a 4 second delay would be irritating enough to look for alternatives.
To answer your second question, I'm not sure that WebAutoType should be adding slashes, it's the sort of thing that's easy to get wrong in strange edge cases (and if there's one thing URLs have in abundance, it's strange edge cases). On the other hand, I do see where you're coming from, and having to set up an exact-match using a custom auto-type match for the entry would be a pain. I'll consider it for the next release.
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex - is there a way to contact you via email? I'm wondering if you could put together a very simple standalone test app that tries to read the URL and perhaps other info from the browser via UIA and logs the info and how long it took to get it. Or maybe WebAutoType already has such a debug mode.
I'd be curious to run it on a few machines and collect data across machines and across browsers. What do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex has been very helpful putting together a quick test. A big THANK YOU, you are a great developer!
Unfortunately it seems that grabbing the URL from the browsers via UIA is very slow on my machines, in one case over 3 sec. to get it from Firefox. We have no ideas what could be causing it and how it could be fixed.
Anyone else noticing any performance issues with WebAutoType?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a plugin to allow the AutoType functionality to work with browser URLs as well as window titles. It can match against the standard URL field on entries, or can have custom AutoType sequences set up to match against alternative URLs or URL patterns. Optionally, the User Name part of the sequence can be skipped when you invoke AutoType starting from a password entry box.
It can also set a hot key for creation of new entries from the current browser page.
Project page: http://sourceforge.net/projects/webautotype
Download: http://sourceforge.net/projects/webautotype/files/latest/download
Bug reports, questions and comments are welcome, as are suggestions for improvements.
Features
Credits:
This project is a continuation of CEPOPTb's original WebAutoType, made with his permission.
Great work Alex, and fast too! You took something that CEPOPTb did a good job on, and made it even better. The Create Entry hotkey is very helpful, and I really like the idea of skipping usernames in password boxes, although it doesn't seem to be working correctly for me. (Chrome 27.0.1453.110) Is it inspecting the HTML for the input type?
For example, on Amazon.com my username is already in the field, so I skip to the password box and use the global autotype hotkey.
That's the HTML for the password box, but it still types the entire sequence of {USERNAME}{TAB}{PASSWORD}{ENTER}. I'm using The WebAutoType Plugin 3.1.0.0, and I do have the option checked for "Automatically skip user name for passwords."
Otherwise, it's serving me quite well so far, and I'm glad to be able to update to KeePass 2.22 :)
You should see about getting this added to the KeePass plugin page for more visibility.
Thanks you and CEPOPTb both for your hard work!
Last edit: Haxus 2013-06-06
Thanks for the comments!
Chrome, by default, does not expose the accessibility information for the web page itself, so while we can still get the URL, we can't get anything else.
To enable accessibility from Chrome, start it with thes flag: --force-renderer-accessibility
Or, visit this url to turn it on from within Chrome: chrome://accessibility
Once it's turned on, the advanced features of WebAutoType should just start working.
Alex
Today I learned...
:)
Thanks Alex.
Hi, looks promising . But when I hit the hot-key it starts up creating a new entry instead of taking the one for the url available in the keepass DB. What am I doing wrong?
If you are talking about the hotkey defined in the WebAutoType settings, that hotkey is for creating a new entry. To auto-type, just use the standard KeePass AutoType hotkey.
Wonderful, thanks a lot!
I've updated the WebAutoType listing on the KeePass plugins page:
http://keepass.info/plugins.html#webautotype
Best regards,
Dominik
That's great, thank you. I'm pleased to be able to use KeePass without needing a browser extension, and will maintain this plugin to continue to do so.
Alex
Great job -- love it! I have a handful of sites which set the window title to something generic like "Login", so whenever I try to Auto-Type it makes me choose which of those I want. Now I can match them against a URL and Auto-Type will know which one to use without needing to prompt me. Very cool. Thanks for sharing!
Chrome v29 made some changes which broke compatibility when accessibility is not turned on.
If you're using Chrome and noticed WebAutoType stopped working, then please update to v3.2 from the usual download link: http://sourceforge.net/projects/webautotype/files/latest/download
3.2 also improves the reliability of UIA field detection after a focus shift (such as after entering the master password), at the cost of introducing a maximum 1 second delay if the field with the focus when you trigger AutoType isn't an edit or password field of some sort (not just in a web browser, anywhere). This should rarely be the case, but if you experience it to be a detrimental change then let me know and I can take steps to improve it, or at worst, make it optional.
I was having some issues with a few websites, but everything is working great again. The 1 second delay is worth it if it helps with compatibility. Thanks Alex. :)
WebAutoType 3.3 is now available from the usual download link: https://sourceforge.net/projects/webautotype/files/latest/download
This is (again) for improving Chrome compatibility - this version should work with non-English versions of Chrome v29 and newer too.
I've also added a new optional function. In the options window, there is now a checkbox for "Show search for repeated autotype". If checked, this works such that if you hit your global auto type hotkey, but no match is found, then you can just repeat the hotkey and KeePass will show the search window, pre-populated with the URL of the page you are on, in case what you want to search for is part of that.
This can be helpful for when you are sure you have an entry for the page, but for some reason it just isn't matching the autotype (usual culprits for me are http vs. https, having forgotten to put the URL in at all, autotype disabled for the entry or group in question, or different TLD (.com, .co.uk, etc.)).
Alex
If you set up AutoType to type {HOME}+{END}{Username}{TAB}{HOME}+{END}{Password} then KeePass always clears the field before sending keystrokes. So, even if a Username field is pre-completed, you can still click in Username as KP will clear it before sending the Username.
As a consequence, you ALWAYS place the mouse in Username before pressing ctrl/alt/a.
Alex
Is there a way in which you could parse the web address so as to guarantee that the user was on the genuine web site, and not a spoof site?
For example, Lloyds bank in the UK starts out at http://www.lloydsbank.com/.
If you click on Logon, you get taken to the secure site https://online.lloydsbank.co.uk/personal/logon/login.jsp, where "lloydsbank.co.uk" cannot be spoofed (and is highlighted bold in Firefox address bar).
If you submit a correct ID and password you are taken to a secure site https://secure.lloydsbank.co.uk/personal/blah_blah_blah_etc, where the "secure" prefix is different from the previous "login" prefix.
If the user could be assured that he was at the real Lloyds bank site, and not a spoof site like lloydsbank.co.uk/nasty_person.com/, it would give added security.
Sorry, but I'm really not clear on what it is you are requesting here - it's possible that this is already the way it behaves, though.
If I set up an entry with the URL https://online.lloydsbank.co.uk/ then it won't match against https://online.lloydsbank.co.uk.nasty_person.com/ (presumably that's what you meant - as /nasty_person.com would imply that the URL was a page served under the real lloydsbank.co.uk domain).
If you need finer control over the matching URLs then you can use the Auto-Type tab of the edit entry window. Click the Add button and then in the Edit Auto-Type Item window click the URL button. You can then put the URL that you want to match into the box. Bear in mind that this must be an exact match, so if you want wildcard behaviour, you have to actually end it with a *.
For example, if you wanted the URL field to be http://www.lloydsbank.com/, but did not want autotype to be performed on sites starting with http://www.lloydsbank.com/ and only want it on the specific URL https://online.lloydsbank.co.uk/personal/logon/login.jsp then what you can do is go to the Auto-Type tab of the entry, override the default sequence to be blank, then add a custom sequence (not using default) for the https://online.lloydsbank.co.uk/personal/logon/login.jsp URL (it will appear in the list with a "??:URL:" prefix in the target window column, ignore that, it's just so that it knows it's supposed to be a URL and not a window title).
That way it would only ever auto-type into the page with that exact URL.
Alex
Last edit: AlexVallat 2013-10-18
First of all thank you very much for this useful plugin. I prefer it to using the default window title match in KeePass.
I do have a performance problem though: I have about 700 entries in KeePass and some of them have 2-5 URLs added, sometimes with wildcards. At times the auto-type feels slow compared to the built-in KeePass window title way, there's a ~2 sec. delay before it starts auto-typing. Is this related to the accessibility way of getting the URL from the browser or rather to the matching of URLs, as it probably has to go through all entries each time. Is there anything I can do to speed it up?
Hello TimK, I think the first thing to do is to pin down where the problem is.
Firstly, can you try creating a new test database, and just put one card in it? If the delay is due the number of cards, then auto-typing from the test database would be fast.
If it is still too slow even with the small test database, then the delay can't be the number of cards, so try adding two entries with the same URL, and then auto-typing again. This will let you see if the delay is in obtaining the URL from the browser (in which case it will occur before showing the selector window to pick the entry to auto-type) or in the auto-typing itself (in which case there will be a delay after you pick an entry to auto-type).
Finally, if the delay is determined to be in obtaining the URL, then please can you let me know which browser and version you are using? Getting the URL is necessarily slower than just getting the window title, as it has to go through accessibility interfaces, but it shouldn't be as much as 2 seconds.
Alex
Alex - thank you very much for your prompt reply.
I tried exactly what you suggested above and here's my conclusion: it is slow to get the URL from the browser (Firefox). When there are 2 identical entries, it takes a bit of time to pop up the selection dialog, then once I select an entry the actual typing goes quickly.
Here's my setup and some observations:
- Firefox 25.0 running on Win7 Pro x64. I tried it on Chrome and IE and while there is some delay with those browsers too, it's not as bad as Firefox. I noticed Chrome is the fastest one to get to the selection dialog, then IE, then Chrome. These are with all the latest stable versions of these browsers as of today, all other OS updates applied. I'm just running MSE, no other security software that monitor various calls or interactions between apps and windows.
- The slower the computer is (I tried it on some underpowered laptop) the slower it is to get to the selection dialog. On a slow laptop it takes 4 sec. to get to the selection dialog.
- Unchecking "Use the URL field value for matching" is not enough to speed it up. I have to remove the WebAutoType plugin completely and then KeePass auto-type is almost instantaneous.
Any ideas?
Hi Tim,
Thanks for getting back to me. Did you try the test with a smaller test database? I wasn't sure from your reply if you did.
In any case, there's another test that will give some more clues: if you go to WebAutoType Options and set a hot key for Create Entry from Web Page, then we can test the reading of the window information without performing the entry search.
Once you've got the hotkey set, go to Firefox and type some text into a textbox on a web page (like a Username field for log-on). With the cursor in that textbox, hit the new hotkey. KeePass should create a new entry, and populate it with the title of the page, the URL of the page, and the text of the textbox as the username. Could you let me know if it gets all three pieces of information, and if the delay is the same in bringing up the new entry?
Sorry about all this, but if I can't figure out exactly where the delay is, I won't know which bit needs fixing! On my machine, it's all instant...
Alex
Alex - yes, my original test was with a fresh database with just 2 similar entries in it, nothing else.
I tried your "save entry" test. It does capture all the info correctly, but it is slow to pop up the KeePass window that asks to save the card. So it seems capturing the info from Firefox is slow.
I even tried a clean Firefox profile just in case any of my addons are at fault. It still slow, maybe it feels just ever so slightly faster than my regular profile or it might be just my imagination because the profile is "clean".
I will continue helping you investigate, if you need any other tests, please let me know. Meanwhile, do you think it is a good idea to remove WebAutoType and instead use a browser addon that always adds the full hostname to the window title so that I can do more reliable matching based on the KP built-in window title approach?
Last edit: TimK 2013-11-05
Alex - one more issue with Chrome this time: I like to set the match URLs to always end with / for added security, e.g. https://example.com/ rather than simply https://example.com IE and Firefox seem to return the trailing / but Chrome does not. Is it possible for WebAutoType to always make it a rule for the simple URLs that have no path to enforce that the match is done using a trailing slash?
I don't want to have a match rule https://example.com* as that could possibly match something malicious such as https://example.com.hacker.com
Tim, thank you for the additional information. The fact that the Create Entry test captures all the information correctly does indicate that although UIA access is working (not timing out, for example), it is just working very slowly. That pins down the area of the problem quite precisely, unfortunately it's also something that I don't think I can fix. Unlike the Search case, the Create Entry case doesn't do any waiting, retrying or anything else under my control, it simply asks for UIA information in the most direct way possible.
I will do some research and see if I can discover any specific circumstances under which UIA might run slowly, but I'm not optimistic. If you are happy with using the browser add-on, that's up to you - I can certainly understand how a 4 second delay would be irritating enough to look for alternatives.
To answer your second question, I'm not sure that WebAutoType should be adding slashes, it's the sort of thing that's easy to get wrong in strange edge cases (and if there's one thing URLs have in abundance, it's strange edge cases). On the other hand, I do see where you're coming from, and having to set up an exact-match using a custom auto-type match for the entry would be a pain. I'll consider it for the next release.
Alex
Thank you Alex. Please play with URLs like https://example.com vs. https://example.com/ in Chrome, the problem will be obvious and annoying quickly :-)
It's strange that UIA depends on the machine. On an i7 quad-core it seems to be decent, but on slower i3 laptops the problem is evident.
Alex - is there a way to contact you via email? I'm wondering if you could put together a very simple standalone test app that tries to read the URL and perhaps other info from the browser via UIA and logs the info and how long it took to get it. Or maybe WebAutoType already has such a debug mode.
I'd be curious to run it on a few machines and collect data across machines and across browsers. What do you think?
Alex has been very helpful putting together a quick test. A big THANK YOU, you are a great developer!
Unfortunately it seems that grabbing the URL from the browsers via UIA is very slow on my machines, in one case over 3 sec. to get it from Firefox. We have no ideas what could be causing it and how it could be fixed.
Anyone else noticing any performance issues with WebAutoType?