> On the patches:
> 
> [2] you define a new attribute Url which is fine, but the actual
> attribute is not ok in several way.
> 
> - You assigned an OID from a hole in the IPAv2 Attibutes space, it
> should be an assigned ID from the IPAv3 attribute space instead
> 
> - You do not namespace the attribute, it should at least be ipaUrl 
> 

I'll look into that

> - you are using case Exact matching, is this intentional? Are the URIs
> in there case sensitive strings ?
> 
> - there is an available attribute called labeledURI (with alias
> labeledurl) in the standard schema (however I notice it also has
> caseExactMatch) that has basically the same definition of your Url
> attribute, why not use that one ?
> 

Actually, URI is case sensitive: http://stackoverflow.com/a/26196170/1978950

I'll check labeledURI you mentioned.

> [3] If I read the patch correctly failing to find a Url is a fatal
> condition, this is not ok as it would fail to operate with older servers
> that do not have a url on the rules.
> 

I believe it is not a fatal condition. If you mean line 100, it is for
the case of some failure of the call. If the call succeeds and there is
no URI, then line 105 happens and the URI is considered empty.
If you are talking about the evaluation in line 21, this will be
changed, the exact string comparison is there just for testing.

> It is not clear to me what happen on an older client if URL is used but
> not the service? Or is service always enforced ? (It is not clear to me
> that it is).
> 

I'm not sure I understand. If there is no service, the rule must
necessarily fail to allow the access before even evaluating URI, or at
least I think so. URI will only reduce the set of HBAC rules matching
certain request.


-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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

Reply via email to