[OJS 3.2.1.1/3.2.0.3] Subscription Module Bug, Article Galley unlocked to public

We’re running OJS 3.2.1.1 with two journals on a subscription model and others on Open Access - we recently noticed that some article galleys that should be locked behind a subscription can be opened and downloaded freely, while others articles of that same journal are locked normally.

We couldn’t figure out a pattern and there is no error in the logs, but after some research, it seems that a purchase from one user unlocks the galley for download from anyone.

We were originally on 3.2.0.3 when we noticed and updated to 3.2.1.1. to see if that might fix the issue. It didn’t.

The button indicates that the articles should be locked, but clicking it grants access to the galley. OJS - Album on Imgur

Hi @Facultas,

Are you using IP address-based subscriptions?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher, thank you for replying so quickly!

Yes, we’re using both institutional (IP-based) and individual.

Hi @Facultas,

It’s likely that you have an IP-based subscription that’s overly broad. Are you using the Subscription block plugin to display on the sidebar whose subscription is granting access?

Regards,
Alec Smecher
Public Knowledge Project Team

Dear Alex,

it’s only specific article galleys, so I’m not sure how this could be caused by an IP-based subscription, even a broad one. As the screenshot shows by the PDF galley symbol, they are also intended to be locked.

Any updates on the issue? @asmecher We can’t pull the journals and many of our articles are still freely accessible to anyone.

Hi @Facultas,

I’d like to clearly establish that IP-based subscriptions aren’t the problem, as they’re the likeliest cause. Do you use the subscription block plugin?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

yes, we’re using that plugin. Would it be helpful if I briefly disable all IP access subscriptions to see if it changes anything and report back? We do have active institutional subscribers, so I can only do it for a brief test.

We’ve also used the quicksubmit plugin for articles where the editorial process isn’t handled directly in OJS, if that could be relevant. Both galleys introduced via quicksubmit and through the regular editorial process are affected though.

Hi @Facultas,

If you’re able to try from a connection that does not have an institutional subscription, and confirm that you can still access the galley unexpectedly, that would help. The block I mentioned can be useful in ascertaining whether or not an IP-based subscription is being used – if it is, it’ll tell you which subscription is active.

Regards,
Alec Smecher
Public Knowledge Project Team

Dear @asmecher

I can already confirm that, that’s actually the first thing we did and how we noticed.

If we were behind an IP with a subscription, access wouldn’t be available for some articles (which still show as locked upfront whilst giving access anyway if clicked) and not for others of the same journal.

Hi @Facultas,

Thanks, that helps – just taking the problem step by step.

Next, can you confirm whether you’re logged in as a user who either has an internal role (e.g. Editor or Copyeditor), or who is assigned as an Author to the submission? Those users will have implicit access to the submission.

Regards,
Alec Smecher
Public Knowledge Project Team

Dear @asmecher

We tested using both local browser installations that were never logged in before (after deactivating the subscription with our own IP that we used for local access in our backoffice) without login and smartphones that were never logged into OJS before, on their own mobile connection, also without login.

Are there any other tests I could perform or information I can provide to help locate the error?

Hi @Facultas,

Are you handy with PHP? The access checks are performed in the class classes/issue/IssueAction.inc.php, primarily in the two functions called:

  • subscribedUser, for user-specific checks, and
  • subscribedDomain, for IP-based subscription checks

Note that plugins can intervene with these functions, and there are several plugins that do this (e.g. to integrate 3rd-party services). If you’re using one of these plugins, that’s a good place to look for configuration problems.

I would recommend using the PHP error_log function to report how the subscription is being granted via your PHP error/warning log. If you can determine how the subscription condition is being met, you can pin down how OJS is granting access to users you don’t expect to have it.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

I’m not versed in PHP myself, but I spoke to our programmer and they did some investigating - they sent me a screenshot of code that looks to be causing the issue. Please see below.

ojs code

Hi @Facultas,

Do you know what the problem was that they were trying to point out? That’s just the piece of code that gets a user’s subscription from the database.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

They said that it has to be related to this code, I’m afraid I couldn’t really get more from them. Presumably they also looked into everything we did and excluded some other possibilities like external plugins to narrow it down. They’re not a direct part of the company so I only have limited access to their services.

Dear OJS Team,
after a health-related absence, I’d like to check back in: has there been any progress in regards to this issue?

Hi @Facultas,

The next step will be to investigate the code on your system – it sounds like someone started that work, but it’s not clear what they were able to determine.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

thank you. What’s the best practice for that? Should I PM cPanel access details?