On 11/13/2014 06:02 PM, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 16:57 +0100, Petr Viktorin wrote:
On 11/13/2014 04:40 PM, Petr Vobornik wrote:
On 13.11.2014 16:19, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote:
On 13.11.2014 16:00, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.


I removed the period from the doc string to maintain consistency with
the rest of the plugin.


I am not reviewing, just curious. What is the purpose of --qrcode
option with

        takes_options = LDAPCreate.takes_options + (
-        Flag('qrcode?', label=_('Display QR code')),
+        Flag('qrcode', label=_('Display QR code'), default=True),

How can user turn it off? Both passing no option and passing
--qrcode will get
the same result, no? :-)

Shouldn't we instead change --qrcode to --no-qrcode and process
somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old

I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).

2. Change it to --no-qrcode (API change)

3. Change the type to Bool (API change)

Like you, I like #2 the best. Attached is an implementation.

I like --no-qrcode as well.

Should we also keep qrcode as 'no_option' to maintain API compatibility
(but not CLI)?

I don't think it is necessary. It only makes sense to specify --qrcode
in an interactive session.

Makes sense.


Not pushing yet to give time for NACK if anybody doesn't agree with the
API change.

Hold on, what is happening here?

Aren't all clients since 4.0 sending the qrcode option to the server?
We absolutely can not break backwards compatibility with released versions.
We also should not break the CLI. Just make it a no-op option, and say
it's deprecated in the doc.

As I understand the current behavior, the qrcode option is *not* sent to
the server by default in any scenario.

Nope, defaults are filled in by the client. (And also on the server if they're still missing; it's part of the common validation.)

You can try it out, actually:

$ ipa -vv otptoken-add
ipa: INFO: trying https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json
ipa: INFO: Forwarding 'otptoken_add' to json server 'https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json'
ipa: INFO: Request: {
    "id": 0,
    "method": "otptoken_add",
    "params": [
            "all": false,
            "ipatokenhotpcounter": 0,
            "ipatokenotpalgorithm": "sha1",
            "ipatokenotpdigits": 6,
"ipatokenotpkey": "5\ufffdK\ufffd1\u000e\ufffd7,\ufffd_\ufffd\ufffd.0\ufffdM\ufffd\u0016\ufffd",
            "ipatokentotpclockoffset": 0,
            "ipatokentotptimestep": 30,
            "no_members": false,
            "qrcode": false,
            "raw": false,
            "type": "totp",
            "version": "2.108"
ipa: INFO: Response: {
    "error": null,
    "id": 0,
    "principal": "ad...@idm.lab.eng.brq.redhat.com",


Freeipa-devel mailing list

Reply via email to