Re: gfsh over http & authentication

[Jinmei Liao]

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 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 
> 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  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 
> >>> 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  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 
> >
>  wrote:
> 
> > 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 to go back and disconnect / reconnect to
> >>>
> >> fix
> 
> > a
> >
> >> password typo.
> >>>
> >>> As a reference point, does 

Re: gfsh over http & authentication

[John Blum]

@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 
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  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 
>>> 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  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 
>
 wrote:

> 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 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 

>>> 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 

Re: gfsh over http & authentication

[Udo Kohlmeyer]

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  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  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  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 

wrote:

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 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 

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.

Re: gfsh over http & authentication

[Michael William Dodge]

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  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  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  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 
>> wrote:
>>> 
 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 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 
>>> 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 

Re: gfsh over http & authentication

[Kevin Duling]

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 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  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.
>
>

Re: gfsh over http & authentication

[Anthony Baker]

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  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.