directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pepersack, Bob G" <Bob.Pepers...@GDIT.com>
Subject RE: Directory Studio: Backslash in DN breaks studio
Date Fri, 11 Mar 2016 20:14:31 GMT
I'm not checking off any enabled protocols when I save the configuration of the default server.
 I have left all of the settings, except the keystore file and its password, as their default
values (i.e. the only change I've been making is to set the keystore file and its password).
 Is this correct?

I see that "Enable TLS" is checked by default.

I've been working entirely in the default server, and have noticed that I don't get this problem
if I create a new server on the "LDAP Servers" tab.  Are you working in your default server
or a new server that you have created.  If you created a new server, is it possible to install
it as a Windows service?  I can't find how to do that, and I've noticed that it stops when
I quit Studio.

I just changed my default server's LDAP port to 389, but I got that same exception:

Unable to save configuration.
 - Changes could not be saved to the connection.
java.lang.Exception: Changes could not be saved to the connection.
	at org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditorUtils.saveConfiguration(ServerConfigurationEditorUtils.java:370)
	at org.apache.directory.studio.apacheds.configuration.jobs.SaveConfigurationRunnable.run(SaveConfigurationRunnable.java:109)
	at org.apache.directory.studio.common.core.jobs.StudioJob.run(StudioJob.java:85)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)


-----Original Message-----
From: Hal Deadman [mailto:hal.deadman@gmail.com] 
Sent: Friday, March 11, 2016 2:58 PM
To: users@directory.apache.org
Subject: Re: Directory Studio: Backslash in DN breaks studio

Are you checking off any enabled protocols when you save the configuration?
I leave all those blank b/c I get errors when I check any of them.

I am doing start TLS on port 389 rather than LDAPS on 636/10636.

I just check Enable TLS in the server config and when I connect from directory studio I choose
encryption method of start tls and specify port 389. I don't think I needed to install the
cert as trusted in order for directory studio to use it but the cert i issued for the directory
was in my windows trust store so it might have used that.

The error you are getting could just be a SSL trust issue (your client doesn't trust certificate
on server).

On Fri, Mar 11, 2016 at 2:00 PM, Pepersack, Bob G <Bob.Pepersack@gdit.com>
wrote:

