need feedback on directory tree design
We're using LDAP to store user profiles. Each person has several associations, and each person has several atrtibutes that are different for each association. (E.g. a person might have an office location in different orgunits.) I don't think a multivalue attribute on the user profile directly will work. We would need to label each attribute in that case. What would be the best way to store such attributes? Can we store these with a separate entry for each peron / ou association? We could reference these separate entries either by the convention that their dn is the dn for the user profile + the attribute, eg. the dn for the person would be "dn: uid=veimot o=aerius.com" and the dn for the attributes relative to the Payroll association would be "dn= uid=veimot, o=aerius.com ou=Payroll". What does the expert say on this? -- - Torgeir
Re: Memory leak in Netscape's LDAP SDK
Just to keep the people with same kind of trouble informed. We replaced the Netscape SDK with Novell's SDK for LDAP. All the said memory problems indicated by both purify and boundschecker disappeared. My Conclusion: If you are using Novell's NDS , then better go with their own sdk. Rashed > Hi , > > We are using Novell NDS and Netscape ldap sdk. > > I seem to be having memory leaks in the Netscape's ldap api's. I am Sent via Deja.com http://www.deja.com/
Constaint Error
I am having a hard time figuring out why I am getting "Constraints Violation" when adding a directory entry on one directory server but not on another. Both servers have the same configuration and schema. Is there any way to get more detail error message from the Perl or Java API? I narrowed it down to the uid attribute. Somehow "martinc" and "krose" just can't be added, everything else is fine. I can't see anything particular about these two uid values. Thanks! Alex
Re: [Fwd: LDAP access in Mozilla]
Dan Mosedale wrote: > if there are plans > to add LDAP access to the address book, we would rather know now. John, the best way to work at Mozilla is to post frequently to the newsgroups and file or take over bugs in bugzilla for each task. There is already an LDAP tracking bug - bug 36557. -- This message is protected by ROT0 encryption and the DMCA. Reading is disallowed and will be prosecuted.
[Fwd: LDAP access in Mozilla]
[Forwarded with permission] > Absolutely; coordinating our work would be a fine thing. I'm in the > process of transitioning to a new job right now where I will be > working full-time on LDAP browser integration, so now is a great time > for us to try and make sure that our work intersects cleanly. > > I noticed that someone from your group (Martin?) had posted some > addressbook-related IDL to one of the groups a while ago. Is that > still relevant to your strategy? > > Dan > Hi Dan, Thanks for the prompt and warm response. Yes, we would like to see the latest code. You can send it me. Currently we are looking at the existing LDAP XPCOM component stuff in the directory/xpcom with a view to using it. We would be more than willing to work alongside you. We will get back to you and to clarify any issues we have and see how we can cooperate. Yes, I work with Paul and Martin. Paul is on vacation soon and I have very recently joined the project after working on the OpenOffice project. I am attaching Paul's latest summary of what we hope to do and how we hope to do it. You can forget everything you have seen up to now. The addressbook.idl strategy from Martin has now been dropped in favour of attempting to use as much of the existing code in Mozilla as we can. Paul's strategy is now to separate the specific database Address Code out so that the LDAP and address book data sources could be added in. Have a look at Paul's document and feel free to comment. We see little or no development taking place in the Address Book sources. We have attempted to find out and I was hoping to use this mail to see if you know different. Again, if there are plans to add LDAP access to the address book, we would rather know now. I will get back to you. John. MozillaAddrBook.pdf
Exporting directory info from MSAD to Netscape AD server
I am working with Netscape Directory server 4.12. What I am trying to accomplish is to push directory data from Microsofts Active Directory server in to the Netscapes AD, both servers are sitting on the same network. Can you recommend a me a good procedure for doing that? Or may be point me to the right direction? I would greatly appreciate it. Max Stepanenko Sent via Deja.com http://www.deja.com/
Re: PSM 2.0 and LDAP in the browser (was Re: PSM 2.0 (PIP) docs now available)
"Nelson B. Bolyard" <[EMAIL PROTECTED]> writes: > Dan Mosedale wrote: > > > So one thing that would be helpful to those of us working on LDAP in > > the browser is the ability to get access to some of the NSS > > functionality for the LDAP C SDK to use. > > > > LDAP in the browser consists of an XPCOM wrapper around the LDAP C > > SDK, which does all the connection management for us under the hood. > > The C SDK itself uses raw or NSPR sockets to do all the work, and I'm > > told that the most recent version interacts with NSS 3.2 directly. > > > Since we want to share as much code as possible, it would be really > > good not to have to link the C SDK against a second copy of NSS > > separate from PSM. So in some ideal world, it seems like the LDAP > > XPCOM wrapper would be able to ask PSM for some set of raw function > > pointers to NSS functions which could then be passed into the LDAP C > > SDK for use. > > > > Comments? > > The LDAP C sdk has always used NSS. In the past, it actually linked its > own copy of NSS into its DSO/DLL. Now, in NSS 3.2, it will simply use the > NSS DSO, and no longer have its own copy. > > The LDAP C SDK developer is one of NSS's main Beta testers. One of the interesting pieces here, as I understand it, is that PSM doesn't use the NSS DSO; it statically links NSS because of an issue related to the symbols that NSS exports. So we'd have to ship two copies of NSS with mozilla, which sort of defeats the code-sharing Dan
Re: [Fwd: LDAP access in Mozilla]
[EMAIL PROTECTED] (Ben Bucksch) writes: > Dan Mosedale wrote: > > > if there are plans > > to add LDAP access to the address book, we would rather know now. > > John, the best way to work at Mozilla is to post frequently to the > newsgroups and file or take over bugs in bugzilla for each task. Heh; actually the main point of my forwarding that was that I thought folks would be interested in the attached PDF. > There is already an LDAP tracking bug - bug 36557. I'll try and add some comments to that and related bugs in upcoming days and weeks regarding what I and others at Netscape are working on and trying to achieve... Dan
Re: [Fwd: LDAP access in Mozilla]
[EMAIL PROTECTED] (Dan Mosedale) writes: > > [Forwarded with permission] > > > Absolutely; coordinating our work would be a fine thing. I'm in the > > process of transitioning to a new job right now where I will be > > working full-time on LDAP browser integration, so now is a great time > > for us to try and make sure that our work intersects cleanly. > > > > I noticed that someone from your group (Martin?) had posted some > > addressbook-related IDL to one of the groups a while ago. Is that > > still relevant to your strategy? > > Thanks for the prompt and warm response. > > Yes, we would like to see the latest code. You can send it me. OK, I'll post the latest datasource in a followup to this thread. As was mentioned in an earlier discussion between Paul and me, the RDF schema that the datasource uses is currently a bit different than the existing addressbook schema. The current datasource schema is essentially a passthrough: any LDAP attribute is represented as an identically named RDF property. It seems like it ought to be pretty easy to make the datasource have attributes in both the existing passthrough namespace as well as the NC-rdf namespace expected by the addressbook. Probably just need to add a translation table into the datasource. > Currently we are looking at the existing LDAP XPCOM component > stuff in the directory/xpcom with a view to using it. Yes, this is the direction we're hoping things will proceed as well. > We would be more than willing to work alongside you. We will get back > to you and to clarify any issues we have and see how we can > cooperate. Fantastic! I'll be posting more stuff here soon with more details about our particular goals. > Yes, I work with Paul and Martin. Paul is on vacation soon and I > have very recently joined the project after working on the OpenOffice > project. I am attaching Paul's latest summary of what we hope to do > and how we hope to do it. You can forget everything you have seen up > to now. The addressbook.idl strategy from Martin has now been dropped > in favour of attempting to use as much of the existing code in > Mozilla as we can. Paul's strategy is now to separate the specific > database Address Code out so that the LDAP and address book data > sources could be added in. Have a look at Paul's document and feel > free to comment. I like that strategy; leveraging the existing code seems like it should get running code significantly sooner. I haven't yet had a chance to look at the PDF file; I'll try and do that tommorrow. Dan
latest LDAP datasource (was Re: [Fwd: LDAP access in Mozilla])
As requested by a few folks, here is the latest nsLDAPDataSource.js
file. It is still not quite working, but getting there.
Peter: this version has a few edits since the one I sent you earlier
today (my time; I guess that'd be yesterday for you). Since jband has
fixed 67258, I've removed debugging cruft related to that, added a few
more comments, and done some more whitespace tweaking. However,
because all of the substantial code changes since the current CVS
revision are yours, would you like to do the honors and check it in so
that the cvsblame doesn't get horked? After it gets checked in, I'll
be able to file another xpconnect bug that this tickles... :-)
Dan
/* -*- Mode: Java; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
* The contents of this file are subject to the Mozilla Public
* License Version 1.1 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an "AS
* IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
* implied. See the License for the specific language governing
* rights and limitations under the License.
*
* The Original Code is the mozilla.org LDAP RDF datasource.
*
* The Initial Developer of the Original Code is Netscape
* Communications Corporation. Portions created by Netscape are
* Copyright (C) 2000 Netscape Communications Corporation. All
* Rights Reserved.
*
* Contributor(s): Dan Mosedale <[EMAIL PROTECTED]>
* Brendan Eich <[EMAIL PROTECTED]>
* Peter Van der Beken <[EMAIL PROTECTED]>
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 or later (the
* "GPL"), in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your
* version of this file only under the terms of the GPL and not to
* allow others to use your version of this file under the MPL,
* indicate your decision by deleting the provisions above and
* replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient
* may use your version of this file under either the MPL or the
* GPL.
*/
const DEBUG = true;
// core RDF schema
//
const RDF_NAMESPACE_URI = "http://www.w3.org/1999/02/22-rdf-syntax-ns#";
const NC_NAMESPACE_URI = "http://home.netscape.com/NC-rdf#";
const LDAPATTR_NAMESPACE_URI = "http://www.mozilla.org/LDAPATTR-rdf#";
// RDF-specific success nsresults
//
const NS_ERROR_RDF_BASE = 0x804f; // XXX is this right?
const NS_RDF_CURSOR_EMPTY = NS_ERROR_RDF_BASE + 1;
const NS_RDF_NO_VALUE = NS_ERROR_RDF_BASE + 2;
const NS_RDF_ASSERTION_ACCEPTED = Components.results.NS_OK;
const NS_RDF_ASSERTION_REJECTED = NS_ERROR_RDF_BASE + 3;
// some stuff from ldap.h
//
const LDAP_RES_BIND = 0x61;
const LDAP_RES_SEARCH_ENTRY = 0x64;
const LDAP_RES_SEARCH_RESULT = 0x65;
const NS_LDAP_SCOPE_BASE = 0;
// ArrayEnumerator courtesy of Brendan Eich <[EMAIL PROTECTED]>
//
function ArrayEnumerator(array) {
this.array = array;
this.index = 0;
}
ArrayEnumerator.prototype = {
hasMoreElements: function() { return this.index < this.array.length; },
getNext: function () { return (this.index < this.array.length) ?
this.array[this.index++] : null; }
}
// nsISupportsArrayEnumerator
//
function nsISupportsArrayEnumerator(array) {
this.array = array;
this.index = 0;
}
nsISupportsArrayEnumerator.prototype = {
hasMoreElements: function() { return this.index < this.array.Count(); },
getNext: function () { return (this.index < this.array.Count()) ?
this.array.GetElementAt(this.index++) : null; }
}
// the datasource object itself
//
const NS_LDAPDATASOURCE_CONTRACTID =
'@mozilla.org/rdf/datasource;1?name=ldap';
const NS_LDAPDATASOURCE_CID =
Components.ID('{8da18684-6486-4a7e-b261-35331f3e7163}');
function nsLDAPDataSource() {}
nsLDAPDataSource.prototype = {
// who is watching us; XXX ok to use new Array?
mObserverList: new Array(),
// RDF property constants.
//
// XXXdmose - can these can actually be statics (ie JS class
// properties rather than JS instance properties)? or would that
// make it hard for the datasource and/or component to be GCed?
//
kRDF_instanceOf: {},
kNC_child: {},
mRdfSvc: {},
// since we implement multiple interfaces, we have to provide QI
//
QueryInterface: function(iid) {
if (!iid.equals(Components.interfaces.nsISupports) &&
!iid.equals(Components.interfaces.nsIRDFDataSource) &&
!iid.equals(Components.interfaces.nsIRDFRemoteDataSource) &&
!iid.equals(Components.interfaces.nsIRDFObserver))
throw Components.results.NS_ERROR_NO_INTERFACE;
return this;
},
Init: function(aURI)
{
Re: [Fwd: LDAP access in Mozilla]
Dan Mosedale wrote: > Heh; actually the main point of my forwarding that was that I thought > folks would be interested in the attached PDF. Duh! I didn't even notice it. > I'll try and add some comments to that and related bugs in upcoming > days and weeks regarding what I and others at Netscape are working on > and trying to achieve... Netscape is working on LDAP, too?? Seems like not only SUn has a communicator problem... -- This message is protected by ROT0 encryption and the DMCA. Reading is disallowed and will be prosecuted.
