I’m trying to develop a custom OJS plugin to check IP-based subscriptions with an external service (which I control). We have our IP ranges stored in an already-existing database that predates our adoption of OJS, and it’s infeasible for us to transfer all of our subscriber data into the OJS database.
I’ve looked at the subscriptionSSO plugin, but I’m not sure it does what we want; users are identified solely by IP address, not by logging into some kind of SSO service.
I’m trying to understand what is the correct architecture for our plugin, and I have a few questions:
Which hooks should we register callbacks for in order to check access?
Once we have a response from our API, what do we do in the two different cases? For instance, we might want to redirect them to a page (either in OJS or elsewhere) with information about how to subscribe; or we might want to show them a modal dialog with that same information.
I’d suggest having a look at the IssueAction::subscribedDomain hook, implemented here. It doesn’t require a user to be logged in; you can inspect the Request object and match the IP address against an external database, then use the $result hook parameter to tell OJS whether the user should be considered subscribed or not.
Thanks,
Alec Smecher
Public Knowledge Project Team
Thanks @asmecher. If I understand you correctly, the callback should mutate the $result object that is passed to it. In this case it looks like $result is just a boolean, so we should just use the callback to check with our external API and set $result accordingly. Is that what you’re saying?
@asmecher Thanks for the pointer. However, I’ve run into a problem.
This approach works fine when when determining access for a specific article. However, on the issue TOC page /<jpath>/issue/view/<id>, the call to $issueAction->subscribedDomain() doesn’t actually include the issue parameter; see ojs/pages/issue/IssueHandler.php at 3_4_0-10 · pkp/ojs · GitHub.
Then the issue doesn’t get passed to the callback that I registered against that hook, so the API doesn’t have the information it needs to determine whether access should be granted – it needs at least a publication year to determine access.
Is this intentional? I see that the Issue object is available in the context I linked to, so I don’t understand why it wouldn’t be passed to $issueAction->subscribedDomain().
Is it possible that there’s some other way to get the issue in this situation, perhaps from the request object? Or am I misunderstanding something?
I don’t see any harm in adding the $issueId parameter to the subscribedDomain function in that case – it’s probably an inadvertent omission, because domain-based subscriptions typically grant complete access to the journal. I’ve added it in this issue:
However, you can also inspect the request parameters directly from the plugin in order to determine what issue is being viewed.
Regards,
Alec Smecher
Public Knowledge Project Team