I think we should avoid using an exception for normal flow control. I'd provide a link to Ward Cunningham's wiki but his wiki is currently down.
There should be a way to determine if the user has credentials before trying to connect. -Kirk On Thu, Oct 13, 2016 at 2:50 PM, Kevin Duling <[email protected]> wrote: > I'm working on GEODE-1959 > <https://issues.apache.org/jira/browse/GEODE-1959> and > the use case goes like this: > > Create your gemfire.properites with a security manager. For example: > > > security-manager=org.apache.geode.security.templates. > SampleSecurityManage > > But do not provide a username and password within it. Point to a > security.json file that contains users and roles. My startup line within > gfsh goes like this: > > *gfsh>*start locator --name=loc --classpath=/Users/kduling/geode/run > > --properties-file=./gemfire.properties > > > Then start a server with security: > > *gfsh>*start server --name=secured --classpath=/Users/kduling/geode/run > > --properties-file=./gemfire.properties --locators=127.0.0.1[10334] > > > This produces a GemFireSecurityException because there are no login > credentials set. The entire stacktrace goes: > > objc[2117]: Class JavaLaunchHelper is implemented in both > > /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/bin/ > java > > and > > /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ > libinstrument.dylib. > > One of the two will be used. Which one is undefined. > > Exception in thread "main" > > org.apache.geode.security.GemFireSecurityException: Failed to find > > credentials from [10.0.2.35(secured:2117):1025] > > at > > org.apache.geode.distributed.internal.membership.gms. > membership.GMSJoinLeave.attemptToJoin(GMSJoinLeave.java:416) > > at > > org.apache.geode.distributed.internal.membership.gms. > membership.GMSJoinLeave.join(GMSJoinLeave.java:314) > > at > > org.apache.geode.distributed.internal.membership.gms.mgr. > GMSMembershipManager.join(GMSMembershipManager.java:662) > > at > > org.apache.geode.distributed.internal.membership.gms.mgr. > GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:749) > > at > > org.apache.geode.distributed.internal.membership.gms. > Services.start(Services.java:183) > > at > > org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory. > newMembershipManager(GMSMemberFactory.java:104) > > at > > org.apache.geode.distributed.internal.membership.MemberFactory. > newMembershipManager(MemberFactory.java:92) > > at > > org.apache.geode.distributed.internal.DistributionManager.< > init>(DistributionManager.java:1092) > > at > > org.apache.geode.distributed.internal.DistributionManager.< > init>(DistributionManager.java:1144) > > at > > org.apache.geode.distributed.internal.DistributionManager. > create(DistributionManager.java:521) > > at > > org.apache.geode.distributed.internal.InternalDistributedSystem. > initialize(InternalDistributedSystem.java:657) > > at > > org.apache.geode.distributed.internal.InternalDistributedSystem. > newInstance(InternalDistributedSystem.java:297) > > at > > org.apache.geode.distributed.DistributedSystem.connect( > DistributedSystem.java:237) > > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:229) > > at > > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProv > ider.createCache(DefaultServerLauncherCacheProvider.java:55) > > at > > org.apache.geode.distributed.ServerLauncher.createCache( > ServerLauncher.java:783) > > at > > org.apache.geode.distributed.ServerLauncher.start( > ServerLauncher.java:703) > > at > > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633) > > at > > org.apache.geode.distributed.ServerLauncher.main( > ServerLauncher.java:184) > > > To resolve this, I was planning on catching the exception at > DistributedSystem.connect() and then prompting for the username/password > similar to what is done in ShellCommands.jmxConnect(). > > Does anyone see a problem with this or have a recommendation for a better > approach? >
