[
https://issues.apache.org/jira/browse/DIRSERVER-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1787.
------------------------------------------
Resolution: Invalid
I have added a test that demonstrates that with the correct entries, the data
are protected against modification by the user we just created.
See http://svn.apache.org/viewvc?rev=1427891&view=rev
> LdifFileLoader does not load a specific LDIF configuration
> ----------------------------------------------------------
>
> Key: DIRSERVER-1787
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1787
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.5, 2.0.0-M8
> Reporter: Jon Russell
>
> My goal is to create a user with read-only access.
> I have two ldifs that I use to acheive this, one modifies the area that I
> want to grant access to:
> version: 1
> dn: ou=system
> changetype: modify
> add: administrativeRole
> administrativeRole: accessControlSpecificArea
> And the other creates the user:
> dn: cn=enableSearchForAllUsers,ou=system
> objectClass: top
> objectClass: subentry
> objectClass: accessControlSubentry
> subtreeSpecification: {}
> cn: enableSearchForAllUsers
> prescriptiveACI: { identificationTag "enableSearchForAllUsers", precedence
> 14, authenticationLevel simple, itemOrUserFirst userFirst: { userClasses {
> allUsers }, userPermissions { { protectedItems {entry,
> allUserAttributeTypesAndValues}, grantsAndDenials { grantRead, grantReturnDN,
> grantBrowse } } } } }
> # User account
> dn: uid=READER ,ou=users,ou=system
> cn: READER
> sn: Reader
> uid: READER
> uidNumber: 10000
> gidNumber: 10000
> objectClass: top
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> userPassword: secret
> When I import both of these ldifs using Apache Directory Studio, it works as
> I expect -- the user is created, and it has read only access.
> However, when I load the same files, in the same order, using LdifFileLoader:
> LdifFileLoader ldifLoader = new
> LdifFileLoader(service.getAdminSession(), workingSchemaPath);
> ldifLoader.execute();
> The result is not the same. No error messages are given, the end result is
> that the user is created, but with no read-only access. Since the user is
> created, I know that it's loading the ldifs from the proper place, and I
> haven't had trouble with other modification-based ldifs in the past. Do you
> know why this discrepancy would be there, and if there's anything I can do to
> get around it? It is difficult since there don't appear to be any errors, so
> I'm not sure what to search for...
> For further reference, here is the full function that I use the
> ldiffFileLoader in:
> /**
> * Load a specific LDIF
> *
> * @param ldifFileName The name of the LDIF file
> * @param classloaderPath The classloader accessible path of the ldif file
> * @throws Exception
> */
> public void loadLDIF (String ldifFileName, String classloaderPath) throws
> Exception {
> InputStream schemaStream = null;
> classloaderPath = classloaderPath + "/" + ldifFileName;
> // support for DEVELOPMENT environment
> if (EnvironmentalConstants.REPO_TOP != null) {
> String schemaPath = EnvironmentalConstants.REPO_TOP +
> "/src/server" + classloaderPath;
> OfmLogHandler.INFO ("Trying to use ldif at %s", schemaPath);
> try {
> schemaStream = new FileInputStream (schemaPath);
> OfmLogHandler.INFO ("Using development ldif at %s",
> classloaderPath);
> } catch (Exception e) {
> OfmLogHandler.WARNING ("initSchema: Development mode, but
> cannot find schema file at %s", schemaPath);
> OfmLogHandler.WARNING ("Exception: %s", e.getMessage ());
> schemaStream = null;
> }
> }
> // support for PRODUCTION environment (or DEVELOPMENT when no schema
> file is found)
> if (schemaStream == null) {
> schemaStream = this.getClass ().getResourceAsStream
> (classloaderPath);
> OfmLogHandler.INFO ("Using production ldif at %s",
> classloaderPath);
> }
> // If we can't find the schema using the logic above, we're in
> serious trouble
> if (schemaStream == null) {
> OfmLogHandler.SEVERE ("initSchema: Unable to find schema file.
> Cannot proceed.");
> System.exit(1);
> }
> // put contents of the schema stream into the working file
> String workingSchemaPath = service.getWorkingDirectory() + "/" +
> ldifFileName;
> try {
> FileOutputStream workingSchemaStream = new FileOutputStream
> (workingSchemaPath);
> IOUtils.copy (schemaStream, workingSchemaStream);
> workingSchemaStream.close ();
> } catch (Exception e) {
> OfmLogHandler.SEVERE ("initSchema: Unable to write to working
> schema file (%s). Cannot proceed.", workingSchemaPath);
> OfmLogHandler.SEVERE ("Exception: %s", e.getMessage ());
> e.printStackTrace ();
> System.exit (1);
> }
> OfmLogHandler.DEBUG ("Loading working schema from: %s",
> workingSchemaPath);
> LdifFileLoader ldifLoader = new
> LdifFileLoader(service.getAdminSession(), workingSchemaPath);
> ldifLoader.execute();
> OfmLogHandler.INFO("LDAP ldif information loaded from %s",
> workingSchemaPath);
> }
> Thanks,
> Jon Russell
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
