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 <kdul...@pivotal.io> 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?
>

Reply via email to