tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shanti Suresh <>
Subject Re: Tomcat HeapMemoryUsage MBean question
Date Fri, 07 Sep 2012 19:42:09 GMT
Hi Christopher, Hi Konstantin,

On Fri, Sep 7, 2012 at 1:54 PM, Christopher Schultz <> wrote:

> Hash: SHA1
> Shanti,
> I personally think that's a bad idea: just set some simple username
> and password and have your client use it: any decent command-line HTTP
> client should support HTTP BASIC authentication.

Sure.  I can do that.  It just leaves the set operations vulnerable too
though.  I can use digested passwords too, but still my scripts will need
to be hard-coded with the password.

> That's good.
> Sure :-)  Thanks.

> Log it as an enhancement request in Bugzilla. I proposed this kind of
> thing a few months ago though I can't seem to find the thread at the
> moment. It was mildly rejected due to lack of interest, but but it
> seems we have a real use-case where a user wants this capability.

Oh, most certainly, there is a definite use-case for this feature.  And
others will use it heavily once you have the capability.  It just doesn't
seem like a good plan to have the get and set secured the same way.

On Fri, Sep 7, 2012 at 2:35 PM, Konstantin Kolinko

> 2012/9/7 Shanti Suresh <>:
> >
> > So I can somehow secure the "set" but open up the "get" and "qry", I will
> > be in happy curl-land.
> >
> My suggestion would be to write a custom jsp page that will collect
> parameters, validate them and then will do a forward to jmxproxy.
> It is easy to secure a single page. It is much better than allowing
> access to the whole jmxproxy.
> <jsp:forward page="/jmxproxy/">
>  <jsp:param name="set" value="..." />
>   ...
> </jsp:forward>

I see.  I can look at that option.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message