Re: Question related to undefined filters

2022-01-13 Thread Emmanuel Lécharny




On 13/01/2022 15:34, Shawn McKinney wrote:



On Jan 12, 2022, at 4:49 PM, Emmanuel Lécharny  wrote:

Indeed, thus my question...

I will add some logs when an Undefined filter is found, so that at leats we 
have some trace...


+ 1

A characteristic of a poor system is bad/unexpected things happening and we 
have no idea why. Very frustrating for the end user.

Per Stefan’s maxim: ’The principle of least surprise’.


Which does not apply very well to LDAP ;-)

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org



Re: Question related to undefined filters

2022-01-13 Thread Shawn McKinney


> On Jan 12, 2022, at 4:49 PM, Emmanuel Lécharny  wrote:
> 
> Indeed, thus my question...
> 
> I will add some logs when an Undefined filter is found, so that at leats we 
> have some trace...

+ 1

A characteristic of a poor system is bad/unexpected things happening and we 
have no idea why. Very frustrating for the end user.

Per Stefan’s maxim: ’The principle of least surprise’. Which I’ve just stolen 
to use as my own ;-)

—
Shawn


-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org



Re: Question related to undefined filters

2022-01-12 Thread Emmanuel Lécharny




On 12/01/2022 21:52, Stefan Seelmann wrote:
I understand it the same way as you, especially the next paragraph makes 
it clear that no error must be returned:


    Servers MUST NOT return errors if attribute descriptions or matching
    rule ids are not recognized, assertion values are invalid, or the
    assertion syntax is not supported.  More details of filter processing
    are given in Clause 7.8 of [X.511].

TBH, as a user, I'd prefer to get a clear error when my filter is 
invalid (fail fast) than an empty result where I don't understand why. 
This doesn't follow the principle of least surprise...


Indeed, thus my question...

I will add some logs when an Undefined filter is found, so that at leats 
we have some trace...


Thanks !
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org



Re: Question related to undefined filters

2022-01-12 Thread Stefan Seelmann
I understand it the same way as you, especially the next paragraph makes 
it clear that no error must be returned:


   Servers MUST NOT return errors if attribute descriptions or matching
   rule ids are not recognized, assertion values are invalid, or the
   assertion syntax is not supported.  More details of filter processing
   are given in Clause 7.8 of [X.511].

TBH, as a user, I'd prefer to get a clear error when my filter is 
invalid (fail fast) than an empty result where I don't understand why. 
This doesn't follow the principle of least surprise...


Kind regards,
Stefan


On 1/12/22 11:12, Emmanuel Lécharny wrote:

Hi!

recently, I was working on fixing a NPE in the server. Thtis was due to 
a wrong filter being sent, where a Substring filter was used for an 
attribute that does not have a SunstringMR (uniqueMmeber).


The filter was like (uniqueMmeber=abc*).

RFC 4511 is not absolutely clear about what to do in this case, or 
should I say, I'm not absolutely sure I understand what it says:


A server MUST evaluate filters according to the three-valued logic of
    [X.511] (1993), Clause 7.8.1.  In summary, a filter is evaluated to
    "TRUE", "FALSE", or "Undefined".  If the filter evaluates to TRUE for
    a particular entry, then the attributes of that entry are returned as
    part of the Search result (subject to any applicable access control
    restrictions).  If the filter evaluates to FALSE or Undefined, then
    the entry is ignored for the Search.

    A filter of the "and" choice is TRUE if all the filters in the SET OF
    evaluate to TRUE, FALSE if at least one filter is FALSE, and
    Undefined otherwise.  A filter of the "or" choice is FALSE if all the
    filters in the SET OF evaluate to FALSE, TRUE if at least one filter
    is TRUE, and Undefined otherwise.  A filter of the 'not' choice is
    TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
    Undefined if it is Undefined.

    A filter item evaluates to Undefined when the server would not be
    able to determine whether the assertion value matches an entry.
    Examples include:

    - An attribute description in an equalityMatch, substrings,
  greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
  is not recognized by the server.

    - The attribute type does not define the appropriate matching rule.

    - A MatchingRuleId in the extensibleMatch is not recognized by the
  server or is not valid for the attribute type.

    - The type of filtering requested is not implemented.

    - The assertion value is invalid.

    For example, if a server did not recognize the attribute type
    shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
    and (shoeSize<=12) would each evaluate to Undefined.


AFAICU, an entry having a uniqueMember attribute should simply noit be 
returned when the bad filter is used.


I'm fine with this logic, assuming this is the correct one.

Any remark or clarification ?

Many thanks !



-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org



Question related to undefined filters

2022-01-12 Thread Emmanuel Lécharny

Hi!

recently, I was working on fixing a NPE in the server. Thtis was due to 
a wrong filter being sent, where a Substring filter was used for an 
attribute that does not have a SunstringMR (uniqueMmeber).


The filter was like (uniqueMmeber=abc*).

RFC 4511 is not absolutely clear about what to do in this case, or 
should I say, I'm not absolutely sure I understand what it says:


A server MUST evaluate filters according to the three-valued logic of
   [X.511] (1993), Clause 7.8.1.  In summary, a filter is evaluated to
   "TRUE", "FALSE", or "Undefined".  If the filter evaluates to TRUE for
   a particular entry, then the attributes of that entry are returned as
   part of the Search result (subject to any applicable access control
   restrictions).  If the filter evaluates to FALSE or Undefined, then
   the entry is ignored for the Search.

   A filter of the "and" choice is TRUE if all the filters in the SET OF
   evaluate to TRUE, FALSE if at least one filter is FALSE, and
   Undefined otherwise.  A filter of the "or" choice is FALSE if all the
   filters in the SET OF evaluate to FALSE, TRUE if at least one filter
   is TRUE, and Undefined otherwise.  A filter of the 'not' choice is
   TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
   Undefined if it is Undefined.

   A filter item evaluates to Undefined when the server would not be
   able to determine whether the assertion value matches an entry.
   Examples include:

   - An attribute description in an equalityMatch, substrings,
 greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
 is not recognized by the server.

   - The attribute type does not define the appropriate matching rule.

   - A MatchingRuleId in the extensibleMatch is not recognized by the
 server or is not valid for the attribute type.

   - The type of filtering requested is not implemented.

   - The assertion value is invalid.

   For example, if a server did not recognize the attribute type
   shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
   and (shoeSize<=12) would each evaluate to Undefined.


AFAICU, an entry having a uniqueMember attribute should simply noit be 
returned when the bad filter is used.


I'm fine with this logic, assuming this is the correct one.

Any remark or clarification ?

Many thanks !
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org