It is very difficult to pinpoint your case, do you see some other messages in the api communication log (OJS_FILES/orcid.log) ?
I am searching in the log for the scenario we did on May 26. I guess the tests we did together start somewhere here:
2021-05-26 14:32:57.758 INFO POST https://api.sandbox.orcid.org/oauth/token
2021-05-26 14:32:57.759 INFO Request header: array (
0 => 'Accept: application/json',
)
This is followed by an INFO on the āRequest bodyā, a string containing code, grant_type, client_id and client_secret.
Next INFO on āResponse bodyā, this time something JSON-like, with access_token, token_type, refresh_token, expires_in, scope, name and orcid.
Next another INFO, this time on āRequest body (without put-code)ā, again something looking like JSON. This contains quite a few keys and is nested, so I will skip writing all of that. Let me know if some part of this is of interest to you.
Next an INFO on a POST call to api.sandbox.orcid.org/v2.1 on work level
Next an INFO on the āHeader: arrayā, which contains Content-Type, Content-Length, Accept and Authorization.
INFO on Response status 201
INFO that āWork added to profileā, with putCode
20 minutes later:
2021-05-26 14:56:26.673 ERROR OrcidHandler::orcidverify - No author found with supplied token
The 20 minutes seem strange. I am not entirely sure what we did during that time. I suppose we looked at the core of the issue, clicking the link from the e-mail received by the author and talking about where and how we could extract the URLs generated by the orcid sandbox.
After the ERROR message I can see the log entries from the successful API call we had after that, where we added the publication_id to the URL manually.
Another note on our scenario: We have two authors for this specific publication. The first does not own an ORCiD-ID, as far as I can tell. The second is the one being asked for authorization.
(Gabriele)
i"m pretty sure weāre experiencing the same problem as @ojs_univie. The link that @Dulip_Withanage put in post #17 above is the same for us, except itās missing the publicationID. If we add the publicationID manually to the URL OJS responds with a green message that the Orcid validation succeeded.
One of the points I noticed when I was testing with ORCID, is that the redirect URL has to be HTTPS, otherwise it did not work.
The environment weāre using is āhttpsā. The āhttpā link is copied from @Dulip_Withanage. My post #8 above outlines the sequence and the problem. We ARE able to make it work if we add the missing publicationID manually, and the log response for both error and success is included in the post. It should be clear to anyone reviewing these posts that using āhttpā is NOT the problem.
@Richard-Higgins : I did a slight change to the web publicationId in a dev branch. Did you test this ?
When I click on the link to the branch, I donāt see any file and/or code youāve changed. I can see the branch, but thereās no indication of what youāve changed. The last commit on the branch is May 22.
Iāve also compared (with diff) v.1_1_2-18 release against this āforumā branch and thereās no difference in the code.
Could you give me the file and code youāve changed in a post rather than by link?
@Dulip_Withanage did you have a similar setup in your tests? Could you maybe try this scenario and see if this makes the issue reproducable for you?
EDIT: @Richard-Higgins did you have one or two authors in your tests?
(Gabriele)
@ojs_univie I tested the process in a variety of different cases. Number of authors made no difference. An email with the ORCID validation link to a registered user can be initiated by staff at any time.
Also, as you noted at the beginning of this thread, when a user self-registers ORCID validation does not encounter this error.
Okay, thank you very much for your reply and doing such extensive testing! Pinpointing this issue is hard. I was hoping the multi-author thing might be it.
(Gabriele)
Hi Both, I tested again the multi-user scenario too.
Although it may not be relevant to this case, I wanted to just report something, which may be of interest.
For OJS to get a author/contributor validation, we send token (email hash) and the credentials to the apiand then get the user-code.
If I have multiple authors here is a workflow, which can happen.
- Add first co author coauthor@mailinator.com
- Login to sandbox and authenticate ORCID but do not logout
- Add second author amwandenga@mailinator.com and send authentication email
- Click the authentication email, (as we are logged in) orcid api automatically authenticates for the wrong user (in this case coauthor@mailinator.com )
No errors happen, but we have the wrong orcid id in OJS. Unfortunately ,from OJS side we cannot control this, cause we get a false yes from the API (through the data entering personās error).
For a production use case , In a shared desktop, this rare use-case can happen., if users do not log out.
This is the current working workflow. Click Image for better quality.
I am seeing the same thing. Something about this branch does not seem right:
āThis branch is 489 commits ahead of ulsdevteam:master.ā
(Gabriele)
@asmecher Could you have a look at this thread? @Dulip_Withanage says that they added a potential solution to Github branch āforum-67928,ā but that branch is identical to main as far as I can tell. Iām concerned with the difficulty weāve experienced in trying to communicate about this issue.
Iāve been in touch with both Orcid support and Lyrasis/OrcidUS about the error, and their first impression is that 1) our problem is probably related to multi-journal instances (which I think is true for @ojs_univie as well) and 2) retaining the publicationID in the return URL will need to be handled by the OJS plugin code.
With thanks,
Richard Higgins
Indiana University Libraries | IUScholarWorks
scholarworks.iu.edu/journals
2 Likes
ORCID has advised us to skip testing sandbox in our dev instance and go straight to implementing the API plugin in production. I hadnāt heard before that since PKP is a āservice providerā for ORCID the sandbox protocol for testing the API process isnāt necessary.
In any case, Iām happy to verify that the production member API works as designed in the orcidProfile plugin, without the error described in this thread.
1 Like
Usually we do test our plugins in a sandbox environment to make sure it works as we expect it to. It is a bit strange to read that sandbox testing isnāt necessary. Isnāt this a decision we ourselves should be able to make?
I am relieved to read the issues found with ORCiD Sandbox member API are not present for production. It is also strange the two would act so differently.
EDIT: I want to add here, that I am deeply grateful @Richard-Higgins for all the time and effort you spent on this issue!
(Gabriele)
1 Like
Hi all,
Iāve been following this thread behind the scenes, but @Dulip_Withanage is our expert on ORCID, so I trust his recommendations 
It does sound like thereās a discrepancy between the ORCID sandbox and production API behaviour, and itās hard for us to debug this remotely ā Iām hoping that someone at ORCID can look into it with better knowledge about how the two environments differ. But for the moment itās good news that this only affects the sandbox and users can work in production without problems.
Regards,
Alec Smecher
Public Knowledge Project Team
The gif looks different from what I remember seeing in the tests. After signing in you are immediately forwarded to OJS. This is not what we saw in our tests. We needed to explicitely click āAuthorizeā in ORCiD. Maybe because we were already logged in in ORCiD sandbox when clicking the link in the e-mail?
(Gabriele)
@ojs_univie yes. When you are logged in , you will only see the āAuthorizeā button.
@Richard-Higgins and @ojs_univie
First of all thank you both for your testing and contributing to the issue in a much deeper tehcnial level.
Here is a summary of the current status
- The issue you mentioned without the publicationId is very hard to reproduce. As it is not visible in a production environment, we have to guess, that something in the way the sandbox react can cause the issue you mentioned. S In OJS side, we are working on more fine-granular error reporting to enable JMS/JEs or Sys-Admins to find out , if there is a configuration error.
The error in the initial report in this ticket can be more customized to return more concrete values. That we will do from OJS side and may be find out the reason, when this scenario is repeated in future again.
What I meant was: I didnāt see the āAuthorizeā button in the gif you posted. I redid the tests just now while being logged out from orcid sandbox and I can see the āAuthorizeā button. How come it is not visible in your gif?