> From : Shawn McKinney [mailto:[email protected]] > Sendt: 6. januar 2016 16:06 > Til: [email protected] > Emne: Re: Handling missing connection to LDAP > > > > On Jan 6, 2016, at 8:52 AM, Emmanuel Lécharny <[email protected]> > wrote: > > > > Le 06/01/16 15:00, Jan Sindberg a écrit : > >> If there is no connection to the LDAP, then it is no longer possible to > create an AccessMgrFactory. > >> > >> First we get: > >> org.apache.directory.fortress.core.CfgRuntimeException: static init: > >> Error loading from cfg file: [fortress.properties] > >> SecurityException=org.apache.directory.fortress.core.FinderException: > >> getConfig dn [cn=DEFAULT,ou=Config,dc=example,dc=com] caught > >> LdapException=INVALID_CREDENTIALS: Bind failed: ERR_316 Directory > >> service is not started., errCode=127 > >> > >> On subsequent calls we get: > >> java.lang.NoClassDefFoundError: Could not initialize class > >> org.apache.directory.fortress.core.AccessMgrFactory > >> > >> Is there a way to handle this and make the Fortress core api reconnect > later? > > > > Complicated... > > > > Fortress is storing all the Authz information in a remote server, and > > if it's not reachable, then you won't be able to make any decision. > > > > AFAIR, we had internal discussion about setting up a local cache > > within the API to allow Fortress to keep going even if the remote LDAP > > server is down. I'm not sure it's in Fortress atm, and I'm not sure we > > decided anything about such an addition... > > > > Shawn ? > > I think it would be a lot of work to satisfy a corner case. But you might > wonder why instantiating a manager component is hitting the remote server > in the first place. The reason is fortress stores much of its parameters on > the > remote server itself in a configuration node. > > For explanation check out this writeup: > https://github.com/apache/directory-fortress-core/blob/master/README- > CONFIG.md > > The runtime is in the process of pulling back that config info when it gets > the > connection error and gives up. > > There might be a case where we want to delay hitting that server, or maybe > allow it to retry later, i.e. at regular intervals. Not as complicated as > caching > the information, but tricky. It would require rewiring how the configuration > subsystem and ldap pooling mechanisms work. Worth considering, but we > need to be careful here, no guarantees against overcomplicating or creating > new problems. > > Shawn
The no-go of a local cache is that security is always about the least priviliges. We don't want to let users continue for "too long" when we chance their permissions on the fly - all because of a network or server problem. Then it is better to not give access at all. But the problem I encounter here is that fortress will never again be able to connect if the first connection fails. I guess it has something to do with classloader? The subsequent java.lang.NoClassDefFoundError comes even when the LDAP is running again. This means that we will have to restart the whole web application in order to get it working again - and that is not a viable option because it will affect many other users. // Jan
