Pkp-lib: Tweak & distribute ORCiD integration plugin

[asmecher]

...from the sprint:
https://github.com/asmecher/pkp-orcidprofile

(After finishing, move issue to master branch for forward-porting.)

[alonsoj]

@asmecher, how about login with orcid token?

[asmecher]

@alonsoj, we didn't tackle that use case but I've been thinking about it over the last few days; it would be fairly simple to add based on the interactions we've already coded. I won't make promises for a particular release but it's definitely on my mind.

[crism]

I very much want to bring this into the OJS 3._x_/OMP 1.2 world, and have forked the plugin to that end. Would that break OJS 2._x_ compatibility, or can we meet both goals in one codebase?

[ctgraham]

@asmecher, @alonsoj: pluggable, hierarchical authentication (including OAuth-based) is on Pitt's near-term objectives for general OJS development. ORCID would make a good candidate for a proof-of-concept.

[crism]

Should the plugin really be in the generic cateogory? Authorization seems more appropriate now.

[ctgraham]

Does an AuthPlugin for us mean authorization, authentication, or both?

I suspect this should be in the generic category to continue to implement the "Link your ORCID" functionality, but should also (optionally) implement an AuthPlugin for authentication.

[asmecher]

The AuthPlugin category needs an overhaul. Plus the plugin as more concerns than just authorization/authentication. For now I'd recommend keeping it in generic.

We have a couple other partners who have identified this plugin for future work and have applied for funding accordingly, so I'd like to make sure we don't step on their toes. I'll point them to this issue.

I'd suggest we take the current master branch, rename it to ojs-dev-2_4, and then adapt to the master branch of OJS and OMP in this repo's master branch.

[asmecher]

(By the way, I'm still cleaning up the current master branch of the plugin, and would like to get that into a decent state before we fork it for OJS 3. I'll get that done this week.)

[crism]

Thanks for the feedback. I’ll keep familiarizing myself with the OJS 3 plugin API, but hold off on significant changes until the base is stable.

[asmecher]

@crism and @ctgraham, I've gotten everything cleaned up and working for OJS 2.x, including email-based claims for authors. Would either/both of you mind taking the newest code for a spin?

The URLs it sends are horrendous, but I'm going to stave that off for future improvement.

[asmecher]

Also bringing in @ajnyga!

[crism]

Trying to test this in OJS 2.4.8, and feeling like an idiot. I’ve mostly only worked with the OJS 3 beta… how the heck do I enable this, @asmecher? I unpacked it in plugins/generic/orcidProfile, and ran tools/upgrade.php upgrade. I don’t see any site-wide plugins admin, and it doesn’t show up in the per-journal plugins list. I can’t find anything in the docs, either, about site-wide plugin administration (except authentication sources). Feel free to e-mail me directly if this is clutter for GitHub…

[asmecher]

No problem, @crism. Log in with a Journal Manager account, go to System Plugins > Generic Plugins, and find it in the list there; enable it, edit and save its settings page, and you should be good to go.

[crism]

Yep, I’m an idiot. It was right there; I’m just really not used to this interface.

[crism]

[Fri May 06 13:44:05.879133 2016] [:error] [pid 10927] [client 172.17.168.18:52967] ojs2 has produced an error\n  Message: WARNING: assert(): Assertion failed\n  In file: /var/www/ojs/plugins/generic/orcidProfile/OrcidProfilePlugin.inc.php\n  At line: 399\n  Stacktrace: \n  Server info:\n   OS: Linux\n   PHP Version: 5.6.20\n   Apache Version: Apache/2.4.6 (Red Hat Enterprise Linux) PHP/5.6.20\n   DB Driver: mysql\n   DB server version: 5.5.44-MariaDB, referer: .../ojs/index.php/pww-proc/manager/plugins/generic

Happened when I asked for settings.

[asmecher]

Really? Weird. What does your URL to that page look like?

[crism]

.../ojs/index.php/pww-proc/manager/plugin/generic/orcidprofileplugin/settings, and it seems to be working OK. I suspect that getManagementVerbs() is wrong; when I started porting to OJS 3, that was one of the first things I needed to fix. As it stands, I think it always returns an empty array.

[asmecher]

OJS3 doesn't use getManagementVerbs; it uses getActions now. Grep through some of the plugins/generic/* for this function in the OJS 3 codebase; I think the plugins there have all been updated accordingly.

[crism]

Yeah, that’s the conclusion I reached… but I wonder if it’s responsible for this warning? The assertion error is caused when an unknown verb is sent to the plugin.

