3 Replies Latest reply on May 26, 2006 11:25 AM by Scott Stark

    jnp+http[s] != invocation via http - bug ?

    Jens Elkner Apprentice


      just tried to tunnel jnps via ssh and found out, that it seems to have real security issues:

      1) the initial context lookup is done via https, ok
      2) but any consecutive ctx.lookup is done via plain http://{serveraddr}:80/...
      3) every ejb3 invocation is done via a plain aka unencrypted socket://{serveraddr}:3873

      So either jnps aka https aka jnp+https is totally bogus or its name is totally misleading :(

      I already solved problem 2) incl. the [stupid] RMI behavior of returning always the server address instead of the actually used one (which makes tunneling possible without the need to fake a DNS server, use local NAT wrt. portmapping):

      protected void processRequest(HttpServletRequest request, HttpServletResponse response) ... {
       InvocationContext ctx = ((ClientContainer) Proxy.getInvocationHandler(namingProxy)).getInvocationContext();
       String url = ((HttpInvokerProxy) ctx.getValue(InvocationKey.INVOKER)).getExternalURLValue();
       log.debug("rewriting {0}", url);
       int idx = url.indexOf(':');
       idx = url.indexOf('/',idx+3);
       url = request.getScheme() + "://" + request.getServerName() + ":"
       + request.getServerPort() + url.substring(idx);
       log.debug("new URL: {0}", url);
       ctx.setValue(InvocationKey.INVOKER, new HttpInvokerProxy(url));

      Unfortunately problem 3) is still unresolved: the JMXInvokerServlet always returns a StatelessRemoteProxy, whome's InvokerLocator is set to socket://${serveraddr}:3873 :(

      And I'm not sure, where to tackle that problem. Actually I think, it must be possible to have a look at the request and if it comes in via http[s], it should be possible to set the uri to http[s]://request.getServerName()+ ":" + request.getServerPort() + /invoker/EJBInvokerServlet

      Any hints, where one could start fixing it ?