On 25.4.2016 14:48, Lukáš Hellebrandt wrote:

I have made some important changes to the design document of this
proposed feature. The difference is mainly changing regular expression
interpretation of URI to longest-prefix matching.

This change was done mainly because of upstream's reactions. I value any
further comments and particularly discussion about the two topics
mentioned at the end of the design page:

* For backwards compatibility, lack of URI in request means any URI is
matched (as described in the design document). Is it a good idea? Any
other solution?

For other attributes in HBAC rules, the lack of a value means nothing is matched. To match anything, you have to set "${attribute}category" to "all". I would prefer if URI matching was consistent with this, if it's possible.

* How about multiple URI's in one HBAC rule? Is it a good idea? How to
interpret combinations of host+scheme+port (one field) and URI paths
(another field) in that case?

I think it is not only good idea, but actually necessary. I guess you would have to consider an URI matched if it's host+scheme+port matches any of the host+scheme+port patterns and at the same time it's path matches any of the path patterns.

BTW what is the reason to split URIs into separate fields? If it's just case sensitivity, I would like to point out that you can switch case sensitivity on and off in the middle of a Perl regex using "(?i)" and "(?-i)".


Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to