[crism]

README needs directions on wiring up the ORCID API. What’s the redirect URI we give to ORCID? It’s not obvious to me.

[asmecher]

Are you seeing that on the setup form? It shouldn't be there...

[crism]

No, but to create the ORCID authentication credentials, I need to tell ORCID what the redirect URI is. I can’t get the client ID and client secret (which the setup form _does_ require) without that.

[asmecher]

Oh, gotcha. Just give it your journal's domain name; that'll permit anything within that domain.

[crism]

Got it, thanks. Success! Populated my admin ORCID ID with my sandbox ID. Now to test authentication…

[crism]

Plugin only acknowledges the numeric part of the ID; if using the Sandbox API, takes it as a normative ORCID.

[crism]

Registration says “Errors occurred processing this form: The email address fields do not match.” Not sure what fields (plural) it’s referring to… even correcting for the Mailinator address I used for the ORCID sandbox, I still get this error. (I think maybe it doesn’t like sandbox-styled ORCID IDs? Will test with the real thing now.)

[crism]

Oh, never mind—either the system had a spasm, or I did; there are two e-mail fields. d-: Not enough coffee today. Anyway, registration with a proper non-sandbox ORCID authentication worked fine.

[crism]

I’d really like to configure it to be a proper authentication source… but this is working as designed for now.

[ajnyga]

When adding more authors, the ORCID field is not locked meaning that the submitting author can write to it.

[asmecher]

@ajnyga, the submitter can only claim the first author entry for themselves using the ORCID login. We could hide the ORCID field entirely during submission, but I thought in this case it was better to leave it present so that the submitting author could enter other authors' ORCIDs if they were available. Then the email claim process only happens for unentered ORCIDs. All submitted ORCIDs are validated by checksum against typos, so I don't think there's a huge risk of garbage data getting entered here.

[asmecher]

@crism, by the way, I'm finished tinkering -- would you like me to fork the plugin into ojs-dev-2_4 and master (OJS 3) branches? I know you were eager to experiment with the master branch and I hate to stand in your way :)

[crism]

@asmecher, I’ve forked it at https://github.com/PublishingWithoutWalls/orcidSso — I’ll send pull requests when I’ve made useful progress. (I started before you were done, which was educational, but not productive.)

[asmecher]

Thanks, @crism -- I've created an ojs-dev-2_4 branch to distinguish it from master (OJS 3.0), and added a note to the README.md to clarify. Let me know if I can clarify anything WRT the OJS 3.0 plugin structures!

[ajnyga]

@asmecher I do not think that typos are the risk. Probably a larger risk is mixing ORCIDs with each other while they are not human readable as such. I think that the ORCID recommendation is to only insert ORCIDs through a validation process.

Another thing I noticed that the email that the plugin sends is empty. I did not have time to check this in detail but it maybe is because the plugin is missing this (form Lucene plugin):

/** * @see Plugin::getInstallEmailTemplatesFile() */ function getInstallEmailTemplatesFile() { return ($this->getPluginPath() . '/emailTemplates.xml'); } /** * @see Plugin::getInstallEmailTemplateDataFile() */ function getInstallEmailTemplateDataFile() { return ($this->getPluginPath() . '/locale/{$installedLocale}/emailTemplates.xml'); }

I will test this plugin starting from next week with a group of journals.

[asmecher]

@ajnyga, thanks -- added that. If you like, you can also create the email template manually from the Journal Manager's "Prepared Emails" area.

[crism]

OK, I have the settings working, at least, in OJS 3. It seems impossible to provide simultaneous OJS 2 and 3 compatibility, since the plugin API has changed (manage() now takes only 2 arguments). Or am I missing something?

Next steps:

• [ ] Get the new registration and submission forms wired up to the plugin
• [ ] Genericize it (change journal references to context) so that it will work in OMP 1.2 as well
• [ ] Adapt it to be a full-on authorization plugin

[asmecher]

We don't want the plugin to be compatible with both; that's why I created an ojs-dev-2_4 branch (for 2.4.x) as opposed to master (for 3.0). It might be possible to maintain compatibility but it'll be tedious and probably less reliable in the long run.

[crism]

That’s what I thought, @asmecher, but I wanted to confirm. I’ll send a pull request when I get the first part up there done.

[asmecher]

Added to OJS 3.0 via submodule; leaving open for 2.4.9.

[isgrim]

@asmecher Is this still relevant?

[asmecher]

Nope, this is obsolete.