On 21.2.2014 20:00, Nathaniel McCallum wrote:
Is it possible to do something more intelligent for the key and date
fields in the add-token UI?
Date fields are currently just a text box. Is there any sort of calendar
we could use here? If not, I'm still unsure of what the format should be
for this field.
It's the format you chose :), try to fill it in CLI, you will have the
same proble. From API level it's just string, from LDAP it's generalized
I've an UI patch prepared where you can write it in ISO format, with a
validator attached to it, so user will be noticed about the format, but
it's waiting for:
The key field should probably have a note indicating that it is Base32
encoding. It would also be nice to restrict the input to Base32
characters. Maybe even automatic case correction...
Actually I think it doesn't help much. Show me a person who can write
base32 encoded string.... But I agree that a validator with some regex
to limit the chars and a note that it should be base32 string is better.
The question is what's the purpose of this field from user perspective.
Is a human being suppose to fill it or is it meant to be only filled by
some provisioning systems? In UI it's just as a backup?
If there is a use case where user is suppose to choose the key, it would
be better to fill the key and convert it to base32 string on a server.
On Fri, 2014-02-21 at 15:24 +0100, Petr Vobornik wrote:
On 10.2.2014 14:12, Petr Vobornik wrote:
On 13.1.2014 17:09, Petr Vobornik wrote:
these patches implements the OTP Web UI.
Last 5 patches is the OTP UI.
First 6 patches is a little refactoring/bug fixes needed for them.
General password dialog is introduced to avoid another implementation.
Self-service UI is implemented to be very simple. Atm user can choose
only token name. Admin interface allows to enter all values.
It's based on the RCUE work -> we need to push RCUE first. Thanks
Nathaniel for review of the last font package. It will speed things up.
- there is clash in id's of checkboxes preventing editation of
subsequently displayed ones with the same name. Will be fixed in
- bugs caused by bugs in API (adding/removal of own tokens in
self-service, inability to enter key on token creation -
- datetime format (widget+validator) will be implemented in separate
- no support of not reviewed CLI patches (HOTP..)
patch 540-1 has been updated
- QR code is centered
- QR code correction level was lowered from H to M
All other current patches from sub-threads are attached as well (it was
getting hard to keep track of them).
Attaching new version of patch 537: 537-4
* adds HOTP support - new switch in adder dialog and ipatokenhotpcounter
field in details facet
* removes 'default' radio button in adder dialog in ipatokenotpalgorithm
and ipatokenotpdigits field
Btw I've encountered an issue on Web UI login when:
- user is created
- token is created for him
- admin resets user's password and changes auth type to 'otp'
- user tries to login with psw+otp
The initial login-password call is successful but subsequent change
password fails - it uses the old psw+otp.
I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903
which is almost implemented.
I also plan to hide fields without any value in otp token details page
in self-service mode. This will be done after #3903 because some
prerequisites for #3903 add useful code for that task.
Freeipa-devel mailing list
Freeipa-devel mailing list