OJS 31: Problem to display content of a journal with its own domain in https because of stylesheet links in http

We officially migrated all our journals to OJS31, to OJS 3.1.0-1 exactly.
Until now it was just in test.

We encounter some problem to display content of a journal with its own domain (using RewriteRule in .htacess) in https because of stylesheet links generated in http. We didn’t encounter this problem with OJS2.

All our journals have their own domain. So we have an “.htacess” file with RewriteRule directives like this:

RewriteEngine On
RewriteCond %{SERVER_NAME} ^(www.)?journal1.org
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.php/journal1/$1 [QSA,L]

And here is an example of our “config.inc.php” file:

base_url = “http://journalsportal.org/journals
disable_path_info = Off
allow_url_fopen = Off
base_url[journal1] = http://journal1.org
restful_urls = Off
trust_x_forwarded_for = On
force_ssl = Off
force_login_ssl = On
session_check_ip = On

And here is a part of our Apache (2.4) config file for http:

<VirtualHost *:80>
ServerName journal1.org
DocumentRoot /var/www/journals

<Directory /var/www/journals>
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Order allow,deny
allow from all

And here is a part of our Apache (2.4) config file for https:

ServerName journal1.org DocumentRoot /var/www/journals

<Directory /var/www/journals>
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Order allow,deny
allow from all

Each journal have their onw custom theme.

