[Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Ben Lipton]

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
> <jcholast at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20160727/5e06bab1/attachment.htm>