Display (javascript?) erros on IE when accessing through reverse proxy

[MICHAIL MOUDATSOS, geändert vor 12 Jahren.]

Hello all

I have installed Liferay 6.0.6 and in front of it, a reverse proxy using Apache. They both reside on the same machine. From that machine, when I access my web application using https://machine-ip/home I can't see my company logo (I see the the company name instead) and the CSS of my sign in portlet and the language portlet is broken (e.g. sign-in portlet has no background color). Their CSS is defined in my deployed theme. On the contrary, when I access the application server directly, that is using https://machine-ip:8443/home the company_logo resource is shown as it should and CSS works. Moreover, when I log in as admin, the dockbar drop down lists (e.g. Manage menu's drop down lists) won't work if I access through reverse proxy but will work If I access the app. server directly. This behavior concerns IE

Apart from those, I have (javascript?) errors on IE that prevent my page iterator's page links to work (on a datatable) on another page, an error which appears on both URLs (through proxy or directly on app server). I'm afraid this might be a problem related to ICEfaces that I use to build the portlet of that page.

Note that the existence of SSL setup probably has nothing to do with it because I had the same problems when I first set everything up over http.

What approach should I take in order to solve these problems?

-Should I look if there's something missing from my reverse proxy configuration? I don't know if it is relevant at all, but I also tried with ajp:// instead of https:// in my httpd.conf file, at ProxyPass and ProxyPassReverse directives, to no avail.

-Is this purely a javascript - IE problem? But then why some things work when accessing the app. server directly and do not work when accessing through proxy?

-Is there a solution for the links not working on page iterators (and on other icefaces components)?

Thank you all in advance

EDIT: (Since I 've searched a lot, I don't remember where exactly, but in some older post I 've read about a known issue of Alloy faces and IE but I don't know if it has to do with what I face, at all. I just thought to add this as a complementary info)

EDIT2: Broken functionality of dockbar drop down lists is also apparent when using Firefox browser as well, so it must be a javascript & proxy related problem - HELP?

[Hitoshi Ozawa, geändert vor 12 Jahren.]

Have you tried turning of fast.loads?

http://ecomware.com/notes/liferay-themes-question-and-answer

[MICHAIL MOUDATSOS, geändert vor 12 Jahren.]

Actually I've seen a post where you propose this for a similar issue, so I had already tried javascript.fast.load=false. Following your link I also tried theme.css.fast.load=false and theme.images.fast.load=false but nothing changed.

It is a bit strange and I don't really know what error is related to what technology and/or setup, but for example as far as the background color of the sign in portlet is concerned, defining this info for the id of the portlet, i.e #portlet_58 had no effect in IE up to version 8 (It worked for IE 9 but client has up to 8 at the moment and and the client's clients will definitely have IE as well, and who knows in which version). Changing the background color definition from this id to a class element, i.e. .portlet-boundary_58_ worked in all browsers.

However, the logic of this "patch"-solution can't be applied everywhere. For example, I don't know why the company logo is not shown (I think the resource /image/company_logo is not shown at all at IE's Developer tools, but I'm not sure since they suck and I don't know if I'm using them properly, in contrast with, eg, firefox or Opera corresponding tools).

It must be a combination of what I let pass through the reverse proxy and some IE issues. The way I'm letting something pass or not through the reverse proxy is by using rewrite conditions and rewrite rule, by denying everything that does not belong to a set of URL matching patters. Maybe I have ommitted something that is useful, but that's surely not entirely "it" because in other browsers company_logo and CSS of login portlet and language portlet is rendered correctly.

Any ideas?

[Hitoshi Ozawa, geändert vor 12 Jahren.]

I'm sorry but I have several installations using Apache + mod_jk upfront and I've never encountered any problem.
It's kind of difficult to help you when I can't reproduce the error.

[MICHAIL MOUDATSOS, geändert vor 12 Jahren.]

Hitoshi Ozawa:

I'm sorry but I have several installations using Apache + mod_jk upfront

I'm not using mod_jk, at least to the best of my knowledge, i.e. there are no LoadModule jk_module libexec/mod_jk.so and AddModule mod_jk.c directives in my httpd.conf file and of course no worker files ctra

I used this Liferay wiki guide as a knowledge base to setup my installation. No such module is used there. Is what am I doing wrong or incomplete and if so, how and in what respect?

My configuration interventions to httpd.conf defaults can be pretty much narrowed to the following

...
ProxyRequests Off
...
Listen 443

<virtualhost 10.0.0.101:443>
	ServerName 10.0.0.101

	SSLEngine on
	SSLProxyEngine On
	SSLProtocol all -SSLv2
	SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
	SSLCertificateFile C:\keystore\signview.crt
	SSLCertificateKeyFile C:\keystore\10.0.0.101-nopassphrase.key

	RewriteEngine On
	RewriteCond %{REQUEST_URI} !^/home
	RewriteCond %{REQUEST_URI} !^/c
	RewriteCond %{REQUEST_URI} !^/c/portal/logout
	RewriteCond %{REQUEST_URI} !^/index.html
	RewriteCond %{REQUEST_URI} !^/image/company_logo*
	RewriteCond %{REQUEST_URI} !^/image/image_gallery
	RewriteCond %{REQUEST_URI} !^/html/portal/css*
	RewriteCond %{REQUEST_URI} !^/group/control_panel
	RewriteCond %{REQUEST_URI} !^/some-page
....
	RewriteCond %{REQUEST_URI} !^/MyPortletProjectName-portlet/image*
	RewriteCond %{REQUEST_URI} !^/MyThemeProjectName-theme*

	RewriteRule ^ - [L,R=404]

	ProxyPass / https://10.0.0.100:8443/
	ProxyPassReverse / https://10.0.0.100:8443/
</virtualhost>

From tomcat-side I did what the guide described concerning server.xml and WEB-INF/web.xml

and I also set the appropriate values for all web server properties and set all *.https.required properties to true ,although as I said before https has nothing to do with this (the problem exists even without enabling https)

What are the implied functional differences between your approach and mine that might be related to the problem I describe?
Do you think it would be worth to try setting everything up all over again your way? Do you have a link for an elaborate guide of how to do this with Liferay?

Thank you in advance!

[Hitoshi Ozawa, geändert vor 12 Jahren.]

The approached outlined uses mod_proxy bundled with Apache http server while I'm using mod_jk. The basic difference is mod_jk that I hink mod_jk is more stable. I haven't had problem using it.

[MICHAIL MOUDATSOS, geändert vor 12 Jahren.]

My page iterator javascript problem was irrelevant as I state here. However I've yet to find a solution for my problems concerning rendering resources such as company logo (resource: /image/company_logo)

[MICHAIL MOUDATSOS, geändert vor 12 Jahren.]

OK it seems that IE has some problems with IDs in CSS. Using Opera Dragonfly I found the script that Liferay uses to render the company logo. It contained the .logo class in the #Heading ID, i.e. there was something like

#Heading .logo{...

I overrode only the .logo class and placed inside all the CSS info that was in the script and it worked!
I know this is a quick n' dirty solution but till I understand what really happens with IE and element ids it ll be just fine...
Note that .logo in my case was not used elsewhere so it was OK to override its definition; other ppl may have to narrow its definition when in another class, like .company-title, that is,

.company-title .logo{...}

EDIT: When adding the CSS in .logo class make sure to put the appropriate url to the image. You may have to use an image from another path