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 wrote:
> @Udo-
>
> That is the thing. It is not just UI; the ping Thread is also there to
> properly set
@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...
NotConnectedExceptio
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
e
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
> 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
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 coul
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
Yes it does, immediately on the connect. So the behavior is different.
On Thu, Feb 2, 2017 at 10:48 AM, Anthony Baker 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
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
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 a
10 matches
Mail list logo
