Hi Davide, Angela,
Note that this is not an issue with oak-auth-ldap, but rather with
The ExternalIdentity implementation used by oak-auth-ldap uses the DN as
both the id and the principal name, so it's working fine. Other
implementations of the external auth mechanism may run into problems
(btw: are other implementations known?).
I'm going to revert the change now, but since the performance
improvement was striking on customer site, I'd like to keep it for the
LDAP case. Anyone feel free to give suggestions on the most elegant way
to do this.
On 12/1/2016 12:52 PM, Angela Schreiber wrote:
IMO the fix for OAK-5200 is straight forward:
1. revert changes made to DynamicSyncContext: it's here where the bug was
that should be doable today.
2. have a quick discussion on oak-dev on how to deal with the new,
exported class ExternalGroupRef
which was introduced (and was already backported): this one would not
be used any
more after 1) but removing it again would (afaik) lead to a major
i want to get more opinions on that, because i am not aware that we had
before (or missed/don't remember how we dealt with it).
if we see that it's not doable or too cumbersome reverting this class,
we may decide
to leave it... we might find it useful later on or end up deprecating
it for 1.8.
but i want to have a conscious decision here and some broader agreement
from the team.
- if we leave it -> changes in auth-ldap code base don't need to be
- if we revert it -> changes in auth-ldap also would need to be reverted
Hope that helps
PS: as far as the original improvement is concerned that was the intention
(but which is not obvious from the subject, which is not correct), we need
to have a new
Improvement ticket, where we can discuss the options... I want that kind
to be properly tracked in jira (and ultimately in the documentation and
that everyone can understand why a given change was made... i had a hard
time yesterday to
understand what was the actual aim of OAK-4930 and it was just by
coincidence that I hours
later spotted the issue... just because I could not understand how I could
have mixed up
ID and principal name in the original code (and which turned out wasn't
On 01/12/16 12:15, "Davide Giannella" <dav...@apache.org> wrote:
I'm planning to cut Oak 1.5.15 on Monday 5th December.
If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.
Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
how long for the fix to get done?