tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pid *" <...@pidster.com>
Subject Re: Tomcat HeapMemoryUsage MBean question
Date Sat, 08 Sep 2012 08:57:34 GMT
On 7 Sep 2012, at 22:00, Shanti Suresh <shanti@umich.edu> wrote:

> Hi Konstantin,
>
> True.  JMX data can be sensitive.


If you're concerned about security do not use the JMXProxy Servlet at all.
Configure security on an exposed JMX port and then interact with the
JVM by connecting to the port. Scripts written in Groovy, for example,
make this pretty easy to do.


p



>
> I am not a JSP expert.  I created the following "test.jsp" page and have it
> sitting in webapps/manager/.  It doesn't work.  I have the error message
> below the JSP text.  Would you have a suggestion for what I might have in
> this page?
>
> ---------- Start of test.jsp:-----
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "
> http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
>  <title>Test JSP</title>
>  <style type="text/css">
>    <!--
>    BODY
> {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;font-size:12px;}
>    H1
> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
>    PRE, TT {border: 1px dotted #525D76}
>    A {color : black;}A.name {color : black;}
>    -->
>  </style>
> </head>
> <body>
>   <h1>Test JSP</h1>
>   <p>
>    Welcome to Test JSP page.
>   </p>
>
> <jsp:forward page="/jmxproxy/">
> <jsp:param name="get" value="java.lang%3Atype%3DMemory" />
> <jsp:param name="att" value="HeapMemoryUsage" />
> <jsp:param name="key" value="used" />
> </jsp:forward>
>
> </body>
>
> </html>
>
> --------------End of test.jsp---------
>
> On invoking the above JSP page, I get:
>
> -------------Start of HTTP connection output:---
> * About to connect() to localhost port 8090
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 8090
>> GET /manager/test.jsp HTTP/1.1
>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5
> OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>> Host: localhost:8090
>> Accept: */*
>>
> < HTTP/1.1 200 OK
> < Server: Apache-Coyote/1.1
> < Set-Cookie: JSESSIONID=3FC31B7F279B68E4417186B5DC702D68; Path=/manager/;
> HttpOnly
> < Content-Type: text/plain;charset=ISO-8859-1
> < Content-Length: 86
> < Date: Fri, 07 Sep 2012 20:47:51 GMT
> Error - javax.management.MalformedObjectNameException: Key properties
> cannot be empty
> * Connection #0 to host localhost left intact
> * Closing connection #0
>
> -------------End of HTTP Connection output-----
>
> Thanks.
>
>                          -Shanti
>
> On Fri, Sep 7, 2012 at 4:29 PM, Konstantin Kolinko
> <knst.kolinko@gmail.com>wrote:
>
>> 2012/9/7 Shanti Suresh <shanti@umich.edu>:
>>> Hi Christopher, Hi Konstantin,
>>>
>>> On Fri, Sep 7, 2012 at 1:54 PM, Christopher Schultz <
>>> chris@christopherschultz.net> wrote:
>>>
>>>>
>>>> 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.
>>>
>>
>> With "get" you can view someone's password.
>> With "set" you can change it, or change assigned roles.
>>
>> (with certain Realm implementations).
>>
>> There is not much difference.  I think allowing generic "get" or
>> generic "set" is a bad idea.
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message