We are currently facing technical issues with the OJS-3.4.0-7 that began this morning. While the portal was functioning normally yesterday, the following problems have been observed today:
Login Issue with Google CAPTCHA
Enabling Google CAPTCHA causes login attempts to fail. However, disabling CAPTCHA allows the login process to proceed successfully.
This looks like either a temporary network outage outside of PKP’s hands, or perhaps your server has added a proxy requirement? I’m not aware of any network or service outages on our end.
Regards,
Alec Smecher
Public Knowledge Project Team
After enabling Google CAPTCHA, the verification works fine (For reference, here is a video that illustrates the issue: Video Example. However, when I click the login/registration button, the process gets stuck without any action or error, and the login attempts fail. When CAPTCHA is disabled, the login proceeds without any issues.
This issue is occurring on both OJS and OMP, which are hosted on the same server.
I’ve verified that the server can ping google.com successfully. However, when trying to ping pkp.sfu.ca, it is not reachable, which might be contributing to the issue.
Your server seems to be firewalled from accessing the PKP server; you’ll need to address that in order for the Plugin Gallery etc. will work. You might be able to work around the login problem by turning off show_upgrade_warning in config.inc.php, but that won’t fix everything.
Regards,
Alec Smecher
Public Knowledge Project Team
I have conducted further checks and noticed that the Journal/Press Settings/ Administration page is either not loading or taking an unusually long time to access. Additionally, the Plugin page, which connects to pkp.sfu.ca, is also not functioning properly.
These issues started suddenly two days ago, and I suspect there might have been changes in the firewall settings or other restrictions imposed by the server provider.
I will contact the server provider to investigate and address the matter.
I have checked and found that some functionality restored after reporting/discussing with server provider. I think the firewall/port (port 80 and port 443) was blocked due to which error was generated hence not able to connect with the external links.
But the PKP website is still showing the error on port 443 whereas its working/connecting with port 80. However, website Administration, plugin gallery still not loading or taking more time. below are the error log of PHP and command prompt testing.
PHP error log:
Failed to retrieve the latest version info: cURL error 28: Operation timed out after 150001 milliseconds with 0 out of 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://pkp.sfu.ca/ojs/xml/ojs-version.xml?id=540ac7edb7229&oai=https%3A%2F%2Fepubs.icar.org.in%2Findex.php%2Findex%2Foai
Port 443 not connected:
curl -v https://pkp.sfu.ca
* About to connect() to pkp.sfu.ca port 443 (#0)
* Trying 208.70.244.23...
* Connected to pkp.sfu.ca (208.70.244.23) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Operation timed out after 300802 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 300802 milliseconds with 0 out of 0 bytes received
Port 80 connected:
curl -v pkp.sfu.ca
* About to connect() to pkp.sfu.ca port 80 (#0)
* Trying 208.70.244.23...
* Connected to pkp.sfu.ca (208.70.244.23) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: pkp.sfu.ca
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Mon, 16 Dec 2024 13:58:20 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://pkp.sfu.ca/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host pkp.sfu.ca left intact
Crossref port 443 connected:
curl -v https://crossref.org
* About to connect() to crossref.org port 443 (#0)
* Trying 208.254.38.78...
* Connected to crossref.org (208.254.38.78) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.crossref.org
* start date: Dec 11 08:39:57 2024 GMT
* expire date: Mar 11 08:39:56 2025 GMT
* common name: *.crossref.org
* issuer: CN=R11,O=Let's Encrypt,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: crossref.org
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< date: Mon, 16 Dec 2024 13:59:05 GMT
< content-type: text/html
< content-length: 169
< server: nginx/1.27.3
< location: https://www.crossref.org/
< permissions-policy: interest-cohort=()
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.27.3</center>
</body>
</html>
* Connection #0 to host crossref.org left intact
When pinging (pkp.sfu.ca) the URL, we encounter a “Request Timed Out” error (see the attached screenshot for reference). We have tried with multiple network.
After thorough discussions with our server provider and an internal review of the firewall settings, we have confirmed that the firewall is configured to allow access on port 443 for all traffic. While port 80 is functioning correctly, the specific URL https://pkp.sfu.ca/ is not establishing a connection through application requests on port 443.
Our server provider has suggested verifying the following with the team managing pkp.sfu.ca:
IP Blocking: Is our server’s IP address inadvertently blocked?
Access Allowance: Is there a need to explicitly allow our IP (103.111.37.34) address for access?
We kindly request your assistance in reviewing this matter and confirming if any actions are required on your end to resolve this issue.
The PKP network configuration doesn’t appear to respond to ping messages (that’s a common enough firewall setup), but your test with curl -v https://pkp.sfu.ca should get a response.
The fact that it stopped working at the moment your host changed its firewall configuration strongly suggests that there’s still a problem there. We don’t require any explicit IP allowances, and I’ve never seen us firewall a legitimate OJS user before. But I’ll check with the PKP network team just in case.
Regards,
Alec Smecher
Public Knowledge Project Team