When we access the journal in “http” (http://journal1.org), all works fine. But when we access the journal in “https” (https://journal1.org), all the links of stylesheet theme are in “http” instead of “https” and the web browser blocks the content because of “mixed active content”. For example:

link rel=“stylesheet” href=“http://journal1.org/$$$call$$$/page/page/css?name=stylesheet” type=“text/css”

But it doesn’t happen for the portal web site. Links of stylesheet theme are well in “https”. For example:

link rel=“stylesheet” href=“https://journalsportal.org/journals/index.php/index/$$$call$$$/page/page/css?name=stylesheet” type=“text/css”

I did some tests. When in “config.inc.php” file, I change this line:

base_url[journal1] = https://journal1.org

All the content, is well displayed in https but we don’t want a base_url in https.

I did some research and I put some “error_log” in some files to display variables values in logs to see where url is generated.

In “_registerStyles” function in “/lib/pkp/classes/plugins/ThemePlugin.inc.php” file, url are called via “$dispatcher->url” function with this line:

$styles = $dispatcher->url($request,ROUTE_COMPONENT,null,‘page.PageHandler’,‘css’,null,array(‘name’ => $name,));

In “_urlGetBaseAndContext” function in “/lib/pkp/classes/core/PKPRouter.inc.php” file, url are generated.
I don’t know exactly how all php code work in this function but when I keep only this line:

$baseUrl = $this->getIndexUrl($request);

My stylesheets links are well generates in https. But they are of course other problems of links that are not well overridden.

My question is:
Is it a problem of OJS31 which doesn’t manage well all cases of “baseUrl” generation ?
OR
Is it a problem of my particular configuration and setting that I have to change ?

Thanks in advance for your help.
Best regards
Helene

Hi @hcl

Is there an special reason to don’t want to? I mean, this would be an easier solution.

Even you redirect request from HTTP to HTTPS through .htaccess your browser will consider mixed content because it will parse html code and will find http requests in a page that is called in https mode.

So I suggest you use base_url with https and change not only your force_login_ssl parameter to On (as it is righ now) but also force_ssl. Perhaps this two conflicted conditions are letting you use SSL in portals home but not in journal.

Please, remember if you choose use SSL that your .htaccess will need redirect request by protocol either (HTTP => HTTPS).

Hope it helps.

Regards,
Israel Cefrin
Public Knowledge Project Team

Hi @israel.cefrin,

Thank you for your answer.
I had to make this change anyway to make it work.

Best regards.
Helene

Hi Everyone,

I’m experiencing a similar issue: with http protocol everything works beautifully, when I switch to https, I get a raw display as if the stylesheets weren’t loaded;

I’m currently running on ojs 3.2.1-1 (a recent upgrade from 3.0.2 where similar problem persisted). The SSL certifacte is ON on the server side; here’s the output of the <?php print_r($_SERVER); script:

Array
(
[TERM] => xterm-256color
[SHELL] => /bin/ovh_ssh
[SSH_CLIENT] => 80.215.77.103 41154 22
[OLDPWD] => /homez.513/sfptozqt
[SSH_TTY] => /dev/pts/0
[USER] => sfptozqt
[LS_COLORS] => rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.lz4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;31:.zip=01;31:.z=01;31:.Z=01;31:.dz=01;31:.gz=01;31:.lrz=01;31:.lz=01;31:.lzo=01;31:.xz=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.cab=01;31:.jpg=01;35:.jpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.axv=01;35:.anx=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.axa=00;36:.oga=00;36:.spx=00;36:.xspf=00;36:
[TMOUT] => 300
[MAIL] => /var/mail/sfptozqt
[PATH] => /usr/local/php7.3/bin:/usr/local/bin:/usr/bin:/bin
[PWD] => /homez.513/sfptozqt/www/rfpt
[LANG] => fr_FR.UTF-8
[SHLVL] => 1
[HOME] => /homez.513/sfptozqt
[LOGNAME] => sfptozqt
[SSH_CONNECTION] => 80.215.77.103 41154 51.68.11.213 22
[HISTTIMEFORMAT] => [%F %T]
[_] => /usr/local/php7.3/bin/php
[PHP_SELF] => check_php.php
[SCRIPT_NAME] => check_php.php
[SCRIPT_FILENAME] => check_php.php
[PATH_TRANSLATED] => check_php.php
[DOCUMENT_ROOT] =>
[REQUEST_TIME_FLOAT] => 1598628184.5137
[REQUEST_TIME] => 1598628184
[argv] => Array
(
[0] => check_php.php
)

[argc] => 1

)

and here’s my config.inc.php setting:

base_url = “https://www.sfpt.fr/rfpt

Thanks in advance for any input you might have on that issue!
ewelina

Hi @erupnik,

What version of OJS are you using? (Please include this in your posts!)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher
Sorry, I mentioned the version but maybe too far in the text:

Thanks!

Hi @erupnik,

There it is, staring me in the face :slight_smile:

Can you check your web browser’s developer tools to see if you can identify whether the browser requested the CSS? I suspect you’ll see a warning there about requesting non-secure content from a secure context.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

You’re right, there’s plenty of source map errors when acessing the website via https protocol:
https_pb

Thank you,
er

Hi @erupnik,

I see cookie warnings and source map warnings, but not a problem actually loading a CSS file – can you check further up?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

I’m still looking around, but what I can see so far is that not all css styles are loaded; in the screenshot below, on the left-handside we have the “htttps” protocol, and on the right it’s the “http”; as you can see, on the left, there are 604 rules missing:
css_pb_load

Thank you!
ewelina

Hi again @asmecher,

I identified that this style sheet is not loading:
https://www.sfpt.fr/rfpt/index.php/RFPT/$$$call$$$/page/page/css?name=stylesheet

Which is responsible for the 604 missing rules. When I add it manually via the web developer tool, the visualization is correct.

Do you have a clue why it’s not loading it and how to fix it?

Thank you,
ewelina

Hi @erupnik,

I noticed when fetching the CSS that it takes quite a long time to load; perhaps that’s causing the browser to ignore its directives? I’d suggest double-checking the file permissions in your cache directory to ensure that OJS has permission to store cached CSS files there. I would also expect to see some permissions-related warnings in your PHP error log.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

Thanks for your suggestions. I checked that the cache directory is “writable” - it is.

I found this error message in the logs:
[Mon Aug 31 18:50:22 2020] [error] [client 46.229.168.133] [host sfpt.fr] AH10131: FastCGI: server "/homez.513/sfptozqt/www/rfpt/index.php" stderr: PHP message: ojs2: 404 Not Found

But it appears in both ‘http’ and ‘https’ calls. Maybe I should look into changing the max_execution_time PHP parameter…

Thanks!
e

Hi @erupnik,

The CSS is eventually being served, so the maximum execution limit wouldn’t apply. Do you see .css files generated in your cache directory?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

I can see the following files inside the cache dir:
0-pkp-lib.css
1-pkp-lib.css
1-stylesheet.css

Thx,
e

Hi @asmecher,

Could it be a problem with absolute versus relative paths to the css files? In other words, using absolute paths to http instead of relative paths?

Thank you,
ewelina

Hi @erupnik,

I don’t think so – the CSS should use protocol-relative URLs, and if you follow the links in your HTML to get the CSS files (and from there to anything referenced), you’ll see that the links work. I wasn’t able to spot any reason the browser wasn’t presenting the CSS, and my OJS installation works the same and has no trouble presenting the styles, which is why I was wondering about the slow speed. But I’m not particularly good with front-end concerns.

Regards,
Alec Smecher
Public Knowledge Project Team