You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As requested, I am splitting the long and unclear #8560 into several issues. This issue is about documenting how BindAuthenticator fetches attributes.
Behaviour
There are two ways to use BindAuthenticator. Way one: call setUserDnPatterns. Way two: call setUserSearch.
If you choose the first way, BindAuthenticator will attempt to bind with the dnPatterns you gave it. It will not, as far as I can tell, perform any search. If the bind succeeds, it will fetch the user's attributes with the user's permissions.
If you choose the second way, BindAuthenticator will perform a search for the user with the app user's permissions. Probably, this search will fetch some attributes -- again, with the app user's permissions. Then, it will bind as the user -- but it will not fetch attributes again.
In summary: if you choose the first way, you get all of the user's attributes that the user can see. If you choose the second way, you get all of the user's attributes that the app user can see. In some LDAP configurations, those two things are not the same.
To see this in action, go to this repository and follow the README. Having done that, first check out one of the only-dnpatterns-* branches. Log in and observe that you can see (in the logs) the sn attribute. Then, check out one of the only-search-* branches. Log in and observe that you can't see the sn attribute. (The access controls of the server are configured so that the user can read the sn attribute, but the anonymous user -- which the application binds as -- can't.)
Why this merits documentation
I spent a couple of hours trying to figure out why changing my bind strategy changed which attributes got fetched. I don't think I'm unusual in not expecting that to happen. It's worth thinking about not making it happen, but that's a separate issue (#8727); whether or not you decide to change the API, documenting the current behaviour seems sensible.
Where to document it
Here, or in the section immediately after ("Using Bind Authentication"). I think just adding the information in my "in summary" paragraph from above is enough.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
As requested, I am splitting the long and unclear #8560 into several issues. This issue is about documenting how
BindAuthenticator
fetches attributes.Behaviour
There are two ways to use
BindAuthenticator
. Way one: callsetUserDnPatterns
. Way two: callsetUserSearch
.If you choose the first way,
BindAuthenticator
will attempt to bind with the dnPatterns you gave it. It will not, as far as I can tell, perform any search. If the bind succeeds, it will fetch the user's attributes with the user's permissions.If you choose the second way,
BindAuthenticator
will perform a search for the user with the app user's permissions. Probably, this search will fetch some attributes -- again, with the app user's permissions. Then, it will bind as the user -- but it will not fetch attributes again.In summary: if you choose the first way, you get all of the user's attributes that the user can see. If you choose the second way, you get all of the user's attributes that the app user can see. In some LDAP configurations, those two things are not the same.
To see this in action, go to this repository and follow the README. Having done that, first check out one of the only-dnpatterns-* branches. Log in and observe that you can see (in the logs) the
sn
attribute. Then, check out one of the only-search-* branches. Log in and observe that you can't see thesn
attribute. (The access controls of the server are configured so that the user can read thesn
attribute, but the anonymous user -- which the application binds as -- can't.)Why this merits documentation
I spent a couple of hours trying to figure out why changing my bind strategy changed which attributes got fetched. I don't think I'm unusual in not expecting that to happen. It's worth thinking about not making it happen, but that's a separate issue (#8727); whether or not you decide to change the API, documenting the current behaviour seems sensible.
Where to document it
Here, or in the section immediately after ("Using Bind Authentication"). I think just adding the information in my "in summary" paragraph from above is enough.
The text was updated successfully, but these errors were encountered: