Hi @deepakc,
This is the only change I can think of that’s relevant:
The documentation for the Guzzle feature this uses is here:
https://docs.guzzlephp.org/en/6.5/request-options.html#allow-redirects
It might be worth exploring whether some adjustment of the Guzzle options identifies the problem/solution.
Regards,
Alec Smecher
Public Knowledge Project Team
hi @asmecher so i had meeting with our server admin. we already have this ‘allow_redirects’ => [‘strict’ => true] .
so in our case the response comes through load balancer however when it tries to reach destination which is our server, it gives 500 internal error. The logs just shows 500 internal error and doesn’t give much.
the firewall doesn’t block the response that comes from orcid. we even tried by disabling web app firewall policy however still got 500 internal error.
port 443 is also good is there any other port that we need to open for the response from orcid?
Any idea what can we try now?
Hi @deepakc,
All I can intuit from here is that some aspect of your server’s outgoing connection environment is not behaving “normally” – unfortunately remotely debugging something like that is just about impossible. I would recommend setting up a test script with Guzzle outside of the OJS environment, and seeing if it either functions normally (in which case OJS is likely the problem) or behaves the same as OJS (in which case the environment is likely the problem). You’ll probably find it easier for a server admin to investigate if they have a proof-of-concept script rather than a big, unfamiliar application.
Regards,
Alec Smecher
Public Knowledge Project Team
hi @asmecher thanks for your reply. outgoing or incoming ?
so when we click on orcid the request goes to orcid and we can see authorize orcid with ojs.
once we authorize the response, it comes from orcid to Load balancer, firewall doesn’t block the response (443 port is open also). when the response tries to reach OJS server from load balancer then we see 500 internal error in the logs.
We will try the guzzle example you gave, thanks for that.
Attached is the log pic:
Hi @deepakc,
The errors from the PHP error log that you quoted above are related to outgoing connections made by OJS using the Guzzle toolkit.
Regards,
Alec Smecher
Public Knowledge Project Team
hi @asmecher so i created folder outside of OJS environment in the same server. installed guzzlehttp via composer and then used script from the link you gave https://webscraping.ai/faq/guzzle/how-can-i-use-guzzle-to-download-files :
Script ran successfully and you can see the result in image attached below
. thanks
Hi @deepakc,
To replicate the behaviour in OJS, you’ll need to also add the option I mentioned above. Off the top of my head, that would be:
$response = $client->request('GET', $url, [
'sink' => $saveTo,
'allow_redirects' => ['strict' => true]
]);
Hi @deepakc,
There are a few additional options that OJS adds that might be the issue. Try further:
$response = $client->request('GET', $url, [
'sink' => $saveTo,
'proxy' => [
'http' => null,
'https' => null,
],
'headers' => [
'User-Agent' => 'ojs2/3.5.0.0',
],
'allow_redirects' => ['strict' => true]
]);
Thanks,
Alec Smecher
Public Knowledge Project Team
hi @asmecher this one was also successful.
Hi @deepakc,
Next I’d suggest invoking this script via the web, rather than the command-line PHP tool. It’s entirely possible that your PHP configuration, security configuration, or some other aspect of the server behaves differently when running scripts via the command line vs. the web server.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher, which URL should I use to invoke this script? There is a virtual server and OJS site urls. The OJS sites are behind the virtual server.
Hi @deepakc,
I’m afraid I can’t help you with that – that’s 100% dependent on your server configuration.
Regards,
Alec Smecher
Public Knowledge Project Team
hi @asmecher i tried the steps you mentioned and it was successful.
Hi @deepakc,
Hmm, I’m running low on ways to suggest remotely debugging – it still seems pretty clear to me that something on your system is blocking access to external sites (ReCaptcha, ORCiD) beyond OJS’s control.
One other thing to try is ensuring that the Guzzle client you have installed is the same version as the one shipped with OJS. (Look in lib/pkp/composer.lock to find the exact version included in OJS.)
Beyond that, you could inspect lib/pkp/classes/form/validation/FormValidatorReCaptcha.php, where the ReCaptcha interaction is implemented, to try to determine what isn’t working in that specific case. You could try enabling the debug option to Guzzle in lib/pkp/classes/core/PKPApplication.php in the getHttpClient function.
Unfortunately it’s just about impossible to debug a situation like this remotely, and I haven’t been able to replicate the behaviour here. The community at large also doesn’t seem to be encountering the same problem, which reinforces my guess that it’s a platform-specific issue on your server.
Thanks,
Alec
hi @asmecher thanks for your reply. We don’t have any reCaptcha issue anymore and recapcatha is working perfectly. The only issue that we are facing is Orcid one. The scripts that you recommended run fine on our server both via web and command line. If server was blocking anything it would have blocked these scripts also.
As mentioned earlier orcid was working fine before we updated ORCID to the latest version. We didn’t implement anything on server. So the only change that came to our OJS sites is after ORCID Update and not server.
I will try to implement scripts with Guzzle version that is being used by OJS and will let you know.
Thanks
Hi @asmecher,
I am trying to upload the ORCID plugin version v1.1.3.13 to the site to determine if the upgrade to ORCID 3.14 is the cause of the issue. I downloaded the source code from the GitHub page: Source code (zip).
What is the best way to upload it manually—should I upload it via the site interface or directly place it in the plugins folder on the server?
when I try to upload .zip file via site plugin upload, it prompts this type of file cannot be uploaded.
Any idea when next orcid plugin update is coming ?
Hi @deepakc,
If you want to upload the ORCiD plugin into the installation tool within OJS, or to install it manually, make sure to use the .tar.gz package from the Releases area. The .zip file is just an archive of the source code, but the .tar.gz packages are run through the plugin build tools, which pull in external dependencies, compile anything needing compiling, etc.
However, OJS doesn’t allow for downgrades, so you’re likely to get an error message if you upload an older version of the plugin. (And as always, be careful about uploading incompatible versions of the plugin into your OJS! Make sure it’s made for the right release of OJS.)
What you’re experiencing with Guzzle doesn’t seem to be typical – I’m not aware of anyone else hitting the same roadblock, and it is quite a widely used plugin. And nobody here has been able to reproduce it, which makes it very difficult to debug. So the best solution would be to see if you can investigate the problem in more depth on your server; otherwise future releases aren’t likely to work any differently.
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher thanks for your help.
Solution - >
Our Server admin implemented some changes which helped to resolve the issue.
Hi @deepakc,
Out of curiosity – do you have some details on what the issue was?
Thanks,
Alec Smecher
Public Knowledge Project Team
