Hitachi Vantara Pentaho Community Forums
Results 1 to 3 of 3

Thread: Running Pentaho behind a proxy

  1. #1

    Default Running Pentaho behind a proxy

    I'm trying to set up a Pentaho site to be one of several sites behind a common web proxy. Pentaho (1.6) will be the analysis tool, but we have existing applications that we want to use as well. We are moving toward a portal solution, but we have a large codebase that we can't alter quickly. One of our goals was single sign-on, but we have non-standard security tools that don't integrate naturally with Basic or Digest Authentication, so we are providing single sign on by having a .Net application write a cookie that will be used by ACEGI. With a reverse proxy, we can forward .Net and Pentaho so that they appear to come from the same server.

    Since I knew that the proxy would have a different name than the internal server, I set base-url to /pentaho/ so it doesn't really matter if my server is 'testproxy' or 'testpentaho'.

    In the longer term, it could be nice to have a caching proxy so that all of the static content in pentaho-style could be served by something like squid rather than jboss. A proxy that can compress content could also be a nice way to reduce bandwith.

    Issues with HTTPS:
    We set up a proxy running Pound ( Pound handles all of the HTTPS connections and sends HTTP requests to Pentaho. In general, this seems to work quite well. I can access all of the Pentaho site using HTTPS and all of the SSL encryption is done on a separate box. I also have my JSESSION cookie used by Pentaho from the server 'testproxy'. So I can write the cookie in .Net apps that use the same proxy and have Pentaho read the cookie with minimal hassle.

    There was a minor (but frustrating) issue where IE kept complaining about mixed (http and https) content on the pages in the demo site. The issue was that there are JavaScript references to things like "". This seems to be a recurring problem, so I'll add my solution. I use window.location.protocol + "//". This works correctly for both https and http. (I don't want to add the burden of https to Sourceforge if there is no benefit, so hardcoding '" seems wrong.) This worked for me and it should be easy to generalize to any other URL.

    There is a second issue that I don't understand. If there are ACEGI experts that might offer some guidance, I would be grateful. I can type https://testproxy/pentaho/Login and enter my username and password over an HTTPS connections. Assuming that I don't fat finger my password, I connect and get redirected to http://testproxy/pentaho/Home. I would rather redirect to https://testproxy/pentaho/Home so that the user keeps using a secure connection. I can go in by hand and type the "s" after http and have a secure connection for the rest of the session. So, this almost works cleanly.

    I'm left scratching my head not quite sure what to do next. Should I dive into a book on Spring/ACEGI, go through the login.jsp or get a packet sniffer and see what sort of packets are going into and out of the Pound proxy?

  2. #2
    Join Date
    Oct 2006


    Regarding the redirect after login, I took a look at the Acegi Security source code. For the redirect, Acegi Security maintains the scheme (e.g. http or https) used in the request that prompted the login form. In other words, assume you're not logged in. You request a page (via http) that requires login. When you successfully login, you are redirected to a URL using http--because that's what you originally used. My guess is that if you request the original page using https, it will be honored on the redirect.

    I suggest also looking into Acegi Security channel security.

  3. #3

    Default Thanks Matt

    I'll look into that. I appreciate you taking time to look through the ACEGI code and offer direction.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.