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.
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.
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:
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.
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.
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:
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?
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.