the verification textfield, and the selected tab.
also remove the code that used the value by the userview panel, since
this is the only way to have a consistent behaviour on the userview
setting and the usermenu tfa setting
this fixes the issue that on the 'user menu' we accidentally showed
the qr code and verification field, even if the user already had a
totp code
now it shows 'Unchanged' like when opened via dc/UserView
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This is base32, so we use only 5 bit per byte to make things simple,
so 32 byte * 5 bit/byte = 160 bit of entropy
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
with the api call to userid/tfa we get the users tfa type as well
as the realm tfa type, so we can replace the call to the realm
with this
to properly show the loadmask, we want to initiate the api call when
the window is already shown, the 'show' event works for this
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If a dependency of a formula returns undefined, it will not get updated,
even if the other parts of the formula would work.
So we change the default to 'null' which gets handled differently,
but serves the same purpose for us.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if we have no info about TFA in the userview (x as key instead of
x!oath or x!u2f) we disabled the whole window and the only action
was to delete
instead show all options, so the user can overwrite the setting
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
to avoid showing numbers as error codes to users, even though the
strings are not much more helpful either...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as name is now a displayfield, which by default does not
gets submitted, so just use the fixed userid directly
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
only when the totp form and the challenge is valid, allow pressing the
apply button, default is disabled, as the 'user_tfa' data binding was
not used anywhere else replace it with something more fitting.
change allowBlank for the challenge
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this way a user cannot (easily) enter wrong characters
else if an invalid Character is entered, one can still hit apply
but not all characters will be used for the secret
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Google Authenticator, for example, just ignores it and thus one
cannot use they produced verification codes...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It's best to let this to the users real account name, it just
clutters the interface, an there's no real value in it.
One can already use the "issuer" field to add personalized info.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>