Customize how KeeFox submits forms about keefox HOT 7 CLOSED

Imported from trac issue 21. Created by wilsonics on 2010-01-08T15:18:13, last modified: 2010-12-04T23:05:47

from keefox.

Trac comment by luckyrat on 2010-01-09 00:08:58:

Hi Matt,

Thanks for the description. I'm not sure which page has the form you refer to but it sounds similar to the form on [http://www.mindscape.co.nz/login.aspx?ReturnUrl=%2fDefault.aspx this Mindscape page]. That form (and the What's Up Gold website) use "ASP.NET forms" and one of the bad things about websites designed in this way is that they don't have "normal" forms and buttons. Microsoft do some clever things to make them look the same as normal website login forms but they don't conform to usual standards - normally it doesn't matter but KeeFox form-filling/submitting isn't exactly "normal" behaviour so things get complicated.

Are you saying that pressing the tab key submits the form on the What's Up Gold website? Are you able to send me the URL so I can take a look?

The features described in #13 and #19 should help to mitigate the problems with certain websites.

For completeness, there is some more technical information below but don't worry if you don't understand it - it'll be a useful reference for me in future and maybe other people would be interested too.

The problem with the Mindscape page is that the "button" you click is not really a button at all - it's just a picture you can click on. This means that KeeFox (and any other automatic form filler) can't submit the form, or rather it manages to submit the form but the clever proprietary Microsoft code never gets to do its thing and the resulting page does not work as expected.

This is the "button" on the Mindscape page:
{{{


}}}

I've been wondering if I can somehow look for patterns in links that surround images and execute the same "doPostBack" command. The main problem with that approach is that I'm not sure I can always find the correct link. It could be especially unreliable on pages with more than one form or forms with more than one "fake image button" (i.e. am I "clicking" on the "login" or "delete account" button?).

Even if I can find the login button on most pages, I'm then a bit worried about the performance of the search although I hope that even a particularly slow search will be acceptable because it will only happen on the rare occasions that KeeFox actually has to submit a form. I think all KeeFox "standard" form submissions will have to suffer the wait while we search for this type of form submission. Hopefully it will help with enough websites that it is a worthwhile delay...

from keefox.

Trac comment by boonebytes on 2010-01-16 14:48:20:

Just a heads-up: I'm a fair bit technical (and so is this post), but not so familiar with KeeFox.. I just started using it about about two hours ago actually :). Anyway, I had a brief look at the code, just enough to see how you're accessing your forms (specifically, I had a high-level look at KFILM_Fill.js)

!LuckyRay, you mentioned some concerns on the performance of the search... Would it be possible to do a type of high-level search to determine if the page is an ASP.NET page first? I understand that it may not always be so straightforward, but even running a "doc.getElementById('EVENTTARGET') (or EVENTARGUMENT / VIEWSTATE) might help to reduce the performance hit on any non-ASP.NET pages, right? I'm thinking if a page does not contain a key ASP.NET object, then you may be able to skip the rest of the search code for the login button...

With respect to the tab key submitting the form, I'm guessing it's related to the onChange or !OnBlur event handler for the last control used, but that's just a guess... I haven't used the What's Up Gold site myself. Is there a way for KeeFox to identify the last field used; that is the one that would trigger this handler? I'm not sure if you can determine this while filling in the form automatically, or if it has to be recorded when you fill in the form the first time (or if that's an option).

According to a single sample of an ASP.NET site, the doPostBack function checks for and optionally runs the onSubmit event handler to verify the form's ready to be submitted, then it takes an eventTarget and eventArgument parameters, then assigns each to the two form elements, and finally submits the form. You might want to confirm this, but you may be able to skip the client-side event handler and just assign the two values and submit. I'm not sure, but I would expect that ASP.NET would validate the form server-side as well.

Well, that's just my two cents... hope it helps! And good job on the add-on, from what I've seen thus far! :)

from keefox.

Trac comment by luckyrat on 2010-01-18 22:03:13:

I think you're right that looking for an ASP.NET marker ID would help performance a lot although I don't know whether there is always a predictable marker (I know !ViewState can be disabled for example). Also, I'm not sure how many other types of page have followed the ASP.NET forms approach - if we find that a thousand CMS systems have their own little marker IDs that we have to look for then we might still be better off searching for funny anchor element IDs with "login" or "signup" in their name ;-)

I think the only way to replicate an !OnBlur/OnChange event would be to store some custom javascript along with the KeePass entry for that site and then execute it before the form is submitted. I can't see any way that script could be populated other than someone writing / pasting it manually into the KeePass entry.

By the time KeeFox sees a form submission, it can't tell with any certainty what the last form field on the page was. I haven't looked but I suspect it might be possible to identify existing !OnBlur/OnChange events attached to particular form fields. However, this is bound to cause problems - e.g. what if the !OnChange event post-processes the data in the form? If KeeFox runs that same event again as part of a future submission, how can it know if it will simply invalidate the form data that it had previously saved?

I've not yet had any bright ideas to enable reliable identification of the login button either and I think this is a crucial step in the submission of these forms. That said, I might be able to enable an advanced option for users to enter the id of a page element that contains javascript to run instead of a normal form submission. Security considerations can complicate matters when one starts mixing javascript between the web browser itself and a public webpage but I think something like this should be possible if I ever have the time.

It's worth noting that it will soon be possible to exclude certain entries from auto-submission and it has always been possible to use !KeePass' built in !AutoType feature for the occasional troublesome form.

from keefox.

Trac comment by luckyrat on 2010-12-04 23:05:47:

Without any clear plan for improving KeeFox's behaviour in this area I'm going to push it to a post 1.0 task. Maybe by then I'll have come up with some more specific and achievable ways to improve detection on forms like these.

from keefox.

This is very similar to #119 but I think there are some areas that don't overlap so I'll keep both open for the time being at least.

from keefox.

There are some interesting ideas in here but it's too broad.

from keefox.