PDA

View Full Version : Running under SSL?



DanielG
04-28-2006, 08:55 AM
Greetings,

Posting this in case someone has some experience of this and maybe able to offer some advice:


I have a succesful install of Pentaho running on Jboss4.0.2 on win2003 server. I have a presentation coming up to show off Pentaho, but require that it runs under SSL to show encryption taking place between server and browser.

I have managed to configure tomcat55.sar and pentaho to operate under port 8443 as https

Whilst this works fine with Mozilla, I am experiencing an old favourite "message" with IE, namely:

"site contains mix of secure/insecure items do you wish to continue" of course not once, but LOADS of times.

I think this is down to the various solution elements being accessed in the Pentaho_Solutions directory - which is of course outside of the jboss engine. E.g when Pentaho pulls loads the images for each solution, these are outside of the SSL connection and therefore prompting I.E to give the warning.

Is my assumption correct?

If so - is there a workaround for this or has someone experienced a similar situation.

Would be most grateful if anyone has some input..

Regards to everyone using/working on for this very exciting project.

Daniel

mbatchelor
04-28-2006, 09:26 AM
I don't believe that's the case. Perhaps your base URL (check the web.xml) is still pointing at port 8080, or perhaps there are some embedded port 8080's hanging around.

DanielG
04-28-2006, 10:43 AM
Marc,

Thank you so much for replying,

It is a huge relief to read that my assumption is wrong and I have probably done something silly to cause the problem.

I have checked the web.xml in web-inf dir of pentaho-webapp prior to building pentaho.war. The value of Base URL is correctly set.

I am somewhat of a novice, so excuse this question:

When you refer to "embedded port 8080's" hanging around - could you give me an example, so I know where to look..

The only other place I can think that port 8080 is referred to is in the tomcat55.sar server.xml when it is set as a connector alongside the 8443 connector.

mbatchelor
04-28-2006, 12:17 PM
Well, to the best of my recollection, it works fine with the connector in the server.xml being specified like this:

<Connector port="80" address="${jboss.bind.address}"
maxThreads="250" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"/>


And then accessing the server like:

https://someserver/pentaho/

Then the web.xml would have the configuration parameter simply set to:

https://someserver/pentaho/

And of course, the Connector for port 8443 would need to be uncommented. I haven't tried redirecting https over port 8080, so I don't have any information on whether that works.

As for spurious 8080's (or other mischief), what I would do is do a view source on the HTML page that finally gets rendered, and look at all the images and such to see what port they're being accessed by.

I'm pretty sure that's all I had to do to work things through ssl.

I hope this helps,

Marc

DanielG
05-01-2006, 03:59 AM
Thanks..
To save my sanity after hours of routing around...

1)The warning about secure/insecure items is only in I.E
2)Regardless if I choose yes/no the page rendered (and source) is identical
3)The only difference is an I.E padlock image that appears
4) commented out the 8080 port connector to rule that traffic out (no difference)

****ok - given up trying to paste code in here**

Post edited by: danielG, at: 05/01/2006 08:34

DanielG
05-01-2006, 04:38 AM
Attached key settings of configuration:

would be great if I could get to the bottom of this little mystery.

Any help - greatly appreciated.


Daniel. http://forums.pentaho.org/archived_att/files/keysettings.txt

mbatchelor
05-01-2006, 05:18 AM
Try the following:

a- Change your base URL to remove the port:

https://me.myserver.co.uk/pentaho

b- Only access the server from IE with:

https://me.myserver.co.uk/pentaho

I believe the port is implied by the https. You shouldn't specify the port (to my recollection).

Let me know if this makes a difference.

DanielG
05-01-2006, 06:35 AM
Thanks Marc,

This is what I did:

1)Edited base url in web.xml in web_inf directory removing port:

https://me.myserver.co.uk/pentaho

2)Rebuilt and deployed the war file

3)made sure both http and https connectors were uncommented

3)Tried to access pentaho using:

https://me.myserver.co.uk/pentaho

But it didn't like it - went straight to a 404

by including the port number I could navigate to Pentaho but the content did not render with the new base url (i.e no port number)

- I attach an example of the source that is generated after I permit unsecured items. http://forums.pentaho.org/archived_att/files/Navigate.txt

Post edited by: danielG, at: 05/01/2006 10:36

DanielG
05-01-2006, 09:52 AM
Marc,

I believe I have tracked the mischief down.

There is a piece of javascript at the top of template.html in system/custom directory of pentaho-solutions.

This appears to reference external sforge image - hence the mix of secure / nonsecure items.

Thank you for your patience and speedy replies.

I hope this exchange helps someone else in the future.

Kind regards,

Daniel.

RobertFolkerts
10-31-2007, 12:21 PM
When giving the paths, I'm assuming that most people take the pentaho sample site and rename the 'war' directories and start morphing the working demo into a custom site.

As noted in this post, there are some references to sflogo.php on the sourceforge site in the demo site. It turns out that Sourceforge will serve these images under both http: and https: so you want to have the browser use the appropriate protocol. If you go into the js (and jsp pages with javascript tags) in the pentaho.war and pentaho-style.war, you can globally replace all of the hardcoded 'http:' in URL strings with window.location.protocol +
This seems cleaner than hardcoding the links for either http: or https:.

codek
08-04-2008, 11:08 AM
I also have this problem with https and IE. Any ideas?

We've packet sniffed and can't find the offending url!

What javascript was your problem in?

Thanks!
Dan