#48659 search over rest389 does not work for root DSE
Closed: wontfix None Opened 8 years ago by pspacek.

URL always /v1/ldap//base returns HTTP error 404, even when logged in as 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.

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.

In my eyes it makes sense to separate operations 'on data' in DIT from other things like LDAP WhoAmI to avoid confusion...

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...

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.

I'm also happy leaving it in the root, as it's a nice simple diagnostic tool too.

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata