Closed
Bug 297131
(ldapcontrols)
Opened 20 years ago
Closed 19 years ago
basic support for LDAP v3 controls
Categories
(MailNews Core :: LDAP Integration, defect)
MailNews Core
LDAP Integration
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta4
People
(Reporter: dmosedale, Assigned: dmosedale)
Details
Attachments
(1 file, 6 obsolete files)
|
64.73 KB,
patch
|
dmosedale
:
review+
dmosedale
:
superreview+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
A Thunderbird extension I'm working on wants a way to send an LDAP v3 control with addressbook and autocomplete searches.
| Assignee | ||
Updated•20 years ago
|
Target Milestone: --- → mozilla1.8beta3
| Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Updated•20 years ago
|
Component: LDAP XPCOM SDK → MailNews: LDAP Integration
Product: Directory → Core
Version: other → Trunk
| Assignee | ||
Comment 1•20 years ago
|
||
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.
| Assignee | ||
Comment 2•20 years ago
|
||
This is skeleton version of a patch, which has the basic interface changes I propose fleshed out.
| Assignee | ||
Comment 3•19 years ago
|
||
Now with classinfo for some of the LDAP classes to quiet XPConnect shrieking.
Attachment #187907 -
Attachment is obsolete: true
| Assignee | ||
Comment 4•19 years ago
|
||
Now includes nsIAbLDAPDirectory.idl.
Attachment #188549 -
Attachment is obsolete: true
| Assignee | ||
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
Comment 5•19 years ago
|
||
This is gonna need to make b4 if it's gonna make 1.1 so shifting the nomination.
Flags: blocking-aviary1.1? → blocking1.8b4?
| Assignee | ||
Updated•19 years ago
|
Alias: ldapcontrols
| Assignee | ||
Comment 6•19 years ago
|
||
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
| Assignee | ||
Comment 7•19 years ago
|
||
Various bugfixes, cleanups, and chock full of documentation comments.
Attachment #189247 -
Attachment is obsolete: true
Attachment #189801 -
Flags: review?(bienvenu)
Comment 8•19 years ago
|
||
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+
| Assignee | ||
Comment 9•19 years ago
|
||
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+
| Assignee | ||
Comment 11•19 years ago
|
||
(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>*|.
| Assignee | ||
Comment 12•19 years ago
|
||
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?
Updated•19 years ago
|
Attachment #190521 -
Flags: approval1.8b4? → approval1.8b4+
| Assignee | ||
Comment 13•19 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 14•19 years ago
|
||
Looks like someone else already sr'ed this
Comment 15•19 years ago
|
||
I think this broke --enable-ldap-experimental (at least in seamonkey): nsLDAPChannel.cpp:199: error: `Abandon' undeclared (first use this function)
Comment 16•19 years ago
|
||
build fix for ldap-experimental checked in with s+sr=dmose (given in IRC)
Updated•19 years ago
|
Flags: blocking1.8b4?
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•