Back in the day, I introduced this "polling thread" to determine whether *Gfsh* was still connected, since as you say, in a HTTP "stateless" environment and in the absence of a "persistent" connection, it otherwise does not know.
So, to simulate the behavior of *Gfsh* when connected via JMX RMI, I needed to poll the Manager. That way when the Manager was no longer available, it would display that *Gfsh* was no longer connected AND that the commands that "require a connection" (e.g. `list region`) were no longer available... again preserving the existing behavior in HTTP mode. Security (basic auth) had not been implemented in *Gfsh* at that time when I created the Management REST API (or rather, it is more accurate to say... REST-like; it's not a true REST-ful interface to be precise, which is one reason it never was made public for users to consume, though it could have been, providing we introduce the proper notion of REST-ful resources abstractions and change the endpoints (URIs) appropriately; anyway...). -j On Thu, Feb 2, 2017 at 11:08 AM, Kevin Duling <kdul...@pivotal.io> wrote: > Yes it does, immediately on the connect. So the behavior is different. > > On Thu, Feb 2, 2017 at 10:48 AM, Anthony Baker <aba...@pivotal.io> wrote: > > > 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. > > > > > -- -John john.blum10101 (skype)
