Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable Basic authentication with collect server #214

Closed
GoogleCodeExporter opened this issue Jun 21, 2015 · 3 comments
Closed

Enable Basic authentication with collect server #214

GoogleCodeExporter opened this issue Jun 21, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

Currently it is not possible, to secure the monitoring-URL with basic 
authentication when you want to use a collect server. Because the ip-adress of 
my collect server is not known upfront, IP-whitelists are not an option for me.

I added a patch for javamelody-core, which allows you to provide the username 
and password for Basic authentication in the style 
http://username:password@hostname:port/context. This is of course not the most 
secure way, but sufficient for my scenario.

For Base64-encoding i added the apache commons-codec library to the pom. It was 
not possible for me to easily understand the build.xml, so this has to be done 
by someone else.

I also added the old java.net repository in the pom to solve a dependency 
problem with javax.transaction.jta.

Regards,
Ralf

Original issue reported on code.google.com by purnhar@gmail.com on 6 May 2012 at 6:07

Attachments:

@GoogleCodeExporter
Copy link
Author

Adding the java.net repository in the pom is a No way, because it is 
discouraged to publish in Maven central with external repositories in the pom, 
and because it may slow down or block builds in Maven (for example, 
maven.glassfish.org was stopped for months and without much information).

But I have upgraded the pom to hibernate-core 3.6.9.Final which should fix the 
problem with jta 1.0.1B. Note: hibernate-core is an optional (not transitive) 
dependency which is there only to compile the HibernateBatcherFactory class.

For Base64, I do not want to add commons-codec as a compile dependency for all 
javamelody users.
So I would prefer to include in sources a copy of this codec for example:
http://www.source-code.biz/base64coder/java/

I will do that if you are ok.

Original comment by evernat@free.fr on 9 May 2012 at 9:59

  • Changed state: Accepted
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

Thank you for your quick response. I'm very fine with your decisions. I added 
the dependencies because it was just was the easiest way for me to test the 
authentication code.

I'm looking forward for a new version of javamelody with the authentication 
feature.

Original comment by purnhar@gmail.com on 9 May 2012 at 11:57

@GoogleCodeExporter
Copy link
Author

It is now committed in trunk (revision 2810 and revision 2813) and ready for 
the next release (1.38).

I have made a new build of the collect server from the trunk including that and 
it is available at:
http://javamelody.googlecode.com/files/javamelody-20120511.war
(There is no need to change the version of javamelody in the monitored webapp 
to enable this.)

Doc to be added in the wiki (UserGuideAdvanced):
    Instead of using {{{allowed-addr-pattern}}}, you may want to secure access with http basic authentication (username and password) in the monitored application. For that, add the following in the {{{web.xml}}} file of the monitored application:

{{{
        <login-config>
                <auth-method>BASIC</auth-method>
                <realm-name>Monitoring</realm-name>
        </login-config>
        <security-role>
                <role-name>monitoring</role-name>
        </security-role>
        <security-constraint>
                <web-resource-collection>
                        <web-resource-name>Monitoring</web-resource-name>
                        <url-pattern>/monitoring</url-pattern>
                </web-resource-collection>
                <auth-constraint>
                        <role-name>monitoring</role-name>
                </auth-constraint>
        </security-constraint>
}}}

    The realm and the user used by the collect server must be defined in the monitored application server, and the user must have the "monitoring" role to have access. For example, if tomcat is used with the default realm in the monitored application server, modify the content of the conf/tomcat-users.xml file as follows: 

{{{
        <?xml version='1.0' encoding='utf-8'?>
        <tomcat-users>
             <role rolename="monitoring"/>
             <user username="monitoring" password="monitoring" roles="monitoring"/>
        </tomcat-users>
}}}

    Then, when you add the monitored application in the collector server, define the username and the password in the URL. For example, the URL of the monitored application, as given to the collect server, could be:
    http://myusername:mypassword@myhost:8080/mywebapp

Original comment by evernat@free.fr on 11 May 2012 at 4:41

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant