I saw it with 3.0.6 and 3.0.8 too. I'm guessing it is due to the addition of the alias property on the service registration that was part of https://issues.apache.org/jira/browse/KARAF-2634
On Fri, Feb 24, 2017 at 12:03 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > I don't think it's only Karaf 4.1.0, I'm pretty sure it was already the > case on 4.0.x. > > Regards > JB > > > On 02/24/2017 08:48 AM, Christian Schneider wrote: > >> I can reproduce the issue: >> >> Start plain karaf 4.1.0 >> >> feature:install webconsole pax-war >> >> Acess http://localhost:8181/gogo/ >> >> If I use http://localhost:8181/gogo >> I get a NPE like below. >> >> Christian >> >> java.lang.NullPointerException >> at org.apache.felix.webconsole.AbstractWebConsolePlugin.renderT >> opNavigation(AbstractWebConsolePlugin.java:681) >> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(A >> bstractWebConsolePlugin.java:190) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder >> .java:845) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilte >> r(ServletHandler.java:1772) >> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.do >> Filter(WebSocketUpgradeFilter.java:193) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilte >> r(ServletHandler.java:1759) >> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHan >> dler.java:582) >> at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletH >> andler.doHandle(HttpServiceServletHandler.java:70) >> at org.eclipse.jetty.server.handler.ScopedHandler.handle(Scoped >> Handler.java:143) >> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHa >> ndler.java:548) >> at org.eclipse.jetty.server.session.SessionHandler.doHandle( >> SessionHandler.java:226) >> at org.eclipse.jetty.server.handler.ContextHandler.doHandle( >> ContextHandler.java:1180) >> at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext. >> doHandle(HttpServiceContext.java:284) >> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHand >> ler.java:512) >> at org.eclipse.jetty.server.session.SessionHandler.doScope( >> SessionHandler.java:185) >> at org.eclipse.jetty.server.handler.ContextHandler.doScope( >> ContextHandler.java:1112) >> at org.eclipse.jetty.server.handler.ScopedHandler.handle(Scoped >> Handler.java:141) >> at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerC >> ollection.handle(JettyServerHandlerCollection.java:80) >> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(Handl >> erWrapper.java:134) >> at org.eclipse.jetty.server.Server.handle(Server.java:534) >> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel. >> java:320) >> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConne >> ction.java:251) >> at org.eclipse.jetty.io.AbstractConnection$ReadCallback. >> succeeded(AbstractConnection.java:283) >> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest. >> java:110) >> at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChann >> elEndPoint.java:93) >> at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume >> .executeProduceConsume(ExecuteProduceConsume.java:303) >> at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume >> .produceConsume(ExecuteProduceConsume.java:148) >> at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume >> .run(ExecuteProduceConsume.java:136) >> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(Queued >> ThreadPool.java:671) >> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedT >> hreadPool.java:589) >> at java.lang.Thread.run(Thread.java:745) >> >> >> >> On 23.02.2017 23:28, Kevin Schmidt 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 >>> >> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
