You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Wren:DS / OpenDJ Control Panel application does not appear to properly handle custom X-ENUM syntaxes; when they are defined in the server, the Control Panel erroneously flags the schema as being incomplete and will not provide a listing of the directory or the schema.
Steps to Reproduce
Install Wren:DS, being sure to create at least a root entry for the DC.
Define an attribute type that uses the new X-ENUM syntax (reference the SunDS article mentioned earlier). You can create the syntax through either the ldapmodify CLI, or by editing 99-user.ldif (place it AFTER the X-ENUM syntax definition).
Restart Wren:DS.
Attempt to connect to the server with Wren:DS / OpenDJ Control Panel.
Expected Results
Control Panel connects to the server without error.
If you browse the schema using the Control Panel application, you will find the OID of the X-ENUM syntax under "Attribute Syntaxes" in the "Manage Schema" window.
Actual Results
Control Panel connects but displays errors.
The error displayed is:
Error Reading Configuration
The definition for the attribute type with OID 1.3.6.1.4.1.32473.5 declared that it should have a syntax with OID 1.3.6.1.4.1.32473.4. No such syntax is configured for use in the Directory Server
Additional Info
Anecdotally, it seems like this might be fixed in the 4.0 branch, according to https://bugster.forgerock.org/jira/browse/OPENDJ-3252. However, simply cherry-picking aaf3145 (the commit cited in the comments for that ticket) on to the 3.0 SDK does NOT solve the issue for 3.x. There was likely a larger re-factor of this code that addressed it.
The text was updated successfully, but these errors were encountered:
GuyPaddock
changed the title
X-Enum Syntaxes Crash Control Panel During Schema Parsing
Bug: X-Enum Syntaxes Crash Control Panel During Schema Parsing
Feb 2, 2018
The Control Panel and the Server both load a "bootstrap" syntaxes before they actually parse schema / load remote schema. What's odd is that the control panel then does the extra step of trying to hold on to those core syntaxes, at the expense of ignoring syntaxes from the server that don't fall under a specific OID (the OpenDS OID).
But... two issues:
The code does a contains() search rather than a startsWith() search, so technically if you put in an OID for a syntax that just happens to contain the base OID anywhere within it's OID (i.e. middle or end), that check will pass.
The filter causes the app to ignore loading all custom syntaxes from the server config.
It seems like we should just be able to remove the filter, but I'm open to ideas. (Indeed, I was able to capture the screenshot I posted under the "expected results" section just by removing the check).
Kortanul
changed the title
Bug: X-Enum Syntaxes Crash Control Panel During Schema Parsing
[3.0] Bug: X-Enum Syntaxes Crash Control Panel During Schema Parsing
Mar 7, 2018
Kortanul
changed the title
[3.0] Bug: X-Enum Syntaxes Crash Control Panel During Schema Parsing
Bug: X-Enum Syntaxes Crash Control Panel During Schema Parsing
Apr 18, 2019
Affected Version: 3.0
Summary
The Wren:DS / OpenDJ Control Panel application does not appear to properly handle custom
X-ENUM
syntaxes; when they are defined in the server, the Control Panel erroneously flags the schema as being incomplete and will not provide a listing of the directory or the schema.Steps to Reproduce
X-ENUM
syntax (for example: https://docs.oracle.com/cd/E19476-01/821-0509/enumeration-syntax-extension.html). You can create the syntax through either theldapmodify
CLI, or by editing99-user.ldif
.X-ENUM
syntax (reference the SunDS article mentioned earlier). You can create the syntax through either theldapmodify
CLI, or by editing99-user.ldif
(place it AFTER theX-ENUM
syntax definition).Expected Results
X-ENUM
syntax under "Attribute Syntaxes" in the "Manage Schema" window.Actual Results
Additional Info
Anecdotally, it seems like this might be fixed in the 4.0 branch, according to https://bugster.forgerock.org/jira/browse/OPENDJ-3252. However, simply cherry-picking aaf3145 (the commit cited in the comments for that ticket) on to the 3.0 SDK does NOT solve the issue for 3.x. There was likely a larger re-factor of this code that addressed it.
The text was updated successfully, but these errors were encountered: