Failed Ajax request or invalid JSON returned (has been blocked by CORS policy). No message in php log files

dung · October 21, 2022, 10:24pm

Describe the issue or problem

I got an error message instead of a list of users after clicking on “users” link. Note that this issue will only be happening with our custom domain names on a multi journals hosting OJS environment

Steps I took leading up to the issue

I’ve listed the steps below for how I access the Users (“users” link) of a journal within the Administration side of our site with the ojsadmin account.

Steps:

Log in with ojsadmin account
On any public homepage of a journal or our Journal Hosting site, access the Administration page by hovering over the ojsadmin user name in the upper-right hand corner. Select Administration from the 4 options.
Under Site Management, select Hosted Journals
Scroll to the relevant journal – in this case CDM – and click on the blue arrow to open the options
Select Users from the 4 options listed below the journal title.
Once selected a User pop-up will partially appear, but an error message will also pop-up (Failed Ajax request or invalid JSON returned)

! Usually a list of users of the journal would appear.

Let me know if you have any questions about this or would like any help resolving this.

Thank you,

What application are you using?

OJS 3.3.0-8

Additional information

I am almost certain the issue is with CORS policy being violated but I do not know how to fix. I have tried to write .htaccess with configuration “Header set Access-Control-Allow-Origin “*”” but no luck.

Can you please help out.

Chrome console message:

Access to XMLHttpRequest at ‘https://cdm.ucalgary.ca/$$$call$$$/grid/admin/context/context-grid/users?_=1666389963357’ from origin ‘https://journalhosting.ucalgary.ca’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

Many thanks!

Dung.

jnugent · October 25, 2022, 1:08pm

Hi @Dung

This wouldn’t be because you’ve got a custom domain for a journal and you’re loading the Users grid from the administration area, are you? If so, that’s a known bug:

github.com/pkp/pkp-lib

OJS 3.2 and 3.3: multi-domain, multi-journal installation: journals with custom domain not editable from central Administration menu

opened 09:59AM - 29 Jun 21 UTC

janpieterk

Bug:1:Low

OJS installation (3.2.1.1 or 3.3.0.7) with the base_url set to maindomain.tld an…d journals both on maindomain.tld/path and customdomain.tld. Editing journal on domain customdomain.tld from central Administration menu does not work. **To Reproduce** Steps to reproduce the behavior: 1. login as admin in maindomain.tld 2. login as admin in customdomain.tld 3. go to “Administration” in the left sidebar. This is always hosted from maindomain.tld 4. go to “Hosted Journals” 5. click on “Edit” for journal abc (which uses customdomain.tld) 6. click “Save” 7. This fires OPTIONS and PUT requests to customdomain.tld 8. observe HTTP 403 with response body `{"error":"form.csrfInvalid","errorMessage":"The form could not be submitted. You may have been logged out. Please reload the page and try again."}` Note that all CORS-headers are correctly sent! See Apache config below. There are no complaints about missing or duplicate Access-Control-Allow-Origin headers or the like. I dived into the OJS code and found this in lib/pkp/classes/security/authorization/internal/ApiCsrfMiddleware.inc.php: ``` $session = Application::get()->getRequest()->getSession(); return $session && $session->getCSRFToken() === $server['HTTP_X_CSRF_TOKEN']; ``` And this seems to be the source of the 403. It turns out that the HTTP_X_CSRF_TOKEN which is sent from maindomain.tld is different from the $session->getCSRFToken() which belongs to the login session of customdomain.tld. This leads me to believe that using the Administration menu (which is always from maindomain.tld) will never work for journals which use a custom domain. Does this look correct, or am I missing something? **What application are you using?** OJS 3.2.1.1 OJS 3.3.0.7 **Additional information** Configuration: config.inc.php: ``` base_url = "https://maindomain.tld" base_url[index] = https://maindomain.tld/index base_url[abc] = https://customdomain.tld base_url[def] = https://maindomain.tld/def restful_urls = On ``` Apache configuration, maindomain.tld.conf: ``` RewriteEngine On RewriteBase / RewriteRule ^api/v1(.*)$ /index.php/api/v1$1 [L,R=307] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ /index.php/$1 [QSA,L] ``` Apache configuration, customdomain.tld.conf ``` Header unset Access-Control-Allow-Origin Header unset Access-Control-Allow-Headers Header unset Access-Control-Allow-Methods Header always set Access-Control-Allow-Origin "*" Header always set Access-Control-Allow-Headers "Content-Type, X-Csrf-Token, X-Http-Method-Override" Header always set Access-Control-Allow-Methods "HEAD, POST, GET, OPTIONS, PUT, DELETE" RewriteEngine On RewriteBase / RewriteCond %{REQUEST_METHOD} !OPTIONS RewriteRule ^api/v1(.*)$ /index.php/abc/api/v1$1 [L,R=307] RewriteCond %{REQUEST_METHOD} OPTIONS RewriteRule ^(.*)$ $1 [L,R=200] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ /index.php/abc/$1 [QSA,L] ``` Possibly related issues: https://github.com/pkp/pkp-lib/issues/5972 https://github.com/pkp/pkp-lib/issues/4595

Best
Jason

dung · October 25, 2022, 2:59pm

Good Morning @jnugent ,

Thank you for your reply, it helps giving me direction of what to do with this issue. To answer your question:

Yes, we access Users grid of a custom domain from OJS Administration / Hosted Journals as seen below

This error message does not happen, in other word it works on our Dev server where we do not use custom domain (Users grid will load after Ajax call). The Dev env has same code version and same database, as expected it has different configuration for base_url due to not using custom domains. Can you help explaining why it works on none custom domains dev server (we have about 4 custom domains)?
As suggested in the post/link you gave above I tried to resolve CORS error by putting in our Virtual Host apache config section this line: (Header set Access-Control-Allow-Origin “*”) I now got this error message: “The current role does not have access to this operation.”

This error message from my understanding is the same bug that you pointed out here.

If you think it makes sense all what I mentioned here and it is a bug then yes I will have no problem looking forward to upgrade from our current 3.3.0-8 to OJS current 3.3.0-12.

Let me know your thoughts. Thank you again so much!

Dung.

jnugent · October 25, 2022, 3:14pm

Hi @dung

I’m pretty sure this bug is not yet fixed in OJS 3.3 so upgrading to 3.3.0.12 will not solve it for you. I can still duplicate the problem in 3.3.0.13 (which is current - you should upgrade anyway, for the security issues fixed there).

There may be other things causing the problem - The users grid in the administration area, when editing a journal, will try to fetch that grid using the custom URL for the journal in question. If you’re not logged into that journal you won’t have a session cookie set and you’ll get a JSON error.

Best
Jason