Seems odd to me that the ‘connect’ command is where the credentials are supplied but the failures are only realized when invoking a secure command. So I would need to go back and disconnect / reconnect to fix a password typo.
As a reference point, does ‘connect’ over JMX surface authentication errors? Anthony > On Feb 2, 2017, at 10:37 AM, Kevin Duling <kdul...@pivotal.io> wrote: > > It's been reported in GEODE-2247 that gfsh can connect in a secured > environment without a username/password when using the --use-http flag. > When using a jmx connection, this would immediately prompt for > user/password. > > In the http environment, the connection isn't any less secure. The moment > one attempts to execute a command that an "anonymous user" cannot execute, > they will receive a failure with a message informing them that the user (in > this case anonymous) cannot execute that command. That's all fine and > good, but the UX should probably be to fail instead on the 'connect' when > in a secure environment. > > Opinions? > > The issue is that gfsh uses the 'ping' endpoint to determine connectivity, > which is not secured. Moreover, it starts a connection poll, hitting that > endpoint every 500ms to ensure the connection is still alive. I can't > determine why it's doing this other than to try to wrap an artificial > 'state' in to the stateless nature of REST. The only advantage I see is > that if I kill my server, gfsh knows right away that it's been disconnected > from it. > > I have not yet determined whether or not the socket stays open through all > of this. I suspect that it does or otherwise I'd see a lot of FIN_WAIT > entries in my netstat results. > > One possible solution to this is to implement security in the endpoint. > But ShellCommandsContoller.java doesn't have any security in it. Security > is handled further downstream.
