1. Home
  2. General
  3. RE: Javascript being loaded using the wrong protocol

RE: Javascript being loaded using the wrong protocol

Jamie Sammons, modified 3 Years ago.
Javascript being loaded using the wrong protocol
New Member Post: 1 Join Date: 2/8/22 Recent Posts

Hi

I have inherited a Liferay installation which I know absolutely nothing about... We are updating the infrastructure and are currently replacing the apache reverse proxy to a NGINX one. All the sites have been moved over without any problems except the LifeRay one... What we are getting is a lot (about 100) calls to the HTTP protocol and not HTTPS as it should be. The calls all look like this: 

   http://xxx.xxx.xxx/o/frontend-js-metal-web/metal-events/src/EventEmitter.js?languageId=en_US 

   http://xxx.xxx.xxx/o/frontend-js-metal-web/metal-events/src/events.js

   http://xxx.xxx.xxx/o/frontend-js-metal-web/metal-dom/src/DomEventEmitterProxy.js?languageId=en_US

which gives us the error: Blocked loading mixed active content => this makes sense as we are going from a HTTPS site and trying to load HTTP js files. I am assuming that somewhere in the CMS somebody mistakenly added the protocol to the link i.e. http://xxx.xx.xxx instead pf just xxx.xx.xxx

I have looked through the entire frontend but cannot seem to find the place that these .js files are added – any ideas?

Thank you in advance

PS: I (unfortunatly) have no installation instructions for LifeRay i.e. I do not know what was installed where!

Lee Jordan, modified 3 Years ago.
RE: Javascript being loaded using the wrong protocol
Expert Posts: 449 Join Date: 5/26/15 Recent Posts

That's a core Liferay module. My guess would be to try this first if the site isn't configured for SSL:
https://liferay.dev/blogs/-/blogs/ssl-configuration-in-liferay-https-

That may kick the core modules to load over SSL.

thumbnail
Olaf Kock, modified 3 Years ago.
RE: Javascript being loaded using the wrong protocol
Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts

The URLs are generated by the app server, e.g. Tomcat.

Tomcat must be aware that the request is served through https - an information that can get lost when a reverse proxy is handling the TLS part and then forwards to Tomcat using http.

There are multiple ways to tackle this problem - e.g. making the proxy forward the information, declaring on Tomcat's site that a request is secure (despite Tomcat's better knowledge). I can't tell how to do it on nginx, but most likely you're running into this issue. It's a common problem in the reverse-proxy-world.