Log-in-procedure

Kee browser extension
1

at first: sorry for my bad english but I´m shure, you will understand.

since a few month the login-prodedure of many homepages changed and has to be done in two steps on two diffent pages. this is a problem for the kee-add-on (my system: windows 10, firefox). for example the homepages of the “ADAC” ([https://www.adac.de/mein-adac/) and the “Postbank” ([https://meine.postbank.de/#/login) doesn´t work automaticly with the add-on. especially the “Postbank” is a problem. the field “Postbank ID” has to be filled by hand, because the kee-add-on doesn´t realize, that there has to fill in the “username”. I think, you have to adjust your software with these new log-in-methodes.
And another problem: normally the log-in will be filled automatically unless you have two or more posibilities, than you have to select. But sometimes you have defenitily only one choice - anyway you have to select the log-in-data by hand from the kee-add-on.

2

I have the same issue. Apparently it happens when the password field is missing. I did take a look at the log in the console on my end.

In browser content page script, received message from background script 16 common.js:16:941
scanForOrphanedFields took: 0 common.js:16:941
Finding matches in a document. readyState: complete common.js:16:1111
findMatches processing 1 forms common.js:16:941
about to get form fields common.js:16:941
processing field with domtype text... common.js:16:941
usernameIndex: -1 common.js:16:941
actualUsernameIndex: 0 common.js:16:941
otherFields.length:1 common.js:16:941
No password field found in this form and either there are no other fields or no whitelisted text field or form element common.js:16:941

This problem was also reported on GitHub.

This Issue was closed as invalid; “post in the community forum”. I bumping this, because I searched the forum as asked by the developer and found no solution to this still existing problem. This is the only post I have found. I know as a developer my self that baby sitting users is annoying, so things get “Invalid”-ed easily, but the user part of me just don’t like how this is handled. This is rather sad for this otherwise excellent software product.

My version data:
Windows 10 (10.0.19043.1237, 64-Bit)
Firefox 92.0.1 (64-Bit)
Kee 3.9.5

URL: Ihr Login zum Online-Banking | Postbank

Before you ask, I tried to adjusts the whitelist in the addon settings. My whitelist data is:

sssWhiteFormName: login   (default)

sssWhiteFormId: login   (default)

sssWhiteFieldName: username,j_username,user_name,user,user-name,login,vb_login_username,name,user name,user id,user-id,userid,email,e-mail,id,form_loginname,wpname,mail,loginid,login id,login_name,openid_identifier,authentication_email,openid,auth_email,auth_id,authentication_identifier,authentication_id,customer_number,customernumber,onlineid,postbankId   (changed, added postbankId)

sssWhiteFieldId: username,j_username,user_name,user,user-name,login,vb_login_username,name,user name,user id,user-id,userid,email,e-mail,id,form_loginname,wpname,mail,loginid,login id,login_name,openid_identifier,authentication_email,openid,auth_email,auth_id,authentication_identifier,authentication_id,customer_number,customernumber,onlineid,postbankId   (changed, added postbankId)

pref_listMatchingIgnoreCase_label: true

The Name field on the Postbank page has the ID postbankId and has no other usable identifying attributes beside some custom ones. The password field works, but is not present on the first login page, which causes the name field to be ignored.

The field in question:

<input class="c-form__input u-mar-b-1" id="postbankId" placeholder="Postbank ID" aria-required="true" data-test-anchor="login-username" type="text" value="">
3

Thanks for the detailed information. I’ve reproduced the problem using Postbank as an example but this reveals a bug which will affect other sites too, depending upon the site and your Kee configuration. The good news is that there is a workaround.

You can see the bug and workaround on GitHub now:

PS: I know the term “invalid” on GitHub is a little broad but I hope you can see that the actual issue now on GitHub is entirely different to the one mentioned above. Bug reports and user “babysitting” are often indistinguishable at the start so it’s important that we keep everything in this one community forum until we identify a concrete change that we want to make to the extension. In this case, you’ve helped us discover a bug which is great, although that’s actually a very unlikely outcome for the majority of the “something does not work” GitHub issues which I mark as invalid and refer back to this forum.

1 Like