> I tried M10 studio and M21 directory with JDK 1.8.-71 and I still get 
> the same exception.  In the modification logs, I see that "ads-keystoreFile"
> has been set with forward slashes in spite of the exception when I try 
> to save.  But, when I try to connect on port 10636, I get this exception:
>
> Error while opening connection
>  - SSL handshake failed.
> org.apache.directory.ldap.client.api.exception.InvalidConnectionException:
> SSL handshake failed.
>         at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.writeRequest(LdapNetworkConnection.java:4149)
>         at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1300)
>         at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1198)
>         at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:365)
>         at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1171)
>         at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:457)
>         at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:303)
>         at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
>         at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
>         at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>
> Also, I have tried escaping the slashes with backslashes and forward 
> slashes without success.
>
> -----Original Message-----
> From: Hal Deadman [mailto:hal.deadman@gmail.com]
> Sent: Friday, March 11, 2016 8:34 AM
> To: users@directory.apache.org
> Subject: Re: Directory Studio: Backslash in DN breaks studio
>
> Are you sure the config editor doesn't work if you are using forward slash?
> I am able to save this as the keystore with M10 studio and M21 directory.
>
> D:/ProgramData/xyz/ldap/instances/default/xyz.jks
>
> I did get different errors with different versions of studio and/or server.
>
> It is stored in ldap under:
>
> dn:
> ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=c
> onfig
> ...
> ads-keystoreFile: D:/ProgramData/xyz/ldap/instances/default/xyz.jks
>
> On Fri, Mar 11, 2016 at 8:18 AM, Pepersack, Bob G 
> <Bob.Pepersack@gdit.com>
> wrote:
>
> > Is there a configuration where I can set my keystore settings with a 
> > text editor, or some other kind of editor?
> >
> > When I build the project from "directory-studio-trunk.zip" with "mvn 
> > clean install -Dmaven.test.skip=true", it throws this exception:
> >
> > [INFO] Scanning for projects...
> > [ERROR] Internal error:
> > org.eclipse.tycho.core.osgitools.OsgiManifestParserException:
> > Exception parsing OSGi MANIFEST
> >
> C:\bit9prog\dev\Installation\directory-studio-trunk\plugins\aciitemeditor\META-INF\MANIFEST.MF:
> > Manifest file not found -> [Help 1]
> > org.apache.maven.InternalErrorException: Internal error:
> > org.eclipse.tycho.core.osgitools.OsgiManifestParserException:
> > Exception parsing OSGi MANIFEST
> > C:\bit9prog\dev\Installation\directory-studio-tru
> > nk\plugins\aciitemeditor\META-INF\MANIFEST.MF: Manifest file not found
> >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166)
> >         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> >         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
> >         at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> orImpl.java:43)
> >         at java.lang.reflect.Method.invoke(Method.java:497)
> >         at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launc
> her.java:289)
> >         at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java
> :229)
> >         at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Lau
> ncher.java:415)
> >         at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java
> > :3
> > 56) Caused by:
> > org.eclipse.tycho.core.osgitools.OsgiManifestParserException:
> > Exception parsing OSGi MANIFEST
> >
> C:\bit9prog\dev\Installation\directory-studio-trunk\plugins\aciitemeditor\META-INF\MANIFEST.MF:
> >  Manifest file not found
> >         at
> >
> org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifestFromD
> irectory(DefaultBundleReader.java:95)
> >         at
> >
> org.eclipse.tycho.core.osgitools.DefaultBundleReader.doLoadManifest(De
> faultBundleReader.java:59)
> >         at
> >
> org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifest(Defa
> ultBundleReader.java:50)
> >         at
> >
> org.eclipse.tycho.core.osgitools.OsgiBundleProject.readArtifactKey(Osg
> iBundleProject.java:147)
> >         at
> >
> org.eclipse.tycho.core.osgitools.OsgiBundleProject.setupProject(OsgiBu
> ndleProject.java:142)
> >         at
> >
> org.eclipse.tycho.core.resolver.DefaultTychoResolver.setupProject(Defa
> ultTychoResolver.java:74)
> >         at
> >
> org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProje
> ctsRead(TychoMavenLifecycleParticipant.java:90)
> >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310)
> >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> >         ... 11 more
> >
> > -----Original Message-----
> > From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
> > Sent: Thursday, March 10, 2016 7:18 PM
> > To: dev@directory.apache.org; users@directory.apache.org
> > Subject: Re: Directory Studio: Backslash in DN breaks studio
> >
> > Le 10/03/16 22:58, Stefan Seelmann a écrit :
> > > On 03/09/2016 07:59 PM, Emmanuel Lécharny wrote:
> > >> Le 09/03/16 18:54, Philip Peake a écrit :
> > >> Can you be a bit more explicit ?
> > >>
> > > Probably same cause as in
> > > https://issues.apache.org/jira/browse/DIRSTUDIO-1087 and
> > > https://issues.apache.org/jira/browse/DIRSERVER-2109
> > >
> > I took some time last week-end to re-think the whole problem. There 
> > are a lot of things we are doing wrong, IMO. Don't get me wrong though :
> > most of the time, it simply works.
> >
> > FTR, I send this mail to the dev list, copying it to the users list.
> >
> > <this is going to be a long mail...>
> >
> > First of all, we need to distinguish the clients from the server. 
> > They are to different beasts, and we should assume the server 
> > *always* receive data that are potentially harmful and incorrect.
> >
> > Then we also need to distinguish String values and Binary values. 
> > The reason we make this distinction is that String values are going 
> > to be encoded in UTF-8 thus using multi-bytes, and also because we 
> > need to convert them from UTF-8 to Unicode (and back).
> >
> > Let's put aside the binary data at the moment.
> >
> > The server
> > ==========
> >
> > Value
> > -----
> >
> > We receive UTF-8 Strings, we convert them to Unicode and now we can 
> > process them in Java. We do need this conversion because we need to 
> > check the values before injecting them in the backend. Doing such 
> > checks in UTF-8 would be very impracticable.
> >
> > There is one critical operation that is done on values when we 
> > process them : we most of the time need to compare them to another value :
> > typically, when we have an index associated with this value, or when 
> > we have a search filter. Comparing two values is not as simple as 
> > doing an lexicographic comparison sadly. We need to 'prepare' the 
> > values accordingly to some very specific rules, and we should also
> 'normalize'
> > those values accordingly to some syntax.
> >
> > A comparison is done following this process :
> >
> > Val 1 -> normalization -> preparation-+
> >                                        \
> >                                         .--> Comparison
> >                                        / Val 2 -> normalization ->
> > preparation-+
> >
> > We can save some processing if one of the two values has already 
> > been normalized or prepared. Actually, we should do that only once 
> > for each value : when they are injected into the server for the 
> > first time. But doing so would also induce some constraint : disk 
> > usage (saving many forms of a data cost space, and time when it 
> > comes to read them from disk. This is all about balance...).
> >
> > Anyway, most of the time, we get a value and we just need to store 
> > it into the backend after having checked its syntax. And that's the key :
> > checking the syntax requires some preparation. Here is how we 
> > proceed when we just need to chck teh syntax :
> >
> > Value --> normalization --> syntax check
> >
> > There is no string preparation.
> >
> > The normalization is specific to each AttributeType. The String 
> > Preparation is the same for all the values.
> >
> >
> > Now, there are two specific use cases : filters, and DN.
> >
> >
> > Filter
> > ------
> >
> > A filter always contains a String that needs to be processed to give 
> > a tuple : <attributeType, value>. There are rules that must be 
> > applied to transform the incoming filter to this tuple. Once we have 
> > created this tuple, we can normalize and prepare the tuple's value : 
> > something that might be complex, especially when dealing with substring matches.
> >
> > So for filter, the process is :
> >
> > fliter -> preProcessing -> Tuple<AttributeType, Value> -> 
> > normalization
> > -> preparation
> >
> >
> > The String preparation is required because the filter's value will 
> > be compared with what we fetch from the backend.
> >
> > DN
> > --
> >
> > The DN is not a String. It's a list of RDN, where each RDN is a list 
> > of AVA, where each AVA is a tuple <attributeType, Value> Although, 
> > as a filter, when it's received, or stored, it's as a String, and 
> > there are some specific rules to follow to get the String being 
> > transformed to
> RDNs.
> > Bottom line, the DN preprocessing is the following :
> >
> > DN String --> preProcessing -> Rdns, AVA, Tuple<AttributeType, 
> > value> [-> normalization -> preparation] (for each AVA)
> >
> > Again, the String preparation is needed because we will store the 
> > RDN into an index, and that requires some comparison (note that it's 
> > not always the case, typically for attributeType with a DN syntax).
> >
> >
> > Comparing values
> > ----------------
> >
> > We saw that we need to normalize and prepare values before being 
> > able to compare them. A good question would be : do we need to 
> > prepare the String beforehand or when we need to compare values ? 
> > That's quite
> irrelevant :
> > it's a choice that need to be make at some point, but it just 
> > impacts the performance and the storage size. We can consider that 
> > when we start comparing two values, they are already prepared 
> > (either because we have stored a prepared version of the String, or 
> > because we have just prepared teh String on the fly before calling the compare method).
> >
> >
> >
> > The Client
> > ==========
> >
> > I will just talk about the Ldap API here, I'm not interested in any 
> > other client.
> >
> > We have two flavors : schema eware and schema agnostic. We also have 
> > to consider two aspects : when we send data to the server, and when 
> > we process the result.
> >
> >
> > Schema agnostic client
> > ----------------------
> >
> > There is no so much we can do here. we have no idea about what can 
> > be the value's syntax, so we can't normalize the value. Bottom line, 
> > here is the basic processing of a value sent to the server :
> >
> > - we don't touch the values. At all. We just convert them from 
> > Unicode to
> > UTF-8
> > - we pre-process filters to feed the SearchRequest. values are 
> > unescaped (ie the escaped chars are replaced by their binary
> > counterpart)
> > - we don't touch the DN
> >
> > Whe values are received from the server, we need to process the data 
> > this way :
> >
> > - we don't touch the values, we just convert them from UTF-8 to 
> > Unicode
> > - we don't touch the DN : it's already in String format, we just 
> > convert them from UTF-8 to Unicode
> >
> > Schema aware client
> > -------------------
> >
> > This is more complex, because now, we can process the values before 
> > sending them to the server. This put some load on the client side 
> > instead of pounding the server with incorrect data that will get
> rejected anyway.
> >
> > - Values : we normalize them, prepare them and check their syntax. 
> > At the end, we convert the original value from Unicode to UTF-8. As 
> > we can see, we lose the normalized and prepared value.
> > - Filter : we unescape them, then we convert them to UTF-8
> > - Dn : we parse it, unescape it, normalizing each value, and at the 
> > end, if the DN is valid, we send the original value as is, after 
> > having converting it to UTF-8
> >
> >
> > As we can see, all what we do is to check the values before sending 
> > them to the remote server, except for the filter.
> >
> > For the received values, we first convert them to Unicode and that's 
> > pretty much it.
> >
> >
> > Escaping
> > --------
> >
> > DN and Filters need some pre-processing called unescaping when we 
> > have to transform them from a String to an internal instance. For 
> > Filter, this is always done on the client side, for the DN is done 
> > on the server side. The idea is to transform those values from a 
> > String (human
> > readable) form to a binary form.
> >
> >
> > What we do wrong
> > ----------------
> >
> > We will only focus on the schema aware API here. This is what we use 
> > on the server side anyway...
> >
> > * First, we are depending on the same API on both side (client and 
> > server). This make things more complex, because the context is different.
> > For instance, there is no need to parse the DN on the client, but we 
> > still do it.  I'm not sure that we could easily abvoid doing so.
> > To some extent, we are penalizing the client.
> >
> > * The most complex situation is when we have to procesds the DN. 
> > This is always done in two phases :
> > - slice the DN into RDNs, the RDNs into AVAs containg Values
> > - apply the schema on each value
> >
> > We coulde easily imagine doing the processing in one single pass.
> > Actually, this is an error not to do so : this cost time, and the 
> > classes are therfore not immutable.
> >
> > * One specific problematic point is when we process escaped chars. 
> > For instance, something like : 'cn=a\ \ \ b' is just a cn with a 
> > value containing 3 spaces. This is what should be returned to the 
> > user, and not a value with only one space. *But* we will be able to 
> > retrieve this value using one of those filters : (cn=a b) or (cn=a  b) or (cn=
> > a         b). Actually the number of spaces is irrelevant when comparing
> > the value, it's not when it comes to send back the value to the user.
> > Again, it has all to see with the distinction between storing values 
> > and comparing values.
> > For filters, we must unescape the String before sending it to the server.
> > The server does not handle the Filter as a String.
> >
> > * The PrepareString class needs to be reviewed. We don't handle 
> > spaces the way it's supposed to be done.
> >
> > Value Class
> > -----------
> >
> > I'm not exactly proud of it. It was a way to avoid having code like :
> >
> >     if ( value instance of String )
> >     {
> >         // This is a String
> >     }
> >     else
> >     {
> >         // This is a byte[]
> >     }
> >
> > so now, we have StringValue and BinaryValue, both of them could be 
> > used with an AttributeType when they are SchemaAware. In retrospect, 
> > I think the distinction between String and Binary values was an error.
> > We should have a Value, holding both, with a flag in it. Chaning 
> > that means we review the entire code, again...
> >
> >
> >
> > Conclusion
> > ==========
> >
> > This is not a pleasant situation. We have some cases where we don't 
> > handle things correctly, and this is largely due to some choices 
> > made a decade ago. Now, I don't think that this should be kept as is.
> > Sometime a big refactoring is better than patching this and that...
> >
> >
> > Now, feel free to express yourself, I would be vert happy to have 
> > your opinion.
> >
> > Many thanks !
> >
> >
>
Mime
View raw message