When I try to select an issue to schedule an article for publication, I get the now-familiar “The requested URL was not recognized” error. The URL returning the 403 is:
I’m wondering if that /osotl/ in the endpoint is the problem. The api directory is just in the root of the installation, as you’d expect. On the server, the website is contained within a directory called osotl.org (as determined by the hosting company).
I’ve been using Firefox for this, which is where I see the 403. In Chrome, the developer tools show a 404:
/osotl/api/v1/submissions/13/publications/13
{error: "api.404.endpointNotFound", errorMessage: "The requested URL was not recognized."}
error: "api.404.endpointNotFound"
errorMessage: "The requested URL was not recognized."
However, the URL, when pasted into a browser, does work, and connects to the end point.
I’m pretty exasperated here - we can’t publish an issue.
I’m afraid you’re going to have to figure out how to get disable_path_info turned Off with the help of your host at some point. There are parts of the system that have never worked within spec when using disable_path_info, like the OAI-PMH interface (and this is beyond our control). There will be negative effects when your site is indexed by search engines like Google. Eventually we’re going to swap out the routing part of the software with something standard like Laravel’s router infrastructure. All of this is pointing towards support for that setting being removed; the disable_path_info setting should be considered deprecated and avoided.
When we first introduced disable_path_info it was because commodity web hosts often didn’t support our preferred URL scheme, which depends on the CGI PATH_INFO variable working properly. In recent years the number of hosts we observer with that configuration have dropped to near zero. I know that’s not what you wanted to hear, but I hope it provides something you can use to lean on your host to fix their configuration.
(Here is a similar discussion of your host and troubles running Moodle, with a suggested work-around that might allow you to get disable_path_info disabled with a few code changes.)
Thanks,
Alec Smecher
Public Knowledge Project Team
Just in case someone else comes looking for a solution, I tried swapping out all references to PATH_INFO to ORIG_PATH_INFO but I get the same ‘URL not recognized’ message when I try to select an issue for publication, plus some more such messages in other places (e.g. the main Submissions page)
Interestingly, the endpoint being generated was exactly the same:
For reference, here are the locations where I changed the PATH_INFO variable (on the server - this screenshot shows the local copy of OJS I used to locate instances of PATH_INFO):
I am now reverting back to using PATH_INFO so other parts of the site aren’t broken.
The change from PATH_INFO to ORIG_PATH_INFO is intended to facilitate/fix turning off the disable_path_info setting; if you leave disable_path_info turned On then you won’t see any difference as the PATH_INFO and/or ORIG_PATH_INFO variables won’t be used.
Regards,
Alec Smecher
Public Knowledge Project Team
However, if you’re following a link that was generated with disable_path_info turned On, it’s no surprise that it’ll result in a 404. Can you navigate your site from the root URL (https://osotl.org) with disable_path_info turned Off?
Regards,
Alec Smecher
Public Knowledge Project Team
Sorry for the slow response @asmecher - I will check this tomorrow. What I meant above was that after I had swapped out all the PATH_INFO references and set disable_path_info to Off, I got a 404 across the whole site, so I couldn’t see the new endpoint or anything else, and quickly reverted back to On with the PATH_INFO references restored. So, probably something else isn’t quite right in my set-up.
Replaced all instances of PATH_INFO with ORIG_PATH_INFO and set disable_path_info to Off again, and get a flat 404 across the whole site:
Maybe there are other settings (base_url?) I need to change, or (more likely) there’s something else broken in my installation. Obviously, having IONOS hosting is the root of the problem…
If I leave all the ORIG_PATH_INFO instances in place and go back to disable_path_info = On, the site keeps running (no 404s) but we get a ‘URL not recognized’ message on the Submissions page/dashboard. The web developer console suggests these are getting 403s:
That probably doesn’t help, but interesting to note that we don’t get that error if we are using PATH_INFO, and the endpoints are reached successfully.
