> The connection probably doesn't need to poll every 500ms. 500 ms provided a good (nearly consistent) UX for the user to know almost instantly that the Manager went away, like the JMX counterpart. 2s is arguable; 5s is probably too long as the user could already be typing another command that is not available. In that case they might get another kind of error (don't recall for sure). Anyway, food for thought.
If another endpoint is needed (though I cannot imagine why) perhaps ` securePing()` would be more descriptive and still offer up an alternative route. On Thu, Feb 2, 2017 at 11:55 AM, Kevin Duling <kdul...@pivotal.io> wrote: > Good to know some history on it. The connection probably doesn't need to > poll every 500ms. I would think 2 seconds or even 5 seconds would be > sufficient in the general case. > > If we make ping require authentication, it may resolve the issue. But I'm > not sure that's the right thing to do. We could create a 'ping2' endpoint > (with some better name that I cannot currently think of) that does require > auth for this thread to validate the connection. > > On Thu, Feb 2, 2017 at 11:49 AM, John Blum <jb...@pivotal.io> wrote: > > > 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) > > > -- -John john.blum10101 (skype)
