##api.submissions.unknownError## ( 3.1.1.2, restful_urls = Off, PHP=5.6.38 )

Yes, I only saw this with the submissions list as well.

hmmmm

Did you discover any differences in server set ups from the one where you has the errors and the one they disappeared on…??

Not really. It took a whole month for them to answer me if they have mod_security enabled so debugging the problem was very difficult.

I do have phpinfo output of their php settings stored. But can not see anything out of the ordinary there. I mean the new server where OJS worked without a problem was almost identical in that regard. Of course phpinfo does not show everything.

:roll_eyes:

Well, I’ll let you know if I get anything sensible out of my server people…

Thanks for your help, and if any ideas occur… let me know!

ping also @asmecher if you have good ideas about this. This could potentially be a big problem when OJS starts to use the API more.

Hi all,

I’d be interested in more details if someone has them. On my own installs I see client-side API errors if I click away too fast (i.e. the JS operations are interrupted and the client is warned even though they probably did the interrupting themselves); this warning should be inhibited but I don’t think it’s what we’re seeing in this report. The unexplained 5xx errors are generally mod_security problems and I’m not sure that’s been eliminated here as a cause yet.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi,

The first thing I did with the problematic server was check mod_security. At least according to the service provider that was not it. Not sure about the other case here. The fast clicking is not it either. I tried loading the actual API call in a separate window when debugging this.

Also note that the API occasionally worked which seems to happen with the other case as well. This of course does not sound like mod_security, but @SKP should definitely check that in any case.

Hi all,

Thanks, @ajnyga – I’m trying (and failing) to navigate a long thread and it looks like that element was already addressed.

@SKP, is this something you’d be open to letting me see directly? If so, please send me a private message with temporary credentials that demonstrate the problem.

Thanks,
Alec Smecher
Public Knowledge Project Team

I may still have access to the problematic server. The production site has moved to a new location and new domain, but the old site is still there just protected with htaccess. Of course I need to ask permission to look at it and do testing.

Hi Alec,

Yes, I’d definitely be happy to let you examine the issue directly.

It’s still occuring and I’ve just been ‘living with it’ for the moment while getting on with other stuff.

I’ll create a user ID for you and message you with it. If you need access to the server itself that can also be arranged.

I didn’t get a wildly helpful response from my host about the 503 errors. but then I didn’t directly mention mod_security. Can you clarify exactly what this is, so I can pin them down on it?

Thanks!
@asmecher @ajnyga

if it is mod_security related, then they should have a log where the errors are visible. Usually some part of the calling url or submitted values contain strings that are thought to be malicious. I have seen a few cases on the forums.

But if it only happens occasionally, then it might not be it. But you could send them an example url that is returning the error and ask if the calls from that url are being blocked by mod_security. Basically anything with the api path in it.

So simply ask if calls from

https://acmejournal.org/index.php/ACME/submissions

are being blocked?

If anything is blocked by mod_security they should have that in a log. But you could ask if they see url’s like https://acmejournal.org/index.php/ACME/api/v1/submissions?status=1&assignedTo=-1&searchPhrase=&count=20&offset=0&=1538047936724 there.

:+1:

I’ll raise a ticket and give that a go.

Cheers.

Hi all,

@SKP, this appears to be some kind of filter or limit on your server that’s outside of OJS. I can query some API endpoints successfully (I’ll PM you the details) but others return a 503 error. The 503 is not something that OJS returns – it’s coming from something else in your server stack, I’m afraid.

Interventions like this should be logged, but I couldn’t recommend where to look, as it depends on your server’s configuration.

Thanks,
Alec Smecher
Public Knowledge Project Team

Good evening

@asmecher @ajnyga

thanks for your help.

Initial response from my host is not looking v. helpful (see below)

I think I’m right to say that noted errors are ‘cosmetic’ and they are wide of the mark regarding the api issue?

I shall follow up with the host with the info from asmecher.

Cheers

Hi Sean,

On checking the logs I could see the below errors logs:

=================
[17-Oct-2018 11:58:39 UTC] PHP Strict Standards: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /home/seanking/public_html/acmejournal.org/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 386
[17-Oct-2018 11:58:40 UTC] PHP Strict Standards: Declaration of ArticleHandler::initialize() should be compatible with PKPHandler::initialize($request) in /home/seanking/public_html/acmejournal.org/pages/article/ArticleHandler.inc.php on line 395
[17-Oct-2018 11:58:40 UTC] PHP Strict Standards: Declaration of SubmissionFileDAO::fromRow() should be compatible with PKPSubmissionFileDAO::fromRow($row, $fileImplementation) in /home/seanking/public_html/acmejournal.org/classes/article/SubmissionFileDAO.inc.php on line 23
[17-Oct-2018 11:58:40 UTC] PHP Strict Standards: Declaration of SubmissionKeywordEntryDAO::getByControlledVocabId() should be compatible with ControlledVocabEntryDAO::getByControlledVocabId($controlledVocabId, $rangeInfo = NULL, $filter = NULL) in /home/seanking/public_html/acmejournal.org/lib/pkp/classes/submission/SubmissionKeywordEntryDAO.inc.php on line 20
[17-Oct-2018 11:58:40 UTC] PHP Deprecated: Non-static method Config::getContextBaseUrls() should not be called statically, assuming $this from incompatible context in /home/seanking/public_html/acmejournal.org/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 199

If you are using the third party content management systems, there are chances for you to use the ‘Plugin, Components & themes’ in it. You need to disable all of them and reactivate one by one until you find the bad/ not compatible plugin or theme.

The strict standard and deprecated errors should not affect this. You can ask them to disable those error types or it could be that you can do it by yourself using an htaccess file or settings in cPanel (if you have one).

Did they say anything about mod_security?

edit: oh, I missed Alec’s post above. I also think that this is not mod_security, but good to rule that out anyway.

Thanks again for tips.

They entirely ignored my question on mod_security…

sigh

I shall press them.