On Mon, 2018-01-29 at 15:07 +0000, Dave Walker wrote: > > The password and secondary_password are reversed. > > On this page it states the ordering: > http://www.infradead.org/openconnect/token.html > > "SecurID token codes will automatically fill in the primary password > field in the authentication form presented by the server" ..? "This > behaviour is empirically determined by the requirements of the servers > that we have tested with; if you find a configuration in which it is > not appropriate, please let us know." > > This mail is letting you know... is there a workaround? I think we should patch the code to use a 'secondary_password' field *if* it exists, and 'password' otherwise. That will require a slightly non-trivial modification to the cstp_can_gen_tokencode() function in auth.c, because now it's no longer *purely* a function of the one option it's being asked to consider. But not *so* hard... patches welcome :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20180129/af2bae75/attachment-0001.bin>