Closed Bug 297131 (ldapcontrols) Opened 20 years ago Closed 19 years ago

basic support for LDAP v3 controls

Categories

(MailNews Core :: LDAP Integration, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: dmosedale, Assigned: dmosedale)

Details

Attachments

(1 file, 6 obsolete files)

A Thunderbird extension I'm working on wants a way to send an LDAP v3 control
with addressbook and autocomplete searches.
Target Milestone: --- → mozilla1.8beta3
Status: NEW → ASSIGNED
Component: LDAP XPCOM SDK → MailNews: LDAP Integration
Product: Directory → Core
Version: other → Trunk
This is going to involve adding some params to a bunch of methods in
nsILDAPOperation.  So all the LDAP callers will need to be touched, but the
changes are almost entirely generic search/replace changes.
Attached patch patch, v1 (obsolete) — Splinter Review
This is skeleton version of a patch, which has the basic interface changes I
propose fleshed out.
Attached patch patch, v2 (obsolete) — Splinter Review
Now with classinfo for some of the LDAP classes to quiet XPConnect shrieking.
Attachment #187907 - Attachment is obsolete: true
Attached patch patch, v3 (obsolete) — Splinter Review
Now includes nsIAbLDAPDirectory.idl.
Attachment #188549 - Attachment is obsolete: true
Flags: blocking-aviary1.1?
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
This is gonna need to make b4 if it's gonna make 1.1 so shifting the nomination.
Flags: blocking-aviary1.1? → blocking1.8b4?
Alias: ldapcontrols
Attached patch patch, v4 (obsolete) — Splinter Review
This patch is mostly code complete, and doesn't break LDAP autocomplete or
addressbook quick search.  Next step is to actually test to make sure that the
controls piece works.
Attachment #188550 - Attachment is obsolete: true
Attached patch patch, v5 (obsolete) — Splinter Review
Various bugfixes, cleanups, and chock full of documentation comments.
Attachment #189247 - Attachment is obsolete: true
Attachment #189801 - Flags: review?(bienvenu)
Comment on attachment 189801 [details] [diff] [review]
patch, v5

========
RCS file: directory/xpcom/base/public/

 The Initial Developer of the Original Code is 
 + * Netscape Communications Corporation. 
 + * Portions created by the Initial Developer are Copyright (C) 2005 
 + * the Initial Developer. All Rights Reserved. 

should be Oracle

It's confusing that these different constants have the same value and are
defined next to each other:

+  const unsigned long TAG_LBER_ERROR = 0xffffffff;
+  const unsigned long TAG_LBER_DEFAULT = 0xffffffff;

+  const unsigned long TAG_LBER_CONSTRUCTED = 0x20;
+  const unsigned long TAG_LBER_ENCODING_MASK = 0x20;

separating them or commenting as to what they specifically are so that it's OK
they're the same would be helpful.

 * @note Specifying a zero-length value is not currently supported at some 
 +   * date, setting this to an nsILDAPBERValue which has not had any of the
 +  
need a period and new sentence there, I think.

+nsLDAPBERElement::~nsLDAPBERElement()
+{
+  if (mElement) {
+    // anything inside here is not something that we own separately from
+    // this object, so free it
+    ber_free(mElement, 1);
+  }
+
+  return;

no need to return from the destructor here.


+  if (aValue) {
+    return NS_ERROR_NOT_IMPLEMENTED;
+  } else {
+    mElement = ber_alloc();

no need for the else. This could all just be:

if (aValue)
  retrn NS_ERROR_NOT_IMPLEMENTED;

mElement = ber_alloc();
return (mElement) ? NS_OK : NS_ERROR_OUT_OF_MEMORY;

+  int i = ber_flatten(mElement, &bv);
+
+  if (i < 0) {
+    return NS_ERROR_OUT_OF_MEMORY;
+  }

no need for the i var here, since we don't use it after this point.

r=bienvenu, with those nits.
Attachment #189801 - Flags: review?(bienvenu) → review+
Attached patch patch, v6 (obsolete) — Splinter Review
Fixed all of David's nits except the trailing return in the destructor, which I
think is better style, since it shows explicit intent.	Also fixed a gcc
warning. Carrying forward r+ from him.
Attachment #189801 - Attachment is obsolete: true
Attachment #190495 - Flags: superreview?(mscott)
Attachment #190495 - Flags: review+
Comment on attachment 190495 [details] [diff] [review]
patch, v6

+    if (!length) {
+	 return NS_OK;
+    }

Need to initialize *aArray to something --- nsnull, at least

> NS_STATIC_CAST(nsILDAPControl *, control.get())

Why is that necessary?

I don't know anything about LDAP but the patch looks otherwise fine.
Attachment #190495 - Flags: superreview?(mscott) → superreview+
(In reply to comment #10)
> (From update of attachment 190495 [details] [diff] [review] [edit])
> +    if (!length) {
> +	 return NS_OK;
> +    }
> 
> Need to initialize *aArray to something --- nsnull, at least

Fixed in the upcoming patch.

> > NS_STATIC_CAST(nsILDAPControl *, control.get())
> 
> Why is that necessary?

Otherwise gcc dies because control.get() returns an
|nsDerivedSafe<nsILDAPControl>*|.
Attached patch patch, v7Splinter Review
Fixed issue caught by review and a couple of comments.
Attachment #190495 - Attachment is obsolete: true
Attachment #190521 - Flags: superreview+
Attachment #190521 - Flags: review+
Attachment #190521 - Flags: approval1.8b4?
Attachment #190521 - Flags: approval1.8b4? → approval1.8b4+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Looks like someone else already sr'ed this
I think this broke --enable-ldap-experimental (at least in seamonkey):

nsLDAPChannel.cpp:199: error: `Abandon' undeclared (first use this function)
build fix for ldap-experimental checked in with s+sr=dmose (given in IRC)
Flags: blocking1.8b4?
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: