OJS2 on Infinity Free (403 ajax problem)

Username (e.g. epiz_XXX) or Website URL

epiz_26016487

Error Message

I am getting 403 for PUT requests to my site’s API while other requests seem to work (i am trying to mount an Open Journal System, a PHP project for journal publishing which uses AJAX calls to its own API, so i guess the problem is not CORS), are you aware of security policy that could be blocking me?

Far from an expert on HTTP so forgive me if i suggest an improbable cause but could NGINX be shaving part of the header and/or bluntly rejecting my request before it reaches the application?

In any case, is there a way to check the logs to see if there was an error at the PHP application level?

General

  1. Request URL: http://siglo18-test.rf.gd/index.php/larevista/api/v1/contexts/4
  2. Request Method: PUT
  3. Status Code: 403 Forbidden
  4. Remote Address: 185.27.134.130:80
  5. Referrer Policy: no-referrer-when-downgrade

Response headers

  1. Cache-Control: public, proxy-revalidate, public, proxy-revalidate
  2. Connection: keep-alive
  3. Content-Encoding: gzip
  4. Content-Type: text/html
  5. Date: Mon, 22 Jun 2020 04:14:39 GMT
  6. Last-Modified: Mon, 22 Jun 2020 03:49:34 GMT
  7. Server: nginx
  8. Transfer-Encoding: chunked
  9. Vary: Accept-Encoding

Console output:

jquery.min.js?v=3.2.0.3:formatted:3857 PUT http://siglo18-test.rf.gd/index.php/larevista/api/v1/contexts/4 403 (Forbidden)

Other Information

This is the home of the project: pkp.sfu.ca/ojs

Also, are you aware of any succesful OJS implementations i could take as example and/or any reason why it should not be compatible?

Thanks in advance!

Hello there,

Ajax requests (CORS) from other websites are not supported here, these external ajax requests are blocked by the security system. Only Ajax requests under your domain will work.

Please refer to this Knowledge Base article for more information regarding the security system and what kind of stuffs it blocks:

1 Like

Hello!

Thanks for your reply, however, my domain is http://siglo18-test.rf.gd so AJAX requests to http://siglo18-test.rf.gd/index.php/larevista/api/v1/contexts/4 should be allowed right?

While I’m not sure this seems to be the problem.

Here’s a quote from the KB article I provided you above:
Which features are not supported?

Because of this security system, the following things will not work correctly or at all on websites on free hosting.

  • API access to websites (like WordPress XML-RPC).
  • AJAX requests from other websites (CORS). AJAX requests are only possible on the same (sub)domain.

And this is the error you encountered meaning it is probably blocked by the security system.

Which errors can I expect?

When trying to access your website with an unsupported client, you may see one of the following errors:

  • 403 Forbidden
1 Like

Hi there! As far as i know, you can if the requests are around the same domain.

Thank you for your replies, indeed, i don´t think its CORS related because some AJAX request do work. I have been browsing the OJS forums and saw that sometimes this can be caused by a triggering of mod_security, so i was wandering if i could see the apache logs and/or there it was possible to disable mod_security altogether? Not sure if i can do this myself or if i need to talk to an admin.

Thanks in advance!

1 Like

As far as I know, this should just work. AJAX on the same domain shouldn’t be an issue, and as far as I know, we don’t run mod_security on free hosting (the browser validation sufficiently protects against attacks and has fewer false positives).

I tried to open the page myself, and I get a 403 error with this JSON response:

{"error":"user.authorization.accessDenied","errorMessage":"##user.authorization.accessDenied##"}

But that might just be because I’m not logged in. Can you check in your browser’s network tab what the actual content of the response on that URL is? Because the 403 response could be generated by your website code.

3 Likes

Thanks for confirming it @Admin!

After searching for help in the official OJS forums (forum.pkp.sfu.ca) it turned out that is an NGINX configuration issue which can be worked around by replacing PUT requests with POST requests but with the “X-Http-Method-Override”: “PUT” header.

I got guidance on how to modify the application code in order to apply this and now it seems to be working!

Thank you all!

Thank you!

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.