I’ve been frustrated by the strange behaviour of the AWS website sign-in page for a number of years now but earlier attempts to understand why Kee is sometimes unable to fill and submit the sign-in form have led nowhere. I have spent today delving deep into the problem and am reporting the results of that investigation here, partly so that I can reference them in future and partly because I know others (e.g. @Megamind, @neshanjo) have struggled with this website too. There’s no complete fix described below but nevertheless it might prove an interesting read for technical users.
-
The page fails to use good practice and follow agreed standards for building forms (e.g. it doesn’t even include a form element so every loose form field on the page has to be bundled into one fake form by Kee).
-
This fake form thus has many form fields and thus the automatic form filling feature can’t work because such a large number of fields is most likely to be something other than a sign-in form and Kee must therefore ignore it. Using an entry with zero form field configuration - just a plain username and password - was one way to workaround this problem since most of the remaining form fields are considered weak matches to the fields in the entry and thus Kee can assume it’s a good enough match to fill. However, this was due to a flaw with the form field match ratio calculation algorithm and therefore this workaround will no longer be possible in Kee 3.6+. Additionally, AWS could re-arrange the fields on their sign-in page in such a way that the wrong field is selected by Kee.
-
The submit button that Kee detects is the correct one for the submission of the completed form (“Sign in”) but there is an intermediate button that must be clicked first as part of a multi-stage sign-in process. Since Kee can’t know this and clicks on the “Sign in” button too early, a mysterious red error box appears at the top of the page and you are required to manually click on that “Next” button. Using the recent feature to allow individual submit preferences on entries to override the manual submit preference is a good way to avoid this red box appearing but apart from shifting the page contents around a bit, there appears to be no detrimental effect when it does appear.
-
Although Kee correctly fills the email address and password into the two correct fields (assuming you don’t have the IDs, etc. misconfigured in your entry), the site clears the value within the password box when you click on the “Next” button.
-
We only put a Kee icon into the top 2 fields of any form. The password field is further down the list of fields so never gets the icon added.
-
The search for matching entries is not triggered when the password field is revealed because it does not meet any existing criteria for automatically searching for matched entries (i.e. there is no page load and the contents of the page is not actually changed - as far as Kee is concerned it already did everything it needed to and the fact that the web page has decided to delete the filled information can’t be anticipated or worked around). To fill the password again, either use the matched entries listed in the main Kee popup, use the matched entries keyboard shortcut, the context menu or trigger a re-scan of matching entries by using the keyboard shortcut to add the Kee icon to the form field (since the earlier email address field is no longer deemed a higher priority than this password field).
All of the above can be further complicated by cookies/local state which the page can use to remember various parts of the sign-in information and change behaviour based upon some proprietary algorithm. So, for example, changing accounts or signing in after clearing cookies never works in one step but sometimes you can re-sign-in to the same account without needing to enter your password in the 2nd stage (assuming you get Kee to click on the normally hidden “Sign in” button).
There are a whole load of possible approaches we could take to allow a Kee user to manually work around those earlier limitations but the only one that obviously comes with significant wider benefits beyond just this single badly behaved website is improved support for multi-stage sign-in. I’m not sure if it will be possible to implement that in such a way that the single large form can be split into smaller “stages” but I think we should attempt that before looking into more complex hacks like adjusting the Kee icon limit for specific sites or allowing for custom submit handler selection routines for specific sites, match ratio threshold adjustment per site, etc. That said, if anyone wants to focus on those more specific improvements, it’s likely I would accept a pull request - just discuss your idea here first though so we can iron out any rough edges that might affect usability or performance.