[Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range
Tomas Babej
tbabej at redhat.com
Mon Jun 10 09:11:48 UTC 2013
On 06/07/2013 05:49 PM, Ana Krivokapic wrote:
> On 06/07/2013 12:15 PM, Tomas Babej wrote:
>> On 05/31/2013 12:08 PM, Ana Krivokapic wrote:
>>> Hello,
>>>
>>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3635.
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-devel mailing list
>>> Freeipa-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>> Hi, the patch itself works as it should, I have only some refactoring
>> comments:
>>
>> 1.) There already is a add_range method that is called from within
>> trust_add's execute()
>> and handles some range validation (currently only whether domain's
>> SID of new and
>> existing range are equal, my patch 67 add some more).
>>
>> Your patch introduces a new method validate_range() that is called
>> from execute(),
>> which leads to some duplication of the logic, mainly two same calls
>> to the API (getting
>> the info about the old range via idrange_show)
>>
>> I'd rather we keep all the validation in one place, preferably inside
>> the add_range method
>> or refactored out of it in the new method that is called only from
>> add_range().
>>
>> 2.) That being said, other parts of refactoring are nice and make
>> code more clear, +1.
>>
>> Tomas
>
> My first instinct was to place this validation in the add_range()
> method. However, add_range() is called after the trust itself is
> added, and validation introduced by this patch needs to happen before
> the trust is added (we need to prevent the addition of trust in case
> the validation fails).
>
> As for the code duplication, you are right about that. I tried to
> minimize duplication - resulting updated patch attached.
> --
> Regards,
>
> Ana Krivokapic
> Associate Software Engineer
> FreeIPA team
> Red Hat Inc.
While this is a nice improvement from the code repetition point of view,
the patch still has one flaw as I see it - the range validation happens
at two separate places:
Once here(already in the code):
if old_range:
old_dom_sid = old_range['result']['ipanttrusteddomainsid'][0];
if old_dom_sid == dom_sid:
return
raise errors.ValidationError(name=_('range exists'),
error=_('ID range with the same name but different ' \
'domain SID already exists. The ID range for ' \
'the new trusted domain must be created manually.'))
And once here(added by your patch):
+ if not self.validate_range(*keys, **options):
+ raise errors.ValidationError(
+ name=_('id range'),
+ error=_(
+ 'An id range already exists for this trust. '
+ 'You should either delete the old range, or '
+ 'exclude --base-id/--range-size options from the
command.'
I'd suggest we have one common place, say validate_range() function as
we have now,
that contains all the checks (more coming in the future for sure).
That would mean that the whole trust-add command will fail in the case
that "ID range
with the same name but different domain SID already exists", since we
now call validate_range()
within execute() method. I checked with Alexander and we agreed that
this is more desired behaviour.
This would also result to reducement of the number of API calls, which
is a nice benefit.
Tomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130610/a5cca6a3/attachment.htm>
More information about the Freeipa-devel
mailing list