URL always /v1/ldap//base returns HTTP error 404, even when logged in as cn=Directory manager.
/v1/ldap//base
cn=Directory manager
Tested with rest389 2cea971040396e73802aae9854b4dfa9523ee2b0.
Added new resources:
/v1/ldap/rootdse /v1/ldap/rootdse/<attr,attr,...>
Also consolidated whoami into the ldap resource
/v1/ldap/whoami
Thank you!
I have a side-note: A while back William and me were thinking about using /dit instead of /ldap.
/dit
/ldap
In my eyes it makes sense to separate operations 'on data' in DIT from other things like LDAP WhoAmI to avoid confusion...
Replying to [comment:6 pspacek]:
Thank you! I have a side-note: A while back William and me were thinking about using /dit instead of /ldap.
That's fine. I think of "ldap" as "ldap operations", but I can change it.
I thought you wanted ldap whoami in the ldap resource?
{{{ I was confused by the combination. It was something like: "/whoami is logically subset of LDAP, right, so why /whoami is not under /ldap?" }}}
I feel "dit" is too specific in this case, which I why I liked "ldap". Using "dit" really leaves whoami without a proper home. Perhaps "whoami" can go into a utility resource, but I'm not sure if we will have anything else that would go into a "utility" resource. I'll discuss this with William...
revision 0001-Ticket-48659-Add-support-for-root-DSE-searches.patch
Revised patch. Left "whoami" in original location/end point, changed "ldap" to "dit", and added:
/v1/dit/rootdse /v1/dit/rootdse/<attr,attr,...>
Looks okay to me.
Given that whoami is an extended op, maybe we need /v1/exop/whoami ?
I'm also happy leaving it in the root, as it's a nice simple diagnostic tool too.
Replying to [comment:9 firstyear]:
Looks okay to me. Given that whoami is an extended op, maybe we need /v1/exop/whoami ?
Perhaps, but I'm not sure there are other extended operations we want to expose to warrant a new resource.
For now lets leave it where it is - it can easily be changed later.
To ssh://git.fedorahosted.org/git/rest389.git 2cea971..3e2f3b6 master -> master commit 3e2f3b6b975c0b2b1ec3e9aeff2eb4f09c1172be Author: Mark Reynolds mreynolds@redhat.com Date: Mon Apr 4 15:31:40 2016 -040
Metadata Update from @pspacek: - Issue assigned to mreynolds - Issue set to the milestone: rest389 1.0
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1788
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.