I do believe the connect over http should fail immediately if incorrect or no credentials are supplied. A securePing sounds like a good way to go.
On Thu, Feb 2, 2017 at 12:32 PM, John Blum <jb...@pivotal.io> wrote: > @Udo- > > That is the thing. It is not just UI; the ping Thread is also there to > properly set the state of *Gfsh* such that certain commands are not > inappropriately made available as well (think *Gfsh* scripting, which if I > remember correctly leads to a different type of error... > NotConnectedException (with an appropriate message) vs. whatever the 404 > translated to), regardless of the polling time. > > On Thu, Feb 2, 2017 at 12:22 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > > > Not sure what the correct polling time would be... But we'd want to avoid > > the situation where we poll too often. We could launch our own > ping-attack. > > > > Also, this UX is not UI, so the difference between updating a screen with > > new information vs checking if the connection is still valid... I'd err > on > > the side of caution and say... poll 2s and elgantly deal with a > connection > > failure when submitting an operation. > > > > --Udo > > > > > > > > On 2/2/17 12:07, Michael William Dodge wrote: > > > >> A rule I've heard for UX is that anything over 200 ms is noticeable and > >> anything over 2 s is slow. Unless polling every 500 ms is causing > problems, > >> it might be best to leave it at 500 ms as a decent compromise between > >> efficiency and responsiveness. > >> > >> Sarge > >> > >> On 2 Feb, 2017, at 12:04, John Blum <jb...@pivotal.io> wrote: > >>> > >>> 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) > >>> > >> > > > > > -- > -John > john.blum10101 (skype) > -- Cheers Jinmei
