Open oriordan opened 8 years ago
I'm not sure I see a reason for this change, the current output format is established and will need to remain in working order. In principle I'm not against adding a different output but I think we need a clear usecase for it.
I do see your point. It feels a bit unclean to parse text output in a HTTP API. Technically speaking the current solution is slightly faster, but I was planning to add JSON support for yubikey-val as well (where it might make even more sense maybe). So the clients and components can talk to each other via JSON. Ideally even the hex would be turned to integer so the output is immediately consumable.
This was the first step, so if you already see you don't want to have JSON support in yubikey-val, it won't make any sense to do it here either.
By the way, I'm working on a python implementation of yubikey-val, yubikey-ksm, and yubico_client bundled in one called yubistack. I'd really welcome any review / comment from you on the project. The aim is to create simple integrated setup, in which components can talk natively to each other, while keeping full compatibility with the original implementation.
Sorry for the delay here..
One tough part in refactoring this is that I don't see a way to get rid of the old format (especially in yubikey-val) which means more complex code for the output.
I'll throw some eyes at yubistack.
Parsing the text output of the KSM server feels unclean. We could rely on HTTP status codes and JSON.