OJS 3.2.1.1: multi-domain, multi-journal installation: issues from journal A can be accessed from the domain of journal B

OJS 3.2.1.1

Two journals with a custom domain in one installation:

base_url = "https://maindomain.tld"
base_url[index] = https://maindomain.tld/index
base_url[abc] = https://customdomain1.tld
base_url[def] = https://customdomain2.tld
restful_urls = On

Let’s say that issue ID 123 belongs to journal abc. This is the correct way to view that issue in the browser:

https://customdomain1.tld/view/issue/123

However, the following URL also works:

https://customdomain2.tld/view/issue/123

And this shows issue ID 123 as belonging to the wrong journal (def instead of abc). There does not seem to be a check if the isssue being requested actually belongs to the domain in the URL.

Is there any way to stop this from happening? The same thing happens in OJS 3.3.0.4.

Thanks in advance,
Jan Pieter

PS See also OJS 3.2.1.1: multi-domain, multi-journal installation: issues from journal A can be accessed from the domain of journal B · Issue #7180 · pkp/pkp-lib · GitHub

Hi Jan,

No, there’s no way to prevent this in OJS, currently. The way we handle this problem at PKPPS is to use Apache’s mod_rewrite module and ensure that domains match journal paths using RewriteCond and RewriteRule. For instance, you could do something like this:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/index.php/abc.*$ [NC]
RewriteRule ^(.*)$ https://customdomain1.tld/index.php/abc$1 [R=301,L]

which checks to see if the request is for your abc journal and if it is sends it to the domain for that journal.

The only slightly annoying thing with doing it this way is that you need to put those Rewrite directives in every one of your virtualhosts and for a lot of domains it can get a bit kludgy to maintain unless you put them in a separate config file and Include it.

Cheers,
Jason

Hello Jason,

I tried your solution, which sounded promising, but I’m afraid it does not work.

The crux is with the which checks to see if the request is for your abc journal.
The problem is that it is not possible for Apache to see for which journal a request is supposed to be, because it looks like every ID from the database can be used after every domain and journal path from the OJS installation. A Rewrite rule will not help here.

Let’s forget about the custom domains for the moment and just use the main domain + journal paths. Using the examples above, we have these two journals:

https://maindomain.tld/abc/
https://maindomain.tld/def/

Now let’s suppose that journal abc has article ID 964:

https://maindomain.tld/abc/article/view/964

I don’t think that there is a rewrite rule which can prevent this from working:

https://maindomain.tld/def/article/view/964

This makes it seem like article ID 964 was published in journal def. How is Apache to know that article ID 964 should only appear after journal path abc? Only OJS has that knowledge.

Hi Jan,

This sounds like something else. There is no way that this should be able to work in normal circumstances because that article is not in that journal. There are checks in the OJS code to verify that the context is correct for an article and while you might see things like articles being served up on the wrong domain because OJS doesn’t really care about domains, you should never see articles being served up on the wrong journal path. Those paths get mapped to context ids in the database and every submission in your database has a context id in the record.

I’m not sure if you’re doing other things to remove index.php or what not and perhaps things are being routed around internally and other problems are appearing because of that.

Cheers
Jason

On the main domain, we use these Rewrite rules to remove index.php and still have “api/v1” working:

RewriteRule ^api/v1(.*)$ /index.php/api/v1$1 [L,R=307]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.php/$1 [QSA,L]

All our journals are imported from existing, separate installations. Now I’m wondering if something could have gone wrong with the importing. We used the FullJournalTransferPlugin to create a combined OJS 2.8 installation and then upgraded that installation to OJS 3.

I’ll check the submissions table to see if that gives a clue.

Thanks for your insights!

Edit: this problem has nothing to do with URL rewriting. On my local copy, running on my laptop, of our OJS installation, which does not have any mod_rewrite stuff going on, these URLs all work:

http://openjournals.localhost/index.php/journal1/article/view/7253
http://openjournals.localhost/index.php/journal2/article/view/7253
http://openjournals.localhost/index.php/journal3/article/view/7253

But only one of those three is correct. The other two show article 7523 in the wrong journal. Very weird.

I’m now trying to understand the structure of the database.
Is context_id in the submissions table the same as journal_id in the journals table?
More generally, is there a description of the database structure somewhere?

Thanks in advance,
Jan Pieter

Hi Jan,

I’m unaware of a complete database schema, but yes, the context_id in the submissions table corresponds to the journal id.

In thinking about this a bit more, I wonder if your base_url mappings are correct. Typically, we include the journal path in our base_url values:

base_url[journal1] = 'https://domain1.com/index.php/journal1'
base_url[journal2] = 'https://domain2.com/index.php/journal2'

Or without index.php in your case. Perhaps that’s where this weirdness is coming from?

Cheers,
Jason

Hello Jason,

I don’t think so. For the moment I am concentrating on my local installation at http://openjournals.localhost, because that one has no additional complications with custom domains or RESTful URLs, it’s all http://openjournals.localhost/index.php/path/article/view/id.

It makes no difference if I put base_url mappings in config.inc.php or not.
So with or without 8 lines of

base_url[path] = http://openjournals.localhost/index.php/path

all articles can be shown in all journals.

As a test, I also installed a fresh copy of OJS 3.2, created two fake journals with each a fake issue with one fake article (so, article ids 1 and 2), without any manual editing of the config.inc.php (there were no generated base_urls in the config file).
In that case, everyting works as expected. Requesting article id 1 or 2 in the wrong journal gives a 404.

As mentioned before, our installation + database was creating by combining and importing dumps from other, older OJS installations. My hunch is that something must have gone wrong there and we have subtly incorrect data in our database.

After upgrading to OJS 3.3.0.7, all problems regarding issues and articles appearing in the wrong journals seem to have been solved.

Hi all,

For reference, this was likely Issues can be served by ID in the wrong journal · Issue #6949 · pkp/pkp-lib · GitHub. This was resolved starting with OJS 3.3.0-6.

Regards,
Alec Smecher
Public Knowledge Project Team

This topic was automatically closed after 2 days. New replies are no longer allowed.