On 07/21/2016 11:43 AM, Petr Spacek wrote:
On 20.7.2016 19:25, Ben Lipton wrote:
On 07/20/2016 12:21 PM, Simo Sorce wrote:
On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote:
On 07/20/2016 10:37 AM, Simo Sorce wrote:
On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote:
On 07/20/2016 06:27 AM, Simo Sorce wrote:
On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote:
Hi,
I have updated the design page
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_
Gene
rati
on/Mapping_Rules
with my plan for implementing user-configurable rules for
mapping
IPA
data into certificate requests. In brief: we will use Jinja2
for
templating. Data rules (which map individual data items) and
syntax
rules (which group them into certificate fields) will both be
snippets
of Jinja2 markup. The formatting process will be as follows:
I've finally found some time to read the sub-page Mapping_Rules and for me it
is kind of hard to follow. It would not be understandable without this e-mail
and the blog posts (BTW the blog articles are among best I have seen!).
Most importantly, the explanations in brackets above ["Data rules (which map
individual data items) and (which group them into certificate fields)"] are
missing in the wiki page itself :-)
Could you fold relevant parts of the e-mails and blogs back into the wiki page
so it is self-contained?
Very good point. I may have been assuming knowledge of the whole design
when reading this document, which doesn't make sense. I did some
cleanup, plus added some more detail about how things work in the
implementation I just sent out for review. I hope that will clarify
things somewhat.
Besides this nit,
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation
sounds reasonable. I like how it prevents bad data from template-injection.
That's what I like about it, too. It does turn out to make things a
little tricky when it comes to writing rules that won't render if the
data they depend on is unavailable. (Because instead of rendering
individual rules which we can drop if they're missing data, we build one
big template that has to handle missing data correctly on its own.) I
think it's probably still worth it, though. I added this to the
"Alternatives considered" section of the above document.
Regarding
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A
, I prefer Option A with separate object for each helper. It is somehow
cleaner and it might be useful to use distinct object classes for each helper
etc.
+1, I think option B was a bit of premature optimization.
API for ipa cert-get-requestdata sounds good.
API for ipa cert-request makes sense to me as well.
In any case I would recommend you to consult API design with Jan Cholasta
<jchol...@redhat.com> - he is our API custodian.
BTW I very much like "Alternatives considered" sections, we should have this
for each design!
Good work, I really like the dutiful analysis!
Thanks for the feedback, and the kind words!
Ben
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
