It appears this issue may have been introduced as a result of issue 2634 ( https://issues.apache.org/jira/browse/KARAF-2634). The change log shows an alias property was added to the plugin service registration which to my understanding, would result in the extender whiteboard publishing the endpoint at the specified URI. The subject of the ticket says it was just to eliminate a warning, so was it really desired to cause this duplicate registration? Is the fix for this issue to just remove the alias from the registration?
On Thu, Feb 23, 2017 at 2:28 PM, Kevin Schmidt <[email protected]> wrote: > Hi, > > I've come across a situation where the Gogo console ends up being > accessible at a URL that is unsecured. This is of course not a good thing > ... > > When I install a base Karaf 4.0.8 (and 3.0.8 too it appears) and install > the webconsole feature, I'm able to go to http://localhost:8181/system/ > console and it requires authentication, and I can navigate to the Gogo > console (http://localhost:8181/system/console/gogo) and everything works > fine. If I try to go to the Gogo console URL directly in a new browser > session, it also requires authentication. All is good. > > But if I install the pax-war feature, problems arise. All of the above > works fine, but the Gogo console is now available at > http://localhost:8181/gogo/ and worse, it doesn't require > authentication. Prior to installing pax-war, hitting that address would > yield a 404. > > It appears what is happening is that the Gogo console plugin registers its > servlet in the service registry with an alias property set to "/gogo" and > the Pax Web Extender Whiteboard sees this and publishes the servlet at an > endpoint using that alias, and does so unsecured. > > I'm not sure if the issue is the Gogo plugin registering itself with an > alias so the extender whiteboard sees it and publishes it, or if the > extender whiteboard is supposed to be smart enough to not publish the new > endpoint, or at least it should do it secured. But it is probably pretty > common to have a Karaf install with webconsole and pax-war features > installed, and if so, this security hole is there to be exploited. > > The workaround we are doing for now is to stop the Gogo plugin bundle as > we don't really need to use it, but I wonder if other endpoints are getting > automatically published through this mechanism that might also be a > surprise? > > What is the correct fix for this? > > Thanks, > > Kevin >
